Bug 23880 - LDAP keeps making you change your password
Summary: LDAP keeps making you change your password
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: nss_ldap (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Aaron Brown
Whiteboard: Florence Beta-3
Depends On:
TreeView+ depends on / blocked
Reported: 2001-01-12 15:46 UTC by Wade Minter
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-01-15 21:47:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Wade Minter 2001-01-12 15:46:38 UTC
I set up LDAP during the installer.  Upon the completion of the install, I
logged into the system with my LDAP account and LDAP password.  The system
printed out:

"You are required to change your password immediately (root enforced)"

To the best of my knowledge, we're not requiring this on the LDAP server. 
So I put a new password in, logged out, and logged back in with the new
password.  It immediately printed out:

"You are required to change your password immediately (root enforced)"

And so forth.  Every time I log in, it requires me to change my password. 
I've heard of one-time-passwords, but this is absurd!  ;-)

Obviously, the local machine shouldn't be doing this.

Comment 1 Nalin Dahyabhai 2001-01-12 16:13:00 UTC
Are you using password expiration with shadow password information (i.e., is
your user's object a shadowAccount object)?  If so, what are the contents of the
user's shadowMin, shadowMax, and shadowLastChange attributes?  Somehow it sounds
as if shadowMax is a too-low value to be useful.

Comment 2 Nalin Dahyabhai 2001-01-12 16:13:46 UTC
It's more likely that this is a pam_ldap-related problem than one with the
directory server itself, so I'm tagging this as an nss_ldap bug for now.

Comment 3 Wade Minter 2001-01-12 16:26:36 UTC
shadowMin: not there
shadowMax: 99999
shadowlastchange: 0
shadowexpire: -1
shadowinactive: -1

Comment 4 Nalin Dahyabhai 2001-01-12 16:54:45 UTC
Aaargh.  Those attributes should be MUST instead of MAY.  Please make sure that
the user has userPassword, shadowLastChange (0), shadowMin (0), shadowMax
(99999), shadowWarning (7), shadowInactive (7), shadowExpire (99999), and
shadowFlag attributes defined.
Did you create this account using the migration scripts supplied with OpenLDAP,
or manually?

Comment 5 Wade Minter 2001-01-12 17:26:47 UTC
I've changed all of the attributes except for ShadowMin (which isn't defined
currently in the schema), and get the same problem.

I'm not sure exactly how the account was created - I believe it was manually,
but I'm not sure.

Comment 6 Nalin Dahyabhai 2001-01-12 21:01:30 UTC
Which schema are you referring to?  It's in both RFC2307 and the nis.schema file
included with OpenLDAP 2.x, so I'm not sure what you mean.  At any rate, you'll
want to set shadowLastChange to -1 to have it be ignored when doing
password-aging calculations at login-time.
There's not much point to having shadow information in a directory, since the
passwd-changing program doesn't have full authority over the entry (at least it
shouldn't over the network), and giving the user the privileges to change
shadowLastChange directly defeats the purpose of having it there at all since a
user can just adjust the attribute instead of changing her password.

Comment 7 Glen Foster 2001-01-15 21:47:16 UTC
This defect is considered MUST-FIX for Florence Beta-3

Comment 8 Nalin Dahyabhai 2001-01-16 17:57:55 UTC
Well, since I'm now convinced that shadow information in LDAP is a very bad
idea, resolving as WONTFIX seems to be appropriate.

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