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