Bug 63631 - authconfig setup for LDAP blocks root if LDAP server down
authconfig setup for LDAP blocks root if LDAP server down
Status: CLOSED DUPLICATE of bug 55193
Product: Red Hat Linux Beta
Classification: Retired
Component: authconfig (Show other bugs)
beta1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
:
Depends On:
Blocks: 63717
  Show dependency treegraph
 
Reported: 2002-04-16 11:43 EDT by Chris Adams
Modified: 2007-04-18 12:42 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-15 03:36:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to /etc/pam.d/system-auth which fixes the local login problems if the LDAP server for authentication is not accessible (1.01 KB, patch)
2003-07-22 09:01 EDT, Nils Philippsen
no flags Details | Diff

  None (edit)
Description Chris Adams 2002-04-16 11:43:52 EDT
The authconfig program puts the following in /etc/pam.d/system-auth if LDAP is
configured:

account     [default=bad success=ok user_unknown=ignore service_err=ignore
system_err=ignore] /lib/security/pam_ldap.so

The problem is if the LDAP server is down, even local users cannot log in
(including root).  So if the LDAP server is on the local system and it crashes
or stops for any reason, the only fix is to power cycle the system.

If "authinfo_unavail=ignore" is added, then local users can still log in when
the LDAP server is down.

The only way this would be a bad thing is if you have the same users in both the
passwd file and in LDAP and you expect the LDAP entry to "override" the local
entry (and that is just asking for trouble anyway).
Comment 1 Christian Thibodeau 2002-04-23 18:34:03 EDT
authconfig also adds a similar entry for Kerberos if kerberos is setup.

account     [default=bad success=ok user_unknown=ignore service_err=ignore
system_err=ignore] /lib/security/pam_krb5.so

root access is denied at the console when that line exists in the system-auth
file. root is not an account defined in Kerberos. I have another account on the
system which is also not defined in kerberos but this account can login.

Also, this prevents use of sudo to access root (I get an Incorrect password from
su when I try to execute /usr/bin/sudo /bin/su - )

Only by commenting out that line can I allow root access to the console and also
allow root access from sudo.
Comment 2 Pawel Salek 2002-06-16 05:53:53 EDT
I confirm this problem exists with 7.3 as well.

The problem might be though with pam package though, not with ldap. See
discussion at
http://www.netsys.com/pamldap/2002/04/msg00026.html
Comment 3 Joshua Jensen 2003-01-06 15:13:49 EST
I've seen this behavior since 7.1 or 7.2.  nsswitch is being totally ignored
when it comes to ldap authentication

This is still a problem in the current beta of 8.1
Comment 4 Chris Ricker 2003-01-07 00:48:54 EST
See also:

Bug 71546: ldap for user files always used, regardless of nsswitch.conf
Bug 66682: nis for user files always used, regardless of nsswitch.conf
Bug 58562: nis for host files always used, regardless of nsswitch.conf
Comment 5 Chris Ricker 2003-01-07 00:50:15 EST
Oops, that should be

Bug 58568: nis for host files always used, regardless of nsswitch.conf
Comment 6 Tommy McNeely 2003-01-07 01:14:59 EST
I am using the "ass" map... it is obvious that redhat does not really even use
/etc/nsswitch.conf except maybe for gethostbyname type lookups... it still
allows me to finger and login from remote (and I tried logging in with a user
account that has never logged into this machine since it was built so its not nscd)


[root@cookies root]# finger -m tommy
Login: tommy                            Name: Tommy McNeely
Directory: /home/tommy                  Shell: /bin/bash
On since Fri Dec 20 23:25 (MST) on tty1     16 days 22 hours idle
Last login Mon Jan  6 13:41 (MST) on pts/12 from pickles.local.redneck.nu
No mail.
No Plan.
[root@cookies root]# grep passwd /etc/nsswitch.conf
#passwd:    db files nisplus nis
passwd:     ass



Tommy
Comment 7 Tommy McNeely 2003-01-07 01:22:56 EST
sorry... itchy trigger finger .. here is a "working" example on another OS

I assure you the below users are valid either in LDAP or local (for root)

[root@icecream root]# finger tommy
Login name: tommy                       In real life: ???
[root@icecream root]# finger scott
Login name: scott                       In real life: ???
[root@icecream root]# finger jeff
Login name: jeff                        In real life: ???
[root@icecream root]# finger root
Login name: root                        In real life: ???


[root@icecream root]# grep ^passwd /etc/nsswitch.conf
passwd:         ass

[root@icecream root]# uname -a
SunOS icecream 5.9 Generic_112233-01 sun4u sparc SUNW,Ultra-5_10


:p
Comment 8 Panu Matilainen 2003-01-21 05:39:42 EST
There's been quite a lot of discussion about this on nss_ldap mailing list, for
example see http://www.netsys.com/nssldap/2002/06/msg00029.html. Suggested fix
is (a) use an LDAP client library with adjustable connect timeout and (b) adjust
that timeout appropriately to "maximise the user experience".
Comment 9 Nils Philippsen 2003-07-22 09:01:31 EDT
Created attachment 93042 [details]
Patch to /etc/pam.d/system-auth which fixes the local login problems if the LDAP server for authentication is not accessible

Same patch as in #63717
Comment 10 Chris Ricker 2003-08-25 17:19:50 EDT
This appears to be fixed in severn / rawhide.... If I pull the network cable on
my LDAP client system, then boot it, I can still log in using my root account
from /etc/passwd && /etc/shadow
Comment 11 Jost Diederichs 2003-12-18 00:14:14 EST
Yes, the above patch fixes the problem, thank you.
However, the "authconfig" program still messes up the file
/etc/pam.d/system-auth if ldap is chosen. 
authconfig needs to be fixed. 
Comment 12 Matthew Miller 2004-03-30 10:01:22 EST
So, should this be marked as a duplicate of bug #55193 (the "fix
authconfig" bug)?
Comment 13 Tomas Mraz 2004-10-15 03:32:46 EDT

*** This bug has been marked as a duplicate of 55193 ***

Note You need to log in before you can comment on or make changes to this bug.