[389-users] AD and 389ds synchronization of password attributes

vladimir Safoo wudadin2003 at gmail.com
Fri Jan 25 05:10:32 UTC 2013


Greetings all,

I need help from the experts, so I thank you ahead of time for any help
that you are able to assist me with.

Problem - Password set to expire in 90 days. Linux users password
expiration is not sync'ing with Windows users password expiration. So I am
getting people that are getting locked out of the environment do to their
passwords expiring.

I have AD 2008 r2 bidirectionally sync'ing with one 389ds master server.
Everything so far has been working fine. I have set up a password policy on
the AD server and have mirrored the same policy on the 389ds servers.
Passwords are set to expire in 90 days. I have multimaster replication set
up on 8 servers and have other read-only consumers.

Resetting a password on a Windows desktop or linux server does not modify
the shadowLastChange value on the Linux 389ds servers. It does, however,
update the passwordexpirationtime on the linux 389ds servers. But the linux
servers don't know what the passwordexpirationtime is so they seem to
ignore it. Though the passwordexpirationtime value is correct and does
reflect the password to expire in 90 days from the initial password setup
or change.

Now since users accounts are created normally before a users starts their
new job, the passwords get out of sync do to linux users resetting their
initial password on the linux servers once they login for the first time.
Our internal chat server authenticates via the AD server, so they are not
always notified when their Windows password has expired on the AD side.

How can I get AD to update the Linux side value for the shadowLastChange
attribute?

I can pull the passwordexpirationtime value, if there is no "normal"
solution for this, I could write a perl script to check for this time and
update the shadowLastChange value I guess. But I need to know if I am just
setting this up wrong and what is the solution or if it is not possible.
Please let me know if more information is needed.

# cat /etc/issue
CentOS release 6.2 (Final)

# rpm -qa 389*
389-ds-console-1.2.6-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
389-ds-base-1.2.9.14-1.el6_2.2.x86_64
389-admin-console-1.1.8-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-dsgw-1.1.9-1.el6.x86_64
389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64
389-adminutil-1.1.15-1.el6.x86_64
389-console-1.1.7-1.el6.noarch
389-admin-1.1.29-1.el6.x86_64
389-admin-console-doc-1.1.8-1.el6.noarch

# slaps uid=tuser
dn: uid=tuser,ou=testOU,ou=Groups,dc=company,dc=net
ntUserLastLogon: 130035596619212394
userPassword::
e1NTSEF9cTlTNmxTc01uRVFHMjU4WVhIUVhLQWRPNU5ndVZMUDZZV3ZYSGc9PQ=
 =
shadowLastChange: 15729
mail: tuser at company.net
loginShell: /bin/bash
uidNumber: 20288
gidNumber: 61000
homeDirectory: /home/tuser
ntUserLastLogoff: 0
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetOrgPerson
objectClass: ntUser
objectClass: posixAccount
objectClass: shadowAccount
ntUserDeleteAccount: true
uid: tuser
sn: user
givenName: test
cn: test user
ntUserCodePage: 0
ntUserAcctExpires: 9223372036854775807
ntUserDomainId: tuser
ntUniqueId: d19af18ff098044db4afb2e59f0ea25b

# slaps uid=tuser passwordexpirationtime
dn: uid=tuser,ou=testOU,ou=Groups,dc=company,dc=net
passwordexpirationtime: 20130425035421Z


Thank you,
389ds admin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20130124/8f4b7489/attachment.html>


More information about the 389-users mailing list