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.