I've got a configuration issue with my test domain controller (Server 2019) where I can't connect via 636 using LDP. (using the full domain name)
On 2008 and 2012 I didn't have to do any additional configuration; it just worked.
However, in 2019 is may appear that I need to manually configure an SSL cert for this to work. I found this article on MS: https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-ldap-over-ssl-3rd-certification-authority and it appears that I need to get a public certificate for each domain that I will be connecting to (which will be a lot). If this is true, those certs would expire and I'm not sure what the effect will be (will it still work or fail?). If it will fail, how do I watch the certs and fix ahead of time?
But this doesn't make sense to me since 2008 and 2012 both work "out of the box" with 636.
When I check the 2019 server with: certutil -v -urlfetch -verify serverssl.cer > output.txt
DecodeFile returned The system cannot find the file specified 0x80070002 (Win32: 2 ERROR_FILE_NOT_FOUND) LoadCert(Cert) returned The system cannot find the file specified 0x80070002 (Win32: 2 ERROR_FILE_NOT_FOUND) CertUtil -verify command FAILED: 0x80070002 (WIN32: 2 ERROR_FILE_NOT_FOUND) CertUtil: The system cannot find the file specified.
So that's telling me the cert does not exist.
Each of the domains I will be connecting to, the computer connecting to them will not be in the same domain. In that above article it was referring to having a cert that can be trusted by both devices.
From the testdomain I can run LDP and connect back into the 2008 or 2012 domain with zero issues on 636 using the builtin configured certificate... But this is a new version and it appears to be different.
Has anyone run into this on 2019 and can share a little more information of what I'm encountering?
User contributions licensed under CC BY-SA 3.0