Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

accountExpires attribute returned without formatting. #105

Closed
w-p opened this issue Sep 3, 2015 · 7 comments
Closed

accountExpires attribute returned without formatting. #105

w-p opened this issue Sep 3, 2015 · 7 comments

Comments

@w-p
Copy link

w-p commented Sep 3, 2015

I have only seen this issue with the accountExpires attribute. Upon returning from a search, it is not being converted to a datetime object like other such attributes (lastLogon, badPasswordTime, etc.).

Clearly other values are being formatted with format_ad_timestamp() but accountExpires is consistently returned as a binary string.

@cannatag
Copy link
Owner

cannatag commented Sep 4, 2015

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
Copy link
Author

w-p commented Sep 4, 2015

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.

@w-p
Copy link
Author

w-p commented Sep 4, 2015

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
Copy link
Owner

cannatag commented Sep 4, 2015

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
Copy link
Author

w-p commented Sep 4, 2015

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

@cannatag
Copy link
Owner

cannatag commented Sep 5, 2015

Will release it in the next release.

bye,
Giovanni

@cannatag
Copy link
Owner

cannatag commented Sep 9, 2015

Fixed in 0.9.9

@cannatag cannatag closed this as completed Sep 9, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants