Enabling SSL Access to AD LDS (Lightweight Directory Services)

June 26th at 12:00am

We recently  had some issues recently implementing SSL on a Active Directory Lightweight Directory Services box.

Here are some of the errors we were seeing:

  • LDP.exe shows Cannot open connection when attempting connection using SSL over port 636

Windows System Event log:

  • Description: A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009030d. The internal error state is 10001.
  • Description: No suitable default server credential exists on this system. This will prevent server applications that expect to make use of the system default credentials from accepting SSL connections. An example of such an application is the directory server. Applications that manage their own credentials, such as the internet information server, are not affected by this.

Windows Security Event Log:

  • Severity: FailureAudit
    Date Time: 6/24/2011 6:56:48 PM
    Source: Microsoft-Windows-Security-Auditing
    Category: (12290)
    Event ID: 5061

 

Notes:

  • AD LDS installed on Windows Server 2008 R2 Standard (Virtual Machine)
  • The VM was an instance of a template which already had LDS installed
  • This server was not joined to any domain
  • In the end this appears to have been a permissions issue (read on for details)
  • The Complete text to the error messages I encountered during this process are posted below for better searchability

 

I tried various steps to get SSL Authentication working with this server. In the end, these are the steps that I found to work:

Note: Microsoft Article Configuring LDAP over SSL Requirements for AD LDS is a must-read for anyone wanting to set this up

1) Created & Installed a Server Certificate Per the MS Guidelines which are:

  • Certificate must be issued to the FQDN of the Server running LDS
  • Installed the certificate to the Local Machine "Personal" certificate store

For help on using MakeCert to create a general purpose certificate, here is a helpful blog post

2) Navigated to C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys and ensured that the Network service and Local System accounts had access to the files in this folder

Note 1: This is not best practice in a production environment. I would suggest only adding read / read & execute permissions for the Service Account that Lightweight Directory Services is using

Note 2: To get SSL authentication to work, I actually had to clear all the permissions from the MachineKeys folder and re-assign the permissions manually. YMMV.

3) To ensure access to the LDS server from other machines in our environment I had to install the certificate on the other machines. I also had to add a hosts file / DNS entry for the Directory server. It appears that the secure connection will only work when the FQDN of the Directory Server is used.

Result: After completing these steps, I was able to connect to the Directory Server using SSL.

 

Comprehensive Troubleshooting Steps:

  • When I saw that SSL Connectivity was not working, I looked for MS Documentation
  • After Installing the certificates and setting up permissions on the files in the MachineKeys folder per the MS Article I was still having authentication issues
  • As this was a cloned Virtual Machine, I tried making a certificate for the original name of the machine and installing it to the same store as the Certificate for the current FQDN (LocalMachine\Personal)
  • When that did not work, I began looking in the Windows Event logs and found what appeared to be security / permissions issues
  • I did some google searching and found some suggestions to export then re-import the certificate (This did not work for me)
  • In an attempt to gain more information I searched the registry for information on the GUIDs listed in the messages (No results returned)
  • When none of this worked, I cleared the permissions on the C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys folder (along with the folder contents) and re-applied what I considered to be a broad enough permissions set to the files to allow SSL authentication to work. I applied Full Control to Network Service, Local System and Administrators. 
    • While this is a bit broad (unsuitable for Production), it works for us as an interim solution While we get a more suitable machine setup.

 

Complete text of errors encountered during the setup process:

Windows System Event Log:

Severity: Error
Date Time: 6/24/2011 6:35:14 PM
Source: Schannel
Category: (0)
Event ID: 36870
User: NT AUTHORITY\SYSTEM
Computer: TEST-MACHINE

Description: A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009030d. The internal error state is 10001.

 

 

Severity: Warning
Date Time: 6/24/2011 6:59:06 PM
Source: Schannel
Category: (0)
Event ID: 36886
User: NT AUTHORITY\SYSTEM
Computer: TEST-MACHINE

Description: No suitable default server credential exists on this system. This will prevent server applications that expect to make use of the system default credentials from accepting SSL connections. An example of such an application is the directory server. Applications that manage their own credentials, such as the internet information server, are not affected by this.

 

Windows Security Event Log:

Severity: FailureAudit
Date Time: 6/24/2011 6:42:37 PM
Source: Microsoft-Windows-Security-Auditing
Category: (12290)
Event ID: 5061
User:
Computer: TEST-MACHINE

Description: Cryptographic operation.

Subject:
Security ID: S-1-5-20
Account Name: JW-LDAPANDSMTP$
Account Domain: WORKGROUP
Logon ID: 0x3e4

Cryptographic Parameters:
Provider Name: Microsoft Software Key Storage Provider
Algorithm Name: %%2432
Key Name: {B1E98987-90F2-44E4-A872-8D544312270F}
Key Type: %%2499

Cryptographic Operation:
Operation: %%2480
Return Code: 0x80090010

 

 

Severity: FailureAudit
Date Time: 6/24/2011 6:56:48 PM
Source: Microsoft-Windows-Security-Auditing
Category: (12290)
Event ID: 5061
User:
Computer: TEST-MACHINE

Description: Cryptographic operation.

Subject:
Security ID: S-1-5-20
Account Name: TEST-MACHINE$
Account Domain: WORKGROUP
Logon ID: 0x3e4

Cryptographic Parameters:
Provider Name: Microsoft Software Key Storage Provider
Algorithm Name: %%2432
Key Name: PvkTmp:a8c7b6cc-132d-499a-9358-7ea733785aab
Key Type: %%2499

Cryptographic Operation:
Operation: %%2480
Return Code: 0x80090010

 

 

Severity: FailureAudit
Date Time: 6/24/2011 6:59:32 PM
Source: Microsoft-Windows-Security-Auditing
Category: (12290)
Event ID: 5061
User:
Computer: TEST-MACHINE

Description: Cryptographic operation.

Subject:
Security ID: S-1-5-20
Account Name: JW-LDAPANDSMTP$\
Account Domain: WORKGROUP
Logon ID: 0x3e4

Cryptographic Parameters:
Provider Name: Microsoft Software Key Storage Provider
Algorithm Name: %%2432
Key Name: {28FBF6F8-B4D4-4181-AFC3-8559C1877AE6}
Key Type: %%2499

Cryptographic Operation:
Operation: %%2480
Return Code: 0x80090010