Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 199188

Summary: OpenLDAP with Linux Authentication - shadowMax variable not handled properly
Product: Red Hat Enterprise Linux 4 Reporter: Michael Romero <mike.l.romero>
Component: nss_ldapAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED NOTABUG QA Contact: Jay Turner <jturner>
Severity: urgent Docs Contact:
Priority: medium    
Version: 4.0CC: jplans, srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-07-17 22:52:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michael Romero 2006-07-17 20:47:48 UTC 
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.
Comment 1 Nalin Dahyabhai 2006-07-17 21:14:07 UTC 
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...
Comment 2 Michael Romero 2006-07-17 22:38:03 UTC 
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 :)
Comment 3 Nalin Dahyabhai 2006-07-17 22:52:10 UTC 
Excellent!  I'll mark this as not-a-bug then.  Thanks!