• Darren (unregistered)

    While we could all probably rewrite this as a single-liner, we must show some respect to the manager who can convert the 'lastLogon' integer value into a usable date and time.

    Also, if you've got multiple Domain Controllers, the 'lastlogon' timestamp might not be accurate. Certainly the 'LastLogonDate' field - which is the converted version of 'lastLogon' - can be out of sync by up to a fortnight across your DCs.

    Oh, frist too.

  • (nodebb)

    Good to know! So you can add hidden users that won't show up in the report by naming them 1hacker and the like.

  • Jason Stringify (unregistered)

    Is the search accent-insensitive? If not, they'd better hope they don't have an Élise on the payroll, never mind an Øyvind.

  • Malte (unregistered)

    This gives me the idea for a cool WTF sorting algorithm. Construct all possible strings in alphabetic order, then walk along that list and pick those that are in your unsorted list. I feel like we are one recursive call away from doing that.

  • COBOL Dilettante (unregistered) in reply to Melissa U

    Wouldn't surprise me if they have a bunch of "test" or "system" usernames prefixed with non-alphabetic characters, and the script works like that for exactly that reason ...

  • (nodebb) in reply to Jason Stringify

    The System.DirectoryServices.DirectorySearcher documentation says that the filter uses the LDAP search filter syntax. These are specified by RFCs 2252 and 2254.

    RFC 2252 §8.3 says:

       Servers SHOULD be capable of performing the following matching rules,
   which are used in substring filters.

   ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

   ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

   ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

    So at best, we're getting a case-insensitive substring matching in Unicode (UTF-8); that's not even guaranteed, but given Windows' proclivity for case insensitivity, I think it's pretty much assured that a Windows server will obey that SHOULD requirement.

    caseIgnoreSubstringsMatch is specified in RFC 4517 §4.2.13, which then refers us to the Map preparation step, specified in RFC 4518 §2.2. That defines some rules about mapping control characters and then refers us to RFC 3454 §B.2 for case folding and some other rules, which finally contains the list of case folding rules that look like typical Unicode case folding (É -> é and Ø -> ø in particular here). RFC 4518 §2.3 also specifies that strings are normalized into Unicode Form KC, as defined in UAX #15.

    So in summary: the search pattern e* would NOT match a name such as Élise and the search pattern o* would NOT match a name such as Øyvind, and that's true regardless of which normalization form the names used (e.g. precomposed vs. decomposed). As best as I can tell, LDAP got all the Unicode right here!

  • Darren (unregistered) in reply to Jason Stringify

    I don't recall every seeing an account in AD which used accents on anything other than the display name fields. Everything I've worked with has had the actual username part - and email address - written without accents.

    That doesn't mean it doesn't - or can't - happen though, just that I suspect that it may be very rare.

Leave a comment on “An Odd Sort”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article