A customer was having issues with a Windows Security pop-up showing for a subset of the users, whenever those users were trying to use a specific application.
The application was failing, because the password needed here is not the user’s Active Directory account password, but the users of course had no idea.
The users affected by this all had the Danish national identity system’s employee certificate ("NemID Medarbejdersignatur”) installed, and this - in conjuction with the specifik application - was causing the pop-up to appear.
And the password needed in the security pop-up is not the user’s Active Directory account password but the password for the certificate installed by the national identity provider, NemID.
for suggested workarounds, see the buttom of this blog post.
Why this specific application?
Because it was using LDAP over SSL (LDAPS).
And when the LDAPS connection is being established, the Domain Controller and the Windows client try to authenticate the client using a certificate, that was never intended for this purpose.
With LDAPS, there is obviously always server authentication by means of the Domain Controller’s SSL certificate as proof of the server’s identity.
But LDAPS on the DC can also verify the client user’s credential by means of a client certificate.
According to this article, this happens, if certain criteria is met in the client cerficate, one of them being:
“The enhanced key usage extension includes the Client Authentication object identifier (1.3.6.1.5.5.7.3.2)”
However, it turns out, contrary to what we read in the MS article, that this is not a requirement.
This certificate issued by the national identity provider, is being used for authentication to LDAPS, even though Enhanced Key Usage (EKU) does not specify this usage.
Neither does the certificate’s Subject or Subject Alternative Name contain anything, that could imply, that it could be used to authenticate the user against Active Directory.
Subject and SAN of the certificate does not contain the AD user account’s UPN, and EKU is empty
As long as the certificate’s “intended purposes” (application policies) includes “client authentication”, and the Domain Controller has the root certificate for the user’s certificate installed in Trusted Root Certificate Authorities, Windows will try to authenticate to the LDAPS service using that certificate.
NOTE! After trying to connect to LDAPS using this certificate, you do not have a succesfully authenticated LDAP Bind, using this certificate. Instead you will see Event ID 4625: An account failed to log on, in the DC’s Event Log.
Had the certificate been a valid user certificate with the right properties, the LDAPS connect and the LDAP Bind could be authenticated properly just using the certificate.
So this is not a security vulnerability, but it is a functional issue, and an annoying one to the end users.
Why the pop-up? Why not just use the certificate?
This is because the certificate is installed with strong private key protection.
This forces the Data Protection API to ask for user’s consent before using the certificate’s private key.
Had it been installed with strong private key protection, Medium level, the user would just be asked for confirmation, not a password.
In this case, the “employee certificate” is protected with a password as well; a password that is chosen by the user. It is not derived from the Active Directory user account password.
And so, the user is asked to provide this password, when establishing a connection to AD using LDAPS.
If you’re curious, you can see how to set strong private key protection when enrolling a certificate manually using the Certificates MMC snap-in:
I suspect a lot more would have observed this, if more certificates were protected with strong private key protection, which would force the pop-up window.
Now, Windows just tries to connect a lot of users with whatever certificate, and the users are never becoming aware about this issue.
How to reproduce
It is actually quite simple: Use the LDP.exe tool from Remote Server Administration Tools to connect to Active Directory using SSL.
If you have a certificate with strong private key protection, and no other applicable user certificate, you could verify the issue by seeing the pop-up window.
If you don’t see it, it is probably because the Domain Controllers do not trust the root (and intermediate) certificate authorities of the certificate. In this case, the certificate would not be used for authentication.
Workarounds
In the case of this customer, there was no need for the root and intermediate CA certs on the Domain Controllers, and these CA certs are not rolled out automatically using the Microsoft Trusted Root Certificate Program updates.
The CA certificates might have been added to the DCs from a Group Policy, that was intended to make all computers in the domain trust these root and intermediate CA certificates.
So, the root and intermediate CA certificates can just be removed from the DCs’ Trusted Root Certification Authority stores.
Then the DC will not accept the client’s certificate, and the user will never see the Windows Security pop-up
This might not be an option in cases, where there is a need for these certificates on the DCs. For example, the user’s certificate (the one with strong private key protection) might be enrolled from an Enterprise PKI, that has to be trusted, or from a CA, that has a root CA in the Microsoft Trusted Root Certificate Program.
In this case, an option could be to remove the “client authentication” from the user certificate’s allowed purposes.
This can be accomplished in the Properties of the certificate:
When “Client Authentication” is removed from intended purposes on the certificate, it will never be used to authenticate to the DC over LDAPS.
A third option, of course, is to enroll certificates for all users from the internal Enterprise PKI.
These certificates should have Client Authentication as purpose and be enrolled for the user’s UPN.
The enhanced key usage extension should include the Client Authentication object identifier (1.3.6.1.5.5.7.3.2).
The regular User Certificate template in a Microsoft CA will fulfill the requirements.
In this case, this certificate could be used by Windows to authenticate agains LDAPS.