Everyone talks about domain controllers and that they should have a certificate installed, but at the end of the day it is optional. Once installed, what actually makes use of that certificate? My understanding is that it is at least needed for:
- Smart Card Authentication
- LDAPS
However, I am seeking to know whether there are specific native actions by the DC or Active Directory where the domain controller make use of the certificate?
I'm aware of the security implications/good practice here :) I'm just interested in the mechanics in play.
Replication between domain controllers will still take place over RPC, even after installing SSL certificates. The payload is encrypted, but not with SSL.
If you use SMTP replication, that replication can be encrypted with the domain controller's SSL certificate... but I hope nobody is using SMTP replication in 2017.
LDAPS is like LDAP, but over SSL/TLS, utilizing the domain controller's certificate. But normal Windows domain members aren't automatically going to start using LDAPS for things like DC Locator or domain join. They'll still just use plain cLDAP and LDAP.
One of the main ways in which we use LDAPS is for 3rd-party services or non domain-joined systems that need a secure way to query the domain controller. With LDAPS those systems can still benefit from encrypted communications even if they're not joined to the domain. (Think VPN concentrators, Wifi routers, Linux systems, etc.)
But domain-joined Windows clients already have SASL signing and sealing and Kerberos, which is already encrypted and is pretty secure. So they'll just keep using that.
Smart card clients make use of the domain controller's SSL certificate when Strict KDC Validation is turned on. It's just an extra measure of protection for smart card clients to be able to verify that the KDC that they're talking to is legitimate.
The domain controllers could also use their certificates for IPsec communication, either amongst themselves or with member servers.
That's all I can think of right now.