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.
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.
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.
shadowMin: not there shadowMax: 99999 shadowlastchange: 0 shadowexpire: -1 shadowinactive: -1
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?
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.
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.
This defect is considered MUST-FIX for Florence Beta-3
Well, since I'm now convinced that shadow information in LDAP is a very bad idea, resolving as WONTFIX seems to be appropriate.