This project is read-only.

lastLogonTimestamp in Active Directory - Closed

Jan 18, 2012 at 2:11 PM

The user attribute lastLogonTimestamp is defined in AD as an Interval.  The value is only set once a user has logged on for the first time.  Until that point, when the value is not set, LinqToLdap returns 0 [zero].  If I use your


when it's not set, LinqToLdap returns "01/01/0001 00:00:00".  Is this by design?

Likewise, the attribute logonCount (also on user) is defined as Integer.  It's also only set once a user has logged on, in this case, to the particular domain controller, since the value is not replicated.  LinqToLdap also returns zero when the value is not set in the directory.

Also, Generalized Times ( - 24) are handled the same way, when they're not set.

I'm split between the simplicity of not having these as Nullable<T> versus the correctness of having them nullable.  If you'd considered and rejected the idea of nullability for Large Integers/Intervals, Integers, etc., I'd be interested to know your thoughts.

Jan 20, 2012 at 5:03 AM

Yes, it is by design.  If you don't use a nullable type then the property will be the .Net default value.  However, after your post on accountExpires, I began thinking about supporting mapping values from the directory to other .Net valid values.  For instance, mapping accountExpires as a nullable DateTime and mapping 9223372036854775807 to be treated as null from the directory and likewise, null from .Net will be converted to 9223372036854775807 when sending it back to the directory.

I'm still ironing out how the API will look and behave.

Jan 28, 2012 at 6:51 AM

I've done a lot of playing with attribute mappings for the two posts in my LinqToLdap series, Mapping directory syntaxes to .NET types and Creating a directory objects assembly for LinqToLdap and I've decided that different attributes require different treatment: I'll generally use Nullable<T> when they can be <not set> in the directory (and not when they can't).