Bug 1018944 - [RFE] Enhance password change tracking
[RFE] Enhance password change tracking
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
7.0
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Noriko Hosoi
Viktor Ashirov
Petr Bokoc
: FutureFeature
: 1018943 (view as bug list)
Depends On:
Blocks: 1203710 1205796 1317686
  Show dependency treegraph
 
Reported: 2013-10-14 14:42 EDT by Rich Megginson
Modified: 2016-11-03 16:33 EDT (History)
8 users (show)

See Also:
Fixed In Version: 389-ds-base-1.3.5.5-1.el7
Doc Type: Enhancement
Doc Text:
Changing a user password now always updates the `shadowLastChange` attribute Previously, some ways of changing a user's password could update the `passwordExpirationTime` attribute but not the `shadowLastChange` attribute. Some systems which can interface with Directory Server, such as Active Directory, expect both attributes to be updated, and therefore this behavior could lead to synchronization errors. With this update, any change to a user password updates both attributes, and synchronization problems no longer occur.
Story Points: ---
Clone Of:
: 1317686 (view as bug list)
Environment:
Last Closed: 2016-11-03 16:33:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 500723 None None None Never

  None (edit)
Description Rich Megginson 2013-10-14 14:42:00 EDT
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/548

Currently the AD password sync does not update the shadowLastChange attribute.
Comment 1 Noriko Hosoi 2014-03-17 14:38:46 EDT
*** Bug 1018943 has been marked as a duplicate of this bug. ***
Comment 11 Ron van der Wees 2014-10-17 03:43:37 EDT
Rich, Appreciate your feedback on c#10.
Comment 12 Rich Megginson 2014-10-17 09:53:50 EDT
It should be possible to add shadowLastChange.  This bug is an RFE for RHEL7 and will be triaged accordingly for 7.2
Comment 17 Mike McCune 2016-03-28 19:11:51 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 19 Sankar Ramalingam 2016-08-29 03:55:40 EDT
Shadowlastchange attribute is added when the password is changed.

Global password policy

1). New user - Change userpassword
dn: uid=allnew2,ou=People,dc=passsync,dc=com
uid: allnew2
objectClass: shadowAccount
shadowLastChange: 17037
shadowMin: 0
shadowMax: 0
shadowWarning: 1
shadowExpire: 17042

2). Existing user with no shadowAccount objectClass - add missing shadowAccount objectClass and change the password.

dn: uid=noshadow2,ou=People,dc=passsync,dc=com
objectClass: shadowAccount
shadowLastChange: 17042
uid: noshadow2
givenName: noshadow2
shadowMin: 0
shadowMax: 0
shadowWarning: 1
shadowExpire: 17042
Comment 20 Sankar Ramalingam 2016-09-01 11:26:35 EDT
ShadowLastChange attribute is added/updated for subtree password policy as well

[root@ibm-x3650m4-01-vm-03 MMR_WINSYNC]# PORT=1189 ; /usr/bin/ldapsearch -x -p $PORT -h localhost -D "cn=Directory Manager" -w Secret123 -b "ou=people,dc=testpw,dc=com" |egrep 'dn:|shadowLastChange:'
dn: ou=People,dc=testpw,dc=com
dn: cn=nsPwPolicyContainer,ou=People,dc=testpw,dc=com
dn: uid=subtrpwp3,ou=People,dc=testpw,dc=com
dn: uid=subtrpwp2,ou=People,dc=testpw,dc=com
dn: uid=subtrpwp1,ou=People,dc=testpw,dc=com
dn: uid=shdwsubtrpwp3,ou=People,dc=testpw,dc=com
shadowLastChange: 17045
dn: uid=shdwsubtrpwp2,ou=People,dc=testpw,dc=com
shadowLastChange: 17045
dn: uid=shdwsubtrpwp1,ou=People,dc=testpw,dc=com
shadowLastChange: 17045

Adding shadowLastChange attribute when adding user.

[root@ibm-x3650m4-01-vm-03 MMR_WINSYNC]# PORT=1189 ; /usr/bin/ldapsearch -x -p $PORT -h localhost -D "cn=Directory Manager" -w Secret123 -b "uid=s999p2,ou=Groups,dc=passsync,dc=com" |egrep 'dn:|shadowLastChange:'
dn: uid=s999p2,ou=Groups,dc=passsync,dc=com
shadowLastChange: 1978

Then, modify the password to check if its updated.
[root@ibm-x3650m4-01-vm-03 MMR_WINSYNC]# sleep 0 ; PORT=1189 ; /usr/bin/ldapmodify -x -p $PORT -h localhost -D "cn=Directory Manager" -w Secret123 << EOF                                           
dn: uid=s999p2,ou=Groups,dc=passsync,dc=com
replace: userPassword
userPassword: Secret123
EOF

modifying entry "uid=s999p2,ou=Groups,dc=passsync,dc=com"

[root@ibm-x3650m4-01-vm-03 MMR_WINSYNC]# PORT=1189 ; /usr/bin/ldapsearch -x -p $PORT -h localhost -D "cn=Directory Manager" -w Secret123 -b "uid=s999p2,ou=Groups,dc=passsync,dc=com" |egrep 'dn:|shadowLastChange:'
dn: uid=s999p2,ou=Groups,dc=passsync,dc=com
shadowLastChange: 17045

Verifying from AD is yet to be completed.
Comment 21 Sankar Ramalingam 2016-09-02 15:52:39 EDT
Tested user synchronization with windows 2012 r2 AD setup. Password change from AD is not updating the shadowLastChange attribute in DS.
Test case:
1. Create a working passsync setup with win2012r2
2. Configure global pw policy in DS
3. Create few users to sync to AD with shadowAccount attribute
4. Once its synced to AD, change the password on AD side.
5. Check if shadowLastChange attribute updated for password update from step #4.

Password is not updated.

Adding a new value at DS side for shadowLastChange attribute.
[root@ibm-ls22-03 ~]#  PORT=1189 ; /usr/bin/ldapmodify -x -p $PORT -h localhost -D "cn=Directory Manager" -w Secret123 << EOFdn: uid=nnn4,ou=dswinsync,dc=passsync,dc=com
replace: shadowLastChange
shadowLastChange: 12222
EOF

modifying entry "uid=nnn4,ou=dswinsync,dc=passsync,dc=com"

[root@ibm-ls22-03 ~]#  PORT=1189 ; /usr/bin/ldapsearch -x -p $PORT -h localhost -D "uid=nnn5,ou=dswinsync,dc=passsync,dc=com" -w Secret12345 -b uid=nnn5,ou=dswinsync,dc=passsync,dc=com |grep -i shadowLastChange
shadowLastChange: 12222
[root@ibm-ls22-03 ~]#  PORT=1189 ; /usr/bin/ldapsearch -x -p $PORT -h localhost -D "uid=nnn5,ou=dswinsync,dc=passsync,dc=com" -w Secret12345 -b uid=nnn4,ou=dswinsync,dc=passsync,dc=com |grep -i shadowLastChange
shadowLastChange: 12222

Checking after changing password at AD side.

[root@ibm-ls22-03 ~]# sleep 360 ;  PORT=1189 ; /usr/bin/ldapsearch -x -p $PORT -h localhost -D "uid=nnn5,ou=dswinsync,dc=passsync,dc=com" -w Secret12345 -b uid=nnn4,ou=dswinsync,dc=passsync,dc=com |grep -i shadowLastChange
shadowLastChange: 12222
[root@ibm-ls22-03 ~]#  PORT=1189 ; /usr/bin/ldapsearch -x -p $PORT -h localhost -D "uid=nnn5,ou=dswinsync,dc=passsync,dc=com" -w Secret12345 -b uid=nnn4,ou=dswinsync,dc=passsync,dc=com |grep -i shadowLastChange
shadowLastChange: 12222
Comment 22 Noriko Hosoi 2016-09-06 14:06:56 EDT
(In reply to Sankar Ramalingam from comment #21)
> Tested user synchronization with windows 2012 r2 AD setup. Password change
> from AD is not updating the shadowLastChange attribute in DS.
> Test case:
> 1. Create a working passsync setup with win2012r2
> 2. Configure global pw policy in DS
> 3. Create few users to sync to AD with shadowAccount attribute
> 4. Once its synced to AD, change the password on AD side.
> 5. Check if shadowLastChange attribute updated for password update from step
> #4.
> 
> Password is not updated.

Does this mean PassSync failed to update the password on DS with the new password on AD?

If so, do you see any error logs from the PassSync?
Comment 23 Sankar Ramalingam 2016-09-07 08:17:10 EDT
Installed IDM for Unix on AD to sync Posix attributes - https://technet.microsoft.com/en-us/library/cc731178.aspx
After that, I tested password change/sync from AD to DS, it worked.
shadowLastChange attribute got updated when password changed at AD.

[root@ratangad MMR_WINSYNC]# PORT=1189 /usr/bin/ldapsearch -x -p $PORT -h localhost -D "cn=Directory Manager" -w Secret123 -b "ou=dswinsync,dc=passsync,dc=com" |grep -i ShadowLast
shadowLastChange: 17051
shadowLastChange: 17051

[root@ratangad MMR_WINSYNC]# PORT=1189 ; /usr/bin/ldapmodify -x -p $PORT -h localhost -D "cn=Directory Manager" -w Secret123 << EOFdn: uid=aaa1,ou=dswinsync,dc=passsync,dc=com
replace: shadowLastChange
shadowLastChange: 18959
EOF
modifying entry "uid=aaa1,ou=dswinsync,dc=passsync,dc=com"

[root@ratangad MMR_WINSYNC]# PORT=1189 ; /usr/bin/ldapmodify -x -p $PORT -h localhost -D "cn=Directory Manager" -w Secret123 << EOFdn: uid=aaa2,ou=dswinsync,dc=passsync,dc=com
replace: shadowLastChange
shadowLastChange: 18959
EOF                                         
modifying entry "uid=aaa2,ou=dswinsync,dc=passsync,dc=com"

[root@ratangad MMR_WINSYNC]# PORT=1189 /usr/bin/ldapsearch -x -p $PORT -h localhost -D "cn=Directory Manager" -w Secret123 -b "ou=dswinsync,dc=passsync,dc=com" |grep -i ShadowLast
shadowLastChange: 18959
shadowLastChange: 18959

[root@ratangad MMR_WINSYNC]# PORT=1189 /usr/bin/ldapsearch -x -p $PORT -h localhost -D "uid=aaa2,ou=dswinsync,dc=passsync,dc=com" -w Redhat1234 -b "ou=dswinsync,dc=passsync,dc=com" |grep -i ShadowLast
shadowLastChange: 17051
shadowLastChange: 17051
--------------

Tested password change from command line too.

[root@ratangad MMR_WINSYNC]# PORT=1189 /usr/bin/ldapsearch -x -p $PORT -h localhost -D "cn=Directory Manager" -w Secret123 -b "ou=dswinsync,dc=passsync,dc=com" |grep -i ShadowLast
shadowLastChange: 18959
shadowLastChange: 18959

[root@ratangad MMR_WINSYNC]# /usr/lib64/mozldap/ldapmodify -Z -P /etc/dirsrv/slapd-M1/cert8.db -h win2012r2-NEW.AD.EXAMPLE.COM -p 636 -D "cn=Administrator,cn=Users,dc=AD,dc=EXAMPLE,dc=COM" -w Secret123 << EOF
dn: CN=aaa4,OU=adpasssync,DC=AD,DC=EXAMPLE,DC=COM
changetype: modify
replace: unicodePwd
unicodePwd::IgBBAGwAbABOAGUAdwAxADIAMwA0ACIA
EOF

modifying entry CN=aaa4,OU=adpasssync,DC=AD,DC=EXAMPLE,DC=COM

[root@ratangad MMR_WINSYNC]# /usr/lib64/mozldap/ldapmodify -Z -P /etc/dirsrv/slapd-M1/cert8.db -h win2012r2-NEW.AD.EXAMPLE.COM -p 636 -D "cn=Administrator,cn=Users,dc=AD,dc=EXAMPLE,dc=COM" -w Secret123 << EOF
dn: CN=aaa3,OU=adpasssync,DC=AD,DC=EXAMPLE,DC=COM
changetype: modify
replace: unicodePwd
unicodePwd::IgBBAGwAbABOAGUAdwAxADIAMwA0ACIA
EOF

modifying entry CN=aaa3,OU=adpasssync,DC=AD,DC=EXAMPLE,DC=COM

[root@ratangad MMR_WINSYNC]# PORT=1189 /usr/bin/ldapsearch -x -p $PORT -h localhost -D "cn=Directory Manager" -w Secret123 -b "ou=dswinsync,dc=passsync,dc=com" |grep -i ShadowLast
shadowLastChange: 17051
shadowLastChange: 17051


Hence, marking the bug as Verified.
Comment 24 Sankar Ramalingam 2016-09-07 09:47:25 EDT
I checked the PwdLastSet attribute as well in AD for a password change in DS. The value of pwdLastSet changed when the password is updated in DS side.

[root@ratangad MMR_WINSYNC]# echo "AD_SEARCH-Shadow" ; ldapsearch -xLLL -H ldap://192.168.122.75 -D "cn=SyncManager,cn=Users,dc=AD,dc=EXAMPLE,dc=COM" -w Secret123 -b "cn=aaa4,ou=adpasssync,dc=AD,dc=EXAMPLE,dc=COM"  |grep -i pwdLastSet
AD_SEARCH-Shadow
pwdLastSet: 131177705440624953
[root@ratangad MMR_WINSYNC]# /usr/lib64/mozldap/ldapmodify -a -Z -P /etc/dirsrv/slapd-M1/cert8.db -h ratangad.eng.blr.redhat.com -p 1616 -D 'cn=Directory Manager' -w Secret123 << EOF
> dn: uid=aaa4,ou=dswinsync,dc=passsync,dc=com
> changetype: modify
> replace: userPassword
> userPassword: RedRed1123
> EOF
modifying entry uid=aaa4,ou=dswinsync,dc=passsync,dc=com

[root@ratangad MMR_WINSYNC]# echo "AD_SEARCH-Shadow" ; ldapsearch -xLLL -H ldap://192.168.122.75 -D "cn=SyncManager,cn=Users,dc=AD,dc=EXAMPLE,dc=COM" -w Secret123 -b "cn=aaa4,ou=adpasssync,dc=AD,dc=EXAMPLE,dc=COM"  |grep -i pwdLastSet
AD_SEARCH-Shadow
pwdLastSet: 131177706677499733
Comment 27 Sankar Ramalingam 2016-09-08 08:53:16 EDT
Hi Noriko, I have couple of questions which I would like to clarify. 

1. Does Passsync take care of adding/updating ShadowLastChange attribute for users synced to DS from AD? Entry in AD is added with ShadowAccount objectClass and unicodePwd attribute.

At present, the shadowAccount objectClass is not synced to DS. Where as, its present on AD, since I added shadowAccount objectclass along with the user.

2. Does Passsync support syncing of shadowAccount objectClass with shadowLastChange attribute to AD from DS? Entry in DS is added with ShadowAccount objectClass and userPassword attribute.

I don't see neither shadowAccount objectclass nor shadowLastChange attribute being synced to AD.


If you think of any other test cases which is not covered here, please do suggest. Thanks!
Comment 28 Noriko Hosoi 2016-09-08 13:37:58 EDT
(In reply to Sankar Ramalingam from comment #27)
> Hi Noriko, I have couple of questions which I would like to clarify. 
> 
> 1. Does Passsync take care of adding/updating ShadowLastChange attribute for
> users synced to DS from AD? 

Not exactly.  What PassSync does is just sending the new password set on AD to DS.  DS updates its ShadowLastChange along with the password change if the entry has a shadowAccount object.

> Entry in AD is added with ShadowAccount objectClass and unicodePwd attribute.
> 
> At present, the shadowAccount objectClass is not synced to DS. Where as, its
> present on AD, since I added shadowAccount objectclass along with the user.

Yes, that's the way how it works.  Windows Sync does not sync all the attributes between AD and DS since each has its own specific schema.

> 2. Does Passsync support syncing of shadowAccount objectClass with
> shadowLastChange attribute to AD from DS? Entry in DS is added with
> ShadowAccount objectClass and userPassword attribute.
> 
> I don't see neither shadowAccount objectclass nor shadowLastChange attribute
> being synced to AD.

That's the expected behaviour.  When a user entry is sync from AD to DS, this set of objectclass is added to the entry, which is hard coded.  I.e., no objectclass is "synchronized" including shadowAccount. 
        objectclass:top
        objectclass:person
        objectclass:organizationalperson
        objectclass:inetOrgPerson
        objectclass:ntUser

The objectclass needs to be configured on AD and DS independently if needed.  So, what you did for testing is correct.

> If you think of any other test cases which is not covered here, please do
> suggest. Thanks!

I think you did a great job.  Thanks a lot, Sankar!
Comment 30 errata-xmlrpc 2016-11-03 16:33:56 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2594.html

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