Closed lucj closed 8 months ago
Did not work when added to the values yaml either until I set
LDAP_SKIP_DEFAULT_TREE: "yes" Only worked briefly however (adding anything underneath my root DN
Hi , You should not add the admin user (top object) as its already done by the chart and deployment. Event when you skip the tree création the admin user is created as its mandatory (see Troubleshooting section of the readme)
So in your deployment @lucj if you want to add by yourself the top organisation then you should defined it under customLdifFiles
or customLdifCm
of the chart and if you have static ldif to initialize your ldap you should also add them in the chart
Hope that helps
one can't see the admin user in the UI. Apprently if this issue https://github.com/osixia/docker-openldap/issues/555 is correct may be due to outdated phpldapadmin versions being used. Could this be the case? if i recall correctly this chart deploys phpldapadmin 1.2.5
Maybe we should update it in this chart
Hi , You should not add the admin user (top object) as its already done by the chart and deployment. Event when you skip the tree création the admin user is created as its mandatory (see Troubleshooting section of the readme)
So in your deployment @lucj if you want to add by yourself the top organisation then you should defined it under
customLdifFiles
orcustomLdifCm
of the chart and if you have static ldif to initialize your ldap you should also add them in the chartHope that helps
I have now tried to follow the advanced instructions and am getting the same issue This base cannot be created with PLA.
. It seems that the base/top org is not being added somehow.
in phpldapadmin when doing export it lets me select the base but then fails to say nothing exists.
when pasting the root creating into the import function of phpldapadmin I actually get an error stating that it already exists
when I then refresh the base example.de is created but nothing below. so the read only admin is also not created and needs to be added manually afterwards or the ldifs applied.
any way to make that work? existing secrets are part of the umbrella chart so they exist before this chart is applied.
here's the values.yaml for reference
global:
ldapDomain: "example.de"
existingSecret: "ldap-secret"
logLevel: debug
persistence:
enabled: false
env:
LDAP_SKIP_DEFAULT_TREE: "yes"
# make sure dn in the following ACLs fits your domain
customAcls: |-
dn: olcDatabase={2}mdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to *
by dn.exact=gidNumber=0+uidNumber=1001,cn=peercred,cn=external,cn=auth manage
by * break
olcAccess: {1}to attrs=userPassword,shadowLastChange
by self write
by dn="cn=admin,dc=example,dc=de" write
by anonymous auth by * none
olcAccess: {2}to *
by dn="cn=admin-read,dc=example,dc=de" read
by dn="cn=admin,dc=example,dc=de" write
by self read
by * none
customLdifFiles:
00-root.ldif: |-
dn: dc=example,dc=de
dc: example
o: example
objectclass: dcObject
objectclass: organization
01-admin-read-user.ldif: |-
dn: cn=admin-read,dc=example,dc=de
cn: admin-read
objectClass: inetOrgPerson
userPassword:: {SSHA}xxxxxxxxxxxx
sn: Admin read only
02-users-group.ldif: |-
dn: ou=users,dc=example,dc=de
objectclass: organizationalUnit
ou: users
03-groups-group.ldif: |-
dn: ou=groups,dc=example,dc=de
objectclass: organizationalUnit
ou: groups
ltb-passwd: # self service password change web interface
enabled: true
ingress: # we do custom ingress using istio
enabled: false
ldap:
bindDN: "cn=admin-read,dc=example,dc=de" # make sure this is set to correct baseDN
searchBase: "ou=users,dc=example,dc=de" # make sure this is set to correct baseDN
passKey: LDAP_ADMIN_READ_PASSWORD
# check https://github.com/jp-gouin/helm-openldap/tree/master/advanced_examples#use-a-user-with-restricted-permissions-for-password-portal
initContainers:
- name: "install-logo"
image: "{{ tpl .Values.image.repository . }}:{{ tpl .Values.image.tag . }}"
command: [sh, -c]
args:
- |-
cat <<EOF >/data/31-logo
#!/command/with-contenv bash
source /assets/functions/00-container
PROCESS_NAME="logo"
cp /tmp/ltb-logo.png /www/ssp/images/ltb-logo.png
chmod +x /data/31-logo
liftoff
EOF
volumeMounts:
- name: data
mountPath: /data
volumes:
- name: logos
configMap:
name: configmap-ldap-companylogos
- name: data
emptyDir: {}
volumeMounts:
- name: logos
mountPath: /tmp/ltb-logo.png
subPath: my-logo.png
- name: data
mountPath: /etc/cont-init.d/31-logo
subPath: 31-logo
phpldapadmin: # web admin interface to manage ldap
enabled: true
ingress: # we do custom ingress using istio
enabled: false
# check https://github.com/jp-gouin/helm-openldap/tree/master/advanced_examples#use-a-user-with-restricted-permissions-for-password-portal
initContainers:
- name: modify-configuration
image: "{{ tpl .Values.image.repository . }}:{{ tpl .Values.image.tag . }}"
command: [sh, -c]
args:
- |-
# modify startup script in order to use logos
cp -p /container/service/phpldapadmin/startup.sh /data/
sed -i -e 's/exit 0/# exit 0/' /data/startup.sh
cat <<'EOF' >>/data/startup.sh
cp /logos/my-logo.png /var/www/phpldapadmin/htdocs/images/default/logo.png
cp /logos/my-logo_50.png /var/www/phpldapadmin/htdocs/images/default/logo-small.png
exit 0
EOF
volumeMounts:
- mountPath: /data
name: data
volumes:
- name: data
emptyDir: {}
- name: logos
configMap:
name: configmap-ldap-companylogos
volumeMounts:
- name: data
mountPath: /data
- name: logos
mountPath: /logos
- name: data
mountPath: /container/service/phpldapadmin/startup.sh
subPath: startup.sh
Just tried using the advancedconfiguration example exactly as written even reconfiguring ldap values to use dc=mydomain,dc=com but getting the same error where the ldif files seem to not be getting applied at all
seems to be related to #120
Describe the bug
Cannot import a LDIF from phpadmin UI. I'm not sure this is a bug or me doing bad stuff though :)
To Reproduce
Login to openldap via the phpadmin UI, then import the following sample LDIF from the import menu
Expected behavior
Groups and users created
Screenshots
If applicable, add screenshots to help explain your problem.