Hi,

I did not run the 'su - james' as root user. So I am expecting it to ask me for the password and trigger the authentication against ldap which delegates the authentication to Kerberos via saslauthd.

The problem is that I can not get it to work for users in the subordinate tree.

I read the man page of pam-ldap and it mentioned that there is a referral option, but after setting it to referral = yes, it still does not work.

Regards,

james

On 12/31/12 2:44 PM, "Dan White" dwhite@olp.net wrote:

On 12/31/12 11:19 -0800, Wu, James C. wrote:

...

I am trying to set up an OpenLDAP and Kerberos authentication for testing purpose. The setup contains a pair of internal ldap server and Kerberos server and the pair of external ldap server and Kerberos server.

I made the tree of the internal ldap server to be a subordinate of the external server and enabled the saslauthd for authentication on both the internal and the external ldap server to the respective Kerberos server.

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.

However, when I point the client machine to the external ldap server and the add the subordinate relationship, I could not get the authentication for the uses in the internal ldap directory to work.

For example, when I used "su - peter" where peter is a user in the external ldap server and the password is {SASL}peter@EXAMPLE.COMmailto:%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.COMmailto:%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.

I tried to modify the /etc/krb5.conf and added the realms for both EXAMPLE.COM and SUB.EXAMPLE.COM. Still, the authentication does not work for users defined in the internal ldap server.

Could anyone give me some hints for this issue?

Assuming that you are running 'su - <user>' as the root user, that command should not trigger an authentication against saslauthd, or kerberos. Nor should is even consult your userPassword entry.

Check the configuration of your nss ldap module, on the server you're running 'su' on. Use 'getent passwd <user>' to trouble shoot.

-- Dan White

The getent passwd returns all the users defined in both the internal and the external ldap servers. When I turned on the debug for pam_ldap, I saw

su: pam_ldap: could not open secret file /etc/pam_ldap.secret (No such file or directory) su: pam_ldap: error trying to bind as user "uid=peter,ou=People,ou=sub,dc=example,dc=com" (Invalid credentials)

But interesting enough, if I use 'su james' where james is an user in the external ldap, then I did not saw any warning or error logs. So I am wondering why for users in external ldap, it does not require the secret file. In the /etc/pam_ldap.conf, I did not specify the bindpw value.

James

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

On 12/31/12 2:44 PM, "Dan White" dwhite@olp.net wrote:

...

On 12/31/12 11:19 -0800, Wu, James C. wrote:

...

I am trying to set up an OpenLDAP and Kerberos authentication for testing purpose. The setup contains a pair of internal ldap server and Kerberos server and the pair of external ldap server and Kerberos server.

I made the tree of the internal ldap server to be a subordinate of the external server and enabled the saslauthd for authentication on both the internal and the external ldap server to the respective Kerberos server.

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.

However, when I point the client machine to the external ldap server and the add the subordinate relationship, I could not get the authentication for the uses in the internal ldap directory to work.

For example, when I used "su - peter" where peter is a user in the external ldap server and the password is {SASL}peter@EXAMPLE.COMmailto:%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.COMmailto:%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.

I tried to modify the /etc/krb5.conf and added the realms for both EXAMPLE.COM and SUB.EXAMPLE.COM. Still, the authentication does not work for users defined in the internal ldap server.

Could anyone give me some hints for this issue?

Assuming that you are running 'su - <user>' as the root user, that command should not trigger an authentication against saslauthd, or kerberos. Nor should is even consult your userPassword entry.

Check the configuration of your nss ldap module, on the server you're running 'su' on. Use 'getent passwd <user>' to trouble shoot.

On 01/01/13 20:49 -0800, Wu, James C. wrote:

I did not run the 'su - james' as root user. So I am expecting it to ask me for the password and trigger the authentication against ldap which delegates the authentication to Kerberos via saslauthd.

That still does not rule out an nss problem. Does 'getent passwd <user>' work for both sets of users?

The problem is that I can not get it to work for users in the subordinate tree.

I read the man page of pam-ldap and it mentioned that there is a referral option, but after setting it to referral = yes, it still does not work.

What you're attempting to do sounds problematic. You're expecting pam_ldap (and nss_ldap?) to figure out that an unqualified 'james' is going to need to be searched for on the internal servers, and that pam_ldap will perform a (user dn) authenticated bind against those same servers. Perhaps you've worked through those scenarios already. If not, consider using fully qualified usernames: peter@example.com and james@sub.example.com.

Enable debugging (debug -1) in your pam/nss_ldap configurations for better troubleshooting output. Install pamtester to test your pam_ldap config, and use getent to test your nss_ldap config.

-- Dan White

Hi,

You are right. In the pam_ldap configuration, I only specified the external LDAP servers and configured the external server to refer query for the sub.example.com to the internal servers.

I tried ldapsearch with -w option on both the internal and the external servers. Both succeeded.

[client] ldapsearch -d -1 -x -H ldap://externalhost -b dc=example,dc=com -D "cn=Manager,dc=example,dc=com" -w password [client] ldapsearch -d -1 -x -H ldap://internalhost -b ou=sub,dc=example,dc=com -D "cn=Manager,dc=example,dc=com" -w password

Similarly, the ldapwhoami also works for both the external and internal servers.

[client] ldapwhoami -d -1 -x -H ldap://internalhost -D "cn=Manager,dc=example,dc=com" -w password [client] ldapwhoami -d -1 -x -H ldap://externalhost -D "cn=Manager,dc=example,dc=com" -w password

When I use [client] ldapsearch -d -1 -x -H ldap://externalhost -b ou=sub,dc=example,dc=com -D "cn=Manager,dc=example,dc=com" -w password

I got

# extended LDIF # # LDAPv3 # base <ou=sub,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #

# search result search: 2 result: 10 Referral matchedDN: ou=sub,dc=example,dc=com ref: ldaps://internalhost ip address/ou=sub,dc=example,dc=com??sub

regards,

james

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

On 01/02/13 11:43 -0800, Wu, James C. wrote:

The getent passwd returns all the users defined in both the internal and the external ldap servers. When I turned on the debug for pam_ldap, I saw

su: pam_ldap: could not open secret file /etc/pam_ldap.secret (No such file or directory) su: pam_ldap: error trying to bind as user "uid=peter,ou=People,ou=sub,dc=example,dc=com" (Invalid credentials)

The first error would be generated when searching for the user's DN, which succeeded (because you're using anonymous binds?). The second error means that the responding server believes you've provided a bad password for peter.

Can you tell which LDAP server is returning "Invalid Credentials"?

But interesting enough, if I use 'su james' where james is an user in the external ldap, then I did not saw any warning or error logs. So I am wondering why for users in external ldap, it does not require the secret file. In the /etc/pam_ldap.conf, I did not specify the bindpw value.

I presume that in your pam_ldap configuration, you're specifying only the external LDAP servers, and that you have configured the external servers to refer queries for the ou=sub,dc=example,dc=com tree to the internal servers.

Try these to narrow down the problem:

ldapsearch -d -1 -x -H ldap://external_server -b "<base>" -D "<binddn>" -w "<bindpw>" "uid=peter" dn ldapsearch -d -1 -x -H ldap://internal_server -b "<base>" -D "<binddn>" -w "<bindpw>" "uid=peter" dn

ldapwhoami -d -1 -x -H ldap://external_server -D "uid=peter,ou=People,ou=sub,dc=example,dc=com" -w ldapwhoami -d -1 -x -H ldap://internal_server -D "uid=peter,ou=People,ou=sub,dc=example,dc=com" -w

Another approach is to proxy queries and binds, with the ldap backend and/or pbind overlay. See slapd-ldap(5) and slapo-pbind(5).

-- Dan White

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

Here is the sample log output of the above two commands

[cloud-user@client]$ ldapwhoami -d -1 -x -H ldap://externalldap -D "uid=peter,ou=People,ou=sub,dc=example,dc=com" -w password ldap_url_parse_ext(ldap:// externalldap) ldap_create ldap_url_parse_ext(ldap:// externalldap:389/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP externalldap:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying externalldap: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=0xa77cb0 ptr=0xa77cb0 end=0xa77cf8 len=72 0000: 30 46 02 01 01 60 41 02 01 03 04 2b 75 69 64 3d 0F...`A....+uid= 0010: 70 65 74 65 72 2c 6f 75 3d 50 65 6f 70 6c 65 2c peter,ou=People, 0020: 6f 75 3d 64 6d 70 2c 64 63 3d 64 69 73 6e 65 79 ou=sub,dc=example 0030: 2c 64 63 3d 63 6f 6d 80 0f 64 6d 70 73 65 63 75 ,dc=com.. 0040: 72 69 74 79 32 30 31 32 ber_scanf fmt ({i) ber: ber_dump: buf=0xa77cb0 ptr=0xa77cb5 end=0xa77cf8 len=67 0000: 60 41 02 01 03 04 2b 75 69 64 3d 70 65 74 65 72 `A....+uid=peter 0010: 2c 6f 75 3d 50 65 6f 70 6c 65 2c 6f 75 3d 64 6d ,ou=People,ou=dm 0020: 70 2c 64 63 3d 64 69 73 6e 65 79 2c 64 63 3d 63 p,dc=example,dc=c 0030: 6f 6d 80 0f 64 6d 70 73 65 63 75 72 69 74 79 32 om.. 0040: 30 31 32 012 ber_flush2: 72 bytes to sd 3 0000: 30 46 02 01 01 60 41 02 01 03 04 2b 75 69 64 3d 0F...`A....+uid= 0010: 70 65 74 65 72 2c 6f 75 3d 50 65 6f 70 6c 65 2c peter,ou=People, 0020: 6f 75 3d 64 6d 70 2c 64 63 3d 64 69 73 6e 65 79 ou=sub,dc=example 0030: 2c 64 63 3d 63 6f 6d 80 0f 64 6d 70 73 65 63 75 ,dc=com.. 0040: 72 69 74 79 32 30 31 32 ldap_write: want=72, written=72 0000: 30 46 02 01 01 60 41 02 01 03 04 2b 75 69 64 3d 0F...`A....+uid= 0010: 70 65 74 65 72 2c 6f 75 3d 50 65 6f 70 6c 65 2c peter,ou=People, 0020: 6f 75 3d 64 6d 70 2c 64 63 3d 64 69 73 6e 65 79 ou=sub,dc=example 0030: 2c 64 63 3d 63 6f 6d 80 0f 64 6d 70 73 65 63 75 ,dc=com.. 0040: 72 69 74 79 32 30 31 32 ldap_result ld 0xa6faa0 msgid 1 wait4msg ld 0xa6faa0 msgid 1 (infinite timeout) wait4msg continue ld 0xa6faa0 msgid 1 all 1 ** ld 0xa6faa0 Connections: * host: 10.42.12.57 port: 389 (default) refcnt: 2 status: Connected last used: Wed Jan 2 14:44:56 2013

** ld 0xa6faa0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0xa6faa0 request count 1 (abandoned 0) ** ld 0xa6faa0 Response Queue: Empty ld 0xa6faa0 response count 0 ldap_chkResponseList ld 0xa6faa0 msgid 1 all 1 ldap_chkResponseList returns ld 0xa6faa0 NULL ldap_int_select read1msg: ld 0xa6faa0 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=0xa78e90 ptr=0xa78e90 end=0xa78e9c len=12 0000: 02 01 01 61 07 0a 01 31 04 00 04 00 ...a...1.... read1msg: ld 0xa6faa0 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0xa78e90 ptr=0xa78e93 end=0xa78e9c len=9 0000: 61 07 0a 01 31 04 00 04 00 a...1.... read1msg: ld 0xa6faa0 0 new referrals read1msg: mark request completed, ld 0xa6faa0 msgid 1 request done: ld 0xa6faa0 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=0xa78e90 ptr=0xa78e93 end=0xa78e9c len=9 0000: 61 07 0a 01 31 04 00 04 00 a...1.... ber_scanf fmt (}) ber: ber_dump: buf=0xa78e90 ptr=0xa78e9c end=0xa78e9c len=0

ldap_msgfree ldap_err2string ldap_bind: Invalid credentials (49)

[cloud-user@client]$ ldapwhoami -d -1 -x -H ldap://internalldap -D "uid=peter,ou=People,ou=sub,dc=example,dc=com" -w password ldap_url_parse_ext(ldap:// internalldap) ldap_create ldap_url_parse_ext(ldap:// internalldap:389/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP internalldap:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying internalldap: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=0x1e62cb0 ptr=0x1e62cb0 end=0x1e62cf8 len=72 0000: 30 46 02 01 01 60 41 02 01 03 04 2b 75 69 64 3d 0F...`A....+uid= 0010: 70 65 74 65 72 2c 6f 75 3d 50 65 6f 70 6c 65 2c peter,ou=People, 0020: 6f 75 3d 64 6d 70 2c 64 63 3d 64 69 73 6e 65 79 ou=sub,dc=example 0030: 2c 64 63 3d 63 6f 6d 80 0f 64 6d 70 73 65 63 75 ,dc=com.. 0040: 72 69 74 79 32 30 31 32 ber_scanf fmt ({i) ber: ber_dump: buf=0x1e62cb0 ptr=0x1e62cb5 end=0x1e62cf8 len=67 0000: 60 41 02 01 03 04 2b 75 69 64 3d 70 65 74 65 72 `A....+uid=peter 0010: 2c 6f 75 3d 50 65 6f 70 6c 65 2c 6f 75 3d 64 6d ,ou=People,ou=dm 0020: 70 2c 64 63 3d 64 69 73 6e 65 79 2c 64 63 3d 63 p,dc=example,dc=c 0030: 6f 6d 80 0f 64 6d 70 73 65 63 75 72 69 74 79 32 om.. 0040: 30 31 32 012 ber_flush2: 72 bytes to sd 3 0000: 30 46 02 01 01 60 41 02 01 03 04 2b 75 69 64 3d 0F...`A....+uid= 0010: 70 65 74 65 72 2c 6f 75 3d 50 65 6f 70 6c 65 2c peter,ou=People, 0020: 6f 75 3d 64 6d 70 2c 64 63 3d 64 69 73 6e 65 79 ou=sub,dc=example 0030: 2c 64 63 3d 63 6f 6d 80 0f 64 6d 70 73 65 63 75 ,dc=com. 0040: 72 69 74 79 32 30 31 32 ldap_write: want=72, written=72 0000: 30 46 02 01 01 60 41 02 01 03 04 2b 75 69 64 3d 0F...`A....+uid= 0010: 70 65 74 65 72 2c 6f 75 3d 50 65 6f 70 6c 65 2c peter,ou=People, 0020: 6f 75 3d 64 6d 70 2c 64 63 3d 64 69 73 6e 65 79 ou=sub,dc=example 0030: 2c 64 63 3d 63 6f 6d 80 0f 64 6d 70 73 65 63 75 ,dc=com.. 0040: 72 69 74 79 32 30 31 32 ldap_result ld 0x1e5aaa0 msgid 1 wait4msg ld 0x1e5aaa0 msgid 1 (infinite timeout) wait4msg continue ld 0x1e5aaa0 msgid 1 all 1 ** ld 0x1e5aaa0 Connections: * host: 10.42.12.54 port: 389 (default) refcnt: 2 status: Connected last used: Wed Jan 2 14:49:30 2013

** ld 0x1e5aaa0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x1e5aaa0 request count 1 (abandoned 0) ** ld 0x1e5aaa0 Response Queue: Empty ld 0x1e5aaa0 response count 0 ldap_chkResponseList ld 0x1e5aaa0 msgid 1 all 1 ldap_chkResponseList returns ld 0x1e5aaa0 NULL ldap_int_select read1msg: ld 0x1e5aaa0 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=0x1e63e90 ptr=0x1e63e90 end=0x1e63e9c len=12 0000: 02 01 01 61 07 0a 01 31 04 00 04 00 ...a...1.... read1msg: ld 0x1e5aaa0 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x1e63e90 ptr=0x1e63e93 end=0x1e63e9c len=9 0000: 61 07 0a 01 31 04 00 04 00 a...1.... read1msg: ld 0x1e5aaa0 0 new referrals read1msg: mark request completed, ld 0x1e5aaa0 msgid 1 request done: ld 0x1e5aaa0 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=0x1e63e90 ptr=0x1e63e93 end=0x1e63e9c len=9 0000: 61 07 0a 01 31 04 00 04 00 a...1.... ber_scanf fmt (}) ber: ber_dump: buf=0x1e63e90 ptr=0x1e63e9c end=0x1e63e9c len=0

ldap_msgfree ldap_err2string ldap_bind: Invalid credentials (49)

james

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

To answer your first question, I do not know which ldap server returns the "Invalid Credentials". --james

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

Hi,

You are right. In the pam_ldap configuration, I only specified the external LDAP servers and configured the external server to refer query for the sub.example.com to the internal servers.

I tried ldapsearch with -w option on both the internal and the external servers. Both succeeded.

[client] ldapsearch -d -1 -x -H ldap://externalhost -b dc=example,dc=com -D "cn=Manager,dc=example,dc=com" -w password [client] ldapsearch -d -1 -x -H ldap://internalhost -b ou=sub,dc=example,dc=com -D "cn=Manager,dc=example,dc=com" -w password

Similarly, the ldapwhoami also works for both the external and internal servers.

[client] ldapwhoami -d -1 -x -H ldap://internalhost -D "cn=Manager,dc=example,dc=com" -w password [client] ldapwhoami -d -1 -x -H ldap://externalhost -D "cn=Manager,dc=example,dc=com" -w password

When I use [client] ldapsearch -d -1 -x -H ldap://externalhost -b ou=sub,dc=example,dc=com -D "cn=Manager,dc=example,dc=com" -w password

I got

# extended LDIF # # LDAPv3 # base <ou=sub,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL #

# search result search: 2 result: 10 Referral matchedDN: ou=sub,dc=example,dc=com ref: ldaps://internalhost ip address/ou=sub,dc=example,dc=com??sub

regards,

james

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

On 01/02/13 11:43 -0800, Wu, James C. wrote:

The getent passwd returns all the users defined in both the internal and the external ldap servers. When I turned on the debug for pam_ldap, I saw

su: pam_ldap: could not open secret file /etc/pam_ldap.secret (No such file or directory) su: pam_ldap: error trying to bind as user "uid=peter,ou=People,ou=sub,dc=example,dc=com" (Invalid credentials)

The first error would be generated when searching for the user's DN, which succeeded (because you're using anonymous binds?). The second error means that the responding server believes you've provided a bad password for peter.

Can you tell which LDAP server is returning "Invalid Credentials"?

But interesting enough, if I use 'su james' where james is an user in the external ldap, then I did not saw any warning or error logs. So I am wondering why for users in external ldap, it does not require the secret file. In the /etc/pam_ldap.conf, I did not specify the bindpw value.

I presume that in your pam_ldap configuration, you're specifying only the external LDAP servers, and that you have configured the external servers to refer queries for the ou=sub,dc=example,dc=com tree to the internal servers.

Try these to narrow down the problem:

ldapsearch -d -1 -x -H ldap://external_server -b "<base>" -D "<binddn>" -w "<bindpw>" "uid=peter" dn ldapsearch -d -1 -x -H ldap://internal_server -b "<base>" -D "<binddn>" -w "<bindpw>" "uid=peter" dn

ldapwhoami -d -1 -x -H ldap://external_server -D "uid=peter,ou=People,ou=sub,dc=example,dc=com" -w ldapwhoami -d -1 -x -H ldap://internal_server -D "uid=peter,ou=People,ou=sub,dc=example,dc=com" -w

Another approach is to proxy queries and binds, with the ldap backend and/or pbind overlay. See slapd-ldap(5) and slapo-pbind(5).

-- Dan White

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.COMmailto:%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.COMmailto:%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

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.COMmailto:%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.COMmailto:%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