Bug 199188 - OpenLDAP with Linux Authentication - shadowMax variable not handled properly
Summary: OpenLDAP with Linux Authentication - shadowMax variable not handled properly
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nss_ldap
Version: 4.0
Hardware: All
OS: Linux
medium
urgent
Target Milestone: ---
: ---
Assignee: Nalin Dahyabhai
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-07-17 20:47 UTC by Michael Romero
Modified: 2015-01-08 00:13 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-07-17 22:52:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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!


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