[Date Prev][Date Next]
RE: sasl Kerberos authentication with subordinate
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.
From: Dan White [mailto:email@example.com]
Sent: Tuesday, January 01, 2013 11:39 PM
To: Wu, James C.
Subject: Re: sasl Kerberos authentication with subordinate
>On 12/31/12 2:44 PM, "Dan White" <firstname.lastname@example.org> 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
>>>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
>>>authentication works. However, when I use "su - James" where james is
>>>a user defined in the internal ldap server with password
>>>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
>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@example.com and firstname.lastname@example.org.
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.