Après de multiples reports, Microsoft a finalement décidé que la Modifications apportées à l'émission de certificats et à l'ouverture de session basée sur des certificats dans Active Directory par le correctif pour Windows Server du 10 mai 2022 (KB5014754) devraient maintenant entrer définitivement en vigueur.
Les contrôleurs de domaine passeront donc automatiquement en mode "full enforcement" le 25 février 2025 si rien d'autre n'est configuré. En septembre 2025, il est annoncé que les paramètres divergents seront supprimés et qu'il n'y aura donc plus d'alternative au full enforcement.
Cela a pour conséquence que les inscriptions via PKInit ne peuvent être utilisées pour une inscription que si elles disposent de l'extension de certificat Security Identifier (SID) nouvellement introduite avec le patch.
Ce qui semble à première vue ne pas être un problème majeur peut en fait en devenir un si l'on considère que de moins en moins de cas d'application basés sur des certificats utilisent aujourd'hui l'auto-enrollment classique.
Comme le Module de politique TameMyCerts pour les services de certificats Active Directory peut aider à résoudre ce problème est expliqué plus en détail dans l'article suivant.
Qui et quoi est concerné ?
La modification concerne en principe tous les cas d'application qui ne peuvent être couverts par l'auto-inscription classique lorsque les certificats sont utilisés pour une inscription via PKInit.
Si l'extension du certificat SID manque dans de tels certificats, cela peut entraîner des problèmes d'authentification, notamment avec les services suivants :
- VPN toujours en ligne
- Contrôle d'accès réseau (NAC) avec le logiciel Microsoft Serveur de politiques de réseau (NPS)
- Windows Hello for Business, si des certificats sont utilisés pour connecter les utilisateurs
Ce problème ne concerne toutefois pas uniquement Microsoft Intune, mais aussi tous les autres systèmes de gestion des appareils mobiles (MDM) qui gèrent des appareils fonctionnant dans un environnement Active Directory avec des certificats.
Il peut s'agir, entre autres, de
- Microsoft Intune
- VMware Workspace One (précédemment connu sous le nom de AirWatch)
- Ivanti MobileIron UEM
- Jamf Pro
- Gestion de la mobilité d'entreprise Baramundi
- BlackBerry Enterprise Mobility Suite
- Bon pour l'entreprise
- Sophos Mobile
- SOTI MobiControl
Le problème ne se limite toutefois pas aux systèmes de gestion des appareils mobiles.
Tous ces systèmes fonctionnent selon un modèle similaire : la demande de certificat est envoyée par le système MDM, l'autorité de certification doit généralement être configurée pour la signer sans la vérifier.
La solution - TameMyCerts
TameMyCerts est un module de politique pour les Microsoft Active Directory Certificate Services (ADCS). Il intervient dans le processus d'émission des certificats et permet d'appliquer des règles avancées.
TameMyCerts est open source et peut être utilisé gratuitement. Toutefois, pour une utilisation en entreprise, il est recommandé d'utiliser le Conclusion d'un contrat de maintenance. Cela garantit que vous recevrez un soutien qualifié et que le module pourra être développé à long terme avec une qualité élevée.
Supposons, à titre d'exemple, que notre entreprise propose aux utilisateurs d'utiliser des terminaux gérés par un système de gestion des appareils mobiles (MDM). Les comptes d'utilisateurs existent dans l'Active Directory et disposent donc d'un Security Identifier (SID), mais le système MDM ne permet pas de les inclure dans la demande de certificat.
TameMyCerts peut y remédier en créant un lien entre la demande de certificat et le compte utilisateur.
Une fois que le module Policy installe a été nous créons un fichier de configuration correspondant:
<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>
Dans cet exemple, nous nous attendons à ce que la demande de certificat ne contienne que le nom d'utilisateur (attribut sAMAccountName) dans l'attribut commonName Attribut du Subject Distinguished Name de la demande de certificat.
Cette partie doit être configurée en conséquence dans le système MDM. Pour VMware Workspace One, la syntaxe serait par exemple "CN={EnrollmentUser}".
La syntaxe attendue pour le commonName est donnée sous la forme d'une expression régulière dans "Pattern" à.
Les "DirectoryServicesMappingLa directive "sAMAccountName" prend maintenant le commonName et recherche dans l'Active Directory un objet de type "user" qui peut présenter comme attribut "sAMAccountName" la valeur du commonName de la demande de certificat, mais uniquement dans le sous-répertoire "ADCS Labor Users", que nous spécifions via "SearchRoot".
Dans la section „ AllowedSecurityGroups “, nous spécifions que le compte utilisateur trouvé doit être membre du groupe de sécurité „ MDM Users “. Dans la section „ DisallowedSecurityGroups “, nous limitons cette condition en précisant que les comptes trouvés ne doivent pas être membres du groupe „ Administrative Users “.
Si aucun objet répondant à tous ces critères n'est trouvé, la demande de certificat est refusée.
Cependant, si un objet est trouvé, nous pouvons maintenant écrire son identifiant de sécurité (SID) dans le certificat émis, ce que nous pouvons faire avec " .SecurityIdentifierExtension" configurer.
Le certificat délivré disposera alors de l'extension de certificat correspondante.
Comme effet secondaire agréable, nous veillons également à ce que seuls les comptes connus reçoivent un certificat, mais uniquement s'ils sont membres d'un groupe spécifique et ne sont pas administrateurs. Nous avons donc considérablement augmenté le niveau de sécurité par rapport à la situation précédente.
Liens complémentaires :
- Modifications apportées à l'émission de certificats et à l'ouverture de session basée sur des certificats dans Active Directory par le correctif pour Windows Server du 10 mai 2022 (KB5014754)
- Les connexions via le serveur de stratégie réseau (NPS) échouent avec la raison suivante : "Authentication failed due to a user credentials mismatch. Soit le nom d'utilisateur fourni ne correspond pas à un compte utilisateur existant, soit le mot de passe était incorrect".
- Un module de politique pour les apprivoiser : Présentation du module de politique TameMyCerts pour Microsoft Active Directory Certificate Services
Français 
Deutsch 
English