[389-users] AD and 389ds synchronization of shadowLastChange

[vladimir Safoo]

My apologies,

I just saw the thread "[389-users] AD <-> LDAP password expiration sync"

Is this correct, there is no current way to sync the shadowLastChange value?





On Fri, Jan 25, 2013 at 12:04 AM, vladimir Safoo <wudadin2003 at gmail.com>wrote:

> 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/20130125/d53590d4/attachment.html>