I have an AD RODC running on Server 2012 R2 Core in my perimeter network.
I am using this for external/hosted applications that can do LDAPS based auth. My problem is that the FQDN of the server is an internal-only name (rodc-01.company.local). I have an A-record in external DNS and external DNS for a friendly name (auth.company.com). I have already verified that normal, non-SSL LDAP traffic over port 389 functions fine for both internal and external applications.
Ideally, I want to only use LDAPS, but according to Microsoft, the FQDN of the server needs to be either in the common name or the SAN of the certificate. Given that I need to use this with external applications, I need a trusted third-party certificate. I obtained one through GoDaddy for auth.company.com. The RODC refuses to recognize the certificate (CAPI2 logs provide a host-name mismatch error). Trusted third-party cert providers do not issue certs for .local domains. Is there a way around this? I can issue a cert from my internal CA infrastructure, but then the external applications refuse to connect because they don't trust the cert, and not all the applications enable me to provide them the cert to trust.
Does anyone have knowledge, or experience making this work? Microsoft has left us in a real bind by putting this requirement on LDAPS.
Best Answer
The power of posting... I finally found this article:
Basically, in order to do this, you have to have the cert in the NTDS services cert store. Problem is that on a SErver Core box, Microsoft provides exactly 0 offical utilities/tools to do this. You can not remotely add certs with private keys to the NTDS cert store, and you can't use the MMC snapin from the Core box, nor do certutil.exe or the built-in PowerShell cmdlets work with anything other than LocalMachine and Current user.
You have to export the registry key pertaining to your cert from the LocalMachine store and then import those settings into the registry into the NTDS cert store's registry location.
Following a reboot, LDAPS connections to auth.company.com were accepted with no problems whatsoever.