Avantgarde Technologies

<a href="http://www.avantgardetechnologies.com.au">Avantgarde Technologies</a>
Perth's IT Experts

Monday, June 20, 2011

Error 49: ldap_simple_bind_s() failed: Invalid Credentials

I have setup a Windows Server 2008 R2 server running LDS. I have an LDS Instance running on 10001 (LDAP) and 20001 (LDAPS).

I added a user account using the following:

dn: CN=testaccount,CN=Users,DC=domain,DC=ADAM
changetype: add
objectClass: user
userPrincipalName: testaccount
cn: testaccount
displayName: My Test Account
userPassword: Passw0rd

Note: As the requirement for special formatting of unicodePwd has been lifted Microsoft has placed a default requirement to ensure all password operations are done through LDAPS instead of LDAP. To allow password operations through LDAP please see:


When I attempt to bind to this account using ldp.exe using "Simple Bind" over LDAP (not secure LDAP) using the following credentials I get an error:

username: CN=testaccount,CN=Users,DC=domain,DC=ADAM
password: Passw0rd

res = ldap_simple_bind_s(ld, 'CN=testaccount,CN=Users,DC=domain,DC=ADAM', ); // v.3
Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
Server error: 8009030C: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 2030, v1db0
Error 0x8009030C The logon attempt failed

There were three things I needed to change to get this working.

Problem 1

I read from multiple places on the internet that by default when you associate a password to an account - the account is disabled. I also know that this error can be related to the user account being disabled - please see:


However the attribute which sets the account password to disabled "msDS-UserAccountDisabled" was not associated with the user class object in the schema. AD LDS has a series of attributes to control a user account for items such as Account Lockout, Account Disabled, Password Never Expires, User Cannot Change Password etc. For a list of these attributes please see:


Note: Active Directory does not have these attributes, instead all these values are associated with an attribute called userAccountControl. This attribute has an integer set to it.. 512 is a normal account. To disable an account add a value of 2. In decimal, this is 514 (2 + 512). For more information on how this works in Active Directory please see: http://support.microsoft.com/kb/305144

To associate these attributes with the user class object you need to connect to the LDS Instance using the Active Directory Schema Console. If Active Directory Schema does not exist in your MMC snap-in list register it using "regsrv32 schmmgmt.dll" from command line.

Note: When connecting to your LDS Instance you cannot use localhost or it will fail. You must use the IP address of the LDS Instance. This is due to a code error in the Active Directory schema console, please see:


Once connected to your LDS Instance in Active Directory Schema MMC snap-in go to the properties of the user class object and click the attributes tab.

As you see none of the msDS-User type class objects exist. Go ahead and add the following attributes:

- ms-DS-UserAccountAutoLocked

- msDS-UserAccountDisabled

- msDS-UserDontExpirePassword

- ms-DS-UserEncryptedTextPassword

- msDS-UserPasswordExpired

- ms-DS-UserPasswordNotRequired

After the attribute is added, restart your LDS Instance service and connect to the application partition in ADSIEdit containing your user account. Set the msDS-UserAccountDisabled to FALSE.

Problem 2

You must allow Simple Bind requests to an AD LDS Instance over standard LDAP. To do this connect to the configuration partition on your LDS Instance using ADSIEdit. My instance is listening on TCP 10001.

Navigate to:

CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={GUID}

Open the properties of Directory Service. Open the multivalued attribute msDS-Other-Settings. Ensure RequireSecureSimpleBind is set to 0. This will ensure that both LDAP and LDAPS connections are allowed to bind authentication to the LDS Instance.

Note: RequireSecureProxyBind is for userProxy class objects which perform bind proxy redirection.

Problem 3

The third problem related to the following TechNet article:


This article states:

AD LDS does not include any default security principals. However, AD LDS does provide importable schema extensions that you can use to create users in AD LDS. Users that are created from these user classes can be used as security principals. In addition, you can make any object class in the AD LDS schema a security principal by adding the msDS-bindableobject auxiliary class and the unicodePwd attribute to the schema definition of an object class. Each AD LDS security principal must be assigned an account and password, which AD LDS uses for authentication.

To do this open up ADSIEdit and connect to the Schema partition of your LDS Instance.

Navigate to the CN=User class object in ADSIEdit under the Schema partition and open its properties.

As you see the msDS-bindableobject auxiliary class does not exist.

Add it to the list and click OK.

Restart the LDS Instance under the services MMC console.

Reset the user's password by connecting to the appropriate application partition in ADSIEdit, right clicking on the user and clicking Reset Password.

I was now ale to perform a simple bind to my LDS Instance using a LDS user account.

res = ldap_simple_bind_s(ld, 'CN=SVCLDAPQuery,CN=Users,DC=domain,DC=ADAM',); // v.3
Authenticated as: 'CN=SVCLDAPQuery,CN=Users,DC=domain,DC=ADAM'.

You can also do this using an LDIF file:

dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: Modify
add: auxiliaryClass
auxiliaryClass: msDS-BindableObject

changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

imported using (ignore line wraps below)

ldifde -i -f
-s : -c
"CN=Schema,CN=Configuration,DC=X" #schemaNamingContext

Thanks to Lee Fight (Directory Services MVP) who assisted me in getting this working!


  1. Small point: You shouldn't have to restart the ADAM instance to make schema changes work. Just waiting (5 minutes is the refresh interval I believe) or kicking off the schemaUpdateNow RootDSE mod should do the trick.


  2. Thank you. This helped me.