--On Tuesday, February 11, 2025 6:47 AM -0500 Dino Edwards dino.edwards@mydirectmail.net wrote:

...

Trying to get pass-through authentication working however, I'm running to the following error in OpenLDAP:

...

Is the system it supposed to auth against another ldap server? If so I

would recommend slapo-remoteauth instead:

Hi, thanks for replying.

Yes the plan is to auth against AD. I didn't even know about remoteauth which looks much simpler to implement. The problem I'm facing is that I'm attempting to utilize the bitnami openldap container to accomplish this and the documentation you pointed to talks about editing the slapd.conf file which the bitnami container does not utilize. Instead it utilizes the dynamic runtime configuration engine for config flexibility which requires a LDIF database instead. I'm not familiar enough with openldap to configure that.

I would suggest you start with a local installation and then adapt the container configuration from there.

But here's an example for cn-config, you'd probably have to adjust for your own environment.

dn: olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRemoteAuthCfg olcOverlay: {6}remoteauth olcRemoteAuthTLS: starttls=yes tls_reqcert=never olcRemoteAuthMapping: default ldaps://ad.example.com:636 olcRemoteAuthDNAttribute: seeAlso olcRemoteAuthDomainAttribute: maildrop olcRemoteAuthDefaultDomain: default olcRemoteAuthDefaultRealm: ldaps://ad.example.com:636 olcRemoteAuthStore: FALSE olcRemoteAuthRetryCount: 3

--Quanah

--On Wednesday, February 12, 2025 6:38 AM -0500 Dino Edwards dino.edwards@mydirectmail.net wrote:

...

But here's an example for cn-config, you'd probably have to adjust for

your own environment.

...

dn: olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRemoteAuthCfg olcOverlay: {6}remoteauth olcRemoteAuthTLS: starttls=yes tls_reqcert=never olcRemoteAuthMapping: default ldaps://ad.example.com:636 olcRemoteAuthDNAttribute: seeAlso olcRemoteAuthDomainAttribute: maildrop olcRemoteAuthDefaultDomain: default olcRemoteAuthDefaultRealm: ldaps://ad.example.com:636 olcRemoteAuthStore: FALSE olcRemoteAuthRetryCount: 3

I tried loading the example below as a remoteauth.ldif file but I got the following errors. Guessing the DN is wrong here?

67ac865a.098ae3bb 0x7eff0a2166c0 connection_input: conn=1005 deferring operation: binding 67ac865a.098c174e 0x7eff0aa176c0 conn=1005 op=1 ADD dn="olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config" 67ac865a.098cea57 0x7eff0aa176c0 conn=1005 op=1 RESULT tag=105 err=21 qtime=0.000066 etime=0.000133 text=objectClass: value #1 invalid per syntax ldap_add: Invalid syntax (21) additional info: objectClass: value #1 invalid per syntax 67ac865a.098d6d29 0x7eff0a2166c0 conn=1005 op=2 UNBIND adding new entry "olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config"

As I said, you'll need to adjust for your environment. You also will likley need to moduleload the remoteauth overlay.

--Quanah

I cannot figure out how to get remoteauth to work. I would appreciate some help. I'm trying to use remoteauth against an AD domain. Using the docs and the examples, this is the config that I have but it's not authenticating to the AD domain:

remoteauth.ldif

dn: cn=module{2},cn=config objectClass: olcModuleList cn: module{1} olcModulePath: /opt/bitnami/openldap/lib/openldap olcModuleLoad: remoteauth.so

dn: olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRemoteAuthCfg olcOverlay: {6}remoteauth olcRemoteAuthDNAttribute: seeAlso olcRemoteAuthDomainAttribute: o olcRemoteAuthDefaultRealm: thedomain olcRemoteAuthMapping: thedomain ldap://dc01.domain.tld:389 olcRemoteAuthTLS: starttls=no tls_reqcert=never olcRemoteAuthRetryCount: 3

This is the remote user config in openldap:

dn: cn=username@domain.tld,ou=users,dc=localdomain,dc=local objectClass: inetOrgPerson cn: username@domain.tld sn: Smoe displayName: Joe Smoe givenName: Joe mail: username@domain.tld o: thedomain:username seeAlso: cn=Joe Smoe,ou=Openldap Users,dc=deeztek,dc=com uid: username@domain.tld userPassword::

Thanks

Thanks

olcRemoteAuthTLS: starttls=no tls_reqcert=never

AD pretty much always requires TLS, but you've turned it off entirely. I

would expect this to fail.

You either need to use ldaps:// + port 636 & starttls=no

OR

ldap:// + port 389

and starttls=yes

Actually, it this particular case your assumption is incorrect. I setup another application to authentication to this particular domain controller without TLS with ldap://dc01.remotedomain.tld:389 and it authenticates with no problem. I will eventually configure TLS but I'm just trying to keep it simple for now until I get this working.

Let's say I have this scenario:

Local username: local.user Local Openldap: localdomain.local Remote User: remote.user Remote AD controller: dc01.remotedomain.tld Remote AD Domain name: remotedomain RemoteAuthDomainAttribute: o (Organization)

This is the config I'm using in remoteauth.ldif:

dn: cn=module{2},cn=config objectClass: olcModuleList cn: module{1} olcModulePath: /opt/bitnami/openldap/lib/openldap olcModuleLoad: remoteauth.so

dn: olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRemoteAuthCfg olcOverlay: {6}remoteauth olcRemoteAuthDNAttribute: seeAlso olcRemoteAuthDomainAttribute: o olcRemoteAuthDefaultRealm: remotedomain olcRemoteAuthMapping: remotedomain ldap://dc01.remotedomain.tld:389 olcRemoteAuthTLS: starttls=no tls_reqcert=never olcRemoteAuthRetryCount: 3

This is the remote user config in openldap:

dn: cn=local.user,ou=users,dc=localdomain,dc=local objectClass: inetOrgPerson cn: local.user sn: User displayName: Local User givenName: Local mail: luser@somedomain.tld o: remotedomain:remote.user seeAlso: cn=Remote user,ou=Users,dc=remotedomain,dc=tld uid: local.user userPassword::

This config is not working. Authhentication fails with the following logs. Please note there is not a single entry for the remote domain which I assume it means that openldap is not even attempting to reach the remote domain controller:

.28ab4b96 0x7fe6abfff6c0 conn=1001 op=1 SRCH attr=uid mail displayName 67b738e8.28ac875d 0x7fe6abfff6c0 conn=1001 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000016 etime=0.000161 nentries=1 tex 67b738e8.28b3d836 0x7fe6b0c756c0 conn=1002 fd=13 ACCEPT from IP=172.16.32.1:40524 (IP=0.0.0.0:1389) 67b738e8.28b6ddb4 0x7fe6abfff6c0 conn=1002 op=0 BIND dn="cn=local.user,ou=users,dc=localdomain,dc=local" m 67b738e8.28b7c4b3 0x7fe6abfff6c0 conn=1002 op=0 RESULT tag=97 err=49 qtime=0.000028 etime=0.000106 text= 67b738e8.28bd54b7 0x7fe6b0c756c0 conn=1002 fd=13 closed (connection lost) 67b738e8.28bdf386 0x7fe6abfff6c0 conn=1001 fd=12 closed (connection lost) 67b738f7.218e694d 0x7fe6b0c756c0 conn=1003 fd=12 ACCEPT from IP=172.16.32.1:36998 (IP=0.0.0.0:1389) 67b738f7.218f04b4 0x7fe6abfff6c0 conn=1003 op=0 BIND dn="cn=ldap-admin,dc=localdomain,dc=local" method=128 67b738f7.218f6645 0x7fe6abfff6c0 conn=1003 op=0 BIND dn="cn=ldap-admin,dc=localdomain,dc=local" mech=SIMPLE bind_ssf=0 67b738f7.218fd3a9 0x7fe6abfff6c0 conn=1003 op=0 RESULT tag=97 err=0 qtime=0.000008 etime=0.000077 text= 67b738f7.21933140 0x7fe6b0c756c0 conn=1003 op=1 SRCH base="ou=users,dc=localdomain,dc=local" scope=2 deref=0 filter="(&(uid=dds)(objectClass=inetOrgPerson))" 67b738f7.21936655 0x7fe6b0c756c0 conn=1003 op=1 SRCH attr=uid mail displayName 67b738f7.21943fac 0x7fe6b0c756c0 conn=1003 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000008 etime=0.000098 nentries=0 tex 67b738f7.2196cf66 0x7fe6abfff6c0 conn=1003 fd=12 closed (connection lost)

Thanks

It won't work as explicitly stated in the manual page: "If the userPassword is present, authentication is performed locally"

The userPassword field is absolutely empty. I don't know why it shows the ":" column there, but Apache Directory Studio is showing "Empty password" in the userPassword attribute.

* You probably need to delete the userPassword attribute?

That was a good idea actually, but sadly it didn’t work either. Same behavior as before. There is absolutely no indication it’s trying to perform remote authentication.

It won't work as explicitly stated in the manual page: > "If the userPassword is present, authentication is performed locally" The userPassword field is absolutely empty. I don't know why it shows the ": " column there, but Apache Directory

--On Thursday, February 27, 2025 6:10 PM +0000 Bradley T Gill bgill@aep.com wrote:

I haven't worked with the integrated remote auth yet, I still use SASL.. It is something that we have on the backburner to migrate to, if it works anything like SASL, you need a userPassword that had a directive, like {SASL}user@domain But that is because it's hijacking the HASHing process, form what I understand. If you have a link to the docs, I'll take a look and see what I can find..

That's not how remoteauth works, and the documentation for the overlay is literally on the website (via the man page function) and distributed as a man page with the software.

--Quanah

You probably need to delete the userPassword attribute?

This is correct.

Finally got it working. Thanks for all the help!

I was able to piece the solution together. As previously mentioned most guidance out there focused on configuring it with slapd.conf, however in my case I was trying to use the Bitnami openldap container which does not use a slapd.conf but instead uses dynamic runtime configuration which complicated matters. Here's the config that works for pass-through remoteauth authentication as well as utilizing argon2 password hashing leveraging the bitnami openldap container for anyone that may find themselves in this nightmare in the future:

docker-compose.yml:

openldap: image: bitnami/openldap:latest container_name: openldap_app ports: - '1389:1389' - '1636:1636' environment: - LDAP_ROOT=dc=local-openldap-domain,dc=local - LDAP_ADMIN_USERNAME=ldap-admin - LDAP_ADMIN_PASSWORD=ldap_admin_password - LDAP_USERS=some-ldap-user - LDAP_PASSWORDS=some_ldap_user_password - LDAP_EXTRA_SCHEMAS=cosine,inetorgperson,nis,argon2,remoteauth - BITNAMI_DEBUG=true - LDAP_LOG_LEVEL=1 networks: openldap_net_ext: ipv4_address: 172.16.xxx.xxx volumes: - openldap_data:/bitnami/openldap - ./schema-argon2.ldif:/opt/bitnami/openldap/etc/schema/schema-argon2.ldif - ./schema-remoteauth.ldif:/opt/bitnami/openldap/etc/schema/schema-remoteauth. ldif - ./custom-argon2.ldif:/custom/custom-argon2.ldif - ./custom-remoteauth.ldif:/custom/custom-remoteauth.ldif

schema-argon2.ldif:

dn: cn=module{1},cn=config objectClass: olcModuleList cn: module{1} olcModulePath: /opt/bitnami/openldap/lib/openldap olcModuleLoad: argon2.so

schema-remoteauth.ldif:

dn: cn=module{2},cn=config objectClass: olcModuleList cn: module{1} olcModulePath: /opt/bitnami/openldap/lib/openldap olcModuleLoad: remoteauth.so

custom-argon2.ldif:

dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcPasswordHash olcPasswordHash: {ARGON2}

custom-remoteauth.ldif:

dn: olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRemoteAuthCfg olcOverlay: {6}remoteauth olcRemoteAuthDNAttribute: seeAlso olcRemoteAuthDomainAttribute: associatedDomain olcRemoteAuthDefaultDomain: ad-domain olcRemoteAuthMapping: ad-domain dc01.ad-domain.tld olcRemoteAuthTLS: starttls=no tls_reqcert=never olcRemoteAuthRetryCount: 3

Once the container is up, add the custom-argon2.ldif and the custom-remoteauth.ldif files as follows:

docker exec openldap_app ldapadd -H ldapi:/// -Y EXTERNAL -f /custom/argon2.ldif docker exec openldap_app ldapadd -H ldapi:/// -Y EXTERNAL -f /custom/remoteauth.ldif

For a remoteauth user use the following attributes in to create a user in openldap where seeAlso is the DN of the user in the remote AD domain. I'm guessing it should work with just the username on the remote domain:

dn: cn=jsmoe,ou=users,dc=local-openldap-domain,dc=local objectClass: domainRelatedObject objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top associatedDomain: ad-domain cn: jsmoe sn: Smoe displayName: Joe Smoe givenName: Joe mail: jsmoe@domain.tld seeAlso: cn=Joe Smoe,ou=Users,dc=ad-domain,dc=tld uid: jsmoe

For a local openldap user, I use the following attributes to create a user in openldap:

dn: cn=mjane,ou=users,dc=local-openldap-domain,dc=local objectClass: inetOrgPerson cn: mjane sn: Jane displayName: Mary Jane givenName: Mary mail: mjane@domain.tld uid: mjane userPassword: {ARGON2}$argon2id$v=19$m=7168,t=5,p=1$NaoI0qbKSpD5Hle+WhfncQ$HIWlTiUf02j8+tq Oattpu2Z9tKyPGXG0YxyrxhmFDFs

--On Friday, February 14, 2025 7:01 AM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:

Can you explain the intentions for " olcRemoteAuthTLS: starttls=yes tls_reqcert=never"? Starting TLS without a certificate? Do you expect encryption then?

Just means it doesn't check the cert for validity AFAIK. AD often uses its own cert system so the end client may not be aware of the CA chain for the provided cert on the AD server.

--Quanah