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)
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: [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 10:45 AM, Dan White <[email protected]> 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: [email protected]
>>
>> Issued 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:
>
> 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
>
> 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
>
$ ldapwhoami -d -1
ldap_create
ldap_pvt_sasl_getmech
ldap_search
put_filter: "(objectclass=*)"
put_filter: simple
put_simple_filter: "objectclass=*"
ldap_build_search_req ATTRS: supportedSASLMechanisms
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP localhost:389
ldap_new_socket: 5
ldap_prepare_socket: 5
ldap_connect_to_host: Trying ::1 389
ldap_pvt_connect: fd: 5 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_dump: buf=0x7ffb84000000 ptr=0x7ffb84000000 end=0x7ffb84000040 len=64
0000: 30 3e 02 01 01 63 39 04 00 0a 01 00 0a 01 00 02 0>...c9.........
0010: 01 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 ..........object
0020: 63 6c 61 73 73 30 19 04 17 73 75 70 70 6f 72 74 class0...support
0030: 65 64 53 41 53 4c 4d 65 63 68 61 6e 69 73 6d 73 edSASLMechanisms
ber_scanf fmt ({) ber:
ber_dump: buf=0x7ffb84000000 ptr=0x7ffb84000005 end=0x7ffb84000040 len=59
0000: 63 39 04 00 0a 01 00 0a 01 00 02 01 00 02 01 00 c9..............
0010: 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 .....objectclass
0020: 30 19 04 17 73 75 70 70 6f 72 74 65 64 53 41 53 0...supportedSAS
0030: 4c 4d 65 63 68 61 6e 69 73 6d 73 LMechanisms
ber_flush2: 64 bytes to sd 5
0000: 30 3e 02 01 01 63 39 04 00 0a 01 00 0a 01 00 02 0>...c9.........
0010: 01 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 ..........object
0020: 63 6c 61 73 73 30 19 04 17 73 75 70 70 6f 72 74 class0...support
0030: 65 64 53 41 53 4c 4d 65 63 68 61 6e 69 73 6d 73 edSASLMechanisms
ldap_write: want=64, written=64
0000: 30 3e 02 01 01 63 39 04 00 0a 01 00 0a 01 00 02 0>...c9.........
0010: 01 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 ..........object
0020: 63 6c 61 73 73 30 19 04 17 73 75 70 70 6f 72 74 class0...support
0030: 65 64 53 41 53 4c 4d 65 63 68 61 6e 69 73 6d 73 edSASLMechanisms
ldap_mark_select_read: sip = 0x7ffb84002600, sd = 5
ldap_int_mark_select_read: sip = 0x7ffb84002600, sd = 5
ldap_result ld 0x7ffb82e00400 msgid 1
wait4msg ld 0x7ffb82e00400 msgid 1 (infinite timeout)
wait4msg continue ld 0x7ffb82e00400 msgid 1 all 1
** ld 0x7ffb82e00400 Connections:
* host: localhost port: 389 (default)
refcnt: 2 status: Connected
last used: Thu Mar 20 10:58:53 2014
** ld 0x7ffb82e00400 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x7ffb82e00400 request count 1 (abandoned 0)
** ld 0x7ffb82e00400 Red-Black Tree Response Queue:
Empty
ld 0x7ffb82e00400 response count 1
ldap_chkResponseList ld 0x7ffb82e00400 msgid 1 all 1
ldap_chkResponseList returns ld 0x7ffb82e00400 NULL
ldap_int_select
read1msg: ld 0x7ffb82e00400 msgid 1 all 1
ber_get_next
ldap_read: want=8, got=8
0000: 30 2e 02 01 01 64 29 04 0....d).
ldap_read: want=40, got=40
0000: 00 30 25 30 23 04 17 73 75 70 70 6f 72 74 65 64 .0%0#..supported
0010: 53 41 53 4c 4d 65 63 68 61 6e 69 73 6d 73 31 08 SASLMechanisms1.
0020: 04 06 47 53 53 41 50 49 ..GSSAPI
ber_get_next: tag 0x30 len 46 contents:
ber_dump: buf=0x7ffb82d00360 ptr=0x7ffb82d00360 end=0x7ffb82d0038e len=46
0000: 02 01 01 64 29 04 00 30 25 30 23 04 17 73 75 70 ...d)..0%0#..sup
0010: 70 6f 72 74 65 64 53 41 53 4c 4d 65 63 68 61 6e portedSASLMechan
0020: 69 73 6d 73 31 08 04 06 47 53 53 41 50 49 isms1...GSSAPI
read1msg: ld 0x7ffb82e00400 msgid 1 message type search-entry
wait4msg continue ld 0x7ffb82e00400 msgid 1 all 1
** ld 0x7ffb82e00400 Connections:
* host: localhost port: 389 (default)
refcnt: 2 status: Connected
last used: Thu Mar 20 10:58:53 2014
** ld 0x7ffb82e00400 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x7ffb82e00400 request count 1 (abandoned 0)
** ld 0x7ffb82e00400 Red-Black Tree Response Queue:
* msgid 1, type 100
ld 0x7ffb82e00400 response count 1
ldap_chkResponseList ld 0x7ffb82e00400 msgid 1 all 1
ldap_chkResponseList returns ld 0x7ffb82e00400 NULL
ldap_int_select
read1msg: ld 0x7ffb82e00400 msgid 1 all 1
ber_get_next
ldap_read: want=8, got=8
0000: 30 0c 02 01 01 65 07 0a 0....e..
ldap_read: want=6, got=6
0000: 01 00 04 00 04 00 ......
ber_get_next: tag 0x30 len 12 contents:
ber_dump: buf=0x7ffb82d00280 ptr=0x7ffb82d00280 end=0x7ffb82d0028c len=12
0000: 02 01 01 65 07 0a 01 00 04 00 04 00 ...e........
read1msg: ld 0x7ffb82e00400 msgid 1 message type search-result
ber_scanf fmt ({eAA) ber:
ber_dump: buf=0x7ffb82d00280 ptr=0x7ffb82d00283 end=0x7ffb82d0028c len=9
0000: 65 07 0a 01 00 04 00 04 00 e........
read1msg: ld 0x7ffb82e00400 0 new referrals
read1msg: mark request completed, ld 0x7ffb82e00400 msgid 1
request done: ld 0x7ffb82e00400 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
adding response ld 0x7ffb82e00400 msgid 1 type 101:
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_dump: buf=0x7ffb82d00280 ptr=0x7ffb82d00283 end=0x7ffb82d0028c len=9
0000: 65 07 0a 01 00 04 00 04 00 e........
ber_scanf fmt (}) ber:
ber_dump: buf=0x7ffb82d00280 ptr=0x7ffb82d0028c end=0x7ffb82d0028c len=0
ldap_get_values
ber_scanf fmt ({x{{a) ber:
ber_dump: buf=0x7ffb82d00360 ptr=0x7ffb82d00363 end=0x7ffb82d0038e len=43
0000: 64 29 04 00 30 25 30 23 04 17 73 75 70 70 6f 72 d)..0%0#..suppor
0010: 74 65 64 53 41 53 4c 4d 65 63 68 61 6e 69 73 6d tedSASLMechanism
0020: 73 31 08 04 06 47 53 53 41 50 49 s1...GSSAPI
ber_scanf fmt ([v]) ber:
ber_dump: buf=0x7ffb82d00360 ptr=0x7ffb82d00384 end=0x7ffb82d0038e len=10
0000: 31 08 04 06 47 53 53 41 50 49 1...GSSAPI
ldap_msgfree
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)
ldap_free_connection 1 1
ldap_mark_select_clear: sip = 0x7ffb84002600, sd = 5
ldap_int_mark_select_clear: sip = 0x7ffb84002600, sd = 5
ldap_send_unbind
ber_flush2: 7 bytes to sd 5
0000: 30 05 02 01 02 42 00 0....B.
ldap_write: want=7, written=7
0000: 30 05 02 01 02 42 00 0....B.
ldap_free_connection: actually freed
