Join Log in
Score:0
ItsPronounced avatar Server

LDAPS certificate isn't working on new server for third parties

cv flag
ItsPronounced

About 5-6 years ago I setup LDAPS on my Primary Domain controller. I setup Active Directory Certificate Services (all on the same server), forwarded the port 636 on my firewall, and was able to successfully authenticate with third parties using this. Last week I decommissioned that server, removed all roles and built a new Primary and Secondary domain controller (Server 2016). After some reading I decided to make the secondary domain controller my ADCS server and have it handle LDAPS. My secondary domain controller's FQDN is dc02.domain.com. The outside address I'm using to connect is ds.domain.com:636. This worked for years with no problem.

I specifically remember using this tutorial the first time to setup LDAPS (which also references this tutorial to setup ADCS, both of which I did). So on my new Secondary Domain Controller I tried following those steps exactly. Everything appeared to work (I could use ldp.exe and get a success message) and I could see the certificate for LDAPS. I updated my firewall port forward to the new server, but when I tried to test with my third party (barracuda essentials) I would get the error: Could not bind privileged user: Ldap Error Code=-1 - Can't contact LDAP server. I tested the forwarded port and it works. After troubleshooting and running the command openssl s_client -connect dc02.domain.com:636, I realized it was still referencing the old CA. So I tried cleaning up the old CA root and personal certs and reissue a new cert. After doing this and running the openssl command again I still get errors and cannot connect from third party. What stands out from the output of the command is:

CONNECTED(000001BC)
depth=0 CN = DC02.domain.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = DC02.domain.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = DC02.domain.com
verify return:1
---
Certificate chain
 0 s:CN = DC02.domain.com
   i:DC = com, DC = domain, CN = domain-DC01-CA
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
       v:NotBefore: Aug 14 23:52:24 2023 GMT; NotAfter: Aug 13 23:52:24 2024 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
xxxxxx
-----END CERTIFICATE-----
subject=
issuer=DC = com, DC = domain, CN = domain-DC01-CA  <--NOTE this is my old CA>
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
Shared Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2069 bytes and written 438 bytes
Verification error: unable to verify the first certificate

Notice the reference to my old CA after END CERT. The old CA is not even turned on. I removed the ADCS and NPS role (NPS might not be relevant here) and shut it down for now to make sure my Active Directory environment is working and replicating with my 2 new domain controllers (so far so good). I noticed that the old CA root certs and old certs are still present on DC02, but I'm not sure if I should remove them or not. I also tried requesting a new cert, using the LDAP template I made (from Kerboros template) and assigning the cert to ldaps service manually using the registry. I've since then reversed those registry changes.

I am by no means a CA or LDAP expert, and this is driving me crazy. At this point I have removed the CA role from DC02 and plan on re-adding it, but I want to make sure I'm going down the right path. What am I missing? Should I approach this another way?

EDIT: adding ldp.exe output. When I run this on the CA I get:

-----------
0x51 = ldap_unbind(ld);
ld = ldap_sslinit("dc02.domain.com", 636, 1);
Error 81 = ldap_set_option(hLdap, LDAP_OPT_PROTOCOL_VERSION, 3);
Error 0 = ldap_connect(hLdap, NULL);
Error 0 = ldap_get_option(hLdap,LDAP_OPT_SSL,(void*)&lv);
Host supports SSL, SSL cipher strength = 256 bits
Established connection to dc02.domain.com.
Retrieving base DSA information...
Getting 1 entries:
Dn: (RootDSE)
configurationNamingContext: CN=Configuration,DC=domain,DC=com; 
currentTime: 8/15/2023 5:01:50 PM Central Daylight Time; 
defaultNamingContext: DC=domain,DC=com; 
dnsHostName: DC02.domain.com; 
domainControllerFunctionality: 7 = ( WIN2016 ); 
domainFunctionality: 7 = ( WIN2016 ); 
dsServiceName: CN=NTDS Settings,CN=DC02,CN=Servers,CN=Domain,CN=Sites,CN=Configuration,DC=domain,DC=com; 
forestFunctionality: 7 = ( WIN2016 ); 
highestCommittedUSN: 86626; 
isGlobalCatalogReady: TRUE; 
isSynchronized: TRUE; 
ldapServiceName: domain.com:[email protected]; 
namingContexts (5): DC=domain,DC=com; CN=Configuration,DC=domain,DC=com; CN=Schema,CN=Configuration,DC=domain,DC=com; DC=DomainDnsZones,DC=domain,DC=com; DC=ForestDnsZones,DC=domain,DC=com; 
rootDomainNamingContext: DC=domain,DC=com; 
schemaNamingContext: CN=Schema,CN=Configuration,DC=domain,DC=com; 
serverName: CN=DC02,CN=Servers,CN=Domain,CN=Sites,CN=Configuration,DC=domain,DC=com; 
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=domain,DC=com; 
supportedCapabilities (6): 1.2.840.113556.1.4.800 = ( ACTIVE_DIRECTORY ); 1.2.840.113556.1.4.1670 = ( ACTIVE_DIRECTORY_V51 ); 1.2.840.113556.1.4.1791 = ( ACTIVE_DIRECTORY_LDAP_INTEG ); 1.2.840.113556.1.4.1935 = ( ACTIVE_DIRECTORY_V61 ); 1.2.840.113556.1.4.2080 = ( ACTIVE_DIRECTORY_V61_R2 ); 1.2.840.113556.1.4.2237 = ( ACTIVE_DIRECTORY_W8 ); 
supportedControl (38): 1.2.840.113556.1.4.319 = ( PAGED_RESULT ); 1.2.840.113556.1.4.801 = ( SD_FLAGS ); 1.2.840.113556.1.4.473 = ( SORT ); 1.2.840.113556.1.4.528 = ( NOTIFICATION ); 1.2.840.113556.1.4.417 = ( SHOW_DELETED ); 1.2.840.113556.1.4.619 = ( LAZY_COMMIT ); 1.2.840.113556.1.4.841 = ( DIRSYNC ); 1.2.840.113556.1.4.529 = ( EXTENDED_DN ); 1.2.840.113556.1.4.805 = ( TREE_DELETE ); 1.2.840.113556.1.4.521 = ( CROSSDOM_MOVE_TARGET ); 1.2.840.113556.1.4.970 = ( GET_STATS ); 1.2.840.113556.1.4.1338 = ( VERIFY_NAME ); 1.2.840.113556.1.4.474 = ( RESP_SORT ); 1.2.840.113556.1.4.1339 = ( DOMAIN_SCOPE ); 1.2.840.113556.1.4.1340 = ( SEARCH_OPTIONS ); 1.2.840.113556.1.4.1413 = ( PERMISSIVE_MODIFY ); 2.16.840.1.113730.3.4.9 = ( VLVREQUEST ); 2.16.840.1.113730.3.4.10 = ( VLVRESPONSE ); 1.2.840.113556.1.4.1504 = ( ASQ ); 1.2.840.113556.1.4.1852 = ( QUOTA_CONTROL ); 1.2.840.113556.1.4.802 = ( RANGE_OPTION ); 1.2.840.113556.1.4.1907 = ( SHUTDOWN_NOTIFY ); 1.2.840.113556.1.4.1948 = ( RANGE_RETRIEVAL_NOERR ); 1.2.840.113556.1.4.1974 = ( FORCE_UPDATE ); 1.2.840.113556.1.4.1341 = ( RODC_DCPROMO ); 1.2.840.113556.1.4.2026 = ( DN_INPUT ); 1.2.840.113556.1.4.2064 = ( SHOW_RECYCLED ); 1.2.840.113556.1.4.2065 = ( SHOW_DEACTIVATED_LINK ); 1.2.840.113556.1.4.2066 = ( POLICY_HINTS_DEPRECATED ); 1.2.840.113556.1.4.2090 = ( DIRSYNC_EX ); 1.2.840.113556.1.4.2205 = ( UPDATE_STATS ); 1.2.840.113556.1.4.2204 = ( TREE_DELETE_EX ); 1.2.840.113556.1.4.2206 = ( SEARCH_HINTS ); 1.2.840.113556.1.4.2211 = ( EXPECTED_ENTRY_COUNT ); 1.2.840.113556.1.4.2239 = ( POLICY_HINTS ); 1.2.840.113556.1.4.2255; 1.2.840.113556.1.4.2256; 1.2.840.113556.1.4.2309; 
supportedLDAPPolicies (20): MaxPoolThreads; MaxPercentDirSyncRequests; MaxDatagramRecv; MaxReceiveBuffer; InitRecvTimeout; MaxConnections; MaxConnIdleTime; MaxPageSize; MaxBatchReturnMessages; MaxQueryDuration; MaxDirSyncDuration; MaxTempTableSize; MaxResultSetSize; MinResultSets; MaxResultSetsPerConn; MaxNotificationPerConn; MaxValRange; MaxValRangeTransitive; ThreadMemoryLimit; SystemMemoryLimitPercent; 
supportedLDAPVersion (2): 3; 2; 
supportedSASLMechanisms (4): GSSAPI; GSS-SPNEGO; EXTERNAL; DIGEST-MD5;

This means it's successful?

84
1 + 3
cn flag
Greg Askew
`The old CA is not even turned on.` consumers need to connect to things such as the CRL to validate revocations. If you turned something off, probably a good idea to host the CRL at a minimum. Or use a normal certificate that has all of the bits accessible on different infrastructure.
1
Reply
ItsPronounced avatar
cv flag
ItsPronounced
Thanks but I'm not sure I understand. The old CA was just for the ldaps connection. It wasn't used to issue certs company wide (small company)
0
Reply
ItsPronounced avatar
cv flag
ItsPronounced
I'm not sure if this matters, but I notice on my CA that there are two identical certs under Trusted Root Certs for said CA. Same thumbprint and everything.. Is this causing an issue?
0
Reply
Score:1
Jan avatar Server
ru flag
Jan

Sounds like a problem with multiple certificates, described here: https://support.microsoft.com/en-us/help/321051/how-to-enable-ldap-over-ssl-with-a-third-party-certification-authority

Schannel, the Microsoft SSL provider, selects the first valid certificate that it finds in the local computer store. If there are multiple valid certificates available in the local computer store, Schannel may not select the correct certificate. The certificate with the longest expiration date will get picked

If you have 2k8 or above, you can put the LDAP certificate in the NTDS\MY store and it will ensure that LDAP picks that one versus certificates that match the machine in the LocalMachine\MY store.

enter image description here enter image description here enter image description here

Here, you have to import the certificate (with the private key!). If the private key is not exportable, please see the following method to copy the certificate to the NTDS store without export/import.

Navigate to the desired certificate in registry and export the whole key. enter image description here

Then in the exported file, replace

Replace

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\MY\Certificates\45EEACDA090BAB6E602C29E14F587D7FEE5DDAD7]

With

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Services\NTDS\SystemCertificates\My\Certificates\45EEACDA090BAB6E602C29E14F587D7FEE5DDAD7]

Double click the REG file. You now have copied the certificate to the NTDS\Personal Store without having to have the private key exportable.

If the new certificate does not get picked automatically, you can refresh LDAPS by rebooting or executing following command

ldifde -i -f reloadLDAP.txt

Where reloadLDAP.txt is a text file that contains the following

    dn:
    changetype: modify
    add: renewServerCertificate
    renewServerCertificate: 1
    -
+ 4
ItsPronounced avatar
cv flag
ItsPronounced
Thank you, this is very concise. I followed the instructions and rebooted but still no luck. However I ran the `openssl s_client -connect dc02.domain.com:636` command again and got the exact same output as above, but it added this at the end: https://imgur.com/9GgvWEd I'm going to run the reloadLDAP file you mention and try again. Is `dn:` is suppose to be blank in reloadLDAP.txt?
0
Reply
Jan avatar
ru flag
Jan
Yes the DN is empty since it is a special "trigger". If you rebooted, then the command is not necessary. Sorry cant view the image at work. Does the openssl show you the correct certificate now?
0
Reply
ItsPronounced avatar
cv flag
ItsPronounced
It's showing the same error as before but added a new section at the end that says `Verification error: unable to verify the first certificate`
0
Reply
Jan avatar
ru flag
Jan
Double checked the openssl output, are you sure you have the correct certificate issued? I only see depth 0, to me it looks like its sending a self-signed certificate and not one signed by a CA (by itself in this case since the CA is on the DC). Copy the stuff between the BEGIN and END certificate into a .cer file and open it on another host to see more the details about the presented certificate.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.