none
AD LDS and locked out accounts response codes

    Question

  • On Active Directory an LDAP bind to a locked out account always returns (regardless if the pwd is correct or not):

    -2146893044 => 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db1 (account locked out)

    This is the expected behavior.
     
    On AD LDS (on Win2008R2) an LDAP bind to a locked out account returns different codes depending if the pwd is valid or not:
     
    If the password is correct AD LDS returns:
    -2146893044 => 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db1 (account locked out)

     If the pwd is NOT correct AD LDS returns:
    -2146893044 => 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1 (unknown username or bad password)
     
    This is obviously a security issue as one can continue to try to find out the correct password while the account is locked out.

    Does anyone know if this behavior can be configured or if this is a bug or by design (hard to believe)

    Monday, March 05, 2012 6:31 PM

Answers

  • Hi,

    The AD LDS test in my lab has the same results as yours.

    If the password is correct:
    -2146893044 => 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db1 (account locked out)

    If the pwd is incoreectr returns:
    -2146893044 => 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1 (unknown username or bad password)


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Marked as answer by szh9id Thursday, March 29, 2012 9:58 PM
    Monday, March 26, 2012 6:03 AM

All replies

  •  

    Hi,

     

    Thank you for your question.

    I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

     

    Thank you for your understanding and support.

    Arthur Li

    TechNet Subscriber Support

    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.


    Arthur Li

    TechNet Community Support

    Wednesday, March 07, 2012 3:33 AM
    Moderator
  • Hi,

    please refer to following article and let me which authentication methods you are used in the AD LDS.

    Overiview of authentication mechanisms in AD LDS:http://blogs.technet.com/b/idaguys/archive/2009/06/19/overiview-of-authentication-in-ad-lds.aspx 


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, March 07, 2012 9:36 AM
  • Hi Jason, thank you for the response. We perform simple bind with DN using LDAPS (port 636). The local server policies do apply and the accounts get locked out as expected, but as I said the return codes are different if correct or incorrect pwd is provided which is different behavior when using simple bind against Active Directory.

    We need simple bind at the moment because of legacy applications. Later we would like to use proxy objects maped to Active Directory accounts. I have not yet tested this behavior when using proxy objects. Will do that as soon as I get time.

    Should this be by design we would need to implement some custom authentication module that checks the ldap attribute manually (ms-DS-UserAccountAutoLocked) and then always return the same response to the user in that case. But I would expect that AD LDS would handle this the same way Active Directory handles it.

    Wednesday, March 07, 2012 9:11 PM
  • Hi,

    thanks for your reply.

    Kerberos authentication depends on KDC service, but LD LDS does't have KDC service. So there are some differents between AD LDS and AD.  Anyway, i will do more tests on my lab and wait for your test results .


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Thursday, March 08, 2012 10:46 AM
  • Hi Jason,

    But for the tests against AD we did a simple bind as well, so I do not think that the KDC (kerberos) plays a role in this scenario.

    Anyway, the problem with the behavior is not really that it is not the same as in AD. The problem is that you get a different return code back depending if the pwd provided is correct or not. This defeats the whole purpose of the lockout feature.

    Were you able to reproduce this behavior in your lab ?

    Thursday, March 08, 2012 4:09 PM
  • Hi,

    AD LDS doesn't support much attributes that control account lockout. the UserAccountControl which is used to control items such as Account Lockout, Account Disabled, Password Never Expires, User Cannot Change Password etc, but AD LDS doesn't support this attribute.

    http://support.microsoft.com/kb/305144

    http://msdn.microsoft.com/en-us/library/aa772124.aspx

    http://support.microsoft.com/kb/250873




    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Saturday, March 10, 2012 9:33 AM
  • Hi,

    yes I am aware of that.

    But was I was just talking about the LDAP return codes when binding to an account that is currently locked out.

    As explained, it returns different codes depending if the password is correct or not which makes the lockout feature useless. The whole point of the lockout feature is that you can only try a limited number of passwords and once the limit is reached the account locks out.

    But in case of AD LDS after the account locks out, if you know that the return codes tell you if the password is correct or not, you can keep guessing passwords and perform a brute force attack. So the concept of the account lockout feature is completely useless with AD LDS.

    This is in contrast to other LDAP systems I looked at (e.g. openLDAP with password policy overlay) which always returns the same error code for locked out accounts, regardless if the pwd entered is corerct or not.

    At this point it looks like this is by design in AD LDS as I could not find an any help on how this can be configured/changed. What is your view? Does this behavior make sense to you?

    Wednesday, March 14, 2012 1:03 AM
  • Hi,

    I have made a test on my lab. when I use LDP.exe to bind to an AD, the reponse code always is "invalid credentials" whatever i type incorrect password or correct password.

    0 = ldap_set_option(ld, LDAP_OPT_ENCRYPT, 1)res = ldap_bind_s(ld, NULL, &NtAuthIdentity, NEGOTIATE (1158)); // v.3
     {NtAuthIdentity: User='joan'; Pwd=<unavailable>; domain = 'tms.com'}
    Error <49>: ldap_bind_s() failed: Invalid Credentials. Server error: 8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 775, v1db1 Error 0x8009030C The logon attempt failed

    So tell me which tools you used to bind to AD and AD LDS.


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, March 14, 2012 9:28 AM
  • Hi,

    I have performed the same test with ldp.exe using simple bind.

    I have entered the pwd wrong a couple of times until the account was locked out.

    It always returned the same error 52e (before lockout and after it was locked out):

    res = ldap_simple_bind_s(ld, 'cn=mytest,ou=users,o=xxx', <unavailable>); // v.3
    Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
    Server error: 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1
    Error 0x8009030C The logon attempt failed

    Then I entered the correct password:

    res = ldap_simple_bind_s(ld, 'cn=mytest,ou=users,o=xxx', <unavailable>); // v.3
    Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
    Server error: 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db1
    Error 0x8009030C The logon attempt failed

    As you can see I then get error 775.

    This was my point. After the account is locked out, you can still determine if the pwd that was entered is correct or not, which defeats the purpose of the lockout feature.

    If I see it correctly, in your test you did not use simple bind. Can you perform the same test with simple bind?

    Friday, March 16, 2012 11:29 PM
  • Hi,

    I have made a simple bind as you did.

    1. i enter bad password before this user lockout. the erroe is 52e

    res = ldap_simple_bind_s(ld, 'joan', <unavailable>); // v.3
    Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
    Server error: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1
    Error 0x80090308 The token supplied to the function is invalid

    2. After user account locked out, the results are same regardless the incorrect or correct password was enterd.

    0 = ldap_set_option(ld, LDAP_OPT_ENCRYPT, 1)
    res = ldap_bind_s(ld, NULL, &NtAuthIdentity, NEGOTIATE (1158)); // v.3
     {NtAuthIdentity: User='joan'; Pwd=<unavailable>; domain = 'tms.com'}
    Error <49>: ldap_bind_s() failed: Invalid Credentials.
    Server error: 8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 775, v1db1
    Error 0x8009030C The logon attempt failed
    -----------
    0 = ldap_set_option(ld, LDAP_OPT_ENCRYPT, 1)
    res = ldap_bind_s(ld, NULL, &NtAuthIdentity, NEGOTIATE (1158)); // v.3
     {NtAuthIdentity: User='joan'; Pwd=<unavailable>; domain = 'tms.com'}
    Error <49>: ldap_bind_s() failed: Invalid Credentials.
    Server error: 8009030C: LdapErr: DSID-0C0904DC, comment: AcceptSecurityContext error, data 775, v1db1
    Error 0x8009030C The logon attempt failed

    Regarding currennt situation, i think we could not determine if the password we enterd is correct or not. This results just determines if the user account was locked out or not.


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, March 19, 2012 4:21 AM
  • Hi,

    Only in step 1 are you using simple bind.
    res = ldap_simple_bind_s(ld, 'joan', <unavailable>); // v.3

    The other ldap binds that return 775 are not simple bind:
    res = ldap_bind_s(ld, NULL, &NtAuthIdentity, NEGOTIATE (1158)); // v.3

    Can please perfom simple bind after the account is locked out.

    Thank you.

    Monday, March 19, 2012 10:44 AM
  • Hi,

    I did a simple bind after user account is locked out and the results are same regardless the password incorrect or correct:

    -----------
    res = ldap_simple_bind_s(ld, 'joan', <unavailable>); // v.3
    Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
    Server error: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db1
    Error 0x80090308 The token supplied to the function is invalid
    -----------
    res = ldap_simple_bind_s(ld, 'joan', <unavailable>); // v.3
    Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
    Server error: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db1
    Error 0x80090308 The token supplied to the function is invalid
    -----------


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Tuesday, March 20, 2012 7:09 AM
  • Thanks for that.

    So that shows me that there must be a way to change that behavior.
    Do you have any idea why our system behaves differently than yours?

    Tuesday, March 20, 2012 1:12 PM
  • hi,

    I did that test from DC running Windows 2008 R2, so could you please tell me the OS version of your DC, so that i can make a test again.

    thanks !


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, March 21, 2012 8:56 AM
  • Hi,

    When reading your question I am not sure if we are testing the same thing here.
    Did you bind with an account in Active Directory that has access to AD LDS?
    If so, that is not the test I was looking for. As said before the ldap bind against AD works as expected.

    In my scenario I have inetorgperson objects in AD LDS an I bind directly to them wihtout any Active Directory domain controller involved.

    The AD LDS is on Windows Server 2008R2 with SP1

    Could you please clarify how you tested.

    Thank you.

    Wednesday, March 21, 2012 5:05 PM
  • Hi,

    I did the simple bind to Win2K8 DC. from your first post, the results always return as "account locked out" when you bind to DC and this results are difference with mine.

    On Active Directory an LDAP bind to a locked out account always returns (regardless if the pwd is correct or not):

    -2146893044 => 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db1 (account locked out)


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Thursday, March 22, 2012 8:39 AM
  • Ok I understand, in that scenario I get the same result.

    Could you also try the same binding to local AD LDS accounts?

    Thursday, March 22, 2012 2:36 PM
  • Hi,

    I have made a test with local AD LDS account and the results are same as yours.


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Proposed as answer by Jason Mei Thursday, March 29, 2012 7:49 AM
    Friday, March 23, 2012 6:59 AM
  • Thank you for the confirmation.

    Your AD LDS always returns the same error (775) for locked acconts

    Our AD LDS:

    If the password is correct returns:
    -2146893044 => 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db1 (account locked out)

    If the pwd is NOT correct returns:
    -2146893044 => 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1 (unknown username or bad password)

    I have no idea why and no one else seems to have an idea why that is.
    I give up.

    Friday, March 23, 2012 8:27 AM
  • Hi,

    The AD LDS test in my lab has the same results as yours.

    If the password is correct:
    -2146893044 => 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 775, v1db1 (account locked out)

    If the pwd is incoreectr returns:
    -2146893044 => 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1 (unknown username or bad password)


    Best regards, Jason Mei Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Marked as answer by szh9id Thursday, March 29, 2012 9:58 PM
    Monday, March 26, 2012 6:03 AM
  • Ok, thanks for the confirmation.

    We have now raised a design change request with Microsoft. It is currently reviewed by the product group. There may be fix coming out for that.

    Thursday, March 29, 2012 10:01 PM
  • Hi guys,

    I stumbled across this post as I am having a little problem with LDS and Kerberos.

    I cannot see it the services for kerberos running on netstat -an or windows service.

    I am running LDS on a W2K8 R2 box. Is kerberos a service that needs to be installed or enabled?

    Any ideas?

    Maelito



    Maelito

    Thursday, February 28, 2013 4:25 PM