Bug 224048

BTW, I can "su - vonbrand" just fine, and "finger vonbrand" and "ls ~vonbrand"
work too, so it isn't that just that access to the account data is hosed.
/etc/nsswitch has:

   passwd:     files ldap
   shadow:     files ldap
   group:      files ldap

> It seems the updated pam still let the infamous ssh scanners enter the tomcat
> account (with !! in /etc/shadow). Need to confirm if they left some backdoor.

That would be pretty bad, but I cannot reproduce that problem anymore here.
Probably they installed some backdoor. You also cannot know for sure whether
there is no local exploit with which they got to root account then. So it would
be better to reinstall the system from scratch.

For the main topic of this bug report - I tried to reproduce and it seems to
work fine here. I have some questions - do you use pam_ldap in the pam
configuration? And can you change the password in LDAP and try whether the new
one works? If the old password isn't too valuable for you could also mail that
password to me along with the 'getent shadow vonbrand' and 'getent passwd
vonbrand' output so I could do more tests.

Hummm... /etc/pam.d/system-auth{,-ac} don't even mention pam_ldap, in fact, that
string doesn't match anything in /etc/pam.d/*. I did set up LDAP authentication
with authconfig-tui (authconfig-5.3.13-1.fc7), just double-checked. Seems that
one is broken...

What should the configuration look like? The examples with nss_ldap-253-4 are
wildly out of date...

I have tested the LDAP authentication checkbox with authconfig-tui (although the
tui is deprecated) and it seems to work fine here with authconfig-5.3.13-1.fc7.

1. What your /etc/sysconfig/authconfig contains?
2. If it contains USELDAPAUTH=no - are you sure you have checked the 'Use LDAP
Authentication' check box and not only the 'Use LDAP' one?
3. If it is checked properly. Can you try to uncheck it and then check it again
if it helps?

The pam config should look like:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet
use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so

2. USELDAPAUTH=yes

Unchecking "Use LDAP Authentication", OKing, and running it again, this time
checking it, fixed both local and ssh login. authconfig-tui is broken. Why is it
deprecated? Not every machine has X and stuff, and using plain authconfig is
rather confusing. The poor sysadmin needs help here, and this doesn't just fix
one configuration file but touches many of them.

3. The pam_ldap line was missing, as I suspected.

Thank you very much!

The question is why got the system-auth-ac broken and when. I am afraid that
without this information it's hard to fix that problem. I'm also curious how the
pam upgrade is related to that problem or not.

The machine had LDAP logins from the beginning, maybe the latest PAM update
broke it? It's the closest change (time-wise) that I remember.

Some more questions. Does getent passwd vonbrand and getent shadow vonbrand show
something meaningful in the password hash field? And if yes, if you create a new
local test user with that password hash, can you log in to this user with your
password?

Also in the process of fixing the hole with !! accounts did you remove pam and
installed another version or just always upgraded (never mind if with rpm
--oldpackage)?

Sorry, can't check now (machine is turned off for vacations here).

I "fixed" that one by shutting off net access (iptables allowing only local
incoming traffic). Only rpm updates.

This is impossible to fix without a reproducer. Perhaps it was some intermittent
glitch in authconfig or other thing.
Closing as CANTFIX.