From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 Description of problem: I configured my system to use LDAP authentication during install and was unable to logon to the machine using the local root account. I booted in single user mode and ran authconfig (still choosing to allow LDAP) and still could not logon. The file /etc/pam.d/system-auth had the line "account required /lib/security/pam_ldap.so" I changed this to "account sufficient /lib/security/pam_ldap.so" and now it is working as desired. If this configuration is intentional, I would request authconfig be modified to allow a choice between required and sufficient, otherwise it is not possible to logon to the machine without LDAP connectivity. I had, for instance, chosen to use TLS but our LDAP directory seemingly doesn't support it, so I was unable to logon in any way (other than single user mode). Version-Release number of selected component (if applicable): authconfig-4.1.19-1 How reproducible: Didn't try Steps to Reproduce: 1.run /usr/sbin/authconfig 2.choose "Use LDAP" 3.enter your LDAP server and base DN 4.reboot and attempt to logon to machine with an account in /etc/passwd but not in the LDAP directory (such as root) Actual Results: I was unable to logon to machine Expected Results: I should have been able to logon as root, using the local account information in /etc/passwd & /etc/shadow Additional info:
I confirm this problem. The old behaviour was to still allow a fallback to the /etc/passwd /etc/shadow when the ldap server is down. Now it falls back to those files only if the ldap server is running, not if it cannot be contacted. Here's what the logs give : Oct 30 15:01:37 localhost login: pam_ldap: ldap_simple_bind Can't contact LDAP server Oct 30 15:01:37 localhost login: Error in service module
I confirm this as well. If you do not set account to sufficient under account, the system will not be accessible when the ldap server is down. This has given me two headaches thus far. ;)
Created attachment 51645 [details] Patch which solves this - see the README.ldap_required file it creates!
Confirmed for me too. Though for me, authconfig creates "account sufficient" for pam_ldap.so after "account required" for pam_unix.so. Modifying the auth commands doesn't work until I reverse the account commands.
I've confirmed this behavior in 7.2, 7.3, and the Advanced Server beta. It looks like they changed the system-auth a bit in 7.3, as it now contains this line: account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/pam_ldap.so I assume this was an attempt at fixing this particular issue, but yet again, if the LDAP server is down, root cannot log in at the console.
Same problem here with RHL 8.0. I've resolved with this line: account [... authinfo_unavail=ignore ...] /lib/security/pam_ldap.so
Created attachment 81986 [details] This patch adds authinfo_unavail=ignore to LOGIC_IGNORE_UNKNOWN in authinfo.c. Should work for every network-based authentication configured with authconfig.
Confirmed that this issue still exists in Red Hat 9, authconfig-4.3.4.
Can we please, please, please get an updated authconfig package? I can confirm that this problem affects all of Red Hat Linux releases 7.3, 8.0, and 9. This is compounded, I believe, by nscd, which will cache DNS failures for a very long time. If there is a minor network outage, which causes the LDAP server to become unavailable, you will apparently *never* be able to log in as any user again. You must reboot the box. This situation sucks. A lot. I can also confirm that the patch attached to this bug on 2002/10/24 resolves the issue. Nalin~ Is there anything we can do to help you resolve this issue? Do you need a test case which will reliably reproduce this problem?
I'm not sure this is the right way to patch this problem.... instead of adding "authinfo_unavail=ignore" to the account definition for pam_ldap, you can instead change the preceding line for pam_unix from: account required /lib/security/$ISA/pam_unix.so to: account sufficient /lib/security/$ISA/pam_unix.so which seems more in keeping with the intentions of the PAM designers. I have not emailed Andrew about this, though. Regardless, the pam options for ldap in system-auth clearly need to be reworked, and the configuration used by authconfig in Red Hat 7.2 - 9.0 is b0rked and is generating lots of bugzilla traffic because pam affects so many other things.
*** Bug 77575 has been marked as a duplicate of this bug. ***
For the record, this ain't just an LDAP problem. Happens with kerberos too. I asssume it's "required" instead of "sufficient" to prevent timing-based information-gathering attacks, so the authinfo_unavail=ignore solution might be best.
Does anyone have an RPM package with the authinfo_unavail=ignore fix? We have a lot of machines authenticating off of LDAP with rh9 and I'd like not to roll out a patch machine-by-machine -- would much prefer to have an rpm on our kickstart/update server. -alan
Sure, check here: http://phantom.dragonsdawn.net/~gordon/authconfig/ There's binary and source packages, but I recommend (for your own security) that you just grab the spec that's appropriate for your system, and the patch. Compare the spec to the one in the src.rpm available from Red Hat, and then use it to build your own binaries.
There are three things I've done to ensure my local users can always log in: 1) the authinfo_unavail=ignore solution 2) adding a line "account sufficient /lib/security/pam_localuser.so" 3) Make sure your ldap servers are listed in /etc/hosts. #3 is very important, because if the DNS servers are down, or you're disconnected from your network, the login will timeout on the DNS lookup, and your login will fail, even if you are root.
Fifty-two months and three redhat major releases after this bug was opened, I can confirm it's still present in flagship RHEL 3 U1. The cause is known, the simple half-line patch is there, now perhaps someone can incorporate it in the distribution so we can waste our time on the next annoyance instead. Since 9 is almost EOL an RHEL is "actively supported" <cough>, the bug should be moved to RHEL.
Don't hold your breath, Zenon! I don't think Nalin reads Bugzilla. He's very talented but he's either overloaded with work or his priorities are screwed.
I'd just like to confirm that this bug is still there in Fedora Core 1. I haven't checked the -test releases of FC2 (at time of writing FC2-test1 is the most recent version). I've been carrying the fix for this (I use the autoinfo_unavail=ignore option) in my config files for years now (RH 7.3, 8.0, 9, AS 3, FC1), and I'd really like to drop it.
I can confirm that this is still a problem in FC2-test2. This is a very significant problem, as it prevents local root logins for emergency problem solving when the network is down -- not cool at all. And as mentioned above, it's not just LDAP -- Kerberos, too. authinfo_unavail, not autoinfo, btw. :)
Indeed this is a real nasty of a bug... would appreciate seeing an official update for RH9, EL3 etc.
Suggest changing summary to: "PAM config for network auth blocks all *local* logins when network is down [has patch]"
The authinfo_unavail patch solves this problem, but the account section of system-auth seems out of place relative to the others. Auth and passwd both mark the local and network authentication modules as sufficient, and then place a required "deny" at the end of the stack. The same should work for the account stack.
*** Bug 112212 has been marked as a duplicate of this bug. ***
*** Bug 103461 has been marked as a duplicate of this bug. ***
*** Bug 118239 has been marked as a duplicate of this bug. ***
The authinfo_unavail fix did not work for me and I figured out why. I had configured my ldap servers in the following way: host ldap1 ldap2 By using domain names rather than IPs, I guess that I'm getting a different error code in pam_ldap, related to the name resolution failure. What about using the solution described in bug 118239?
I just tried another approach. Instead of setting all those behaviors, only set behaviors for default and success: account [default=ignore success=ok] /lib/security/$ISA/pam_ldap.so on my Test-System it looks allright, but I don't know whether this breaks security or not. Can anybody confirm that this is still safe? I', not sure about this. Charles: Can you confirm this fixes the Bug for your scenario? Matthew: Does this still prevent the "timing-based information attacks" you mentioned earlier? I think it does, but I am not a security expert.
Re: comment #14 Following these three steps still keeps root locked out of a "Red Hat Enterprise Linux AS release 3 (Taroon)" configured for LDAP authentication if the network connection becomes unavailable. Either login(1) times out before DNS does or we're still stuck in pam_ldap, and since none of the above log at all, it's kind of hard to tell.
It would appear that the culprit is not, in fact, pam_ldap.so, but pam_unix.so, and as long as you touch it if the local host's network connection goes down, you're screwed, because pam_unix.so calls getpwname() which, in turn, calls LDAP, which is where we die. See http://www.netsys.com/pamldap/2002/04/msg00026.html.
We just lost our connection to our ldap servers and I had to manually reboot each of my file servers to single user mode in order to login as root. This seems like a huge bug to me. My manager just asked me why this bug has been outstanding for two and a half years on a product labelled "enterprise"? I don't have an answer for him.
Confirming this bug still exists in Fedora Core 2 test3 and will probably still exist in Core 2 :-(. How do other distributions handle this?
Maybe Nalin no longer maintains this component? Re-assigning needed?
In September 2002 I went to a AUUG conference and listened to a talk "Polythene PAM ain't what she used to be". This problem was described then. Nalin is mentioned in the paper. http://meltin.net/people/martin/publications/polythenepam.pdf I don't know if the workaround in the paper solves the problem.
The workaround in the paper referenced in #32 works for me. Mostly... I still have the problem that if I kill the network, log in as root (which works, thanks to the config above), and do an ls -la, it hangs. Apparently the ls can't get the uid/gid information. If I kill nscd, then I get raw numbers back as expected. Maybe there is something I can tweak in nscd.conf so that lookups fail faster? Also, this bug MAY be fixed in FC2... I have some FC2 machines here (the rest are 90% Redhat9 with a few FC1) and they could log in as root when ldap died.... Don't knw about the ls -la thing though...
Note: Authconfig from Fedora Core 2 has a partial fix -- the account section begins with: account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 Which should cure the problem for system accounts. Personally, pam_localuser seems like a better (more comprehensive and more specific) choice, but it's possible that there's further implications of that.
Do not use pam_succeed_if as discussed above if you are using NIS and nsswitch.conf in compat mode as logins for users in more than 8 groups will fail. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125653
"Authconfig from Fedora Core 2 has a partial fix -- the account section begins with: account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 Which should cure the problem for system accounts." This does not fix the problem on FC3-Test2. Root login attempt times out in about 50 seconds.
"1) the authinfo_unavail=ignore solution 2) adding a line "account sufficient /lib/security/pam_localuser.so" 3) Make sure your ldap servers are listed in /etc/hosts." The above works on FC3-Test2: account required /lib/security/$ISA/pam_unix.so account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 account [default=bad success=ok user_unknown=ignore service_err=ignore authi nfo_unavail=ignore ] /lib/security/$ISA/pam_ldap.so account required /lib/security/$ISA/pam_permit.so account sufficient /lib/security/$ISA/pam_localuser.so ls is hanging for about a second when LDAP is unavailable. :(
This now works fine for system accounts (uid<100) when using current authconfig and pam packages. Enabling it for all local users is WONTFIX as it would be a security problem.
*** Bug 121944 has been marked as a duplicate of this bug. ***
*** Bug 63631 has been marked as a duplicate of this bug. ***
*** Bug 122700 has been marked as a duplicate of this bug. ***
*** Bug 100504 has been marked as a duplicate of this bug. ***
*** Bug 53796 has been marked as a duplicate of this bug. ***
These fixes do work, if /usr is mounted locally. We are running of a nfs mounted /usr, the pam modules are linked to shared libraries in /usr, so if the network is down not even root can login to the system. This is an issue for me.