There is a reason why many Active Directory admins still use the GUI: it is simple and straightforward. On the other hand, scripts allow us to automate and scale AD tasks, which is also beneficial for admins. A classic example of this duality is working with dates within Active Directory (AD). To illustrate, let’s focus on the “accountExpires” attribute, commonly used for contractors, temporary staff, or trial accounts. An example of the “accountExpires” attribute as it appears in the GUI is shown below.
While the GUI is an easy way to look up the account expiration date of a single AD user account, it would be a dreadful experience to do so for hundreds of users. That is where the magic of PowerShell comes into play.
Why Active Directory Dates Are Painful
First off, Active Directory stores most date and time attributes, including “accountExpires,” as 64-bit integers representing something called Windows FILETIME. Believe it or not, this format counts the number of 100-nanosecond intervals that have elapsed since January 1, 1601 UTC. Of course, a raw integer like 133123456789012345 means nothing to a human reader until it is converted into a readable date using PowerShell.
In the example below, PowerShell is being used to search for all accounts that will expire in the next 30 days. This is a relatively straightforward task.
The problems start arising with special sentinel values. For instance, when an administrator $explicitly sets an account to never expire, AD stores it as a well-known sentinel value. Two common “never expire” sentinels are 0 and 9223372036854775807. This, of course, produces a date in either the year 1601 or 30,282, both of which are not meaningful in any way. The date in the image below is relatively common and means the account is set to ‘Never’ expire.
Another problem arises when the expiration bit has never been modified. In other words, the “accountExpires” attribute was never explicitly set after the account was created. Thus, the attribute’s value is nonsense, so your script needs to be written so that it checks for these sentinel values before converting them to a readable date. If not handle, the bad data could create an error within PowerShell which then requires troubleshooting. The screenshot below shows a PowerShell script that demonstrates this.
The issue with the “accountExpires” attribute in Active Directory is a classic example of how legacy design choices can create unexpected challenges in modern scripting. While the sentinel values used to represent “Never Expires” may be valid in the Active Directory schema, they are meaningless as dates. Hence, if a PowerShell script attempts to convert them without validation, it will throw errors or produce absurd results. Fortunately, the problem is well documented, and the fix is straightforward.
The following shows an example of how you can “code around” these quirks within PowerShell to always get a valid result:
Keep this scenario in mind the next time you work with dates in PowerShell scripting.