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