RE: sasl Kerberos authentication with subordinate

["Wu, James C." <James.C.Wu@disney.com>]

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.COM<mailto:%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.COM<mailto:%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