aka "Configuring SSL for AD LDS on Windows Server 2008 Server Core"
You may have found your way here because:
- you are having issues binding to an ADAM userProxy
- you are getting the error "Invalid Credentials Server error: 8009030C: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 202d, v1772 Error 0x8009030C The logon attempt failed" in LDP
- you are trying to setup SSL for AD LDS on Windows Server 2008 Server Core
In my case, the solution to the first two problems ended up being the impetus to write the solution for the third bullet above. My problem first began when testing binds to userProxy objects in AD LDS connecting back to an AD 2008 forest. Here was my configuration:
- AD LDS running on Windows Server 2008 Standard, Server Core (SP2) (6.0.6002.18005) (~300k objects)
- AD DS running on Windows Server 2008 Standard (SP2)
- All servers are in the same domain/forest, including the AD LDS servers (domain joined)
-
userProxy schema loaded into ADAM among others, inetorgperson and custom extensions in use
-
userProxy objects currently being provisioned via ILM and linked to AD with objectSID (verified)
- SSL certificate already assigned to the ADAM server with Server Authentication assertion and fullname
- Using LDP to test…
Binding to inetOrgPerson objects in ADAM worked fine, but userProxy binds did not. All attempts to verify that the linked AD account was not locked, disabled, expired with a valid password were validated. Binding against the userProxy with LDP using UPN or DN yielded the following results:
res = ldap_simple_bind_s(ld, , ); // v.3
Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
Server error: 8009030C: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 202d, v1772
Error 0x8009030C The logon attempt failed
Further digging in the LDS server's Security Event Log yielded this error:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 8/21/2009 9:37:36 AM
Event ID: 4776
Task Category: Credential Validation
Level: Information
Keywords: Audit Failure
User: N/A
Computer: LDSIDI01VDO.foo.intg
Description:
The domain controller attempted to validate the credentials for an account.
Authentication Package: ADAM_LDSIDI01VDO
Logon Account: CN=user,OU=Employees,OU=Bar,OU=Administration,O=Foo,C=us
Source Workstation: 10.x.x.x:52186
Error Code: 0xc000006d
I posted this issue to a group of Directory Service MVP's and we eventually arrived at a solution; joe of joeware fame rightly pointed out that I was NOT using LDAPS (SSL) to bind to ADAM as the documentation clearly spells out. Kurt Hudson pointed out that the 202d error code was pointing out that SSL was required:
202d is ERROR_DS_CONFIDENTIALITY_REQUIRED (This request requires a secure connection.)
So, first problem solved, if you are binding to AD LDS/ADAM over 389 then you will not be able to test or use userProxy bind redirection back to AD. Therefore, you must enable SSL for your ADAM instance and this is where things got tricky if you are using Server Core. There is a certain lack of documentation as to how to do this in Server Core. With Kurt Hudson's help (Kurt writes documentation for the AD team at Microsoft!) we finally stumbled upon an answer. Here are my high-level notes:
- The processes documented here and here are somewhat misleading in that…
- You do not have to import the certificate into the ADAM instance or Network Service account as the instructions mention – this side tracked me for hours trying to figure out how to do this with certutil
- Finding the files in MachineKeys is not as easy as it sounds
So, assuming you already have a certificate assigned to your server for the full server name, you should be able to follow these steps to enable AD LDS/ADAM for SSL on a Server Core box:
Configuring SSL for AD LDS on Windows Server 2008 Server Core
- Step 1: Remote into your ADAM server – you'll have a command prompt
- Step 2: Change directory to:
C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys
- Step 3: Where are the files? Try looking for files with the System attribute set:
dir /as
- Step 4: Find out which of these files relate to your SSL certificate – run:
certutil –store My
- Step 5: Locate the Key Container GUID, this is the file you need for our next operation – run icacls /grant "NETWORK SERVICE":(R)
HINT: the file will tab-expand!
- Step 6: Try your LDP bind against the FQDN of your ADAM sever, remember to set the SSL flag and change the port to 636. Now you should be able to bind to userProxy objects!
Thanks to everyone that pitched in!