I recently had a customer ask me about how mapping of loginExpirationTime to Account-Expires in AD works, and I referred to the documentation. From the IdM 4.6 docs:


---
Expiring Accounts in Active Directory
If you map the eDirectory attribute of Login Expiration Time to the Active Directory attribute of accountExpires, an account in Active Directory expires a day earlier than the time set in eDirectory.

This happens because Active Directory sets the value of the accountExpires attribute in full-day increments. The eDirectory attribute of Login Expiration Time uses a specific day and time to expire the account.

For example, if you set an account in eDirectory, to expire on July 15, 2007, at 5:00 p.m., the last full day this account is valid in Active Directory is July 14.

If you use the Microsoft Management Console to set the account to expire on July 15, 2007, the eDirectory attribute of Login Expiration Time is set to expire on July 16, 2007 at 12:00 a.m. Because the Microsoft Management Console doesnt allow for a value of time to be set, the default is 12:00 a.m.

The driver uses the most restrictive settings. You can add an additional day to the expiration time in Microsoft depending upon what your requirements are.
---


But upon some checking, I discovered the Account-Expires in AD has for quite some time supported a true timestamp:

https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

I don't think you can set it in ADUC, but you certainly can via ADSI and PowerShell.

So my question is, why does the AD driver still behave this way? The documentation is really wrong. ADUC only supports full day increments for Account-Expires, but Account-Expires supports a timestamp just like eDir does.

Matt