0

Using OpenLDAP (2.4.44) on CENTOS 7 and have configured {SASL} pass-thru to another remote LDAP for some users using the userPassword field. This can change (overwrite) to using the local password {CRYPT} - rather than the SASL pass-thru - for various reasons. We have a script that changes this as a admin requested action, i.e from {SASL}user@abc.qwe.com to {CRYPT}skfghdfghdhwsiy (and one the other way from {CRYPT} to {SASL} that has no issue). However have noticed that the script always causes a 'failed' login on the SASL remote LDAP server. We could live with that one failed login, but unfortunately any password changes afterwards (The Openldap local one) for that user also attempt a login via SASL (why?) and after a few goes at this locks out the user on the remote SASL connected LDAP server. The 'admin' user in the script this is NOT RootDN but a special 'admin' user with the ACL permissions to change userPassword for the user in question. Things I have worked out:

  • This is an LDAP issue (not SASL). It is the OpenLDAP calling SASL when {SASL} is not set in userPassword that is the issue.
  • If the RootDN openLDAP user does the {CRYPT} userPassword entry, there is NO issue - So I assume RootDN has some special powers/does not trigger something when updating userPassword?
  • If the 'Admin' user with manage permissions on userPassword does the change, the issues occurs, and continue to have a problem ongoing on all password changes...until
  • There seems to be some point when it stops going (incorrectly) to SASL. A timeout/cache. Not narrowed this down or proven it yet.

Any clues or explanations of how this is working?

Thanks

Ben Shade
  • 1
  • Should also say that don't really want to use RootDN user for this action, which is why we are (trying) to use another specific 'admin' user. – Ben Shade Oct 29 '18 at 13:10

1 Answers1

0

Not sure of the reasons still, but found out that removing (deleting) the userPassword field (as one operation) then setting it (as either {SASL} or {CRYPT} as needed) in a second operation by the 'admin' (not RootDN) user does (correctly) not call the SASL/other LDAP, so no failed passwords on the remote LDAP.

It is the single operation that caused the issue, but no clearer on why this is, but at least have a working solution.

Spent a few days on this before posting! Why is it that you always find 'an answer' just after posting! Thanks

Ben Shade
  • 1