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

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
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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.