With LDAP server stopped, local authentication fails...

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

 



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.




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux