Attached is the output from running "ldapwhoami -d -1" on the Mac having the issue (i.e. running Mavericks). From the output of that command, it seems that GSSAPI is a supported SASL mechanism (perhaps the only one?). The command fails with the following:
ldap_sasl_interactive_bind: server supports: GSSAPI ldap_int_sasl_bind: GSSAPI ldap_int_sasl_open: host=blue52s-mbp.netgear.com SASL/GSSAPI authentication started ldap_msgfree ldap_err2string ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text (Matching credential (krbtgt/NETGEAR.COM@BW.INT) not found)
This is a Mac running Mac OS X 10.9 (Mavericks) that was configured by our sys admin to connect to our company's Active Directory server when logging into the machine. That is independent of what we are trying to do with OpenLDAP from an application development standpoint, but perhaps the two are conflicting? We have several developers running the previous Mac OS X version (i.e. 10.8.5 - Mountain Lion), who are not having these issues with OpenLDAP. Perhaps it has something to do with how Apple built/configured OpenLDAP for Mavericks?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Denis Ahearn | Senior Software Developer *Bluewater | **bluewaterbrand.com* http://www.bluewaterbrand.com/
d: 952.215.0786 e: denis.ahearn@bluewaterbrand.com v: Why Bluewater? http://youtu.be/RHPQjFrPHtY
*Your Brand. Empowered. *
Facebook https://www.facebook.com/BluewaterBrand | LinkedInhttp://www.linkedin.com/company/bluewater-inc| Twitter https://twitter.com/bluewaterbrand | YouTubehttp://www.youtube.com/bluewaterbrand | 1:1 Marketing Blog http://www.bluewaterbrand.com/insights/blog/ **Bluewater is celebrating its 15th year in helping leading franchises grow with **smart marketing* http://youtu.be/rDSynh1ZAR0*.*
On Thu, Mar 20, 2014 at 10:45 AM, Dan White dwhite@olp.net wrote:
Putting the email list back into the CC.
On 03/20/14 10:16 -0500, Denis Ahearn wrote:
Thanks for responding Dan. We have spent the past several days taking the information you provided and trying to get smarter about how OpenLDAP and Kerberos work on Mac OS X Mavericks. Unfortunately we haven't made much progress. I think it may be because the way we are trying to use OpenLDAP is not the standard way that Apple intends it to be used from a server or client standpoint, so there doesn't seem to be any documentation available that speaks directly to our use case. Responses to your questions are listed below.
If you are authenticating against Active Directory, how does slapd fit
into the picture?
Our Rails app authenticates using Active Directory only in staging and production. We're using OpenLDAP (slapd) in our local development environments to simulate this (i.e. to provide a local LDAP server that serves the purpose that Active Directory does in production). To test locally, we define an organization, groups and users in ldif files that get loaded into OpenLDAP using ldapadd.
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?
Are you referring to setting an authz-regex rule in slapd.conf? If so, we do not have any authz-regex rules in our slapd.conf. I attached the slapd.conf and ldap.conf files that are being used with OpenLDAP if that helps.
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.
I ran the klist command on the Mac that is having this issue. Output is below:
$ klist
Credentials cache: API:77A8E90B-01BF-4F18-A94E-035C3AB25A59
Principal: dahearn@BWD.INTIssued Expires Principal
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).
We tried the suggestions you listed above, none of which seemed to have any effect on OpenLDAP's behavior (output in slapd.log is exactly the same).
I'm still not clear if ruby is attempting SASL GSSAPI authentication or not. Your syslog (auth facility) may tell you that. Since you have a ticket, it's certainly possible.
You can disable GSSAPI in a couple of additional ways:
- Remove the SASL GSSAPI shared library, assuming your cyrus sasl install
was compiled using shared libraries. pluginviewer (or saslpluginview) should list the mechanisms which are installed.
- Configure a slapd.conf SASL configuration, on the server, which
explicitly lists which mechanisms you wish to offer. The FAQ at:
http://www.cyrussasl.org/mediawiki/index.php/FAQ
details how to *enable* GSSAPI for slapd. Find out where cyrus sasl is looking for config files (e.g. /usr/lib/sasl2 or /etc/sasl2) and create a slapd.conf file with this line:
mech_list: PLAIN LOGIN DIGEST-MD5
Are you performing pass-through authentication? In that case, try running saslauthd in debug mode for testing.
We are only using OpenLDAP in our development environment as a way to
store groups and users for testing purposes, and to provide an LDAP server that our application can talk to in the same way it talks to Active Directory in our production environment. We rely upon logic in the application (the Ruby Devise and CanCan gems) to provide the necessary authentication and authorization services. What I think we need to do is make OpenLDAP not use Kerberos or other authentication mechanisms, but I haven't been able to figure out if this is possible and if so, how to do that. Does this sound like the way to go? If so, can you provide any assistance in setting this up? Is there anything else I can send you to help you understand our setup?
Replace the ruby authentication step with a ldapsearch/ldapwhoami call (with a -d -1 option for debugging on the client side). Or see if you can specify a debug option within Ruby (assuming it is using libldap). If you can figure out how your ruby code is connecting to the server in this way, your problem will likely stand out pretty quickly. A wireshark trace of the ruby ldap connection may help with that as well.
-- Dan White