Only LDAP data transfers are exposed. Other authentication or authorization data using Kerberos, SASL, and even NTLM have their own encryption systems. The Microsoft Management Console (mmc) snap-ins, since
Windows 2000 SP4 have used LDAP sign and seal or
Simple Authentication and Security Layer (SASL) and replication between domain controllers
is encrypted using Kerberos.
Warning Before you install a certification authority (CA), you should be aware that you are creating or extending
a public key infrastructure (PKI). Be sure to design a PKI that is appropriate for your organization. See
PKI Design Brief Overview for additional information.
To request a certificate from your LDAPSL server, do the following on each domain controller that requires LDAPS connections:
Are there any best practices with LDAP over SSL such as:
If you enable LDAP over SSL, the SSL certificate should be installed on every domain controller?
Or does it not matter, and perfectly okay to enable in the Default Domain controllers GPO "Domain controller: LDAP server signing requirements" but only put the SSL certificate on a small subset of Domain Controllers, and dedicate those DCs as application authentication DCs for things that need LDAP and simple bind?
Add or Remove Snap-ins dialog box click OK.
Expand Certificates - Services (Active Directory Domain Services) and then click NTDS\Personal.
Right-click NTDS\Personal, click All Tasks, and then click Import.
It seems this procedure is applicable only on a domain controller isn't? But if I want to export the same Certificates from the domain controller and import them into the Web Server who is responsible for the LDAPs authentication, the Active Directory Domain Services is not available because it is a member server.
Therefore, a Note is applicable in this article.
Might be good to also note that depending on the account running AD DS or AD LDS service, it may be necessary to add NTFS rights to the file in the cert store under C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys - AD DS running as local system I'd hope would have rights by default except in the most severely locked down environments, but AD LDS was mentioned above, and often that would be run under Network Service or a proxy account and need read & execute rights assigned.
support.microsoft.com/.../938703 for troubleshooting.
Hello, you should add this infor regarding Certificate Storage behavior in 2008 and superior:
Windows Server 2008 improvements
The original recommendation in this article was to put certificates in the Local Machine's Personal store. Although this option is supported, you can also put certificates in the NTDS Service's Personal certificate store on Windows Server 2008 and on later versions of Active Directory Domain Services (AD DS). For more information about how to add the certificate to the NTDS service's Personal certificate store, visit the following Microsoft TechNet Web site:
AD DS preferentially looks for certificates in this store over the Local Machine's store. This makes it easier to configure AD DS to use the certificate that you want it to use. This is because there might be multiple certificates in the Local Machines Personal store, and it can be difficult to predict which one is selected.
AD DS detects when a new certificate is dropped into its certificate store and then triggers an SSL certificate update without having to restart AD DS or restart the domain controller.
A new rootDse operation that is named renewServerCertificate can be used to manually trigger AD DS to update its SSL certificates without having to restart AD DS or restart the domain controller. This attribute can be updated using adsiedit.msc, or by importing the change in LDAP Directory Interchange Format (LDIF) using ldifde.exe. For more information on using LDIF to update this attribute, visit the following Microsoft MSDN Web site:
Finally, if a Windows Server 2008 or a later version domain controller finds multiple certificates in its store, it automatically selects the certificate whose expiration date is furthest in the future. Then, if your current certificate is approaching its expiration date, you can drop the replacement certificate in the store, and AD DS automatically switches to use it.
All these work for Windows Server 2008 AD DS and for 2008 Active Directory Lightweight Directory Services (AD LDS). For AD LDS, put certificates into the Personal certificate store for the service that corresponds to the AD LDS instance instead of for the NTDS service. date, you can drop the replacement certificate in the store, and AD DS automatically switches to use it.