lists.arthurdejong.org
RSS feed

[nssldap] Re: Re: disconnected nss_ldap

[Date Prev][Date Next] [Thread Prev][Thread Next]

[nssldap] Re: Re: disconnected nss_ldap



On Sat, 2009-10-24 at 03:16 -0400, Ryan Lynch wrote:
> 
> nscd and the name service switch arent' supposed to handle
> authenticating users via LDAP binds.

They are not.  It was the pam_unix modules "account" mode that was
refusing the access because when the password map returns an "x" in the
password field, a shadow entry must be available for pam_unix to verify
the expiry status of the password.

When you are disconnected from the LDAP server you don't have shadow
entries so pam_unix fails the "account" checks which denies login.

This is why I started the other thread about having nss_ldap not return
a "x" for the password when the shadow map is not available/desired.
Which just happens to be all of the time when you are using Kerberos.

>  Authentication and authorization
> are two totally separate chains of events.

Understood, very well.

> You need to set up 'pam_ldap' and 'pam_ccreds', which will run in
> parallel with 'nscd' and 'nss_ldap(d)'.

But neither of those deals with the shadow map problem.

> nscd caches the group-to-GID
> and user-to-UID mappings, and 'pam_ccreds' caches the LDAP creds and
> bind results.

Right.  And nothing caches the shadow map for pam_unix's account module,
hence the need for the "broken_shadow" hack or more properly the ability
to disable the "x" in the password field of the passwd map on
configurations that don't really need or want shadow functionality.

> I can't speak to Ubuntu-specific issues, I don't have a lot of
> experience there, but I've seen a decent number of bugs in the PADL
> suite and nscd, in the last few years. Maybe Launchpad has a ticket
> from between those two releases that explains the difference?

No, it's quite easily the bug you mentioned earlier in that something
needs to probe all cache entries at least once per TTL or they get
dropped.

> Can I suggest something? If you haven't already gotten in touch with
> someone who's using LDAP authen and authn caching (pam_ldap and
> pam_ccreds), it might be worthwhile to re-phrase that issue as a
> separate question on the list. I can show you how I do authen, but my
> bag is all Kerberos, and it sounds like you're probably headed for an
> all-LDAP setup.

No.  I authenticate with Kerberos as well.  And everything works just
fine for all of my clients except the disconnected ones (only when
disconnected of course), so I have everything set up as I need it.  It's
just this nscd and dropping cached entries when it shouldn't be
silliness that is punching a hole in the solution.

nscd really does seem like it would complete the solution if it didn't
suffer from redhat bug 2132.

Cheers,
b.