passwd -S with LDAP - always locked user

SUSE Product Topics SLES Configure-Administer
1

I’m not sure if this is configuration problem or general tool deficiency. When I have users in LDAP with shadowAccount class, “passwd -S” will always show password status as LK (locked) even though user has valid password. As examplehtest:~ # passwd -S user user LK 04/24/2014 0 10000 30 -1butobjectclass : top person posixAccount shadowAccount userpassword : {crypt}$1$85Y1T7VB$wbMtouL9wVjcVwtrEHCD20 uid : user
This is SLES11 SP3. Anyone else?

2

Hi aborzenkov,

[QUOTE=aborzenkov;20799]I’m not sure if this is configuration problem or general tool deficiency. When I have users in LDAP with shadowAccount class, “passwd -S” will always show password status as LK (locked) even though user has valid password. As examplehtest:~ # passwd -S user user LK 04/24/2014 0 10000 30 -1butobjectclass : top person posixAccount shadowAccount userpassword : {crypt}hashremovedforsecurityreasons uid : user
This is SLES11 SP3. Anyone else?[/QUOTE]

I’m currently off-site and have only a SLES11SP1 system to look at (not even able to actually play with the LDAP server).

The account I was looking at had no shadowAccount class and reports “LK”, too. I can see that passwd is looking for the attributes shadowLastChange, shadowMax, shadowMin, shadowWarning, shadowInactive, shadowExpire and shadowFlag, which are of course not available in my case. I assume that a failure to report these values is interpreted in a “worst case” fashion, hence the “LK”.

You might want to check if “passwd -S” reports differently when you enter valid values for these attributes (shadowFlag is “reserved for future use”, iirc) - have a look at /etc/shadow to get an idea for proper values.

If filling these attributes helps, the remaining question is why these aren’t filled in by the system. Have you set up the server (the one where you’re running “passwd” via bind DN and password; the LDAP service via ACLs) so that the system has write access to the according LDAP entries?

Regards,
Jens

3

[QUOTE=jmozdzen;20801]
The account I was looking at had no shadowAccount class[/quote]
shadowAccount was probably red herring (although passwd -S likely makes little sense without it). [quote]I can see that passwd is looking for the attributes shadowLastChange, shadowMax, shadowMin, shadowWarning, shadowInactive, shadowExpire and shadowFlag,[/quote]
Exactly - no userPassword. What happens is, as Unix has no “account locked” passwd field, passwd bases decision on content of password field. In case of nss_ldap if userPassword attribute is missing, it returns “*” - which is one way of “locking” user account (by preventing it from ever authenticate). Depending on ACLs on userPassword, nss_ldap may not be able to read it, even if running as root. In our case userPassword is basically restricted to authentication and writing by owner which explains why nss_ldap was not able to fetch it. For testing I added ACL allowing specific DN read access and made nss_ldap bind as this DN with expected results:user1 PS 03/05/2013 0 10000 30 -1 user2 PS 03/12/2014 0 10000 30 -1
Unfortunately there is no way to explicitly make authenticated bind when running passwd, and I have no influence of LDAP server policy or ACLs (or content of /etc/ldap.conf for that matter).