Groupe de sécurité Utilisateurs protégés

  • Article

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Les Utilisateurs protégés sont un groupe de sécurité global pour Active Directory (AD) conçu pour se protéger contre les attaques par vol d’informations d’identification. Le groupe déclenche une protection non configurable sur les appareils et les ordinateurs hôtes pour empêcher la mise en cache des informations d’identification lors de la connexion de membres du groupe.

Prérequis

Avant de pouvoir déployer un groupe Utilisateurs protégés, votre système doit satisfaire aux conditions préalables suivantes :

  • Les hôtes doivent exécuter l’un des systèmes d’exploitation suivants :

    • Windows 8.1 ou ultérieure
    • Windows Server 2012 R2 ou ultérieure avec les mises à jour de sécurité les plus récentes installées

  • Le niveau fonctionnel du domaine doit correspondre à Windows Server 2012 R2 ou ultérieure. Pour en savoir plus sur les niveaux fonctionnels, consultez Niveaux fonctionnels de domaine et de forêt.

Remarque

L’administrateur de domaine intégré, S-1-5-<domain>-500, est toujours exempté des stratégies d’authentification, même lorsqu’il est affecté à un silo de stratégies d’authentification. Pour plus d'informations, voir Comment configurer des comptes protégés.

  • Les appartenances aux groupes de sécurité globaux Utilisateurs protégés autorisent les membres à utiliser uniquement le chiffrement Kerberos AES (Advanced Encryption Standards). Les membres du groupe Utilisateurs protégés doivent être en mesure de s’authentifier à l’aide d’AES.

Protections appliquées par Active Directory

Lorsque vous devenez membre du groupe Utilisateurs protégés, AD applique automatiquement certains contrôles préconfigurés que vous ne pourrez pas modifier tant que vous serez membre de ce groupe.

Protections d’appareil pour les membres du groupe Utilisateurs protégés connectés

Lorsque l’utilisateur connecté est membre du groupe Utilisateurs protégés, celui-ci fournit les protections suivantes :

  • La délégation des informations d’identification (CredSSP) ne met pas en cache les informations d’identification en texte brut de l’utilisateur, même s’il active le paramètre de stratégie de groupe Autoriser la délégation d’informations d’identification par défaut.

  • Pour Windows 8.1 et ultérieures, et Windows Server 2012 R2 et ultérieures, Windows Digest ne met pas en cache les informations d’identification en texte brut de l’utilisateur, même lorsqu’il a activé Windows Digest.

  • NTLM arrête la mise en cache des informations d’identification en texte brut de l’utilisateur ou de la fonction unidirectionnelle NT (NTOWF).

  • Kerberos cesse de créer des clés DES (Data Encryption Standard) ou RC4. Kerberos ne met pas non plus en cache les informations d’identification en texte brut ou les clés à long terme de l’utilisateur après l’acquisition du ticket initial TGT (Ticket Granting Ticket).

  • Le système ne crée pas de vérificateur mis en cache lors de la connexion ou du déverrouillage de l’utilisateur. Ainsi, les systèmes membres ne prennent plus en charge la connexion hors connexion.

Une fois que vous avez ajouté un nouveau compte d’utilisateur au groupe Utilisateurs protégés, ces protections s’activent lorsque le nouvel utilisateur protégé se connecte à son appareil.

Protections de contrôleur de domaine pour le groupe Utilisateurs protégés

Les comptes d’Utilisateurs protégés qui s’authentifient auprès d’un domaine exécutant Windows Server 2012 R2 ou ultérieure ne peuvent pas effectuer les opérations suivantes :

  • s'authentifier avec l'authentification NTLM ;

  • utiliser les types de chiffrement DES ou RC4 dans la pré-authentification Kerberos ;

  • déléguer en utilisant la délégation non contrainte ou contrainte ;

  • renouveler des tickets TGT Kerberos au-delà de la durée de vie initiale de 4 heures ;

Des paramètres non configurables pour l’expiration des tickets TGT sont établis pour chaque compte dans le groupe Utilisateurs protégés. En général, le contrôleur de domaine définit la durée de vie et le renouvellement TGT en fonction des deux stratégies de domaine suivantes :

  • Durée de vie maximale pour le ticket utilisateur
  • Durée de vie maximale pour le renouvellement du ticket utilisateur

Pour les membres du groupe Utilisateurs protégés, ce dernier définit automatiquement ces limites de durée de vie à 600 minutes. L’utilisateur ne peut pas modifier cette limite, sauf s’il quitte le groupe.

Fonctionnement du groupe Utilisateurs protégés

Vous pouvez ajouter des utilisateurs au groupe Utilisateurs protégés à l’aide des méthodes suivantes :

Important

  • N’ajoutez jamais de comptes de services et d’ordinateurs au groupe Utilisateurs protégés. L’appartenance à ces comptes n’offre pas de protection locale car le mot de passe ou le certificat est toujours disponible sur l’hôte.

  • N’ajoutez pas de comptes qui sont déjà membres de groupes dotés de privilèges élevés, notamment les groupes Administrateurs d’entreprise ou Admins du domaine, tant que vous ne pouvez pas garantir que l’ajout de ces comptes n’aura pas de conséquences négatives. Les utilisateurs disposant de privilèges élevés qui font partie des Utilisateurs protégés sont soumis aux mêmes limitations et restrictions que les utilisateurs standard, et ces paramètres ne peuvent être ni contournés ni modifiés. Si vous ajoutez tous les membres de ces groupes au groupe Utilisateurs protégés, leurs comptes risquent d’être verrouillés accidentellement. Il est essentiel de tester votre système pour vous assurer que les modifications apportées aux paramètres obligatoires n’entraveront pas l’accès aux comptes de ces groupes d’utilisateurs privilégiés.

Les membres du groupe Utilisateurs protégés peuvent uniquement s’authentifier à l’aide du chiffrement Kerberos AES (Advanced Encryption Standards). Cette méthode nécessite des clés AES pour le compte dans Active Directory. L’administrateur intégré ne dispose pas d’une clé AES, sauf si le mot de passe du domaine exécutant Windows Server 2008 ou une version ultérieure change. Tout compte dont le mot de passe est modifié par un contrôleur de domaine qui exécute une version antérieure de Windows Server est exclu de l’authentification.

Pour éviter les verrouillages et les clés AES manquantes, nous vous recommandons de suivre les instructions ci-dessous :

  • N’exécutez pas de tests dans les domaines, sauf si tous les contrôleurs de domaine exécutent Windows Server 2008 ou une version ultérieure.

  • Si vous avez migré des comptes à partir d’autres domaines, vous devez réinitialiser le mot de passe pour que les comptes possèdent des hachages AES. Dans le cas contraire, ces comptes peuvent s’authentifier.

  • Les utilisateurs doivent modifier les mots de passe après le passage au niveau fonctionnel de domaine de Windows Server 2008 ou ultérieure. Cela leur garantit des hachages de mots de passe AES lorsqu’ils deviennent membres du groupe Utilisateurs protégés.

Ajouter un groupe de sécurité global Utilisateurs protégés à des domaines de niveau inférieur

Les contrôleurs de domaine qui exécutent un système d’exploitation antérieur à Windows Server 2012 R2 peuvent prendre en charge l’ajout de membres au nouveau groupe de sécurité Utilisateurs protégés. Ces membres peuvent ainsi bénéficier des protections de l’appareil avant que vous ne mettiez le domaine à niveau.

Remarque

Les contrôleurs de domaine qui exécutent des versions antérieures de Windows Server 2012 R2 ne prennent pas en charge les protections de domaine.

Pour créer un groupe Utilisateurs protégés sur un contrôleur de domaine qui exécute une version antérieure de Windows Server :

  1. Transférez le rôle d’émulateur de contrôleur de domaine principal vers un contrôleur de domaine qui exécute Windows Server 2012 R2.

  2. Répliquez l’objet de groupe vers les autres contrôleurs de domaine.

Ensuite, les utilisateurs peuvent bénéficier des protections des appareils avant que vous ne mettiez le domaine à niveau.

Propriétés AD du groupe Utilisateurs protégés

Le tableau suivant spécifie les propriétés Active Directory du groupe Utilisateurs protégés.

Attribut Valeur
SID/RID connu S-1-5-21-<domaine>-525
Type Global du domaine
Conteneur par défaut CN=Users, DC=<domaine>, DC=
Membres par défaut None
Membre par défaut de None
Protégé par ADMINSDHOLDER ? Non
Sortie du conteneur par défaut sécurisée ? Oui
Délégation de la gestion de ce groupe à des administrateurs extérieurs au service sécurisée ? Non
Droits d’utilisateur par défaut Aucun droit d’utilisateur par défaut

Journaux d’événements

Deux journaux d'administration opérationnels sont disponibles pour résoudre les problèmes associés aux événements concernant les utilisateurs protégés. Ces nouveaux journaux se trouvent dans l’observateur d’événements et sont désactivés par défaut. Ils sont sous Journaux des applications et des services\Microsoft\Windows\Authentification.

Pour activer la capture de ces journaux d’activité :

  1. Cliquez avec le bouton droit de la souris sur Démarrer, puis sélectionnez Observateur d’événements.

  2. Ouvrez les Journaux des applications et des services\Microsoft\Windows\Authentication.

  3. Cliquez avec le bouton droit de la souris sur le nom de chaque journal que vous souhaitez activer, puis sélectionnez Activer le journal.

ID d'événement et journal Description
104

ProtectedUser-Client

 Cause : Le package de sécurité sur le client ne contient pas les informations d'identification.
L'erreur est consignée sur l'ordinateur client quand le compte est membre du groupe de sécurité Utilisateurs protégés. Cet événement indique que le package de sécurité ne met pas en cache les informations d'identification nécessaires pour une authentification auprès du serveur.

Affiche le nom du package, le nom d'utilisateur, le nom du domaine et le nom du serveur.
304

ProtectedUser-Client

 Motif : le package de sécurité ne stocke pas les informations d’identification des utilisateurs protégés.
Un événement d’information est journalisé dans le client pour indiquer que le package de sécurité ne met pas en cache les informations de connexion de l’utilisateur. Normalement, Digest (WDigest), la délégation des informations d'identification (CredSSP) et NTLM ne devraient pas pouvoir obtenir les informations d'identification de connexion pour les utilisateurs protégés. Les applications peuvent quand même réussir si elles demandent des informations d'identification.

Affiche le nom du package, le nom d'utilisateur et le nom du domaine.
100

ProtectedUserFailures-DomainController

 Cause : Un échec de connexion NTLM se produit pour un compte qui figure dans le groupe de sécurité Utilisateurs protégés.
Une erreur est consignée dans le contrôleur de domaine pour indiquer l'échec de l'authentification NTLM en raison de l'appartenance du compte au groupe de sécurité Utilisateurs protégés.

Affiche le nom du compte et le nom de l'appareil.
104

ProtectedUserFailures-DomainController

 Cause : Les types de chiffrement DES ou RC4 sont utilisés pour l'authentification Kerberos et un échec de connexion se produit pour un utilisateur dans le groupe de sécurité Utilisateurs protégés.
La pré-authentification Kerberos a échoué, car les types de chiffrement DES et RC4 ne peuvent pas être utilisés quand le compte est membre du groupe de sécurité Utilisateurs protégés.

(AES est acceptable.)
303

ProtectedUserSuccesses-DomainController

 Cause : Un ticket TGT Kerberos a été correctement émis pour un membre du groupe Utilisateurs protégés.

Ressources supplémentaires