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

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