Open polarathene opened 1 year ago
FWIW, the goal is to integrate with the seperate docker-mailserver
container using saslauthd
to connect to the OpenLDAP container in our tests. I believe once this auth issue is resolved within the docker-openldap
container it will work smoothly.
In the meantime, once the above ldapwhoami
/ ldapsearch
commands work, the same running container can install, configure and test saslauthd with the following:
apt-get update && apt-get install sasl2-bin libsasl2-modules libsasl2-modules-ldap nano
nano /etc/saslauthd.conf
saslauthd.conf
:
ldap_servers: ldap://ldap.example.test
ldap_auth_method: bind
ldap_bind_dn: cn=admin,dc=example,dc=test
ldap_bind_pw: adminpassword
ldap_search_base: ou=people,dc=example,dc=test
ldap_filter: (&(userid=%u)(mailEnabled=TRUE))
ldap_start_tls: no
ldap_tls_check_peer: no
ldap_referrals: yes
log_level: 10
# Run the saslauthd daemon with the config and LDAP plugin to auth against ldap:
saslauthd -d -a ldap -O /etc/saslauthd.conf
# In a separate terminal shell, verify everything is working:
testsaslauthd -u john.doe -p secret
I have identified a missing config was required for granting ACL to anonymous
bind for auth (_references: slapd docs for olcAccess
, OpenLDAP docs access 8.2.2
+ 8.4
_).
In the osixia/openldap
image, this was configured via .ldif
here (v1.1.6
), while the current master of that image adds one more ACL rule that is similar to this projects (bitspur/rock8s/docker-openldap
) image ACL (and the upstream bitnami image ACL)
This auth.ldif
should carry that over by appending this rule? I've mounted it into /migrations
. I'm not sure if the admin access is necessary, but could be templated as .tmpl
instead of hard-coding the LDAP_ROOT
.
dn: olcDatabase={2}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: to attrs=userPassword
by self write
by dn="cn=admin,dc=example,dc=test" write
by anonymous auth
by * none
NOTE: My user account .ldif
files also did not need the changetype: add
. I didn't create the original files or setup the original openldap docker image. Those now reside in /ldifs
.
--env LDAP_HASH_PASSWORD='NONE'
has no relevance to the userPassword
value (at least for the .ldif
account files I mount). The README description isn't quite clear to me where that applies. Perhaps it's the fallback if no scheme prefix exists in the stored value?
Verified with ldapwhoami
:
$ ldapwhoami -v -x -H ldap://ldap.example.test -D 'uid=john.doe,ou=people,dc=example,dc=test' -w secret
ldap_initialize( ldap://ldap.example.test:389/??base )
dn:uid=john.doe,ou=people,dc=example,dc=test
Result: Success (0)
# Relevant container log output:
64ddb03c conn=1007 fd=12 ACCEPT from IP=172.17.0.2:42292 (IP=0.0.0.0:389)
64ddb03c conn=1007 op=0 BIND dn="uid=john.doe,ou=people,dc=example,dc=test" method=128
64ddb03c conn=1007 op=0 BIND dn="uid=john.doe,ou=people,dc=example,dc=test" mech=SIMPLE ssf=0
64ddb03c conn=1007 op=0 RESULT tag=97 err=0 text=
64ddb03c conn=1007 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.3
64ddb03c conn=1007 op=1 WHOAMI
64ddb03c conn=1007 op=1 RESULT oid= err=0 text=
64ddb03c conn=1007 op=2 UNBIND
64ddb03c conn=1007 fd=12 closed
Verified with saslauthd setup described in previous comment:
$ testsaslauthd -u john.doe -p secret
0: OK "Success."
# Relevant container log output:
64ddb13a conn=1008 fd=12 ACCEPT from IP=172.17.0.2:41852 (IP=0.0.0.0:389)
64ddb13a conn=1008 op=0 BIND dn="cn=admin,dc=example,dc=test" method=128
64ddb13a conn=1008 op=0 BIND dn="cn=admin,dc=example,dc=test" mech=SIMPLE ssf=0
64ddb13a conn=1008 op=0 RESULT tag=97 err=0 text=
64ddb13a conn=1008 op=1 SRCH base="ou=people,dc=example,dc=test" scope=2 deref=0 filter="(&(uid=john.doe)(mailEnabled=TRUE))"
64ddb13a conn=1008 op=1 SRCH attr=dn
64ddb13a <= mdb_equality_candidates: (uid) not indexed
64ddb13a <= mdb_equality_candidates: (mailEnabled) not indexed
64ddb13a conn=1008 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
64ddb13a conn=1008 op=2 BIND anonymous mech=implicit ssf=0
64ddb13a conn=1008 op=2 BIND dn="uid=john.doe,ou=people,dc=example,dc=test" method=128
64ddb13a conn=1008 op=2 BIND dn="uid=john.doe,ou=people,dc=example,dc=test" mech=SIMPLE ssf=0
64ddb13a conn=1008 op=2 RESULT tag=97 err=0 text=
Here the testsaslauthd
command sends the credentials to the saslauthd
daemon, which connects to LDAP service with admin credentials (simple mechanism) and queries a user (dn
attribute) with the search base and filter from saslauthd.conf
settings. Afterwards it performs an anonymous bind (implicit mechanism?) presumably to retrieve the hashed userPassword
value (granted by anonymous auth
acl), performing auth for the actual user via bind dn (simple mechanism again, like ldapwhoami -x
) which is successful.
If the anonymous auth
acl is dropped, the ldapwhoami
/ ldapsearch
commands likewise fail with "Invalid credentials (49)". Despite the container logs not mentioning any anonymous bind (Bind DN logged with mech=SIMPLE
):
# Failure example when `anonymous auth` acl is not configured:
$ ldapwhoami -v -x -H ldap://ldap.example.test -D 'uid=john.doe,ou=people,dc=example,dc=test' -w secret
ldap_initialize( ldap://ldap.example.test:389/??base )
ldap_bind: Invalid credentials (49)
# Relevant container log output:
64ddb636 conn=1007 fd=12 ACCEPT from IP=172.17.0.2:59398 (IP=0.0.0.0:389)
64ddb636 conn=1007 op=0 BIND dn="uid=john.doe,ou=people,dc=example,dc=test" method=128
64ddb636 conn=1007 op=0 RESULT tag=97 err=49 text=
64ddb636 conn=1007 op=1 UNBIND
64ddb636 conn=1007 fd=12 closed
So the error message of "invalid credentials" was a bit misleading. It seems it was more of a problem retrieving userPassword
due to lack of permissions?
Since I managed to get bitnami/openldap
working and no response to this report, I'm going to stick with that for the time being: https://github.com/docker-mailserver/docker-mailserver/pull/3494
I'll leave this issue open, as the bitnami/openldap
image doesn't need the ACL migration, so that might be an unintended bug on your end, or should document the difference a bit more clearly as to why it was adjusted?
Off-topic: I recently noticed while looking through LDAP issues that you've previously engaged with docker-mailserver
in the past, That was a nice surprise to recognize I had seen your name earlier when I landed here looking for an LDAP image replacement! 😁
@polarathene I actually made this image specifically for my use of docker-mailserver. I used to use osixia/docker-openldap as well.
I have a helm chart for this as well.
https://github.com/clayrisser/charts/tree/main/beta/openldap
Problem
Migrating from an old unmaintained OpenLDAP image
osixia/docker-openldap
, users added via LDIF fail to authenticate with "Invalid credentials (49)".Reproduction
ldapwhoami
andldapsearch
commands within the same running container (docker exec -it ldap-test bash
) are both sufficient at illustrating the problem.Admin user can query the LDIF record successfully:
Where
userPassword
is base64 encoded in the response toc2VjcmV0
(akasecret
).Related log output from the `ldapsearch` command
``` 64dc88f8 conn=1008 fd=12 ACCEPT from IP=172.17.0.2:54138 (IP=0.0.0.0:389) 64dc88f8 conn=1008 op=0 BIND dn="cn=admin,dc=example,dc=test" method=128 64dc88f8 conn=1008 op=0 BIND dn="cn=admin,dc=example,dc=test" mech=SIMPLE ssf=0 64dc88f8 conn=1008 op=0 RESULT tag=97 err=0 text= 64dc88f8 conn=1008 op=1 SRCH base="ou=people,dc=example,dc=test" scope=2 deref=0 filter="(&(uid=john.doe)(mailEnabled=TRUE))" 64dc88f8 <= mdb_equality_candidates: (uid) not indexed 64dc88f8 <= mdb_equality_candidates: (mailEnabled) not indexed 64dc88f8 conn=1008 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= 64dc88f8 conn=1008 op=2 UNBIND 64dc88f8 conn=1008 fd=12 closed ```Whereas the equivalent for the custom user fails with:
docker run
NONE
just to keep it simple. I triedSHA
for a predictable SHA-1 (due to no salt,slappasswd -s secret -h '{SHA}'
always outputs{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=
), but I am unsure why credentials are "invalid"..ldif
files are mounted to/migrations
as your README advises due to usingchangetype
to do so. It doesn't seem to make any difference either way.Log output during startup
``` rm: cannot remove '/opt/bitnami/openldap/ldifs': Permission denied 08:21:29.93 INFO ==> ** Starting LDAP setup ** 08:21:29.95 INFO ==> Validating settings in LDAP_* env vars 08:21:29.95 INFO ==> Initializing OpenLDAP... 08:21:29.95 DEBUG ==> Ensuring expected directories/files exist... 08:21:29.96 INFO ==> Creating LDAP online configuration 08:21:29.96 INFO ==> Creating slapd.ldif 08:21:29.98 INFO ==> Starting OpenLDAP server in background 64dc8709 @(#) $OpenLDAP: slapd 2.4.57+dfsg-3+deb11u1 (May 14 2022 18:32:57) $ Debian OpenLDAP MaintainersRelevant snippet from above log (for the two custom LDIF files)
``` ldapmodify -Y EXTERNAL -H ldapi:/// -f /opt/bitnami/openldap/migrations/01_mail-tree.ldif SASL/EXTERNAL authentication started 64dc870e conn=1002 fd=12 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) 64dc870e conn=1002 op=0 BIND dn="" method=163 64dc870e conn=1002 op=0 BIND authcid="gidNumber=0+uidNumber=1001,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=1001,cn=peercred,cn=external,cn=auth" 64dc870e conn=1002 op=0 BIND dn="gidNumber=0+uidNumber=1001,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 64dc870e conn=1002 op=0 RESULT tag=97 err=0 text= SASL username: gidNumber=0+uidNumber=1001,cn=peercred,cn=external,cn=auth SASL SSF: 0 64dc870e conn=1002 op=1 ADD dn="ou=people,dc=example,dc=test" 64dc870e conn=1002 op=1 RESULT tag=105 err=0 text= 64dc870e conn=1002 op=2 UNBIND adding new entry "ou=people,dc=example,dc=test" 64dc870e conn=1002 fd=12 closed ldapmodify -Y EXTERNAL -H ldapi:/// -f /opt/bitnami/openldap/migrations/02_user-email.ldif SASL/EXTERNAL authentication started 64dc870e conn=1003 fd=12 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) 64dc870e conn=1003 op=0 BIND dn="" method=163 64dc870e conn=1003 op=0 BIND authcid="gidNumber=0+uidNumber=1001,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=1001,cn=peercred,cn=external,cn=auth" 64dc870e conn=1003 op=0 BIND dn="gidNumber=0+uidNumber=1001,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 64dc870e conn=1003 op=0 RESULT tag=97 err=0 text= SASL username: gidNumber=0+uidNumber=1001,cn=peercred,cn=external,cn=auth SASL SSF: 0 64dc870e conn=1003 op=1 ADD dn="uid=john.doe,ou=people,dc=example,dc=test" 64dc870e conn=1003 op=1 RESULT tag=105 err=0 text= 64dc870e conn=1003 op=2 UNBIND 64dc870e conn=1003 fd=12 closed adding new entry "userid=john.doe,ou=people,dc=example,dc=test" ```Custom LDIF
Minimized to the two files below (2nd relies on the
postfix-book.schema
this image already provides). Creates a single mail user account to test against.01_mail-tree.ldif
:02_user-email.ldif
:Background
Over the past two days (no LDAP experience), I've been trying to migrate the
docker-mailserver
LDAP test away from theosixia/docker-openldap
image (we've used an old pinned version from many years ago, the latest just crashes).That image was last maintained 2 years ago, and the bitnami openldap image seems to be one of the only actively maintained ones I came across that seemed suitable. However I ran into some compatibility issues there and my inexperience with LDAP... but this variant image with improvements is almost working, last roadblock is getting created users to successfully authenticate.