Bug 694311

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_ldapAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: high Docs Contact:
Priority: high    
Version: 5.5CC: 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:
Description Flags
Proposed patch
none
New proposed patch none

Description Pierre Carrier 2011-04-06 23:26:05 UTC
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?).

Comment 1 Pierre Carrier 2011-04-06 23:31:44 UTC
Created attachment 490435 [details]
Proposed patch

Comment 5 Pierre Carrier 2011-04-10 13:40:31 UTC
A (probably unusable yet) implementation of this feature for sssd:

https://fedorahosted.org/pipermail/sssd-devel/2011-April/005961.html

-- 
Pierre

Comment 8 Pierre Carrier 2011-04-13 15:09:58 UTC
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

Comment 9 Pierre Carrier 2011-04-18 11:16:22 UTC
*** Bug 697465 has been marked as a duplicate of this bug. ***

Comment 10 Pierre Carrier 2011-04-18 11:25:14 UTC
Created attachment 492859 [details]
New proposed patch

Comment 13 RHEL Program Management 2011-07-05 19:55:11 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.