accountExpires attribute returned without formatting. about ldap3

[w-p]

The accountExpires attribute is an AD timestamp like lastLogon and badPasswordTime.

accountExpires
attribute: https://msdn.microsoft.com/en-us/library/ms675098(v=vs.85).aspx
schema: https://msdn.microsoft.com/en-us/library/Cc221084.aspx

badPasswordTime
attribute: https://msdn.microsoft.com/en-us/library/ms675243(v=vs.85).aspx
schema: https://msdn.microsoft.com/en-us/library/Cc221229.aspx

Both of these attributes have the same attributeSyntax and omSyntax values however, while badPasswordTime is sent through the formatter, accountExpires is not.

[cannatag]

Hi Will, what is the syntax of this attribute in the schema? Are you using the get_info=SCHEMA parameter in the server object? If the accountExpires has a custom format it can be added to the standard formatter of ldap3.

[w-p]

Apologies, the issue is apparently not that the attribute itself is not being formatted but rather that the value presented by AD is not being accounted for. In the case of accountExpires the AD timestamp uses the value 9223372036854775807 to indicate that the account will never expire.

I don't think there is an infinity representation of a datetime object in Python so perhaps returning float('inf') in this particular case would make sense? This works nicely for JSON representation.

So, in format_ad_timestamp() there could be something like:

if raw_value == b'9223372036854775807':
    return float('inf')

I'm not sure of the performance implications though.

[cannatag]

HI Will, that value is used to represent the highest value that can be stored in a 64 bit signed integer ( 2^63 − 1 or 7FFF FFFF FFFF FFFF in hex) and in this case should mean the highest date that can be stored in the accountExpires attribute.

To be consistent with the value returned by format_ad_timestamp() I prefer:

if raw_value == b'9223372036854775807':  # max value to be stored in a 64 bit signed int
    return datetime.max  # returns datetime.datetime(9999, 12, 31, 23, 59, 59, 999999)

This return the highest date managed by the python datetime module and should not break existing code.

[w-p]

I was just about to revise my previous assertion. You are correct. Staying standard is the right way to go. Thanks.

[cannatag]

Will release it in the next release.

bye,
Giovanni

[cannatag]

Fixed in 0.9.9