Announcement

Collapse
No announcement yet.

AD attributes question, possibly noobish =)

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • AD attributes question, possibly noobish =)

    Hello, I found these forums after some extensive searching. I tried to search for my issue in the existing threads but since I could not I decided I would give it a shot here.

    Currently I access an AD service via LDAP in a java application wherein I am specifying the attributes I want to return in the NamingEnumeration object. They are:

    String returnedAtts[]={"distinguishedName","pwdLastSet","badPwdCount"," userPrincipalName"};

    One of my tasks is to retrieve the badPwdCount and once it reaches 5, a lock message is displayed to the user. I have all of this figured out. However some really strange business is happening with the attribute "badPwdCount." For some odd reason, it disappears from the user profile in the AD! For example, here are a few lines from an exported LDIF of this happening:

    BEFORE:
    #-------------------------------------------------------------------------------
    # This file has been generated on 08.26.2009 at 10:17 from XXXXXXXXXXX
    # by Softerra LDAP Browser 2.6 (http://www.ldapbrowser.com)
    #-------------------------------------------------------------------------------
    ...
    name: John Doe
    objectGUID:: j7l/KysXDEadFSRo6pGMBg==
    userAccountControl: 512
    badPwdCount: 0
    codePage: 0
    countryCode: 0
    badPasswordTime: 128957719320423377
    lastLogon: 128957733611645817
    pwdLastSet: 128945682535312500
    primaryGroupID: 513
    objectSid:: AQUAAAAAAAUVAAAAyRzCH9dbMym6auUVpHQAAA==
    accountExpires: 9223372036854775807
    logonCount: 0
    sAMAccountName: JDoe
    sAMAccountType: 805306368
    legacyExchangeDN: ADCDisabledMail
    ...

    ...Ok, so now I log into the app a few times to test things, and eventually I get a NullPointer. I check the AD profile once again and now 4 attributes are missing:

    AFTER:
    #-------------------------------------------------------------------------------
    # This file has been generated on 08.26.2009 at 10:52 from XXXXXXXXXXX
    # by Softerra LDAP Browser 2.6 (http://www.ldapbrowser.com)
    #-------------------------------------------------------------------------------
    ...
    name: John Doe
    objectGUID:: j7l/KysXDEadFSRo6pGMBg==
    userAccountControl: 512

    codePage: 0
    countryCode: 0


    pwdLastSet: 128945682535312500
    primaryGroupID: 513
    objectSid:: AQUAAAAAAAUVAAAAyRzCH9dbMym6auUVpHQAAA==
    accountExpires: 9223372036854775807

    sAMAccountName: JDoe
    sAMAccountType: 805306368
    legacyExchangeDN: ADCDisabledMail
    ...

    (I inserted the blanks for ease of reading)

    Why is this happening? Since I can no longer retrieve the attribute 'badPwdCount' the application fails. Is it being hid for some permission reason? Eventually it returns!

    Also, I can never seem to increment the badPwdCount by anything more than 1.

    Sorry for the long first post, this is a mystery to me.

    Cheers

  • #2
    Re: AD attributes question, possibly noobish =)

    Do you always connect to the same DC? badpwdcount does not replicate.

    Comment


    • #3
      Re: AD attributes question, possibly noobish =)

      Hi and thanks for the response.

      I am connecting to the same DC - now...since the time I posted this I've researched and I understand what you are saying. Each DC is going to have its own value for badPwdCount. Once I figured that out I'm now able to increment the value correctly.

      However, the mystery continues with the missing attributes. If I do figure it out I will post what I find. Something tells me it has to do with my initial call to the AD server with the sAMAccount I'm using to get in with (permissions?), but I still don't have anything other than a hunch. I'm no expert in AD whatsoever, so I'm feeling around in the dark (and on the internet).

      Comment


      • #4
        Re: AD attributes question, possibly noobish =)

        On your Default Domain Policy, What is the account lockout threshhold? It could be that if the Policy is set to lock the user account after 5 attempts, the badpwdcount may have been reset and account locked even before your application reads it.

        Further Microsoft recomends the account lockout threshhold to be set to 10. As its not only the user, cached credentials are used even by applications for authentication.
        AD Admin

        Comment

        Working...
        X