After several postponements, Microsoft finally decided that the Changes to Certificate Issuance and Certificate-Based Logon to Active Directory with the May 10, 2022 Patch for Windows Server (KB5014754) should now finally come into force.
Domain controllers will therefore automatically switch to full enforcement mode on February 25, 2025, unless configured otherwise. As of September 2025, it has been announced that deviating settings will no longer apply and there will therefore no longer be an alternative to full enforcement.
The consequence of this is that logins via PKInit can only be used for a login if they have the new Security Identifier (SID) certificate extension introduced with the patch.
What at first sounds as if this is not a major problem may well become one when you consider that fewer and fewer certificate-based use cases are using classic autoenrollment these days.
How the TameMyCerts Policy Module for the Active Directory Certificate Services can help with this problem is explained in more detail in the following article.
Who and what is affected?
The change basically affects all use cases that cannot be covered by classic autoenrolment if the certificates are used for logon via PKInit.
If the SID certificate extension is missing in such certificates, this can lead to authentication problems, especially with the following services:
- Always On VPN
- Network Access Control (NAC) with the Microsoft Network Policy Server (NPS)
- Windows Hello for Business, if certificates are used to log in users
However, this problem not only affects Microsoft Intune, but also all other mobile device management (MDM) systems that manage devices that work in an Active Directory environment with certificates.
Among others, these can be
- Microsoft Intune
- VMware Workspace One (previously known as AirWatch)
- Ivanti MobileIron UEM
- Jamf Pro
- Baramundi Enterprise Mobility Management
- BlackBerry Enterprise Mobility Suite
- Good for Enterprise
- Sophos Mobile
- SOTI MobiControl
However, the problem is not limited to mobile device management systems.
All these systems work according to a similar pattern: The certificate request is signed by the MDM system, the certification authority must usually be configured to sign it without verification.
The solution - TameMyCerts
TameMyCerts is a policy module for Microsoft Active Directory Certificate Services (ADCS). It intervenes in the certificate issuance process and enables the application of extended rules.
TameMyCerts is open source and can be used free of charge. For use in the corporate sector, however, we recommend the Conclusion of a maintenance contract. This ensures that you receive qualified support and that the module can be further developed to a high quality in the long term.
Let's assume, for example, that our company offers users the use of end devices that are managed via a mobile device management system (MDM). Although the user accounts exist in the Active Directory and therefore have a security identifier (SID), the MDM system does not offer the option of adding these to the certificate application.
TameMyCerts can help here by establishing a connection between the certificate request and the user account.
After the policy module installed was, we create a corresponding configuration file:
<CertificateRequestPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Subject>
<SubjectRule>
<Field>userPrincipalName</Field>
<Mandatory>true</Mandatory>
<Patterns>
<Pattern>
<Expression>^[a-zA-Z0-9]*$</Expression>
</Pattern>
</Patterns>
</SubjectRule>
</Subject>
<DirectoryServicesMapping>
<SearchRoot>OU=ADCS Labor Users,DC=intra,DC=adcslabor,DC=de</SearchRoot>
<CertificateAttribute>commonName</CertificateAttribute>
<DirectoryServicesAttribute>sAMAccountName</DirectoryServicesAttribute>
<ObjectCategory>user</ObjectCategory>
<AllowedSecurityGroups>
<string>CN=MDM Users,OU=ADCS Labor Groups,DC=intra,DC=adcslabor,DC=de</string>
</AllowedSecurityGroups>
<DisallowedSecurityGroups>
<string>CN=Administrative Accounts,OU=ADCS Labor Groups,DC=intra,DC=adcslabor,DC=de</string>
</DisallowedSecurityGroups>
</DirectoryServicesMapping>
<SecurityIdentifierExtension>Add</SecurityIdentifierExtension>
</CertificateRequestPolicy>
In this example, we expect the certificate request to contain only the user name (sAMAccountName attribute) in the commonName Attribute of the Subject Distinguished Name of the certificate application.
This part must be configured accordingly in the MDM system. For VMware Workspace One, for example, the syntax would be "CN={EnrollmentUser}".
We enter the expected syntax for the commonName as a regular expression in the "Pattern" to.
The "DirectoryServicesMapping" directive now takes the commonName and searches the Active Directory for an object of the type "user", which can have the value from the commonName of the certificate request as the "sAMAccountName" attribute, but only in the "ADCS Labor Users" subdirectory, which we specify via "SearchRoot".
In the "AllowedSecurityGroups" area, we specify that the user account found must be a member of the "MDM Users" security group, while under "DisllowedSecurityGroups" we restrict this to the fact that accounts found must not be members of "Administrative Users".
If no object is found that meets all these criteria, the certificate application is rejected.
However, if an object is found, we can now write its security identifier (SID) to the issued certificate, which we can do via "SecurityIdentifierExtension" configure.
The issued certificate will now have the corresponding certificate extension.
As a pleasant side effect, we also ensure that certificates are only issued for known accounts, but only if they are members of a certain group and are not administrators. As a result, we have significantly increased the level of security compared to before.
Related links:
- Changes to Certificate Issuance and Certificate-Based Logon to Active Directory with the May 10, 2022 Patch for Windows Server (KB5014754)
- Logins via the Network Policy Server (NPS) fail with reason "Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect."
- A policy module to tame them all: Introducing the TameMyCerts Policy Module for the Microsoft Certification Authority.
English 
Deutsch