Comptes Active Directory
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016
Les systèmes d’exploitation Windows Server sont installés avec des comptes locaux par défaut. Par ailleurs, vous pouvez créer des comptes d’utilisateur pour répondre aux exigences de votre organisation.
Cet article de référence décrit les comptes locaux Windows Server par défaut qui sont stockés localement sur le contrôleur de domaine et utilisés dans Active Directory. Il ne décrit pas les comptes d’utilisateur locaux par défaut pour un membre, un serveur autonome ou un client Windows. Pour plus d’informations, consultez Comptes locaux.
Comptes locaux par défaut dans Active Directory
Les comptes locaux par défaut sont des comptes intégrés qui sont créés automatiquement lorsqu’un contrôleur de domaine Windows Server est installé et que le domaine est créé. Ces comptes locaux par défaut possèdent des équivalents dans Active Directory. Ils disposent également d’un accès à l’échelle du domaine et sont complètement distincts des comptes d’utilisateur locaux par défaut pour un membre ou un serveur autonome.
Vous pouvez attribuer des droits et des autorisations à des comptes locaux par défaut sur un contrôleur de domaine particulier, et uniquement sur ce contrôleur de domaine. Ces comptes sont locaux par rapport à ce domaine. Une fois les comptes locaux par défaut installés, ils sont stockés dans le conteneur Utilisateurs dans Utilisateurs et ordinateurs Active Directory. Il est recommandé de conserver les comptes locaux par défaut dans le conteneur Utilisateurs et de ne pas tenter de déplacer ces comptes, par exemple vers une autre unité d’organisation.
Les comptes locaux par défaut dans le conteneur Utilisateurs sont les suivants : Administrateur, Invité et KRBTGT. Le compte Assistant de l’aide est installé lorsqu’une session d’assistance à distance est établie. Les sections suivantes décrivent les comptes locaux par défaut et leur utilisation dans Active Directory.
Les comptes locaux par défaut effectuent les actions suivantes :
Permettre au domaine de représenter, d’identifier et d’authentifier l’identité de l’utilisateur affecté au compte à l’aide d’informations d’identification uniques (nom d’utilisateur et mot de passe). Il est recommandé d’affecter chaque utilisateur à un compte unique pour garantir une sécurité maximale. Plusieurs utilisateurs ne sont pas autorisés à partager un compte. Un compte d’utilisateur permet à un utilisateur de se connecter à des ordinateurs, des réseaux et des domaines avec un identificateur unique qui peut être authentifié par l’ordinateur, le réseau ou le domaine.
Autoriser (accorder ou refuser) l’accès aux ressources. Une fois les informations d’identification d’un utilisateur authentifiées, l’utilisateur est autorisé à accéder au réseau et aux ressources de domaine en fonction des droits explicitement attribués à l’utilisateur sur la ressource.
Auditer les actions effectuées sur un compte d’utilisateur.
Dans Active Directory, les administrateurs utilisent des comptes locaux par défaut pour gérer les serveurs de domaine et de membres, aussi bien directement qu’à partir de stations de travail d’administration dédiées. Les comptes Active Directory fournissent l’accès aux ressources réseau. Les comptes d’utilisateur et d’ordinateur Active Directory peuvent représenter une entité physique, telle qu’un ordinateur ou une personne, ou agir en tant que comptes de service dédiés pour certaines applications.
Chaque compte local par défaut est automatiquement affecté à un groupe de sécurité préconfiguré avec les droits et autorisations appropriés pour effectuer des tâches spécifiques. Les groupes de sécurité Active Directory permettent de rassembler des comptes d’utilisateur, des comptes d’ordinateur et d’autres groupes dans des unités gérables. Pour plus d’informations, consultez Groupes de sécurité Active Directory.
Sur un contrôleur de domaine Active Directory, chaque compte local par défaut est appelé Principal de sécurité. Un principal de sécurité est un objet annuaire utilisé pour sécuriser et gérer les services Active Directory qui fournissent l’accès aux ressources du contrôleur de domaine. Un principal de sécurité inclut des objets tels que des comptes d’utilisateur, des comptes d’ordinateur, des groupes de sécurité ou les threads ou processus qui s’exécutent dans le contexte de sécurité d’un compte d’utilisateur ou d’un compte d’ordinateur. Pour plus d’informations, consultez Principaux de sécurité.
Un principal de sécurité est représenté par un identificateur de sécurité unique (SID). Les SID liés à chacun des comptes locaux par défaut dans Active Directory sont décrits dans les sections suivantes.
Certains des comptes locaux par défaut sont protégés par un processus en arrière-plan qui vérifie et applique régulièrement un descripteur de sécurité spécifique. Un descripteur de sécurité est une structure de données qui contient les informations de sécurité associées à un objet protégé. Ce processus garantit que toute modification non autorisée du descripteur de sécurité sur l’un des comptes ou groupes locaux par défaut est remplacée par les paramètres protégés.
Le descripteur de sécurité est présent sur l’objet AdminSDHolder. Si vous souhaitez modifier les autorisations sur l’un des groupes d’administrateurs de service ou sur l’un de ses comptes membres, vous devez modifier le descripteur de sécurité sur l’objet AdminSDHolder afin de vous assurer qu’il est appliqué de manière systématique. Soyez prudent lorsque vous apportez ces modifications, car vous modifiez également les paramètres par défaut appliqués à tous vos comptes protégés.
Compte d’administrateur
Un compte Administrateur est un compte par défaut utilisé dans toutes les versions du système d’exploitation Windows sur chaque ordinateur et appareil. Le compte Administrateur est utilisé par l’administrateur système pour les tâches qui nécessitent des informations d’identification administratives. Ce compte ne peut pas être supprimé ni verrouillé, mais il peut être renommé ou désactivé.
Le compte Administrateur donne à l’utilisateur un accès complet (autorisations de contrôle total) aux fichiers, répertoires, services et autres ressources qui se trouvent sur ce serveur local. Le compte Administrateur peut être utilisé pour créer des utilisateurs locaux et pour attribuer des droits d’utilisateur et des autorisations de contrôle d’accès. Le compte peut également être utilisé pour prendre le contrôle des ressources locales à tout moment en modifiant simplement les droits et autorisations de l’utilisateur. Bien que des fichiers et des répertoires puissent être protégés temporairement du compte administrateur, le compte peut prendre le contrôle de ces ressources à tout moment en modifiant les autorisations d’accès.
Appartenance à un groupe de comptes
Le compte Administrateur est membre des groupes de sécurité par défaut, comme décrit dans le tableau Attributs du compte administrateur plus loin dans cet article.
Les groupes de sécurité garantissent que vous pouvez contrôler les droits d’administrateur sans avoir à modifier chaque compte Administrateur. Dans la plupart des cas, vous n’avez pas besoin de modifier les paramètres de base de ce compte. Toutefois, vous devrez peut-être modifier ses paramètres avancés, tels que l’appartenance à des groupes particuliers.
Considérations relatives à la sécurité
Après l’installation du système d’exploitation du serveur, votre première tâche consiste à configurer les propriétés du compte Administrateur de manière sécurisée. Cela inclut la configuration d’un mot de passe particulièrement long et fort et la sécurisation des paramètres de profil de Contrôle à distance et des Services Bureau à distance.
Le compte Administrateur peut également être désactivé lorsqu’il n’est pas requis. En désactivant le compte Administrateur ou en modifiant son nom, les utilisateurs malveillants auront plus de mal à essayer d’accéder au compte. Toutefois, lorsque le compte Administrateur est désactivé, il peut toujours être utilisé pour accéder à un contrôleur de domaine à l’aide du mode sans échec.
Sur un contrôleur de domaine, le compte Administrateur devient le compte d’administrateur de domaine. Le compte d’administrateur de domaine permet de se connecter au contrôleur de domaine, et nécessite un mot de passe fort. Le compte d’administrateur de domaine vous donne accès aux ressources de domaine.
Notes
Lorsque le contrôleur de domaine est installé initialement, vous pouvez vous connecter et utiliser Gestionnaire de serveur pour configurer un compte Administrateur local, avec les droits et autorisations que vous souhaitez attribuer. Par exemple, vous pouvez utiliser un compte Administrateur local pour gérer le système d’exploitation lorsque vous l’installez pour la première fois. En adoptant cette approche, vous pouvez configurer le système d’exploitation sans risque d’être bloqué. En règle générale, vous n’avez pas besoin d’utiliser le compte après l’installation. Vous pouvez créer des comptes d’utilisateur locaux sur le contrôleur de domaine uniquement avant l’installation d’Active Directory Domain Services et non après.
Quand Active Directory est installé sur le premier contrôleur de domaine du domaine, le compte Administrateur est créé pour Active Directory. Le compte Administrateur est le compte le plus puissant du domaine. Il reçoit des droits d’accès et d’administration à l’échelle du domaine pour administrer l’ordinateur et le domaine, et dispose des droits et autorisations les plus étendus sur le domaine. La personne qui installe Active Directory Domain Services sur l’ordinateur crée le mot de passe de ce compte lors de l’installation.
Attributs de compte administrateur
| Attribut | Valeur |
|---|---|
| SID/RID connu | S-1-5-<domain>-500 |
| Type | Utilisateur |
| Conteneur par défaut | CN=Utilisateurs, DC=<domain>, DC= |
| Membres par défaut | N/A |
| Membre par défaut de | Administrateurs, Admins du domaine, Administrateurs d’entreprise, Utilisateurs de domaine (l’ID de groupe principal de tous les comptes d’utilisateur est Utilisateurs de domaine) Propriétaires créateurs de la stratégie de groupe et Administrateurs du schéma dans le groupe d’utilisateurs du domaine Active Directory |
| Protégé par ADMINSDHOLDER ? | Oui |
| Sortie du conteneur par défaut sécurisée ? | Oui |
| La gestion de ce groupe peut-elle être déléguée à des administrateurs extérieurs au service de façon sécurisée ? | Non |
Compte Invité
Le compte Invité est un compte local par défaut qui dispose d’un accès limité à l’ordinateur et qui est désactivé par défaut. Par défaut, le mot de passe du compte Invité est laissé vide. Un mot de passe vide permet d’accéder au compte Invité sans demander à l’utilisateur d’entrer un mot de passe.
Le compte Invité permet aux utilisateurs occasionnels ou ponctuels, qui n’ont pas de compte individuel sur l’ordinateur, de se connecter au serveur ou domaine local avec des droits et autorisations restreints. Le compte Invité peut être activé et le mot de passe peut être configuré si nécessaire, mais uniquement par un membre du groupe Administrateur sur le domaine.
Appartenance à un groupe de comptes Invités
Le compte Invité est membre des groupes de sécurité par défaut décrits dans le tableau Attributs du compte invité suivant. Par défaut, le compte Invité est le seul membre du groupe Invités par défaut, qui permet à un utilisateur de se connecter à un serveur, et du groupe global Invités du domaine, qui permet à un utilisateur de se connecter à un domaine.
Un membre du groupe Administrateurs ou Admins du domaine peut configurer un utilisateur avec un compte Invité sur un ou plusieurs ordinateurs.
Considérations relatives à la sécurité des comptes Invités
Étant donné que le compte Invité peut fournir un accès anonyme, il s’agit d’un risque pour la sécurité. Il possède également un SID bien connu. Pour cette raison, il est recommandé de laisser le compte Invité désactivé, sauf si son utilisation est requise et, dans ce cas, uniquement avec des droits et autorisations restreints pendant une période très limitée.
Lorsque le compte Invité est requis, un administrateur sur le contrôleur de domaine est requis pour activer le compte Invité. Le compte Invité peut être activé sans exiger de mot de passe, ou il peut être activé avec un mot de passe fort. L’administrateur accorde également des droits et des autorisations restreints pour le compte Invité. Pour empêcher tout accès non autorisé :
N’accordez pas au compte Invité le droit d’utilisateur Arrêter le système. Lorsqu’un ordinateur s’arrête ou démarre, il est possible qu’un utilisateur Invité ou toute personne disposant d’un accès local, tel qu’un utilisateur malveillant, puisse obtenir un accès non autorisé à l’ordinateur.
Ne fournissez pas au compte Invité la possibilité d’afficher les journaux des événements. Une fois le compte Invité activé, il est recommandé de surveiller ce compte fréquemment pour s’assurer que les autres utilisateurs ne peuvent pas utiliser les services et autres ressources, comme celles qui ont été laissées involontairement disponibles par un utilisateur précédent.
N’utilisez pas le compte Invité lorsque le serveur dispose d’un accès réseau externe ou d’un accès à d’autres ordinateurs.
Si vous décidez d’activer le compte Invité, veillez à restreindre son utilisation et à modifier régulièrement le mot de passe. Comme avec le compte Administrateur, il est recommandé de renommer le compte par mesure de sécurité supplémentaire.
Par ailleurs, un administrateur est responsable de la gestion du compte Invité. L’administrateur surveille le compte Invité, le désactive lorsqu’il n’est plus utilisé et modifie ou supprime son mot de passe en fonction des besoins.
Pour plus d’informations sur les attributs du compte Invité, consultez le tableau suivant :
Attributs du compte Invité
| Attribut | Valeur |
|---|---|
| SID/RID connu | S-1-5-<domain>-501 |
| Type | Utilisateur |
| Conteneur par défaut | CN=Utilisateurs, DC=<domain>, DC= |
| Membres par défaut | None |
| Membre par défaut de | Invités, Invités du domaine |
| Protégé par ADMINSDHOLDER ? | Non |
| Sortie du conteneur par défaut sécurisée ? | Peut être déplacé, mais cela est déconseillé. |
| La gestion de ce groupe peut-elle être déléguée à des administrateurs extérieurs au service de façon sécurisée ? | Non |
Compte Assistant de l’aide (installé à l’aide d’une session d’assistance à distance)
Le compte Assistant de l’aide est un compte local par défaut qui est activé lors de l’exécution d’une session d’assistance à distance. Ce compte est automatiquement désactivé si aucune demande d’assistance à distance n’est en attente.
Assistant de l’aide est le compte principal utilisé pour établir une session d’assistance à distance. La session d’assistance à distance permet de se connecter à un autre ordinateur exécutant le système d’exploitation Windows, et elle est lancée sur invitation. Pour solliciter une assistance à distance, un utilisateur envoie une invitation à partir de son ordinateur, par e-mail ou sous forme de fichier, à une personne qui peut fournir de l’aide. Une fois l’invitation de l’utilisateur à une session d’assistance à distance acceptée, le compte Assistant de l’aide par défaut est automatiquement créé pour accorder à la personne qui fournit de l’aide un accès limité à l’ordinateur. Le compte Assistant de l’aide est géré par le service Gestionnaire de sessions d’aide sur le Bureau à distance.
Considérations relatives à la sécurité d’Assistant de l’aide
Les SID qui se rapportent au compte Assistant de l’aide par défaut sont les suivants :
SID : S-1-5-
<domain>-13, nom d’affichage Utilisateur Terminal Server. Ce groupe inclut tous les utilisateurs qui se connectent à un serveur sur lequel les services Bureau à distance sont activés. Sous Windows Server 2008 R2, les services Bureau à distance sont appelés services Terminal Server.SID : S-1-5-
<domain>-14, nom d’affichage Ouverture de session interactive distante. Ce groupe comprend tous les utilisateurs qui se connectent à l’ordinateur à l’aide d’une connexion Bureau à distance. Ce groupe est un sous-ensemble du groupe interactif. Les jetons d’accès qui contiennent le SID d’ouverture de session interactive distante contiennent également le SID interactif.
Pour le système d’exploitation Windows Server, l’assistance à distance est un composant facultatif qui n’est pas installé par défaut. Vous devez installer l’assistance à distance avant de pouvoir l’utiliser.
Pour plus d’informations sur les attributs du compte Assistant de l’aide, consultez le tableau suivant :
Attributs du compte Assistant de l’aide
| Attribut | Valeur |
|---|---|
| SID/RID connu | S-1-5-<domain>-13 (utilisateur Terminal Server), S-1-5-<domain>-14 (ouverture de session interactive distante) |
| Type | Utilisateur |
| Conteneur par défaut | CN=Utilisateurs, DC=<domain>, DC= |
| Membres par défaut | None |
| Membre par défaut de | Invités du domaine Invités |
| Protégé par ADMINSDHOLDER ? | Non |
| Sortie du conteneur par défaut sécurisée ? | Peut être déplacé, mais cela est déconseillé. |
| La gestion de ce groupe peut-elle être déléguée à des administrateurs extérieurs au service de façon sécurisée ? | Non |
Compte KRBTGT
Le compte KRBTGT est un compte local par défaut qui agit en tant que compte de service pour le service Centre de distribution de clés (KDC). Ce compte ne peut pas être supprimé et le nom du compte ne peut pas être modifié. Le compte KRBTGT ne peut pas être activé dans Active Directory.
KRBTGT est également le nom de principal de sécurité utilisé par le KDC pour un domaine Windows Server, comme spécifié par la norme de sécurité RFC 4120. Le compte KRBTGT est l’entité du principal de sécurité KRBTGT, et il est créé automatiquement lorsqu’un nouveau domaine est créé.
L’authentification Kerberos Windows Server est obtenue à l’aide d’un ticket DGT (Ticket-Granting Ticket) Kerberos spécial, chiffré avec une clé symétrique. Cette clé est créée à partir du mot de passe du serveur ou du service auquel l’accès est demandé. Le mot de passe TGT du compte KRBTGT est connu uniquement par le service Kerberos. Pour demander un ticket de session, le TGT doit être présenté au KDC. Le TGT est envoyé au client Kerberos à partir du KDC.
Considérations relatives à la maintenance du compte KRBTGT
Un mot de passe fort est automatiquement affecté aux comptes KRBTGT et de confiance. Comme pour tout compte de service disposant de privilèges, les organisations doivent modifier ces mots de passe régulièrement. Le mot de passe du compte KDC est utilisé pour créer une clé secrète pour le chiffrement et le déchiffrement des demandes TGT émises. Le mot de passe d’un compte de confiance de domaine est utilisé pour créer une clé inter-domaines pour le chiffrement des tickets de référence.
La réinitialisation du mot de passe nécessite que vous soyez membre du groupe Admins du domaine ou que l’autorité appropriée vous ait été déléguée. Par ailleurs, vous devez être membre du groupe Administrateurs local, ou l’autorité appropriée doit vous avoir été déléguée.
Après avoir réinitialisé le mot de passe KRBTGT, assurez-vous que l’ID d’événement 9 dans la source d’événements Key-Distribution-Center (Kerberos) est écrit dans le journal des événements système.
Considérations relatives à la sécurité des comptes KRBTGT
Il est également recommandé de réinitialiser le mot de passe du compte KRBTGT pour s’assurer qu’un contrôleur de domaine récemment restauré ne se réplique pas avec un contrôleur de domaine compromis. Dans ce cas, dans une récupération de forêt volumineuse répartie sur plusieurs emplacements, vous ne pouvez pas garantir que tous les contrôleurs de domaine sont arrêtés et, s’ils sont arrêtés, qu’ils ne peuvent pas être redémarrés avant que toutes les étapes de récupération appropriées aient été effectuées. Après avoir réinitialisé le compte KRBTGT, un autre contrôleur de domaine ne peut pas répliquer le mot de passe de ce compte à l’aide d’un ancien mot de passe.
Une organisation qui soupçonne la compromission du domaine du compte KRBTGT doit envisager l’utilisation de services professionnels de réponse aux incidents. La restauration de la propriété du compte a un impact sur l’ensemble du domaine, nécessite beaucoup de travail et doit se faire dans le cadre d’un effort de récupération plus large.
Le mot de passe KRBTGT est la clé sur laquelle repose toute la confiance dans Kerberos. La réinitialisation du mot de passe KRBTGT revient à renouveler le certificat d’autorité de certification racine avec une nouvelle clé et à immédiatement ne plus approuver l’ancienne clé, ce qui affecte presque toutes les opérations Kerberos ultérieures.
Pour tous les types de compte (utilisateurs, ordinateurs et services)
Tous les TGT déjà émis et distribués ne seront plus valides, car les contrôleurs de domaine les rejetteront. Ces tickets sont chiffrés avec le KRBTGT afin que n’importe quel contrôleur de domaine puisse les valider. Lorsque le mot de passe change, les tickets ne sont plus valides.
Toutes les sessions actuellement authentifiées que les utilisateurs connectés ont établies (en fonction de leurs tickets de service) à une ressource (comme un partage de fichiers, un site SharePoint ou un serveur Exchange) sont valides jusqu’à ce que le ticket de service soit requis pour réauthentification.
Les connexions authentifiées NTLM ne sont pas affectées.
Étant donné qu’il est impossible de prédire les erreurs spécifiques qui se produiront pour un utilisateur donné dans un environnement d’exploitation de production, vous devez supposer que tous les ordinateurs et tous les utilisateurs seront affectés.
Important
Le redémarrage d’un ordinateur est le seul moyen fiable de récupérer les fonctionnalités, car cela entraîne la nouvelle connexion du compte d’ordinateur et des comptes d’utilisateur. Une nouvelle connexion demandera de nouveaux TGT valides avec le nouveau KRBTGT, ce qui corrigera les problèmes opérationnels liés à KRBTGT sur cet ordinateur.
Contrôleurs de domaine en lecture seule et compte KRBTGT
Windows Server 2008 a introduit le contrôleur de domaine en lecture seule. Le contrôleur de domaine en lecture seule est présenté comme un centre de distribution de clés (KDC) pour les succursales. Le contrôleur de domaine en lecture seule utilise un compte et un mot de passe KRBTGT différents de ceux du KDC sur un contrôleur de domaine accessible en écriture lorsqu’il signe ou chiffre les requêtes TGT (Ticket Granting Ticket). Une fois qu’un compte a été correctement authentifié, le contrôleur de domaine en lecture seule détermine si les informations d’identification d’un utilisateur ou d’un ordinateur peuvent être répliquées depuis le contrôleur de domaine accessible en écriture vers le contrôleur de domaine en lecture seule à l’aide de la stratégie de réplication de mot de passe.
Une fois les informations d’identification mises en cache sur le contrôleur de domaine en lecture seule, celui-ci peut accepter les demandes de connexion de cet utilisateur jusqu’à ce que les informations d’identification changent. Lorsqu’un TGT est signé avec le compte KRBTGT du contrôleur de domaine en lecture seule, celui-ci reconnaît qu’il dispose d’une copie mise en cache des informations d’identification. Si un autre contrôleur de domaine signe le TGT, le contrôleur de domaine en lecture seule transfère les requêtes à un contrôleur de domaine accessible en écriture.
Attributs du compte KRBTGT
Pour plus d’informations sur les attributs du compte KRBTGT, consultez le tableau suivant :
| Attribut | Valeur |
|---|---|
| SID/RID connu | S-1-5-<domain>-502 |
| Type | Utilisateur |
| Conteneur par défaut | CN=Utilisateurs, DC=<domain>, DC= |
| Membres par défaut | None |
| Membre par défaut de | Groupe Utilisateurs du domaine (l’ID de groupe principal de tous les comptes d’utilisateur est Utilisateurs de domaine) |
| Protégé par ADMINSDHOLDER ? | Oui |
| Sortie du conteneur par défaut sécurisée ? | Peut être déplacé, mais cela est déconseillé. |
| La gestion de ce groupe peut-elle être déléguée à des administrateurs extérieurs au service de façon sécurisée ? | Non |
Paramètres des comptes locaux par défaut dans Active Directory
Chaque compte local par défaut dans Active Directory possède plusieurs paramètres de compte que vous pouvez utiliser pour configurer les paramètres de mot de passe et les informations propres à la sécurité, comme décrit dans le tableau suivant :
| Paramètres de compte | Description |
|---|---|
| L’utilisateur doit changer de mot de passe à la prochaine ouverture de session | Force la modification du mot de passe la prochaine fois que l’utilisateur se connectera au réseau. Utilisez cette option pour vous assurer que l’utilisateur est la seule personne à connaître le mot de passe. |
| L’utilisateur ne peut pas changer de mot de passe | Empêche l’utilisateur de modifier le mot de passe. Utilisez cette option pour garder le contrôle sur un compte d’utilisateur, tel un compte Invité ou un compte temporaire. |
| Le mot de passe n’expire jamais | Empêche l’expiration du mot de passe de l’utilisateur. Il est recommandé d’activer cette option avec des comptes de service et d’utiliser des mots de passe forts. |
| Enregistrer les mots de passe en utilisant un chiffrement réversible | Fournit une prise en charge pour les applications qui utilisent des protocoles nécessitant une connaissance de la forme en texte clair du mot de passe de l’utilisateur à des fins d’authentification. Cette option est requise lorsque vous utilisez le protocole CHAP (Challenge Handshake Authentication Protocol) dans Internet Authentication Services (IAS) et lorsque vous utilisez l’authentification Digest dans Internet Information Services (IIS). |
| Le compte est désactivé | Empêche l’utilisateur de se connecter avec le compte sélectionné. En tant qu’administrateur, vous pouvez utiliser des comptes désactivés comme modèles pour des comptes d’utilisateurs courants. |
| Une carte à puce est nécessaire pour ouvrir une session interactive | Nécessite l’utilisation d’une carte à puce par l’utilisateur pour se connecter au réseau de manière interactive. L’utilisateur doit aussi posséder un lecteur de carte à puce installé sur son ordinateur et un code confidentiel (PIN) valide pour la carte à puce. Lorsque cet attribut est appliqué sur le compte, l’effet est le suivant : |
| Le compte est approuvé pour la délégation | Permet à un service qui s’exécute sous ce compte d’effectuer des opérations au nom d’autres comptes d’utilisateurs sur le réseau. Un service qui s’exécute sous un compte d’utilisateur (également appelé un compte de service) approuvé pour la délégation peut emprunter l’identité d’un client pour obtenir l’accès aux ressources sur l’ordinateur qui exécute le service ou sur d’autres ordinateurs. Par exemple, dans une forêt définie sur le niveau fonctionnel de Windows Server 2003, ce paramètre se trouve sous l’onglet Délégation. Il est disponible uniquement pour les comptes auxquels ont été attribués des noms de principaux de service (SPN), qui sont définis à l’aide de la commande setspn des outils de support Windows. Ce paramètre affecte la sécurité et doit être attribué avec précaution. |
| Le compte est sensible et ne peut pas être délégué | Donne le contrôle sur un compte utilisateur, par exemple un compte Invité ou un compte temporaire. Cette option peut être utilisée si ce compte ne peut pas être affecté à un autre compte pour délégation. |
| Utiliser les types de chiffrement DES pour ce compte | Fournit la prise en charge pour la norme DES (Data Encryption Standard). La norme DES prend en charge plusieurs niveaux de chiffrement, y compris les normes Microsoft Point-to-Point Encryption (MPPE) Standard (40 et 56 bits), MPPE Standard (56 bits), MPPE Strong (56 bits), Internet Protocol security (IPsec) DES (128 bits), IPsec DES (40 bits), IPsec DES (56 bits) et IPsec Triple DES (3DES). |
| La pré-authentification Kerberos n’est pas nécessaire | Fournit une prise en charge pour les autres implémentations du protocole Kerberos. Étant donné que la pré-authentification offre une sécurité supplémentaire, soyez prudent lorsque vous activez cette option. Les contrôleurs de domaine exécutant Windows 2000 ou Windows Server 2003 peuvent utiliser d’autres mécanismes pour synchroniser l’heure. |
Notes
L’option DES n’est pas activée par défaut dans les systèmes d’exploitation Windows Server (à compter de Windows Server 2008 R2) ou dans les systèmes d’exploitation clients Windows (à compter de Windows 7). Pour ces systèmes d’exploitation, les ordinateurs n’utilisent pas les suites de chiffrement DES-CBC-MD5 ou DES-CBC-CRC par défaut. Si votre environnement nécessite DES, ce paramètre peut affecter la compatibilité avec les ordinateurs clients ou avec les services et les applications de votre environnement.
Pour plus d’informations, consultez Hunting down DES in order to securely deploy Kerberos (Traque de DES pour déployer Kerberos de manière sécurisée).
Gérer les comptes locaux par défaut dans Active Directory
Une fois les comptes locaux par défaut installés, ils se trouvent dans le conteneur Utilisateurs dans Utilisateurs et ordinateurs Active Directory. Vous pouvez créer, désactiver, réinitialiser et supprimer des comptes locaux par défaut à l’aide de Microsoft Management Console (MMC) pour Utilisateurs et ordinateurs Active Directory, ainsi que des outils en ligne de commande.
Vous pouvez utiliser Utilisateurs et ordinateurs Active Directory pour attribuer des droits et des autorisations sur un contrôleur de domaine local spécifié, et sur ce contrôleur de domaine uniquement, afin de limiter la capacité des utilisateurs et des groupes locaux à effectuer certaines actions. Un droit autorise un utilisateur à effectuer certaines actions sur un ordinateur, comme effectuer des copies de sauvegarde de fichiers et de dossiers ou arrêter un ordinateur. À l’opposé, une autorisation est une règle associée à un objet (généralement, un fichier, un dossier ou une imprimante), qui régule quels utilisateurs peuvent accéder à l’objet et de quelle manière.
Pour plus d’informations sur la création et la gestion de comptes d’utilisateurs locaux dans Active Directory, voir Gérer les utilisateurs locaux.
Vous pouvez également utiliser Utilisateurs et ordinateurs Active Directory sur un contrôleur de domaine afin de cibler des ordinateurs distants qui ne sont pas des contrôleurs de domaine sur le réseau.
Vous pouvez obtenir des suggestions de Microsoft pour les configurations de contrôleur de domaine que vous pouvez distribuer à l’aide de l’outil Security Compliance Manager (SCM). Pour plus d’informations, consultez Microsoft Security Compliance Manager.
Certains des comptes d’utilisateurs locaux par défaut sont protégés par un processus en arrière-plan qui vérifie et applique régulièrement un descripteur de sécurité spécifique, qui est une structure de données qui contient des informations de sécurité associées à un objet protégé. Le descripteur de sécurité est présent sur l’objet AdminSDHolder.
Cela signifie que, lorsque vous souhaitez modifier les autorisations sur un groupe d’administrateurs de service ou sur l’un de ses comptes membres, vous devez également modifier le descripteur de sécurité sur l’objet AdminSDHolder. Cette approche garantit que les autorisations sont appliquées de manière cohérente. Soyez prudent lorsque vous apportez ces modifications, car cette action peut également affecter les paramètres par défaut appliqués à tous vos comptes d’administration protégés.
Restreindre et protéger les comptes de domaine sensibles
La restriction et la protection des comptes de domaine dans votre environnement de domaine requièrent que vous adoptiez et implémentiez l’approche recommandée suivante :
Limitez strictement l’appartenance aux groupes Administrateurs, Admins du domaine et Administrateurs de l’entreprise.
Contrôlez rigoureusement où et comment les comptes de domaine sont utilisés.
Les comptes de membre dans les groupes Administrateurs, Admins du domaine et Administrateurs de l’entreprise d’un domaine ou d’une forêt sont des cibles de grande valeur pour les utilisateurs malveillants. Pour limiter toute exposition, il est recommandé de limiter strictement l’appartenance à ces groupes d’administrateurs au plus petit nombre de comptes. La restriction de l’appartenance à ces groupes réduit le risque qu’un administrateur utilise involontairement ces informations d’identification et crée une vulnérabilité que des utilisateurs malveillants peuvent exploiter.
Par ailleurs, il est recommandé de contrôler rigoureusement où et comment les comptes de domaine sensibles sont utilisés. Limitez l’utilisation des comptes Admins du domaine et des autres comptes Administrateur afin d’éviter qu’ils ne soient utilisés pour se connecter à des systèmes de gestion et à des stations de travail qui sont sécurisés au même niveau que les systèmes gérés. Lorsque les comptes Administrateur ne sont pas limités de cette manière, chaque station de travail à partir de laquelle un administrateur du domaine se connecte fournit un emplacement supplémentaire que les utilisateurs malveillants peuvent exploiter.
L’implémentation de ces bonnes pratiques se divise en différentes tâches que vous trouverez ci-dessous :
- Séparer les comptes administrateur des comptes d’utilisateur
- Restreindre l’accès de connexion des administrateurs aux serveurs et stations de travail
- Désactiver le droit de délégation de compte pour les comptes administrateur sensibles
Pour parer aux situations où des défis d’intégration avec l’environnement de domaine sont attendus, chaque tâche est décrite en fonction des exigences à respecter pour une implémentation minimale, meilleure ou idéale. Comme pour toutes les modifications importantes apportées à un environnement de production, veillez à tester ces modifications en détail avant de les implémenter et de les déployer. Ensuite, mettez en place le déploiement de manière à permettre une restauration de la modification si des problèmes techniques se produisent.
Séparer les comptes administrateur des comptes d’utilisateur
Limitez les comptes Admins du domaine et les autres comptes sensibles afin d’empêcher qu’ils ne soient utilisés pour se connecter à des serveurs et des stations de travail dont le niveau de confiance est plus faible. Limitez et protégez les comptes Administrateur en isolant les comptes Administrateur des comptes d’utilisateur standard, en séparant les tâches administratives des autres tâches et en limitant l’utilisation de ces comptes. Créez des comptes dédiés pour le personnel administratif qui a besoin d’informations d’identification d’administrateur pour effectuer des tâches administratives spécifiques, puis créez des comptes distincts pour d’autres tâches utilisateur standard, conformément aux instructions suivantes :
Compte privilégié : allouez des comptes administrateur pour effectuer les tâches administratives suivantes uniquement :
Implémentation minimale : créez des comptes distincts pour les administrateurs du domaine, les administrateurs d’entreprise ou équivalent, avec les droits d’administrateur appropriés dans le domaine ou la forêt. Servez-vous des comptes auxquels des droits d’administrateur sensibles ont été accordés uniquement pour administrer les données de domaine et les contrôleurs de domaine.
Implémentation meilleure : créez des comptes distincts pour les administrateurs disposant de droits d’administration réduits, tels que les comptes pour les administrateurs de station de travail et les comptes disposant de droits d’utilisateur sur les unités d’organisation Active Directory désignées.
Implémentation idéale : créez plusieurs comptes distincts pour un administrateur qui a plusieurs responsabilités professionnelles qui nécessitent différents niveaux de confiance. Configurez chaque compte Administrateur avec des droits d’utilisateur différents, par exemple pour l’administration des stations de travail, l’administration de serveurs et l’administration de domaine, afin de permettre à l’administrateur de se connecter aux stations de travail, serveurs et contrôleurs de domaine spécifiés, et ce strictement en fonction de ses responsabilités professionnelles.
Comptes d’utilisateur standard : octroyez des droits d’utilisateur standard pour les tâches d’utilisateur standard, comme les e-mails, la navigation web et l’utilisation des applications de cœur de métier. Ces comptes ne doivent pas se voir accorder de droits d’administrateur.
Important
Assurez-vous que les comptes Administrateur sensibles ne peuvent pas accéder aux e-mails ni naviguer sur Internet, comme décrit dans la section suivante.
Pour en savoir plus sur l’accès privilégié, consultez Appareils à accès privilégié.
Restreindre l’accès de connexion des administrateurs aux serveurs et stations de travail
Il est recommandé d’empêcher les administrateurs d’utiliser des comptes Administrateur sensibles pour se connecter à des serveurs et des stations de travail dont le niveau de confiance est plus faible. Cette restriction empêche les administrateurs d’augmenter par inadvertance le risque de vol d’informations d’identification en se connectant à un ordinateur dont le niveau de confiance est plus faible.
Important
Vérifiez que vous disposez d’un accès local au contrôleur de domaine ou que vous avez créé au moins une station de travail d’administration dédiée.
Procédez comme suit pour limiter l’accès de connexion aux serveurs et stations de travail dont le niveau de confiance est plus faible :
Implémentation minimale : empêchez les administrateurs du domaine de disposer d’un accès de connexion aux serveurs et aux stations de travail. Avant de commencer cette procédure, identifiez toutes les unités d’organisation du domaine qui contiennent des stations de travail et des serveurs. Les ordinateurs non identifiés et présents dans des unités d’organisation n’empêcheront pas les administrateurs disposant de comptes sensibles de se connecter à eux.
Implémentation meilleure : limitez les administrateurs du domaine aux serveurs et stations de travail hors contrôleur de domaine.
Implémentation idéale : empêchez les administrateurs de serveur de se connecter aux stations de travail, en plus des administrateurs du domaine.
Notes
Pour cette procédure, ne liez pas à l’unité d’organisation des comptes qui contiennent des stations de travail pour les administrateurs qui effectuent uniquement des tâches d’administration et ne fournissent pas d’accès à Internet ni aux e-mails.
Pour empêcher les administrateurs du domaine d’accéder aux stations de travail (implémentation minimale)
En tant qu’administrateur du domaine, ouvrez la console de gestion des stratégies de groupe (GPMC).
Ouvrez Gestion des stratégies de groupe, puis développez <forest>\Domains\
<domain>.Cliquez avec le bouton droit sur Objets de stratégie de groupe, puis sélectionnez Nouveau.
Dans la fenêtre Nouvel objet GPO, nommez le GPO qui empêche les administrateurs de se connecter aux stations de travail, puis sélectionnez OK.
Cliquez avec le bouton droit sur Nouvel objet GPO, puis sélectionnez Modifier.
Configurez les droits d’utilisateur pour refuser la connexion locale pour les administrateurs du domaine.
Sélectionnez Configuration ordinateur>Stratégies>Paramètres Windows>Stratégies locales, sélectionnez Attribution des droits utilisateur, puis procédez comme suit :
a. Double-cliquez sur Interdire l’ouverture d’une session locale, puis sélectionnez Définir ces paramètres de stratégie. b. Sélectionnez Ajouter un utilisateur ou un groupe, sélectionnez Parcourir, tapez Administrateurs de l’entreprise, puis sélectionnez OK. c. Sélectionnez Ajouter un utilisateur ou un groupe, sélectionnez Parcourir, tapez Admins du domaine, puis sélectionnez OK.
Astuce
Vous pouvez éventuellement ajouter tous les groupes qui contiennent des administrateurs de serveur que vous souhaitez empêcher de se connecter aux stations de travail.
Notes
Cette étape peut entraîner des problèmes avec les tâches d’administrateur qui s’exécutent en tant que tâches ou services planifiés avec des comptes présents dans le groupe Admins du domaine. La pratique consistant à utiliser des comptes Administrateur du domaine pour exécuter des services et des tâches sur des stations de travail crée un risque important d’attaques par vol d’informations d’identification et, par conséquent, doit être remplacée par d’autres moyens permettant d’exécuter des tâches ou des services planifiés.
d. Sélectionnez OK pour achever la configuration.
Liez le GPO à la première unité d’organisation de station de travail. Accédez au chemin <forêt>\Domains\
<domain>\OU, puis procédez comme suit :a. Cliquez avec le bouton droit sur l’unité d’organisation de la station de travail, puis sélectionnez Lier un objet de stratégie de groupe existant.
b. Sélectionnez le GPO que vous venez de créer, puis sélectionnez OK.
Testez les fonctionnalités des applications d’entreprise sur les stations de travail de la première unité d’organisation, puis résolvez les problèmes causés par la nouvelle stratégie.
Liez toutes les autres unités d’organisation qui contiennent des stations de travail.
Toutefois, ne créez pas de lien vers l’unité d’organisation de la station de travail d’administration si elle est créée pour les stations de travail d’administration qui sont dédiées uniquement aux tâches d’administration et qui n’ont pas accès à Internet ni à la messagerie.
Important
Si vous étendez ultérieurement cette solution, ne refusez pas les droits de connexion pour le groupe Utilisateurs du domaine. Le groupe Utilisateurs du domaine inclut tous les comptes d’utilisateur du domaine, y compris les utilisateurs, les administrateurs du domaine et les administrateurs de l’entreprise.
Désactiver le droit de délégation de compte pour les comptes Administrateur sensibles
Bien que les comptes d’utilisateur ne soient pas marqués pour la délégation par défaut, les comptes d’un domaine Active Directory peuvent être approuvés pour la délégation. Cela signifie qu’un service ou un ordinateur approuvé pour la délégation peut emprunter l’identité d’un compte qui s’authentifie auprès d’eux afin d’accéder à d’autres ressources sur le réseau.
Pour les comptes sensibles, tels que ceux appartenant aux membres des groupes Administrateurs, Admins du domaine ou Administrateurs de l’entreprise dans Active Directory, la délégation peut présenter un risque important d’élévation des droits. Par exemple, si un compte du groupe Admins du domaine est utilisé pour se connecter à un serveur membre compromis pour lequel la délégation est approuvée, ce serveur peut demander l’accès aux ressources dans le contexte du compte Admins du domaine et transformer la compromission de ce serveur membre en compromission du domaine.
Il est recommandé de configurer les objets utilisateur pour tous les comptes sensibles dans Active Directory en cochant la case Le compte est sensible et ne peut pas être délégué sous Options de compte pour empêcher la délégation de ces comptes. Pour plus d’informations, consultez Paramètres des comptes locaux par défaut dans Active Directory.
Comme pour toute modification de configuration, testez entièrement ce paramètre activé pour vous assurer qu’il fonctionne correctement avant de l’implémenter.
Sécuriser et gérer les contrôleurs de domaine
Il est recommandé d’appliquer strictement des restrictions aux contrôleurs de domaine de votre environnement. Cela garantit que les contrôleurs de domaine :
- exécutent uniquement les logiciels requis ;
- exigent que le logiciel soit régulièrement mis à jour ;
- sont configurés avec les paramètres de sécurité appropriés.
L’un des aspects de la sécurisation et de la gestion des contrôleurs de domaine consiste à s’assurer que les comptes d’utilisateur locaux par défaut sont entièrement protégés. Il est primordial de restreindre et de sécuriser tous les comptes de domaine sensibles, comme décrit dans les sections précédentes.
Étant donné que les contrôleurs de domaine stockent les hachages de mot de passe des informations d’identification de tous les comptes du domaine, ils constituent des cibles de choix pour les utilisateurs malveillants. Lorsque les contrôleurs de domaine ne sont pas bien gérés et sécurisés à l’aide de restrictions appliquées de manière stricte, ils peuvent être compromis par des utilisateurs malveillants. Par exemple, un utilisateur malveillant peut voler des informations d’identification d’administrateur de domaine sensibles à partir d’un contrôleur de domaine, puis se servir de ces informations d’identification pour attaquer le domaine et la forêt.
Par ailleurs, les applications installées et les agents de gestion sur les contrôleurs de domaine peuvent fournir un chemin d’accès à l’élévation des droits, que les utilisateurs malveillants peuvent utiliser pour compromettre le service de gestion ou les administrateurs de ce service. Les outils et services de gestion, que votre organisation utilise pour gérer les contrôleurs de domaine et leurs administrateurs, sont tout aussi importants pour la sécurité des contrôleurs de domaine et des comptes d’administrateur de domaine. Assurez-vous que ces services et administrateurs sont pleinement sécurisés avec un effort égal.