ADS Conversions: Converting LastLogonDate & AccountExpiryDate

[Craig]

I am trying to convert the LastLogin AccountExpiry values from ADS. I can
convert the PasswordLastSet value into a readable datetime by using this:

DateTime.FromFileTime("129110656994678181").ToString

However, this doesn't work for the aforementioned other 2. Is there a way to
do this in .NET?

[Richard Mueller [MVP]]

Post by Craig
I am trying to convert the LastLogin AccountExpiry values from ADS. I can
DateTime.FromFileTime("129110656994678181").ToString
However, this doesn't work for the aforementioned other 2. Is there a way to
do this in .NET?

The AD attribute names are pwdLastSet, lastLogon, and accountExpires. The
property LastLogin only applies to local accounts (in the local SAM account
database), there is no AccountExpiry, and the only place I have seen
PasswordLastSet is in powershell scripts (which for unknown reasons seem to
recognize this).

All three of the AD attributes (pwdLastSet, lastLogon, and accountExpires)
are data type Integer8, meaning 64-bit numbers that represent dates as the
number of 100-nanosecond intervals since 12:00 AM, January 1, 1601. All are
in UTC, so need to be adjusted for the local time zone. The
DateTime.FromFileTime method handles this. All three attributes can have a
value of 0 (zero), which means "never". In addition, accountExpires can have
the value 2^63-1 (9,223,372,036,854,775,807), which also means "never".

A further complication is that the lastLogon attribute is not replicated. A
different value for each user is saved on every Domain Controller (DC). To
get the last logon value you need to query every DC in the domain to find
the largest value. If your domain is at Windows 2003 functional level or
above, you can use the lastLogonTimeStamp attribute. This attribute is
replicated, but is only updated during logon if the old value is at least 14
days old (by default). This means you can query any DC, but the value is
only accurate to within 14 days. However, this should meet the needs of most
users.

[Gerry Hickman]

Post by Richard Mueller [MVP]
database), there is no AccountExpiry, and the only place I have seen
PasswordLastSet is in powershell scripts (which for unknown reasons seem to
recognize this).

Do you have any examples using PasswordLastSet? I think they may be
using the Quest library (where for some reason they renamed everything a
bit like Microsoft's ADUC has different names for attributes).

Post by Richard Mueller [MVP]
All three of the AD attributes (pwdLastSet, lastLogon, and accountExpires)
are data type Integer8, meaning 64-bit numbers that represent dates as the
number of 100-nanosecond intervals since 12:00 AM, January 1, 1601. All are
in UTC, so need to be adjusted for the local time zone. The
DateTime.FromFileTime method handles this.

In PowerShell there's also an issue that the data type you get for these
is different depending on how you obtain the user object. If you "find"
the user, the data types get changed to "help" you. If you "get" the
user, you end up with System.__ComObject

This is just the tip of the iceberg with PowerShell "helping" you by
mangling data types in a undocumented and inconsistent way. More info in
my thread above:

"Function Return mangles object? PowerShell/AD"

[kajakaran]

k.siversa ons gebeld, ik wil graag weten hoe kan ik mensen omgaan

Post by Gerry Hickman

Post by Richard Mueller [MVP]
database), there is no AccountExpiry, and the only place I have seen
PasswordLastSet is in powershell scripts (which for unknown reasons seem to
recognize this).

Do you have any examples using PasswordLastSet? I think they may be
using the Quest library (where for some reason they renamed everything a
bit like Microsoft's ADUC has different names for attributes).

Post by Richard Mueller [MVP]
All three of the AD attributes (pwdLastSet, lastLogon, and

accountExpires)

Post by Gerry Hickman

Post by Richard Mueller [MVP]
are data type Integer8, meaning 64-bit numbers that represent dates as the
number of 100-nanosecond intervals since 12:00 AM, January 1, 1601. All are
in UTC, so need to be adjusted for the local time zone. The
DateTime.FromFileTime method handles this.

In PowerShell there's also an issue that the data type you get for these
is different depending on how you obtain the user object. If you "find"
the user, the data types get changed to "help" you. If you "get" the
user, you end up with System.__ComObject
This is just the tip of the iceberg with PowerShell "helping" you by
mangling data types in a undocumented and inconsistent way. More info in
"Function Return mangles object? PowerShell/AD"
--
Gerry Hickman (London UK)

[23243]

Post by Richard Mueller [MVP]
database), there is no AccountExpiry, and the only place I have seen
PasswordLastSet is in powershell scripts (which for unknown reasons seem to
recognize this).

Do you have any examples using PasswordLastSet? I think they may be using
the Quest library (where for some reason they renamed everything a bit
like Microsoft's ADUC has different names for attributes).

Post by Richard Mueller [MVP]
All three of the AD attributes (pwdLastSet, lastLogon, and
accountExpires)
are data type Integer8, meaning 64-bit numbers that represent dates as the
number of 100-nanosecond intervals since 12:00 AM, January 1, 1601. All are
in UTC, so need to be adjusted for the local time zone. The
DateTime.FromFileTime method handles this.

In PowerShell there's also an issue that the data type you get for these
is different depending on how you obtain the user object. If you "find"
the user, the data types get changed to "help" you. If you "get" the user,
you end up with System.__ComObject
This is just the tip of the iceberg with PowerShell "helping" you by
mangling data types in a undocumented and inconsistent way. More info in
"Function Return mangles object? PowerShell/AD"
--
Gerry Hickman (London UK)

[Matthew]

To clarify, you can convert LastLogonTimeStamp to a readable date in powershell with a command like this:

[DateTime]::FromFileTIme((get-aduser MyUsername -Properties LastLogonTimestamp).LastLogonTimeStamp)

Post by Craig
I am trying to convert the LastLogin AccountExpiry values from ADS. I can
DateTime.FromFileTime("129110656994678181").ToString
However, this does not work for the aforementioned other 2. Is there a way to
do this in .NET?

Post by Richard Mueller [MVP]
The AD attribute names are pwdLastSet, lastLogon, and accountExpires. The
property LastLogin only applies to local accounts (in the local SAM account
database), there is no AccountExpiry, and the only place I have seen
PasswordLastSet is in powershell scripts (which for unknown reasons seem to
recognize this).
All three of the AD attributes (pwdLastSet, lastLogon, and accountExpires)
are data type Integer8, meaning 64-bit numbers that represent dates as the
number of 100-nanosecond intervals since 12:00 AM, January 1, 1601. All are
in UTC, so need to be adjusted for the local time zone. The
DateTime.FromFileTime method handles this. All three attributes can have a
value of 0 (zero), which means "never". In addition, accountExpires can have
the value 2^63-1 (9,223,372,036,854,775,807), which also means "never".
A further complication is that the lastLogon attribute is not replicated. A
different value for each user is saved on every Domain Controller (DC). To
get the last logon value you need to query every DC in the domain to find
the largest value. If your domain is at Windows 2003 functional level or
above, you can use the lastLogonTimeStamp attribute. This attribute is
replicated, but is only updated during logon if the old value is at least 14
days old (by default). This means you can query any DC, but the value is
only accurate to within 14 days. However, this should meet the needs of most
users.
--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--

Post by Gerry Hickman
Do you have any examples using PasswordLastSet? I think they may be
using the Quest library (where for some reason they renamed everything a
bit like Microsoft's ADUC has different names for attributes).
In PowerShell there is also an issue that the data type you get for these
is different depending on how you obtain the user object. If you "find"
the user, the data types get changed to "help" you. If you "get" the
user, you end up with System.__ComObject
This is just the tip of the iceberg with PowerShell "helping" you by
mangling data types in a undocumented and inconsistent way. More info in
"Function Return mangles object? PowerShell/AD"
--
Gerry Hickman (London UK)

Post by kajakaran
k.siversa ons gebeld, ik wil graag weten hoe kan ik mensen omgaan
to
accountExpires)
the
are

Submitted via EggHeadCafe
ASP.NET - Zip Selected Files and Add Files in Memory with DotNetZip
http://www.eggheadcafe.com/tutorials/aspnet/fd2b3765-624b-47ea-a461-bf3ad6dcbf7b/aspnet--zip-selected-files-and-add-files-in-memory-with-dotnetzip.aspx

[23243]

Post by Richard Mueller [MVP]
database), there is no AccountExpiry, and the only place I have seen
PasswordLastSet is in powershell scripts (which for unknown reasons seem
to
recognize this).

Do you have any examples using PasswordLastSet? I think they may be using
the Quest library (where for some reason they renamed everything a bit
like Microsoft's ADUC has different names for attributes).

Post by Richard Mueller [MVP]
All three of the AD attributes (pwdLastSet, lastLogon, and
accountExpires)
are data type Integer8, meaning 64-bit numbers that represent dates as
the
number of 100-nanosecond intervals since 12:00 AM, January 1, 1601. All
are
in UTC, so need to be adjusted for the local time zone. The
DateTime.FromFileTime method handles this.

In PowerShell there's also an issue that the data type you get for these
is different depending on how you obtain the user object. If you "find"
the user, the data types get changed to "help" you. If you "get" the
user, you end up with System.__ComObject
This is just the tip of the iceberg with PowerShell "helping" you by
mangling data types in a undocumented and inconsistent way. More info in
"Function Return mangles object? PowerShell/AD"
--
Gerry Hickman (London UK)

[23243]

Post by Richard Mueller [MVP]
database), there is no AccountExpiry, and the only place I have seen
PasswordLastSet is in powershell scripts (which for unknown reasons seem
to
recognize this).

Do you have any examples using PasswordLastSet? I think they may be using
the Quest library (where for some reason they renamed everything a bit
like Microsoft's ADUC has different names for attributes).

Post by Richard Mueller [MVP]
All three of the AD attributes (pwdLastSet, lastLogon, and
accountExpires)
are data type Integer8, meaning 64-bit numbers that represent dates as
the
number of 100-nanosecond intervals since 12:00 AM, January 1, 1601. All
are
in UTC, so need to be adjusted for the local time zone. The
DateTime.FromFileTime method handles this.

In PowerShell there's also an issue that the data type you get for these
is different depending on how you obtain the user object. If you "find"
the user, the data types get changed to "help" you. If you "get" the
user, you end up with System.__ComObject
This is just the tip of the iceberg with PowerShell "helping" you by
mangling data types in a undocumented and inconsistent way. More info in
"Function Return mangles object? PowerShell/AD"
--
Gerry Hickman (London UK)

[23243]

Post by Richard Mueller [MVP]
database), there is no AccountExpiry, and the only place I have seen
PasswordLastSet is in powershell scripts (which for unknown reasons seem
to
recognize this).

Do you have any examples using PasswordLastSet? I think they may be using
the Quest library (where for some reason they renamed everything a bit
like Microsoft's ADUC has different names for attributes).

Post by Richard Mueller [MVP]
All three of the AD attributes (pwdLastSet, lastLogon, and
accountExpires)
are data type Integer8, meaning 64-bit numbers that represent dates as
the
number of 100-nanosecond intervals since 12:00 AM, January 1, 1601. All
are
in UTC, so need to be adjusted for the local time zone. The
DateTime.FromFileTime method handles this.

In PowerShell there's also an issue that the data type you get for these
is different depending on how you obtain the user object. If you "find"
the user, the data types get changed to "help" you. If you "get" the
user, you end up with System.__ComObject
This is just the tip of the iceberg with PowerShell "helping" you by
mangling data types in a undocumented and inconsistent way. More info in
"Function Return mangles object? PowerShell/AD"
--
Gerry Hickman (London UK)