On 03/11/14 11:53 -0500, Denis Ahearn wrote:
We have a Rails app that uses OpenLDAP in the local development environment on Mac OS X to authenticate and authorize users (we use Active Directory in production and staging). Up until now all development has been done on Macs running Mountain Lion, and OpenLDAP has worked fine. Recently a new developer joined our team who is using a Mac running Mavericks, however OpenLDAP is behaving differently on his Mac. On Mavericks, OpenLDAP is trying to do something with Kerberos, which is failing. We see the following in the slapd.log on Mavericks:
If you are authenticating against Active Directory, how does slapd fit into the picture?
5319fc2c >>> dnPrettyNormal: <cn=jdoe,ou=people,dc=bluewaterbrand,dc=com> 5319fc2c <<< dnPrettyNormal: <cn=jdoe,ou=people,dc=bluewaterbrand,dc=com>, <cn=jdoe,ou=people,dc=bluewaterbrand,dc=com> 5319fc2c do_bind: version=3 dn="cn=jdoe,ou=people,dc=bluewaterbrand,dc=com" method=128 5319fc2c bdb_dn2entry("cn=jdoe,ou=people,dc=bluewaterbrand,dc=com") 5319fc2c => bdb_search 5319fc2c bdb_dn2entry("cn=kerberoskdc,cn=config,dc=bluewaterbrand,dc=com") 5319fc2c => bdb_dn2id("cn=config,dc=bluewaterbrand,dc=com") 5319fc2c <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) 5319fc2c entry_decode: "dc=bluewaterbrand,dc=com" 5319fc2c <= entry_decode(dc=bluewaterbrand,dc=com) 5319fc2c send_ldap_result: conn=-1 op=0 p=0 5319fc2c Entry *odusers_copy_entry(Operation *): Unable to locate cn=kerberoskdc,cn=config,dc=bluewaterbrand,dc=com (32)
Do you have an authz-regex rule mapping the authentication identity to this? Can you reproduce this problem with ldapsearch/ldapwhoami, using the same parameters as your ruby code?
5319fc2c odusers_copy_krbrealm: No entry associated with KerberosKDC cn=kerberoskdc,cn=config,dc=bluewaterbrand,dc=com 5319fc2c odusers_krb_auth: could not retrieve krb realm while authing jdoe 5319fc2c int odusers_increment_failedlogin(struct berval *): Unable to retrieve description of loginFailedAttempts attribute5319fc2c bdb_bind: Error to increment failed login count for cn=jdoe,ou=people,dc=bluewaterbrand,dc=com5319fc2c send_ldap_result: conn=1003 op=0 p=3
It appears your client has a kerberos ticket, and is attempting GSSAPI authentication. You can verify that with klist or your OS's kerberos utilities.
Here's the same section of slapd.log from a Mac running Mountain Lion, which is working correctly:
531e25c9 >>> dnPrettyNormal: <cn=cjdoe,ou=people,dc=bluewaterbrand,dc=com> 531e25c9 <<< dnPrettyNormal: <cn=cjdoe,ou=people,dc=bluewaterbrand,dc=com>, <cn=cjdoe,ou=people,dc=bluewaterbrand,dc=com> 531e25c9 do_bind: version=3 dn="cn=cjdoe,ou=people,dc=bluewaterbrand,dc=com" method=128 531e25c9 bdb_dn2entry("cn=cjdoe,ou=people,dc=bluewaterbrand,dc=com") 531e25c9 do_bind: v3 bind: "cn=cjdoe,ou=people,dc=bluewaterbrand,dc=com" to "cn=cjdoe,ou=people,dc=bluewaterbrand,dc=com" 531e25c9 send_ldap_result: conn=1003 op=0 p=3 531e25c9 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 14 ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ 531e25c9 connection_get(14): got connid=1003 531e25c9 connection_read(14): checking for input on id=1003 ber_get_next ldap_read: want=8, got=0
We've spent a copule of days looking into this, and can't find any noticeable differences in the ldap.conf and slapd.conf files between Mavericks and Mountain Lion that would explain why Mavericks is doing a search on "cn=kerberoskdc,cn=config,dc=bluewaterbrand,dc=com".
Does anyone know why OpenLDAP on Mavericks is behaving the way that it is, and more importantly, what would be the correct way to resolve this issue? Our Rails app is using the devise and devise_ldap_authenticatable gems to handle user authentication, so it would seem that we don't want OpenLDAP to do anything with Kerberos at all. Can this be controlled via configuration, or is this an issue with how the OpenLDAP shipped with Mavericks was built?
The client side Ruby code may allow you to configure a sasl mechanism. If not, see ldap.conf(5) and set an appropriate LDAPSASL_MECH environment variable or set SASL_MECH within your home .ldaprc file (to, for instance, DIGEST-MD5).