Unable to Authenticate to LDAP Server for Active Directory Authentication

[ClaytonDaniels]

Good morning,

Hoping the community can provide some assistance. I do have a Support Ticket in, but it has proved futile to this point. We had a certificate expire on our DCs (2016 Datacenter). Upon realization, I renewed and downloaded the Cert and applied it to the DCs.

DC01 is the Primary, DC02 is the Secondary. DC01 is the RADIUS server. Both Global Catalogs. Both contain the Cert in the Personal > Certificates folder with an expiry date of 6/23.

We started receiving calls that Client VPN wasn't working. Investigation commenced.

Security & SD WAN > Active Directory (authenticate uses with AD)

Short domain	Server IP   Domain admin	Password	Status
domain          10.1.0.3    domain\admin        •••••••••••••   yellow
domain          10.1.0.4    domain\admin        •••••••••••••   red

Neither Active Directory server can contact Radius via Dashboard. .3 is WMI error. .4 is ldap_start_tls: Server is unavailable

Security & SD WAN > Client VPN (enabled)

Short domain	Server IP   Domain admin	Password
domain          10.1.0.4    admin               •••••••••••••

No warning for inability to connect, authenticate, or contact LDAP Server.

Support sent me to the WMI Error information page which was the Configuring Active Directory with MX Security Appliances documentation. I ran through this page thoroughly, retraced all steps and made certain that everything was set to go.

Support also sent me to the KB5004442 support page for Microsoft. I discovered my servers needed a registry entry to potentially solve this issue. Both DCs had the registry entry RequireIntegrityActivationAuthenticationLevel applied with a value (hexidecimal) of 0 to disable hardening. This should have fixed the issue according to everything else I have read. No go.

However, there was a change on the Security & SD WAN > Active Directory Dashboard. This is when the ldap_start_tls: Server is unavailable error started to appear.

Support sent me to Active Directory Issue Resolution Guide and more specifically, linked me down to the ldap_start_tls: Server is Unavailable section. I have confirmed, to the best of my knowledge, that each DC contains the TLS 1.2 protocol and it is enabled. Also, to the best of my knowledge, the domain certificate is valid.

Hoping for some direction on where to go from here... my guess is that Support is going to tell me it's a Sever 2016 issue. To that point, Event Viewer of DC01 shows WARNINGS every 7 or 8 seconds:

Event ID 36886, Schannel
No Suitable default server credentials exists on this system. This will prevent applications that expect to make use of the system default credentials from accepting SSL connections. An example of such an application is the directory server.

And every 20 minutes or so, an ERROR:

Event ID 10036, DistributedCOM
The server-side authentication level policy does not allow the user %1\%2 SID (%3) from address %4 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application.

This is the error that should have been resolved with the Registry edit to disable hardening and to be transparent, this error was generating every 5 or 6 seconds yesterday. Now, only every 20 minutes or so.

One other thing of note... to my knowledge, each Server 2016 DC is fully up to date, however, I do not see that KB5005573 is installed on the machine (the one related to KB5004442 that dealt with DCOM). I attempted to install KB5005573 manually, but it told me the file was not applicable. That seemed odd.

I think that is all the information I have. I don't think I left anything out. I look forward to any advice or solutions you all may have!

Thank you, Meraki Community!

-ClaytonDaniels

[ClaytonDaniels · Accepted solution]

I seem to have at least resolved the connection to the RADIUS server. It turns out the SSL may have been the culprit. After rereading (for the 4th time) the Certificate Requirements for TLS I decided to reissue the Cert with the FQDN (as a Subject Alternative Name) of the RADIUS server (actually, both DCs). Once I reapplied the cert on the DCs, the connection from the Dashboard to the RADIUS server went green and the WARNING messages (concerning SChannel) ceased.

To be clear, while this does seem to be the answer, none of the previous 3 certificates (dating back to 2018) had the FQDN as a Subject Alternative Name. I don't know if this is a Microsoft change or a Meraki change that now requires the FQDN of the DC itself. 

Hope this helps someone in the future!

[PhilipDAth]

I was under the impression it always had to be the FQDN, but maybe I have just been lucky.  I think some things are ok with it being just one way or the other.

The last certificate I did for this I used the FQDN as the subject name, and listed just the host name as a second name, so it can validate either - and then I extended the certificate expiry date for 10 years so I never have to touch it again.  It's yucky.