RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1018944 - [RFE] Enhance password change tracking
Summary: [RFE] Enhance password change tracking
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
Petr Bokoc
URL:
Whiteboard:
: 1018943 (view as bug list)
Depends On:
Blocks: 1203710 1205796 1317686
TreeView+ depends on / blocked
 
Reported: 2013-10-14 18:42 UTC by Rich Megginson
Modified: 2020-09-13 21:44 UTC (History)
8 users (show)

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.
Clone Of:
: 1317686 (view as bug list)
Environment:
Last Closed: 2016-11-03 20:33:56 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1893 0 None closed 389 showing inconsistent values for shadowMax and shadowWarning in 1.3.5.1 2020-11-06 15:08:55 UTC
Github 389ds 389-ds-base issues 548 0 None closed RFE: Allow AD password sync to update shadowLastChange 2020-11-06 15:08:55 UTC
Red Hat Knowledge Base (Solution) 500723 0 None None None Never
Red Hat Product Errata RHSA-2016:2594 0 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2016-11-03 12:11:08 UTC

Description Rich Megginson 2013-10-14 18:42:00 UTC 
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 18:38:46 UTC 
*** Bug 1018943 has been marked as a duplicate of this bug. ***
Comment 11 Ron van der Wees 2014-10-17 07:43:37 UTC 
Rich, Appreciate your feedback on c#10.
Comment 12 Rich Megginson 2014-10-17 13:53:50 UTC 
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 23:11:51 UTC 
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Comment 19 Sankar Ramalingam 2016-08-29 07:55:40 UTC 
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 15:26:35 UTC 
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 19:52:39 UTC 
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 18:06:56 UTC 
(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 12:17:10 UTC 
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 13:47:25 UTC 
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 12:53:16 UTC 
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 17:37:58 UTC 
(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 20:33:56 UTC 
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.