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:[email protected]] Sent: Tuesday, January 01, 2013 11:39 PM To: Wu, James C. Cc: [email protected] Subject: Re: sasl Kerberos authentication with subordinate >On 12/31/12 2:44 PM, "Dan White" <[email protected]> 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}[email protected]<mailto:%7bsasl%[email protected]>. The >>>authentication works. However, when I use "su - James" where james is >>>a user defined in the internal ldap server with password >>>{SASL}[email protected]<mailto:%7bsasl%[email protected]>, >>>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: [email protected] and [email protected]. 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
