local authentication problems (tls, nscd, nss_ldap)

[Rafael A Barrero]

Hi;

In my environment, we have about 20 servers (rhel4+rhel5) connecting  
as clients for local authentication to an OpenLDAP server  
(openldap2.3-2.3.39-3.rhel4, Buchan's RPMs) with slurpd replicating to  
a slave server. Half of the servers primarily use the master, while  
the other half primarily use the slave.

The OpenLDAP implemenation is working well, however we're having a few  
issues with the nss_ldap client:

1. TLS negotiation errors - doesn't seem to occur for all rhel4  
clients, or all the time... Doesn't work on RHEL5. Has anyone seen  
this? Why does it occur?
2. If nscd is not running and TLS is configured, authentication  
doesn't work (su - user), but lookups do work (id user). nss_ldap  
complains about binding to the ldap server.
3. If nscd is not running and TLS is *not* configured, everything  
works (including failover to slave).

I should say that in our /etc/ldap.conf file, we have a specific  
'binddn' user that has read-only privileges to the ldap database for  
querying (works)...

I'm wondering why TLS doesn't work on RHEL5, and why TLS doesn't work  
when nscd is not running. Also, any explanations or references on how  
nss_ldap and nscd work would be great.

Thanks,

Rafael

[Tony Earnshaw-4]

Rafael A Barrero skrev, on 06-02-2008 04:53:

> In my environment, we have about 20 servers (rhel4+rhel5) connecting as
> clients for local authentication to an OpenLDAP server
> (openldap2.3-2.3.39-3.rhel4, Buchan's RPMs) with slurpd replicating to a
> slave server. Half of the servers primarily use the master, while the
> other half primarily use the slave.
>
> The OpenLDAP implemenation is working well, however we're having a few
> issues with the nss_ldap client:
>
> 1. TLS negotiation errors - doesn't seem to occur for all rhel4 clients,
> or all the time... Doesn't work on RHEL5. Has anyone seen this? Why does
> it occur?
> 2. If nscd is not running and TLS is configured, authentication doesn't
> work (su - user), but lookups do work (id user). nss_ldap complains
> about binding to the ldap server.
> 3. If nscd is not running and TLS is *not* configured, everything works
> (including failover to slave).
>
> I should say that in our /etc/ldap.conf file, we have a specific
> 'binddn' user that has read-only privileges to the ldap database for
> querying (works)...
>
> I'm wondering why TLS doesn't work on RHEL5, and why TLS doesn't work
> when nscd is not running. Also, any explanations or references on how
> nss_ldap and nscd work would be great.

Hi, the following is not going to help you solve your problem, but it
will make you take a fresh look.

We swapped out our 4 RHAS4 servers with RHEL5 last summer. Delta
syncrepl master is an i386 machine, the 3 consumer slaves are x86_64 all
running Buchan's stuff but built on the appropriate platform from a
single srpm. Master is running OL 2.3.33, consumers 2.3.38. One of the
consumers is a Samba PDC that insists on Red Hat's clients but all the
others are running Buchan's clients.

In connection with the introduction of a password policy regime shortly
before Christmas we cut out the use of a proxy user for ldap.conf
because users have to be able to change their own passwords (write
access) using pam_exop. Users on all 4 consumers must be able to change
passwords and use utilities on all consumers.

We are using the standard Red Hat pam_ldap/nss_ldap libraries. pam is
going directly to the master from all of them for password modification
and authentication and I'm using TLS (starttls) for all of this. Local
stuff that uses OL's own libraries goes directly to the machine's slave
LDAP.

I've been bitten badly in the past by nscd and would never touch it
again with a bargepole. Besides which it would be impossible in our
ppolicy situation with people constantly changing passwords.

I could only guess that you could have a network problem; in our case
the three slaves are on one segment, the master on another over a 2Gb
switch and firewall (master is in the DMZ).

Sorry, but there it is. pam starttls works as designed with RHEL5 at our
site.

Best,

--Tonni

--
Tony Earnshaw
Email: tonni at hetnet dot nl

[Rafael A Barrero]

Hi Tony;

Thanks for the feedback. We use a proxy user because user password  
changes are done only through a web portal. I'm not entirely certain  
that the TLS negotiation problem can be attributed only to networking  
problems. As I mentioned, we have two servers and the consumers use  
the closest server to them. In other words, the consumers are always  
on the same subnet as their "primary" OpenLDAP server.

I have read a lot of people having problems using nscd, yet as I  
mentioned, I can get TLS to work without it! How have you been bitten  
badly?

I will try again on RHEL5 to see if we can enable TLS successfully.

Can someone explain the workflow of communications for pam_ldap,  
nss_ldap and how they interface with the other system libs/daemons?

Thanks,

Rafael


On Feb 6, 2008, at 12:04 AM, Tony Earnshaw wrote:

> Rafael A Barrero skrev, on 06-02-2008 04:53:
>
>> In my environment, we have about 20 servers (rhel4+rhel5)  
>> connecting as clients for local authentication to an OpenLDAP  
>> server (openldap2.3-2.3.39-3.rhel4, Buchan's RPMs) with slurpd  
>> replicating to a slave server. Half of the servers primarily use  
>> the master, while the other half primarily use the slave.
>> The OpenLDAP implemenation is working well, however we're having a  
>> few issues with the nss_ldap client:
>> 1. TLS negotiation errors - doesn't seem to occur for all rhel4  
>> clients, or all the time... Doesn't work on RHEL5. Has anyone seen  
>> this? Why does it occur?
>> 2. If nscd is not running and TLS is configured, authentication  
>> doesn't work (su - user), but lookups do work (id user). nss_ldap  
>> complains about binding to the ldap server.
>> 3. If nscd is not running and TLS is *not* configured, everything  
>> works (including failover to slave).
>> I should say that in our /etc/ldap.conf file, we have a specific  
>> 'binddn' user that has read-only privileges to the ldap database  
>> for querying (works)...
>> I'm wondering why TLS doesn't work on RHEL5, and why TLS doesn't  
>> work when nscd is not running. Also, any explanations or references  
>> on how nss_ldap and nscd work would be great.
>
> Hi, the following is not going to help you solve your problem, but  
> it will make you take a fresh look.
>
> We swapped out our 4 RHAS4 servers with RHEL5 last summer. Delta  
> syncrepl master is an i386 machine, the 3 consumer slaves are x86_64  
> all running Buchan's stuff but built on the appropriate platform  
> from a single srpm. Master is running OL 2.3.33, consumers 2.3.38.  
> One of the consumers is a Samba PDC that insists on Red Hat's  
> clients but all the others are running Buchan's clients.
>
> In connection with the introduction of a password policy regime  
> shortly before Christmas we cut out the use of a proxy user for  
> ldap.conf because users have to be able to change their own  
> passwords (write access) using pam_exop. Users on all 4 consumers  
> must be able to change passwords and use utilities on all consumers.
>
> We are using the standard Red Hat pam_ldap/nss_ldap libraries. pam  
> is going directly to the master from all of them for password  
> modification and authentication and I'm using TLS (starttls) for all  
> of this. Local stuff that uses OL's own libraries goes directly to  
> the machine's slave LDAP.
>
> I've been bitten badly in the past by nscd and would never touch it  
> again with a bargepole. Besides which it would be impossible in our  
> ppolicy situation with people constantly changing passwords.
>
> I could only guess that you could have a network problem; in our  
> case the three slaves are on one segment, the master on another over  
> a 2Gb switch and firewall (master is in the DMZ).
>
> Sorry, but there it is. pam starttls works as designed with RHEL5 at  
> our site.
>
> Best,
>
> --Tonni
>
> --
> Tony Earnshaw
> Email: tonni at hetnet dot nl