Red Hat Bugzilla – Bug 199188
OpenLDAP with Linux Authentication - shadowMax variable not handled properly
Last modified: 2015-01-07 19:13:30 EST
Description of problem: I have built an OpenLDAP environment for Linux System Authentication. I just discovered that the shadowMax variable used within LDAP is not handled the same with the corresponding /etc/shadow field is handled. I am expecting to be able to put in a number i.e. "30" in the shadowMax field within LDAP and have it mean that the password will expire 30 days from the day it was last modified. All of the documentation I am referencing on the net is saying that this should be the behavior I should be expecting as well. What I have found is that if you set it to "30", it ALWAYS believes its expired because what its actually taking the difference from shadowLastChange and shadowMax and looking for the difference between those two values to determing when the password expires. i.e. if the last time I changed my password showed up as 13377 and that was my shadowLastChange value, a 30 day expiration for the shadowMax variable would need to be 13407. If I create a local user, the /etc/shadow field that should correspond with shadowMax behaves exactly as expected. "30" would mean expiring in 30 days. Version-Release number of selected component (if applicable): nss_ldap-226-10 openldap-2.2.13-4 (linux system client) How reproducible: Every Time Steps to Reproduce: 1. Build an OpenLDAP environment for Linux Authentication. 2. Create a user using the shadowAccount and account objectClasses. 3. Set the password using the "passwd" utility to get a valid date in shadowLastChange. 4. Set the shadowMax field in LDAP to "30" and attempt to login. Actual results: You should be prompted to change your password because your password will appear to have expired. Expected results: You should be able to login successfully and not need to change your password for 30 days. Additional info: I am also using the back-sql module with my LDAP schema and PostgreSQL is my backend.
Can you post the output of "getent shadow username" for an affected user? This sounds as though pam_ldap isn't able to read all of the details from the directory via nss_ldap, and is behaving strangely as a result...
hehe you were onto something when you asked that.. I hadn't used that "getent shadow <username>" command before and when I ran it initially, I got back.. <username>:x::0:13348:7:::0 I saw that it was only seeing the shadowMax value and not shadowLastChange. I then realized that I set the userPassword and shadowLastChange values up with a special ACL. I had... access to attrs=userPassword,shadowLastChange by self write by anonymous auth by * none access to * by * read This allowed the passwd command to write to the shadowLastChange attribute whenever a password was changed but it turns out was blocking the system from reading that value if it wasn't that user.. I changed it to this.. access to attrs=userPassword by self write by anonymous auth by * none access to attrs=shadowLastChange by self write by * read access to * by * read The output of "getent shadow <username>" now showed up with... <username>:x:13317:0:30:7:::0 Tested expiration and it works as expected. Thanks :)
Excellent! I'll mark this as not-a-bug then. Thanks!