| Summary: | Native AD password policy attributes break shadow entries on forced password change, preventing login | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Pierre Carrier <prc> | ||||||
| Component: | nss_ldap | Assignee: | Nalin Dahyabhai <nalin> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 5.5 | CC: | cww, dpal, jplans, prc, sgallagh | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 697465 697468 719107 (view as bug list) | Environment: | |||||||
| Last Closed: | 2011-07-05 19:55:11 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 719107 | ||||||||
| Attachments: |
|
||||||||
Created attachment 490435 [details]
Proposed patch
A (probably unusable yet) implementation of this feature for sssd: https://fedorahosted.org/pipermail/sssd-devel/2011-April/005961.html -- Pierre This does fix the nss information, but there's an issue with pam. I'm trying to quickly implement support there right now. Based on https://fedorahosted.org/pipermail/sssd-devel/2011-April/005965.html looks like the non-zero values where broken too, I'm looking into that. -- Pierre *** Bug 697465 has been marked as a duplicate of this bug. *** Created attachment 492859 [details]
New proposed patch
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. |
Description of problem: - When mapping shadowLastChange to pwdLastSet: - shadow entries break for passwords set before 1970 (negative value) :) - forcing a password change in ADS does not force a password change in pam but breaks login instead Version-Release number of selected component (if applicable): From 208 to now How reproducible: 100% Steps to Reproduce: 1. In ADS, check for a user foo "User must change its password at next login" 2. Configure nss_ldap against this ADS, including mapping shadowLastChange to pwdLastSet) 3. Do a "getent shadow foo" 4. Try to login Actual results: 1. In "getent shadow foo", one gets: foo:*:-134774::99999::::0 2. When opening a session (here through ssh), one gets in /var/log/secure: Jan 1 00:00:00 example sshd[2]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=example.com user=foo Jan 1 00:00:00 example sshd[2]: pam_ldap: error trying to bind as user "CN=foo,OU=users,OU=demo,DC=example,DC=com" (Invalid credentials) Apr 1 00:00:00 example sshd[2]: Failed password for foo from 10.1.2.3 port 612345 ssh2 Expected results: 1. In "getent shadow foo", one should get: foo:*:0::99999::::0 2. When logging in, a password change is forced. $ ssh foo foo's password: You are required to change your password immediately (root enforced) Last login: Wed Dec 31 23:00:00 2010 from example.net WARNING: Your password has expired. You must change your password now and login again! Changing password for user foo. Changing password for foo. (current) UNIX password: Additional info: 1. From nss_ldap upstream ChangeLog, for 208: * add support for native Active Directory password policy attributes (enabled if shadowLastChange is mapped to pwdLastSet) 2. From shadow(5), date of last password change [...] The value 0 has a special meaning, which is that the user should change her pasword the next time she will log in the system. 3. From http://msdn.microsoft.com/en-us/library/ms679430(v=vs.85).aspx : If this value is set to 0 and the User-Account-Control attribute does not contain the UF_DONT_EXPIRE_PASSWD flag, then the user must set the password at the next logon. 4. Please find patch attached. It handles the value 0 in ADS (Jan 1, 1601) as the special value 0 in shadow (Jan 1, 1970), and any date before Jan 1, 1970 as Jan 2, 1970 (but who cares?).