|
»
»
»
« Return to Thread: local authentication problems (tls, nscd, nss_ldap)
Re: local authentication problems (tls, nscd, nss_ldap)
by Rafael A Barrero
::
Rate this Message:
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
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
« Return to Thread: local authentication problems (tls, nscd, nss_ldap)
| Free Forum Powered by Nabble | Forum Help |