[389-users] With LDAP server stopped, local authentication fails...

[Edward Capriolo]

On Thu, Feb 11, 2010 at 2:00 PM,  <patrick.morris at hp.com> wrote:
> Hi Sean!
>
> On Thu, 11 Feb 2010, Sean Carolan wrote:
>
>> > But if --enableldap is changed to --disableldap, then the local users
>> > can log on and run sudo commands fine.  This of course is all while
>> > the LDAP server is down.
>>
>> I may have narrowed down the problem a bit.  Inside /etc/nsswitch.conf
>> there is a line that looks like this:
>>
>> group:      files ldap
>>
>> It's as if the local system is searching for some group data on the
>> ldap server, but is never able to reach it so it just sits there and
>> hangs.  If I remove the 'ldap' part from the end, logins work fine
>> with no issues even when the ldap server is down.
>>
>> So my questions are:
>>
>> 1.  Why is this group line gumming up the entire authentication process?
>> 2.  Do I need "ldap" on the group line?  If I take it out how will it
>> affect my running systems?
>
> Answer to the "Why?" question:
>
> You may have groups in LDAP that you don't have locally.  The server has
> no way to know.  Those groups may include the person who just tried to
> log in.  The only way to know if those groups exist is to look in LDAP
> and run through those groups to see if the person logging in is a member
> of any of them, so it *is* going to try if you've told it to check LDAP
> for group info.
>
> Your basic problem seems to be that that lookup is taking far too long
> to time out when the LDAP server is down. There are a lot of reasons
> this might happen, but with the setup we use here (which is very near
> identical to yours) the connection failure happens really fast, and PAM
> just moves on.  That, of course, assumes the LDAP server is not running
> at all and not listening on port 389, which may or may not fit the
> definition of "down" as you're using it here.
>
> I should also probably note that this has probably not been an issue for
> me with the same setup partially because, here, LDAP's critical, and we
> make sure it's never down by using redundant systems, and it's really
> unlikely here that LDAP will ever be completely unavailable... and since
> we store login information there, I'd fully expect logins to fail if
> LDAP was totally unavailable... I'd actually *want* them to fail, since
> that's the one authoritative source of authentication we use.  In the
> same way, if we used local files, I'd expect logins to fail if someone
> deleted /etc/shadow.
>
> By the way, you don't *need* the ldap in the group spec in
> nsswitch.conf... unless, of course, you want to access group information
> from LDAP, in which case you do.
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

The best you can do here is set 'bind policy soft' ldap conf. Also
enable your chkconfig nscd on. If you are going to do ldap auth make
sure you have an LDAP cluster/farm and a load balancer or some high
availability systems. Things go pretty bad when your LDAP server is
down.