[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: sasl Kerberos authentication with subordinate

To: Dan White <dwhite@olp.net>
Subject: RE: sasl Kerberos authentication with subordinate
From: "Wu, James C." <James.C.Wu@disney.com>
Date: Wed, 2 Jan 2013 19:42:25 -0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "openldap-technical@openldap.org" <openldap-technical@openldap.org>
Content-language: en-US
References: <7D664BE6CF058A4CB1A06984A7AA678F17F41EAF99@SM-CALA-VXMB06A.swna.wdpr.disney.com> <7D664BE6CF058A4CB1A06984A7AA678F17F41EA76C@SM-CALA-VXMB06A.swna.wdpr.disney.com> <20130103031820.GA8022@dan.olp.net>
Thread-index: Ac3pYQMh9yFT1QVQThajizYaC31QlQAAPY8AAAByP6A=
Thread-topic: sasl Kerberos authentication with subordinate

When I used  ldapsearch -d -1 -x -H ldap://externalldaphost -b ou=people,ou=sub,dc=example,dc=com -D dc=example,dc=com uid=mark -w password

On the server side,  I got

50e4fd04 connection_read(20): checking for input on id=1050
ber_get_next
ldap_read: want=8, got=0

50e4fd04 ber_get_next on fd 20 failed errno=0 (Success)
50e4fd04 connection_read(20): input error=-2 id=1050, closing.
50e4fd04 connection_closing: readying conn=1050 sd=20 for close
50e4fd04 connection_close: conn=1050 sd=20
50e4fd04 daemon: removing 20
50e4fd04 conn=1050 fd=20 closed (connection lost)

On the client side, I got 

ldap_url_parse_ext(ldap://externalhostip)
ldap_create
ldap_url_parse_ext(ldap:// externalhostip:389/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP externalhostip:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying externalhostip:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_dump: buf=0x2025ce0 ptr=0x2025ce0 end=0x2025d0d len=45
  0000:  30 2b 02 01 01 60 26 02  01 03 04 10 64 63 3d 64   0+...`&.....dc=example
  0010:  69 73 6e 65 79 2c 64 63  3d 63 6f 6d 80 0f 64 6d   ,dc=com..
  0020:  70 73 65 63 75 72 69 74  79 32 30 31 32            
ber_scanf fmt ({i) ber:
ber_dump: buf=0x2025ce0 ptr=0x2025ce5 end=0x2025d0d len=40
  0000:  60 26 02 01 03 04 10 64  63 3d 64 69 73 6e 65 79   `&.....dc=example
  0010:  2c 64 63 3d 63 6f 6d 80  0f 64 6d 70 73 65 63 75   ,dc=com..
  0020:  72 69 74 79 32 30 31 32                            
ber_flush2: 45 bytes to sd 3
  0000:  30 2b 02 01 01 60 26 02  01 03 04 10 64 63 3d 64   0+...`&.....dc=example
  0010:  69 73 6e 65 79 2c 64 63  3d 63 6f 6d 80 0f 64 6d   ,dc=com..
  0020:  70 73 65 63 75 72 69 74  79 32 30 31 32            
ldap_write: want=45, written=45
  0000:  30 2b 02 01 01 60 26 02  01 03 04 10 64 63 3d 64   0+...`&.....dc=e
  0010:  69 73 6e 65 79 2c 64 63  3d 63 6f 6d 80 0f 64 6d   example,dc=com..
  0020:  70 73 65 63 75 72 69 74  79 32 30 31 32            
ldap_result ld 0x201dad0 msgid 1
wait4msg ld 0x201dad0 msgid 1 (infinite timeout)
wait4msg continue ld 0x201dad0 msgid 1 all 1
** ld 0x201dad0 Connections:
* host: 10.42.12.57  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Wed Jan  2 19:37:40 2013


** ld 0x201dad0 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x201dad0 request count 1 (abandoned 0)
** ld 0x201dad0 Response Queue:
   Empty
  ld 0x201dad0 response count 0
ldap_chkResponseList ld 0x201dad0 msgid 1 all 1
ldap_chkResponseList returns ld 0x201dad0 NULL
ldap_int_select
read1msg: ld 0x201dad0 msgid 1 all 1
ber_get_next
ldap_read: want=8, got=8
  0000:  30 0c 02 01 01 61 07 0a                            0....a..
ldap_read: want=6, got=6
  0000:  01 31 04 00 04 00                                  .1....
ber_get_next: tag 0x30 len 12 contents:
ber_dump: buf=0x2026ec0 ptr=0x2026ec0 end=0x2026ecc len=12
  0000:  02 01 01 61 07 0a 01 31  04 00 04 00               ...a...1....
read1msg: ld 0x201dad0 msgid 1 message type bind
ber_scanf fmt ({eAA) ber:
ber_dump: buf=0x2026ec0 ptr=0x2026ec3 end=0x2026ecc len=9
  0000:  61 07 0a 01 31 04 00 04  00                        a...1....
read1msg: ld 0x201dad0 0 new referrals
read1msg:  mark request completed, ld 0x201dad0 msgid 1
request done: ld 0x201dad0 msgid 1
res_errno: 49, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_dump: buf=0x2026ec0 ptr=0x2026ec3 end=0x2026ecc len=9
  0000:  61 07 0a 01 31 04 00 04  00                        a...1....
ber_scanf fmt (}) ber:
ber_dump: buf=0x2026ec0 ptr=0x2026ecc end=0x2026ecc len=0

ldap_msgfree
ldap_err2string
ldap_bind: Invalid credentials (49)


-----Original Message-----
From: Wu, James C. 
Sent: Wednesday, January 02, 2013 7:26 PM
To: 'Dan White'
Cc: openldap-technical@openldap.org
Subject: RE: sasl Kerberos authentication with subordinate

Hi,

Actually 'peter' is not the right user t test against because its password in the internal ldap server is defined as {SASL}peter@EXAMPLE.COM.  It should be {SASL}peter@SUB.EXAMPLE.COM.

I tested againt another user mark whose password is {SASL}mark@SUB.EXAMPLE.COM. Both the ldapsearch and ldapwhoami worked well if I use the internal ldap server. This is what I expected. 

When I test againt the external server, using  ldapwhoami -d -1 -x -H ldap://externalldapserver -D "uid=mark,ou=People,ou=sub,dc=example,dc=com" -w password

 the ldap log shows this error message:

 50e4f948 >>> dnPrettyNormal: <uid=mark,ou=People,ou=sub,dc=example,dc=com>
=> ldap_bv2dn(uid=mark,ou=People,ou=sub,dc=example,dc=com,0)
<= ldap_bv2dn(uid=mark,ou=People,ou=sub,dc=example,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=mark,ou=People,ou=sub,dc=example,dc=com)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=mark,ou=people,ou=sub,dc=example,dc=com)=0
50e4f948 <<< dnPrettyNormal: <uid=mark,ou=People,ou=sub,dc=example,dc=com>, <uid=mark,   ou=people,ou=sub,dc=example,dc=com>
50e4f948 conn=1034 op=0 BIND dn="uid=mark,ou=People,ou=sub,dc=example,dc=com" method=1   28
50e4f948 do_bind: version=3 dn="uid=mark,ou=People,ou=sub,dc=example,dc=com" method=12   8
50e4f948 ==> bdb_bind: dn: uid=mark,ou=People,ou=sub,dc=example,dc=com
50e4f948 bdb_dn2entry("uid=mark,ou=people,ou=sub,dc=example,dc=com")
50e4f948 => bdb_dn2id("ou=people,ou=sub,dc=example,dc=com")
50e4f948 <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-309   88)
50e4f948 send_ldap_result: conn=1034 op=0 p=3
50e4f948 send_ldap_result: err=49 matched="" text=""
50e4f948 send_ldap_response: msgid=1 tag=97 err=49

Similary message is also shown when I run the ldapsearch command. 

James

-----Original Message-----
From: Dan White [mailto:dwhite@olp.net]
Sent: Wednesday, January 02, 2013 7:18 PM
To: Wu, James C.
Cc: openldap-technical@openldap.org
Subject: Re: sasl Kerberos authentication with subordinate

On 12/31/12 11:19 -0800, Wu, James C. wrote:
>I have tested that the LDAP authentication through saslauthd using 
>Kerberos works well on both the internal ldap and Kerberos pair and the 
>external ldap Kerberos pair.

How did you verify authentication was working with your internal server?

>For example, when I used "su - peter" where peter is a user in the 
>external ldap server and the password is 
>{SASL}peter@EXAMPLE.COM<mailto:%7bSASL%7dpeter@EXAMPLE.COM>. The 
>authentication works. However, when I use "su - James" where james is a 
>user defined in the internal ldap server with password 
>{SASL}james@SUB.EXAMPLE.COM<mailto:%7bSASL%7djames@SUB.EXAMPLE.COM>,
>then the authentication failed. I check the log file, the internal 
>server did get the search request forwarded from the external ldap 
>server and returned the correct information back. However, I did not 
>see the saslauthd process on either the external or the internal ldap 
>server get any inquiry for the authentication.

On 01/02/13 14:52 -0800, Wu, James C. wrote:
>When I add uid to the -D flag in the ldapwhoami, then it failed on both 
>the external and internal ldap servers.
>
>ldapwhoami -x -H ldap://internalldap -D 
>"uid=peter,ou=People,ou=sub,dc=example,dc=com" -w password ldapwhoami 
>-x -H ldap://externalldap -D 
>"uid=peter,ou=People,ou=sub,dc=example,dc=com" -w password

How does this second command (against your internal server) differ from the above verification?

--
Dan White

References:
- RE: sasl Kerberos authentication with subordinate
  - From: "Wu, James C." <James.C.Wu@disney.com>
- Re: sasl Kerberos authentication with subordinate
  - From: Dan White <dwhite@olp.net>

Prev by Date: RE: sasl Kerberos authentication with subordinate
Next by Date: Re: Multi-Master OpenLDAP Replication for 3 nodes -- slapadd command failing
Index(es):
- Chronological
- Thread