Conseils sur la configuration des comptes protégés
Par le biais d'attaques PtH (Pass-the-Hash), une personne malveillante peut s'authentifier sur un service ou un serveur distant à l'aide du hachage NTLM sous-jacent du mot de passe d'un utilisateur (ou d'autres dérivés d'informations d'identification). Microsoft a précédemment publié des conseils pour prévenir les attaques PtH. Windows Server 2012 R2 inclut des nouvelles fonctionnalités pour aider à mieux prévenir ce type d'attaques. Pour plus d’informations sur d’autres fonctionnalités de sécurité permettant de se prémunir contre le vol d’informations d’identification, consultez Gestion et protection des informations d’identification. Cette rubrique décrit comment configurer les nouvelles fonctionnalités suivantes :
Windows 8.1 et Windows Server 2012 R2 présentent d'autres fonctionnalités de prévention contre le vol d'informations d'identification. Elles sont abordées dans les rubriques suivantes :
Utilisateurs protégés
Il s'agit d'un nouveau groupe de sécurité global auquel vous pouvez ajouter des nouveaux utilisateurs ou des utilisateurs existants. Les appareils Windows 8.1 et les hôtes Windows Server 2012 R2 se comportent différemment avec les membres de ce groupe pour fournir une meilleure protection contre le vol d'informations d'identification. Pour un membre du groupe, un appareil Windows 8.1 ou un hôte Windows Server 2012 R2 ne met pas en cache les informations d'identification qui ne sont pas prises en charge pour les utilisateurs protégés. Les membres de ce groupe ne sont pas mieux protégés s’ils sont connectés à un appareil exécutant une version de Windows antérieure à Windows 8.1.
Les membres du groupe Utilisateurs protégés qui se sont authentifiés sur des appareils Windows 8.1 et des hôtes Windows Server 2012 R2 ne peuvent plus utiliser :
la délégation d'informations d'identification par défaut (CredSSP) : les informations d'identification en texte brut ne sont pas mises en cache même si la stratégie Autoriser la délégation d'informations d'identification par défaut est activée ;
Windows Digest : les informations d'identification en texte brut ne sont pas mises en cache même si elles sont activées ;
NTLM : NTOWF n'est pas mis en cache ;
les clés à long terme Kerberos : le ticket TGT (Ticket-Granting Ticket) Kerberos s'obtient à l'ouverture de session et ne peut pas être à nouveau obtenu automatiquement ;
l'authentification hors ligne : le vérificateur d'ouverture de session en cache n'est pas créé.
Si le niveau fonctionnel du domaine est Windows Server 2012 R2, les membres du groupe ne peuvent plus :
effectuer d'authentifications NTLM ;
utiliser les suites de chiffrement DES (Data Encryption Standard) ou RC4 dans la pré-authentification Kerberos ;
être délégués en utilisant la délégation non contrainte ou contrainte ;
renouveler les tickets TGT utilisateur au-delà de la durée de vie initiale de 4 heures.
Pour ajouter des utilisateurs au groupe, vous pouvez utiliser des outils d’interface utilisateur tels que le Centre d’administration Active Directory (ADAC, Active Directory Administrative Center) ou Utilisateurs et ordinateurs Active Directory, ou encore un outil en ligne de commande tel que le groupe Dsmod, ou enfin l’applet de commande Windows PowerShellAdd-ADGroupMember. Les comptes de services et d'ordinateurs ne doivent pas être membres du 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.
Avertissement
Les restrictions d'authentification n'offrent pas de solutions de contournement, ce qui veut dire que les membres des groupes dotés de privilèges élevés tels que les groupes Administrateurs d'entreprise ou Admins du domaine sont soumis aux mêmes restrictions que les autres membres du groupe Utilisateurs protégés. Si tous les membres de tels groupes sont ajoutés au groupe Utilisateurs protégés, il est possible que tous ces comptes soient verrouillés. Vous ne devez jamais ajouter tous les comptes à privilèges élevés au groupe Utilisateurs protégés tant que vous n’avez pas testé minutieusement l’impact potentiel.
Les membres du groupe Utilisateurs protégés doivent être capables d'effectuer une authentification à 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 comporte pas de clé AES sauf si le mot de passe a été modifié sur un contrôleur de domaine qui exécute Windows Server 2008 ou version ultérieure. De plus, un compte dont le mot de passe a été modifié sur un contrôleur de domaine exécutant une version antérieure de Windows Server est verrouillé. Nous vous recommandons, par conséquent de suivre ces meilleures pratiques :
Ne pas effectuer de test sur des domaines sauf si tous les contrôleurs de domaine exécutent Windows Server 2008 ou version ultérieure.
changer le mot de passe pour tous les comptes de domaine qui ont été créés avant que le domaine ne l'ait été lui-même car cela empêche leur authentification ;
Modifier le mot de passe de chaque utilisateur avant d’ajouter le compte au groupe Utilisateurs protégés ou vérifier que le mot de passe a été récemment changé sur un contrôleur de domaine qui exécute Windows Server 2008 ou version ultérieure.
Conditions requises pour utiliser des comptes protégés
Ces derniers doivent respecter les conditions de déploiements requises suivantes :
Pour fournir des restrictions côté client pour les utilisateurs protégés, les hôtes doivent exécuter Windows 8.1 ou Windows Server 2012 R2. Un utilisateur doit uniquement s'authentifier avec un compte qui est membre d'un groupe Utilisateurs protégés. Dans ce cas, le groupe Utilisateurs protégés peut être créé en transférant le rôle d'émulateur de contrôleur de domaine principal à un contrôleur de domaine qui exécute Windows Server 2012 R2. Une fois l'objet de groupe répliqué sur d'autres contrôleurs de domaine, le rôle de l'émulateur PDC peut être hébergé sur un contrôleur de domaine qui exécute une version antérieure de Windows Server.
Pour fournir des restrictions côté contrôleur de domaine pour les utilisateurs protégés, c'est-à-dire pour limiter l'utilisation de l'authentification NTLM entre autres restrictions, le niveau fonctionnel du domaine doit être Windows Server 2012 R2. Pour plus d’informations sur les niveaux fonctionnels, consultez Présentation des niveaux fonctionnels des services de domaine Active Directory (AD DS).
Remarque
L’administrateur de domaine intégré (S-1-5-<domain>-500) est toujours exempté de stratégies d’authentification, même lorsqu’elles sont affectées à un silo de stratégie d’authentification.
Résoudre des problèmes liés aux événements concernant les utilisateurs protégés
Cette section aborde de nouveaux journaux qui permettent de résoudre des problèmes liés à des événements concernant les utilisateurs protégés. Elle décrit également comment les utilisateurs protégés peuvent répercuter les modifications pour résoudre les problèmes d'expiration de tickets TGT ou de délégation.
Nouveaux journaux pour les utilisateurs protégés
Deux nouveaux journaux d'administration opérationnels sont disponibles pour résoudre les problèmes associés aux événements concernant les utilisateurs protégés : utilisateur protégé - Journal client et échecs liés à l'utilisateur protégé - Journal du contrôleur de domaine. Ces nouveaux journaux se trouvent dans l'Observateur d'événements et sont désactivés par défaut. Pour activer un journal, cliquez sur Journaux des applications et des services, Microsoft, Windows, Authentification, puis cliquez sur le nom du journal et sur Action (ou cliquez avec le bouton droit sur le journal), puis sur Activer le journal.
Pour plus d’informations sur les événements consignés dans ces journaux, consultez Stratégies d’authentification et silos de stratégies d’authentification.
Résoudre les problèmes d'expiration TGT
Généralement, le contrôleur de domaine définit la durée de vie et le renouvellement TGT en fonction de la stratégie de domaine, comme illustré dans la fenêtre Éditeur de gestion des stratégies de groupe.
Dans le cas des utilisateurs protégés, les paramètres suivants sont codés en dur :
durée de vie maximale pour le ticket utilisateur : 240 minutes.
durée de vie maximale pour le renouvellement du ticket utilisateur : 240 minutes.
Résoudre les problèmes de délégation
Auparavant, en cas d'échec d'une technologie utilisant la délégation Kerberos, le compte client était vérifié pour voir si l'option Le compte est sensible et ne peut pas être délégué était définie. Cependant, si le compte est membre du groupe Utilisateurs protégés, ce paramètre n'est peut-être pas configuré dans le Centre d'administration Active Directory (ADAC). Ainsi, vérifiez le paramètre et l'appartenance au groupe quand vous résolvez les problèmes de délégation.
Vérifier les tentatives d'authentification
Pour vérifier les tentatives d'authentification spécifiquement pour les membres du groupe Utilisateurs protégés, vous pouvez continuer à collecter les événements de vérification du journal de sécurité ou rassembler les données dans les journaux d'administration opérationnels. Pour plus d’informations sur ces événements, consultez Stratégies d’authentification et silos de stratégies d’authentification.
Fournir les protections côté contrôleur de domaine pour les services et les ordinateurs
Les comptes de services et d'ordinateurs ne doivent pas être membres du groupe Utilisateurs protégés. Cette section décrit les protections basées sur le contrôleur de domaine qui peuvent être offertes pour ces comptes :
rejet de l'authentification NTLM : configurable uniquement via les stratégies du bloc NTLM;
Rejet de la norme DES (Data Encryption Standard) dans la pré-authentification Kerberos : les contrôleurs de domaine Windows Server 2012 R2 n’acceptent pas la norme DES pour les comptes d’ordinateur sauf s’ils sont configurés pour DES uniquement, car chaque version de Windows publiée avec Kerberos prend également en charge RC4.
rejet de RC4 dans la pré-authentification Kerberos : non configurable ;
Remarque
Même si vous pouvez modifier la configuration des types de chiffrement pris en charge, il n’est pas recommandé de changer ces paramètres pour les comptes d’ordinateur sans les tester dans l’environnement cible.
restreindre les tickets utilisateur (TGT) à une durée de vie initiale de 4 heures : utiliser les stratégies d'authentification ;
refuser la délégation avec délégation non contrainte ou contrainte : pour restreindre un compte, ouvrez le Centre d'administration Active Directory (ADAC), puis cochez la case Le compte est sensible et ne peut pas être délégué .
Stratégies d’authentification
Il s'agit d'un nouveau conteneur des services de domaine Active Directory (AD DS) comprenant les objets de la stratégie d'authentification. Les stratégies d'authentification peuvent spécifier les paramètres qui permettent de prévenir l'exposition au vol d'informations d'identification, tels que la restriction de la durée de vie TGT des comptes ou l'ajout d'autres conditions associées aux revendications.
Dans Windows Server 2012, le contrôle d'accès dynamique a introduit une classe d'objet étendue à la forêt Active Directory appelée « stratégie d'accès centralisée » qui permet de configurer facilement les serveurs de fichiers dans une organisation. Dans Windows Server 2012 R2, vous pouvez utiliser la nouvelle classe d'objet « Stratégie d'authentification » (objectClass msDS-AuthNPolicies) pour appliquer la configuration d'authentification aux classes de compte des domaines Windows Server 2012 R2. Les classes de compte Active Directory sont les suivantes :
Utilisateur
Computer
Compte de service administré et compte de service administré de groupe (GMSA, Group Managed Service Account)
Actualisateur Kerberos rapide
Le protocole d'authentification Kerberos consiste en trois types d'échanges, également connus en tant que sous-protocoles :
l'échange du service d'authentification (AS, Authentication Service) (KRB_AS_*),
l'échange du service d'accord de tickets (TGS, Ticket-Granting Service) (KRB_TGS_*),
l'échange client/serveur AP (Application Protocol) (KRB_AP_*).
Pendant l'échange AS, le client utilise le mot de passe du compte ou de la clé privée pour créer un pré-authentificateur afin de demander un ticket TGT. Cela intervient au cours de l'authentification de l'utilisateur ou à la première demande de ticket de service.
Pendant l'échange TGS, le ticket TGT du compte sert à créer un authentificateur pour demander un ticket de service. Cela se produit quand une connexion authentifiée est nécessaire.
L'échange AP a généralement lieu quand des données se trouvent à l'intérieur du protocole d'application et n'est pas affecté par des stratégies d'authentification.
Pour plus d’informations, consultez Fonctionnement du protocole d’authentification Kerberos version 5.
Vue d’ensemble
Les stratégies d'authentification complètent le groupe Utilisateurs protégés en fournissant un moyen d'appliquer des restrictions configurables aux comptes et en imposant des restrictions aux comptes de services et d'ordinateurs. Elles entrent en vigueur pendant l'échange AS ou l'échange TGS.
Vous pouvez restreindre l'authentification initiale ou l'échange AS en configurant :
une durée de vie TGT ;
des conditions de contrôle d'accès pour restreindre l'authentification de l'utilisateur (les appareils d'où provient l'échange AS doivent respecter ces conditions).
Vous pouvez restreindre les demandes de ticket de service via un échange de service d'accord de tickets (TGS) en configurant :
- les conditions de contrôle d'accès que le client (utilisateur, service, ordinateur) ou l'appareil d'où émane l'échange TGS doit respecter.
Conditions requises pour utiliser des stratégies d'authentification
| Stratégie | Configuration requise |
|---|---|
| Fournir des durées de vie TGT personnalisées | Domaines de compte de niveau fonctionnel du domaine Windows Server 2012 R2 |
| Restreindre l'authentification utilisateur | - Domaines de comptes de niveau fonctionnel du domaine Windows Server 2012 R2 avec prise en charge du contrôle d'accès dynamique - Appareils Windows 8, Windows 8.1, Windows Server 2012 ou Windows Server 2012 R2 avec prise en charge du contrôle d’accès dynamique |
| Restreindre l'émission de tickets de service qui est basée sur le compte d'utilisateur et les groupes de sécurité | Domaines de ressources de niveau fonctionnel du domaine Windows Server 2012 R2 |
| Restreindre l'émission de tickets de service en fonction des revendications d'utilisateur ou du compte d'appareil, des groupes de sécurité ou des revendications | Domaines de ressources de niveau fonctionnel du domaine Windows Server 2012 R2 avec prise en charge du contrôle d'accès dynamique |
Restreindre un compte d'utilisateur aux appareils et hôtes spécifiques
Un compte à valeur élevée assorti d'un privilège d'administration doit être membre du groupe Utilisateurs protégés. Par défaut, aucun compte n'est membre du groupe Utilisateurs protégés. Avant d'ajouter des comptes au groupe, configurez la prise en charge du contrôleur de domaine et créez une stratégie d'audit pour vérifier qu'il n'y a aucun problème majeur.
Configurer la prise en charge du contrôleur de domaine
Le compte de domaine de l'utilisateur doit se situer au niveau fonctionnel du domaine Windows Server 2012 R2. Vérifiez que tous les contrôleurs de domaine sont Windows Server 2012 R2, puis utilisez les approbations et les domaines Active Directory pour augmenter le niveau fonctionnel du domaine vers Windows Server 2012 R2.
Pour configurer la prise en charge du contrôle d'accès dynamique
Dans la stratégie des contrôleurs de domaine par défaut, cliquez sur Activé pour activer Prise en charge par le client du centre de distribution de clés des revendications, de l'authentification composée et du blindage Kerberos dans Configuration ordinateur | Modèles d'administration | Système | KDC.
Sous Options, dans la zone de liste déroulante, sélectionnez Toujours fournir des revendications.
Remarque
Vous pouvez également configurer Pris en charge, mais dans la mesure où le domaine est au niveau fonctionnel du domaine Windows Server 2012 R2, le fait que les contrôleurs de domaine fournissent toujours des revendications permet des vérifications d'accès basées sur les revendications, quand des hôtes et des appareils ne prenant pas en charge les revendications sont utilisés pour connecter les services prenant en charge les revendications.
Avertissement
La configuration de Rejeter les demandes d’authentification non blindées entraîne des échecs d’authentification de tout système d’exploitation qui ne prend pas en charge le blindage Kerberos, tel que Windows 7 et les systèmes d’exploitation antérieurs ou ceux à partir de Windows 8, qui n’ont pas été explicitement configurés pour le prendre en charge.
Créer un audit de compte d'utilisateur pour la stratégie d'authentification avec ADAC
Ouvrez le Centre d'administration Active Directory (ADAC).
Notes
Le nœud Authentification sélectionné est visible pour des domaines qui sont au niveau fonctionnel du domaine Windows Server 2012 R2. Si le nœud n'apparaît pas, réessayez en utilisant un compte d'administrateur de domaine à partir d'un domaine qui se situe au niveau fonctionnel du domaine Windows Server 2012 R2.
Cliquez sur Stratégies d'authentification, puis sur Nouveau pour créer une stratégie.
Les stratégies d'authentification doivent avoir un nom d'affichage. Elles sont appliquées par défaut.
Pour créer une stratégie en mode Auditer uniquement, cliquez sur Auditer uniquement les restrictions de stratégie.
Les stratégies d'authentification sont appliquées en fonction du type de compte Active Directory. Une stratégie unique peut s'appliquer au trois types de compte en configurant les paramètres pour chaque type. Les types de compte sont les suivants :
Utilisateur
Computer
Compte de service administré et compte de service administré de groupe
Si vous avez étendu le schéma avec de nouveaux principaux qui peuvent être utilisés par le centre de distribution de clés (KDC, Key Distribution Center), le nouveau type de compte est classé à partir du type de compte dérivé le plus proche.
Pour configurer la durée de vie TGT des comptes d'utilisateur, cochez la case Spécifiez la durée de vie du ticket TGT (Ticket Granting Ticket) pour les comptes d'utilisateur et entrez la durée en minutes.
Par exemple, si vous voulez une durée de vie TGT maximale de 10 heures, entrez 600 comme illustré. Si aucune durée de vie TGT n'est configurée et si le compte est membre du groupe Protected Users, la durée de vie et le renouvellement TGT sont de 4 heures. Sinon, la durée de vie et le renouvellement TGT dépendent de la stratégie de domaine comme le montre la fenêtre Éditeur de gestion des stratégies de groupe suivante, pour un domaine comportant des paramètres par défaut.
Pour restreindre la sélection d'appareils du compte d'utilisateur, cliquez sur Modifier afin de définir les conditions qui sont nécessaires pour l'appareil.
Dans la fenêtre Modifier les conditions de contrôle d'accès, cliquez sur Ajouter une condition.
Ajouter le compte d'ordinateur ou les conditions du groupe
Pour configurer les comptes d'ordinateur ou les groupes, dans la liste déroulante, sélectionnez la zone de liste déroulante Membre de chaque, puis modifiez Membre de n'importe lequel.
Remarque
Ce contrôle d'accès définit les conditions de l'appareil ou de l'hôte à partir duquel l'utilisateur s'authentifie. Dans la terminologie du contrôle d'accès, le compte d'ordinateur de l'appareil ou de l'hôte est l'utilisateur, ce qui explique qu'Utilisateur soit la seule option.
Cliquez sur Ajouter des éléments.
Pour modifier les types d'objets, cliquez sur Types d'objets.
Pour sélectionner les objets d'ordinateur dans Active Directory, cliquez sur Ordinateurs, puis sur OK.
Tapez le nom des ordinateurs pour restreindre l'utilisateur, puis cliquez sur Vérifier les noms.
Cliquez sur OK et créez une autre condition pour le compte d'ordinateur.
Une fois terminé, cliquez sur OK et les conditions définies apparaîtront pour le compte d'ordinateur.
Ajouter des conditions de revendication d'ordinateur
Pour configurer des revendications d'ordinateur, déroulez le groupe pour sélectionner la revendication.
Les revendications sont uniquement disponibles si elles sont déjà déployées dans la forêt.
Tapez le nom de l'unité d'organisation, auprès de laquelle le compte d'utilisateur peut uniquement s'authentifier.
Une fois terminé, cliquez sur OK et la zone affichera les conditions définies.
Résoudre les problèmes liés aux revendications d'ordinateur
Si la revendication a été déployée, mais qu'elle n'est pas disponible, elle est peut être uniquement configurée pour les classes Ordinateur.
Imaginons que vous vouliez restreindre l'authentification en fonction de l'unité d'organisation (OU, Organizational Unit) de l'ordinateur, qui a déjà été configurée, mais seulement pour les classes Ordinateur .
Pour que la revendication soit disponible et que vous puissiez restreindre l'authentification de l'utilisateur sur l'appareil, cochez la case Utilisateur.
Déployer un compte d'utilisateur avec une stratégie d'authentification à l'aide d'ADAC
À partir du compte Utilisateur, cliquez sur Stratégie.
Cochez la case Affectez une stratégie d'authentification à ce compte.
Sélectionnez ensuite la stratégie d'authentification à appliquer à l'utilisateur.
Configurer la prise en charge du contrôle d'accès dynamique sur les appareils et les hôtes
Vous pouvez configurer les durées de vie TGT sans configurer le contrôle d'accès dynamique. Le contrôle d'accès dynamique est uniquement nécessaire pour la vérification AllowedToAuthenticateFrom et AllowedToAuthenticateTo.
À l'aide de la stratégie de groupe ou de l'Éditeur de stratégie de groupe locale, activez Prise en charge par le client Kerberos des revendications, de l'authentification composée et du blindage Kerberos Configuration ordinateur | Modèles d'administration | Système | Kerberos :
Résoudre les problèmes des stratégies d'authentification
Déterminer les comptes auxquels est directement affectée une stratégie d'authentification
La section des comptes de la stratégie d'authentification illustre les comptes qui ont directement appliqué la stratégie.
Utiliser les échecs de stratégie d'authentification - journal d'administration du contrôleur de domaine
Un nouveau journal d'administration Échecs de stratégie d'authentification - contrôleur de domaine sous Journaux des applications et des services>Microsoft>Windows>Authentification a été créé pour faciliter la détection d’échecs liés aux stratégies d’authentification. Le journal est désactivé par défaut. Pour l'activer, cliquez avec le bouton droit sur le nom du journal, puis cliquez sur Activer le journal. Le contenu des nouveaux événements est très semblable à celui des événements d'audit du ticket de service et de ticket TGT Kerberos. Pour plus d’informations sur ces événements, consultez Stratégies d’authentification et silos de stratégies d’authentification.
Gérer les stratégies d'authentification à l'aide de Windows PowerShell
Cette commande crée une stratégie d'authentification nommée « TestAuthenticationPolicy ». Le paramètre UserAllowedToAuthenticateFrom spécifie les appareils à partir desquels les utilisateurs peuvent s'authentifier par une chaîne SDDL dans le fichier « someFile.txt ».
PS C:\> New-ADAuthenticationPolicy testAuthenticationPolicy -UserAllowedToAuthenticateFrom (Get-Acl .\someFile.txt).sddl
Cette commande obtient toutes les stratégies d'authentification qui correspondent au filtre spécifié par le paramètre Filter.
PS C:\> Get-ADAuthenticationPolicy -Filter "Name -like 'testADAuthenticationPolicy*'" -Server Server02.Contoso.com
Cette commande modifie la description et les propriétés UserTGTLifetimeMins de la stratégie d'authentification spécifiée.
PS C:\> Set-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1 -Description "Description" -UserTGTLifetimeMins 45
Cette commande supprime la stratégie d'authentification spécifiée par le paramètre Identity.
PS C:\> Remove-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1
Cette commande utilise l'applet de commande Get-ADAuthenticationPolicy avec le paramètre Filter pour obtenir toutes les stratégies d'authentification qui ne sont pas appliquées. Le jeu de résultats est dirigé vers l'applet de commande Remove-ADAuthenticationPolicy.
PS C:\> Get-ADAuthenticationPolicy -Filter 'Enforce -eq $false' | Remove-ADAuthenticationPolicy
Silos de stratégies d'authentification
Il s'agit d'un nouveau conteneur (objectClass msDS-AuthNPolicySilos) des services de domaine Active Directory (AD DS) pour les comptes d'utilisateur, d'ordinateur et de service. Ces silos permettent de protéger des comptes à valeur élevée. Toutes les organisations doivent protéger les membres des groupes Administrateurs d'entreprise, Admins de domaine et Administrateurs de schéma car ces comptes peuvent être utilisés par une personne malveillante pour accéder n'importe où dans la forêt, mais d'autres comptes ont également besoin d'une protection.
Certaines organisations isolent les charges de travail en créant des comptes qui leur sont uniques et en appliquant des paramètres de stratégie de groupe pour limiter l'ouverture de session interactive locale et distante et les privilèges d'administration. Les silos de stratégies d'authentification complètent ce travail en créant un moyen de définir une relation entre les comptes d'utilisateur, d'ordinateur et de service administrés. Ces comptes n'appartiennent qu'à un seul silo. Vous pouvez configurer la stratégie d'authentification pour chaque type de compte pour contrôler :
la durée de vie TGT non renouvelable ;
les conditions de contrôle d'accès pour renvoyer le ticket TGT (Remarque : ne peut s'appliquer aux systèmes car le blindage Kerberos est nécessaire) ;
les conditions de contrôle d'accès pour retourner le ticket de service.
De plus, les comptes figurant dans un silo de stratégies d'authentification comportent une revendication de silo, qui peut être utilisée par les ressources prenant en charge les revendications telles que les serveurs de fichiers pour contrôler l'accès.
Un nouveau descripteur de sécurité peut être configuré pour contrôler l'émission du ticket de service en fonction de :
l'utilisateur, les groupes de sécurité de l'utilisateur et/ou les revendications de l'utilisateur ;
l'appareil, le groupe de sécurité de l'appareil et/ou les revendications de périphérique.
L'acheminement de ces informations au contrôleur de domaine de la ressource nécessite le contrôle d'accès dynamique :
Revendications d'utilisateur :
Clients Windows 8 et version ultérieure prenant en charge le contrôle d'accès dynamique
Le domaine de compte prend en charge le contrôle d'accès dynamique et les revendications
Appareil et/ou groupe de sécurité de l'appareil :
Clients Windows 8 et version ultérieure prenant en charge le contrôle d'accès dynamique
Ressource configurée pour l'authentification composée
Revendications de périphérique :
Clients Windows 8 et version ultérieure prenant en charge le contrôle d'accès dynamique
Le domaine d'appareil prend en charge le contrôle d'accès dynamique et les revendications
Ressource configurée pour l'authentification composée
Les stratégies d'authentification peuvent être appliquées à tous les membres d'un silo plutôt qu'à des comptes individuels, ou des stratégies d'authentification distinctes peuvent être appliquées à différents types de comptes à l'intérieur d'un silo. Par exemple, une stratégie d'authentification peut être appliquée à des comptes d'utilisateur dotés de privilèges élevés tandis qu'une autre stratégie peut être appliquée à des comptes de service. Au moins une stratégie d'authentification doit être créée avant qu'un silo de stratégies d'authentification ne puisse l'être.
Remarque
Une stratégie d'authentification peut être appliquée aux membres d'un silo de stratégies d'authentification. Elle peut être aussi appliquée indépendamment des silos pour restreindre l'étendue du compte spécifique. Par exemple, pour protéger un compte unique ou un petit ensemble de comptes, vous pouvez définir une stratégie sur ces comptes sans ajouter les comptes à un silo.
Vous pouvez créer un silo de stratégies d’authentification en utilisant le Centre d’administration Active Directory ou Windows PowerShell. Par défaut, un silo de stratégies d'authentification vérifie uniquement les stratégies de silos, ce qui revient à spécifier le paramètre WhatIf dans les applets de commande Windows PowerShell. Dans ce cas, les restrictions du silo de stratégies ne s'appliquent pas, mais les audits sont générés pour indiquer si des échecs se produisent quand les restrictions sont appliquées.
Pour créer un silo de stratégies d'authentification en utilisant le Centre d'administration Active Directory
Ouvrez Centre d'administration Active Directory, cliquez sur Authentification, cliquez avec le bouton droit sur Silos de stratégies d'authentification, cliquez sur Nouveau, puis sur Silo de stratégies d'authentification.
Dans Nom d'affichage, tapez le nom du silo. Dans Comptes autorisés, cliquez sur Ajouter, tapez le nom des comptes, puis cliquez sur OK. Vous pouvez spécifier les utilisateurs, les ordinateurs ou les comptes de service. Indiquez ensuite si vous allez utiliser une stratégie unique pour tous les principaux ou une stratégie distincte pour chaque type de principal, et le nom de la ou des stratégies.
Gérer les silos de stratégies d'authentification à l'aide de Windows PowerShell
Cette commande crée un objet de silo de stratégies d'authentification et l'applique.
PS C:\>New-ADAuthenticationPolicySilo -Name newSilo -Enforce
Cette commande obtient tous les silos de stratégies d'authentification qui correspondent au filtre spécifié par le paramètre Filter. La sortie est alors transmise à l'applet de commande Format-Table pour afficher le nom de la stratégie et la valeur pour appliquer (Enforce) à chaque stratégie.
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Name -like "*silo*"' | Format-Table Name, Enforce -AutoSize
Name Enforce
---- -------
silo True
silos False
Cette commande utilise l'applet de commande Get-ADAuthenticationPolicySilo avec le paramètre Filter pour obtenir tous les silos de stratégies d'authentification qui ne sont pas appliqués et diriger le résultat du filtre vers l'applet de commande Remove-ADAuthenticationPolicySilo.
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Enforce -eq $False' | Remove-ADAuthenticationPolicySilo
Cette commande octroie l'accès au silo de stratégies d'authentification nommé Silo au compte d'utilisateur User01.
PS C:\>Grant-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01
Cette commande révoque l'accès au silo de stratégies d'authentification nommé Silo pour le compte d'utilisateur User01. Le paramètre Confirm ayant la valeur $False, aucun message de confirmation n'apparaît.
PS C:\>Revoke-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01 -Confirm:$False
Cet exemple utilise d'abord l'applet de commande Get-ADComputer pour obtenir tous les comptes d'utilisateur correspondant au filtre spécifié par le paramètre Filter. La sortie de cette commande est transmise à Set-ADAccountAuthenticatinPolicySilo pour leur affecter le silo de stratégies d'authentification Silo et la stratégie d'authentification AuthenticationPolicy02.
PS C:\>Get-ADComputer -Filter 'Name -like "newComputer*"' | Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo Silo -AuthenticationPolicy AuthenticationPolicy02