Bug 224048 - Can't login with account on LDAP
Can't login with account on LDAP
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
rawhide
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Tomas Mraz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-23 15:20 EST by Horst H. von Brand
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-06 10:19:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Horst H. von Brand 2007-01-23 15:20:45 EST
Description of problem:
I can't login to my x86_64 machine, not locally and not over ssh. My account is
managed by LDAP. I can login to root (in files), and I can login to other
machines on the net (same LDAP setup, either up-to-date Aurora Corona or CentOS
4.4).

Version-Release number of selected component (if applicable):
pam-0.99.7.0-2.fc7

How reproducible:
Always

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Via ssh, in /var/log/secure:

   Jan 23 17:14:17 quelen sshd[3680]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=laptop13.inf.utfsm.cl
user=vonbrand
   Jan 23 17:14:19 quelen sshd[3680]: Failed password for vonbrand from
200.1.19.201 port 55735 ssh2
   Jan 23 17:14:29 quelen last message repeated 2 times
   Jan 23 17:14:29 quelen sshd[3681]: Connection closed by 200.1.19.201

On tty1:

   Jan 23 17:16:38 quelen login: pam_unix(login:auth): authentication failure; logn
ame=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost=  user=vonbrand
   Jan 23 17:16:40 quelen login: FAILED LOGIN 1 FROM (null) FOR vonbrand, Authentic
ation failure

I've been known to mistype my password, but not this many times in a row.

Expected results:


Additional info:
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.
Comment 1 Horst H. von Brand 2007-01-23 15:29:06 EST
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

Comment 2 Tomas Mraz 2007-01-25 04:33:46 EST
> 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.
Comment 3 Horst H. von Brand 2007-01-26 11:37:46 EST
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...
Comment 4 Tomas Mraz 2007-01-26 12:16:58 EST
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
Comment 5 Horst H. von Brand 2007-01-26 12:35:01 EST
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!



Comment 6 Tomas Mraz 2007-01-26 13:42:19 EST
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.
Comment 7 Horst H. von Brand 2007-01-26 15:34:52 EST
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.
Comment 8 Tomas Mraz 2007-01-26 16:03:45 EST
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)?
Comment 9 Horst H. von Brand 2007-01-27 09:23:20 EST
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.
Comment 10 Tomas Mraz 2007-02-06 10:19:17 EST
This is impossible to fix without a reproducer. Perhaps it was some intermittent
glitch in authconfig or other thing.
Closing as CANTFIX.

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