Fwiw, we ended up working around our issue by installing OpenLDAP on Mac OS X Mavericks using Homebrew:
brew install homebrew/dupes/openldap --with-berkeley-db We configured this instance of OpenLDAP the same way were were configuring the instance that comes with Mavericks, and everything worked as we expected. This actually ends up being a better solution for our situation anyhow, as it breaks a dependence we had with something installed as part of the OS. Thank you to Dan White for suggesting things to try for disabling Kerberos within the OpenLDAP that ships with Mavericks. We tried, but were never successful disabling Kerberos. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Denis Ahearn | Senior Software Developer *Bluewater | **bluewaterbrand.com* <http://www.bluewaterbrand.com/> d: 952.215.0786 e: [email protected] v: Why Bluewater? <http://youtu.be/RHPQjFrPHtY> *Your Brand. Empowered. * Facebook <https://www.facebook.com/BluewaterBrand> | LinkedIn<http://www.linkedin.com/company/bluewater-inc>| Twitter <https://twitter.com/bluewaterbrand> | YouTube<http://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 1:01 PM, Dan White <[email protected]> wrote: > On 03/20/14 11:18 -0500, Denis Ahearn wrote: > >> 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/[email protected]) not >> found) >> > > Makes sense. Either specify the mechanism you want to use, or disable > gssapi on the server or client using one of the below methods. > > > 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? >> > > On Thu, Mar 20, 2014 at 10:45 AM, Dan White <[email protected]> wrote: >> >>> You can disable GSSAPI in a couple of additional ways: >>> >>> 1) 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. >>> >>> 2) 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 >>> >> > -- > Dan White >
