Authenticating users with an OpenLDAP server.

A long chat with Apple support could not resolve this problem. They indicated that nothing has essentially changed between 10.9 and 10.10.5, with respect to how authentication is handled via OpenLDAP.

By turning up the debug level in the opendirectoryd.log, I am able to pinpoint the moment a good and failed login diverge. This is what a successful login looks like in on 10.9.5:

2015-10-01 09:05:18.815216 CDT - 162.870, Node: /LDAPv3/ldap-server.mydomain.org, Module: ldap - Audit - success - Verify password for record type Users 'ajanzen' node '/LDAPv3/ldap-server.mydomain.org'

2015-10-01 09:05:18.815434 CDT - 162.870, Node: /LDAPv3/ldap-server.mydomain.org, Module: ldap - ODRecordVerifyPassword completed

This is the same portion from a Yosemite failed login:

2015-10-01 08:48:22.395387 CDT - AID: 0x0000000000000000 - 231.1733, Node: /LDAPv3/ldap-server.mydomain.org, Module: ldap - Audit - Invalid credentials (5000) - Verify password for record type Users 'ajanzen' node '/LDAPv3/ldap-server.mydomain.org'

2015-10-01 08:48:22.395583 CDT - AID: 0x0000000000000000 - 231.1733, Node: /LDAPv3/ldap-server.mydomain.org, Module: ldap - ODRecordVerifyPassword failed with error 'Invalid credentials' (5000)

Does this help point in the direction of where to look further? I would appreciate any suggestions about where to start digging deeper.

--

Jon

I have this problem resolved.

What I found was the passwords in OpenLDAP were in this format:

{MD5}<base 64 encoded md5 digest><newline character>

The base64 encoder on the Linux server always adds a a newline character (\n) to the end encoding. Multiple platforms have always ignored that character until OS X 10.10.5. Simply removing the newline before inserting the encoded password into the OpenLDAP database allows 10.10.5 and later to authenticate against that password.

--

Jon

This depends on how the password is added to ldap. In my case I was using ruby-ldap library to modify the passwords by passing it a string containing the password. That string contained the newline character after it was converted to digest format, so removing the newline before passing the digest to ldap was what solved it for me.

You are probably creating your passwords and inserting them in some other way. You should try to examine the password string just before it is sent to the ldap library that does the updating. If it contains a newline, you have the same problem and need to truncate the string.

I hope this helps.

--

Jon