Recommandations relatives au compte de service d’annuaire Microsoft Defender pour Identity

Découvrez comment créer un compte de service d’annuaire (DSA) et le configurer pour qu’il fonctionne avec Microsoft Defender pour Identity.

Introduction

Le compte de service d’annuaire (DSA) dans Defender pour Identity est utilisé par le capteur pour effectuer les fonctions suivantes :

  • Au démarrage, le capteur se connecte au contrôleur de domaine à l’aide du protocole LDAP avec les informations d’identification du compte DSA.

  • Le capteur interroge le contrôleur de domaine pour obtenir des informations sur les entités observées dans le trafic réseau, les événements surveillés et les activités ETW surveillées.

  • Un capteur de chaque domaine est défini comme « synchronisateur de domaine » et est responsable du suivi des modifications apportées aux entités du domaine, comme les objets créés, les attributs d’entité suivis par Defender pour Identity, et ainsi de suite.

  • Si le capteur voit les activités d’entités dans d’autres domaines, il interroge ce domaine via LDAP pour obtenir des informations sur l’entité.

  • Defender pour Identity demande la liste des membres du groupe d’administrateurs local à partir d’appareils vus dans le trafic réseau, les événements et les activités ETW. Pour ce faire, effectuez un appel SAM-R sur l’appareil. Ces informations sont utilisées pour calculer les chemins de mouvement latéral potentiels.

Notes

Par défaut, Defender pour Identity prend en charge jusqu’à 30 informations d’identification. Si vous souhaitez ajouter des informations d’identification supplémentaires, contactez le support de Defender pour Identity.

Types de comptes DSA

Il existe deux types de DSA qui peuvent être utilisés :

  • Compte de service administré de groupe (gMSA) – recommandé

  • Compte d’utilisateur standard dans Active Directory

Type de DSA Avantages Inconvénients
gMSA
  • Déploiement plus sécurisé, car Active Directory gère la création et la rotation du mot de passe du compte comme le mot de passe d’un compte d’ordinateur.
  • Vous pouvez contrôler la fréquence à laquelle le mot de passe du compte est modifié.
  • Nécessite des étapes de configuration supplémentaires.
  • Compte d’utilisateur standard
  • Prend en charge toutes les versions du système d’exploitation prises en charge par le capteur.
  • Facile à créer et à utiliser.
  • Il est facile de configurer des autorisations de lecture entre des forêts approuvées.
  • Moins sécurisé, car il nécessite la création et la gestion des mots de passe.
  • Peut entraîner un temps d’arrêt si le mot de passe expire et que le mot de passe n’est pas mis à jour (à la fois à la configuration de l’utilisateur et de la DSA).
  • Nombre d’entrées DSA

    Combien d’entrées DSA sont requises ?

    Un minimum d’une entrée DSA est requis par Defender pour Identity. Il doit disposer d’autorisations de lecture pour tous les domaines des forêts.

    Dans un environnement multi-forêt non approuvé, un compte DSA est requis pour chaque forêt.

    Comment le capteur choisit-il l’entité DSA à utiliser ?

    Lorsque le capteur démarre, il obtient la liste des entrées DSA configurées dans Defender pour Identity.

    Une entrée DSA est configurée

    Le capteur tente d’utiliser l’entrée DSA configurée lors du démarrage, en réaction à un nouveau domaine contactant le contrôleur de domaine, chaque fois qu’une requête SAM-R est effectuée, ou chaque fois qu’une telle connexion doit être recréée.

    • Compte normal : le capteur tente de se connecter au contrôleur de domaine à l’aide du nom d’utilisateur et du mot de passe configurés.

    • Compte gMSA : : le capteur tente de récupérer le mot de passe du compte gMSA à partir d’Active Directory (AD). Après avoir récupéré le mot de passe, le capteur tente de se connecter au domaine.

    Deux entrées DSA ou plus sont configurées

    Lorsqu’il existe au moins deux entrées DSA, la logique suivante est appliquée :

    • Le capteur recherche une entrée avec une correspondance exacte du nom de domaine du domaine cible. Si une correspondance exacte est trouvée, le capteur tente de s’authentifier à l’aide des informations d’identification de cette entrée.
    • S’il n’existe pas de correspondance exacte du nom de domaine ou de l’entrée de correspondance exacte qui n’a pas pu s’authentifier, le capteur recherche dans la liste une entrée pour le domaine parent (à l’aide du nom de domaine complet DNS, et non des relations racine/enfant de forêt) et tente de s’authentifier à l’aide des informations d’identification de cette entrée.
    • S’il n’y a pas d’entrée pour le domaine parent ou si l’entrée de domaine parent n’a pas pu s’authentifier, le capteur recherche dans la liste une entrée pour un « domaine frère » (à nouveau, à l’aide du nom de domaine complet DNS, et non des relations racine/enfant de forêt) et tente de s’authentifier à l’aide des informations d’identification de cette entrée.
    • S’il n’y a pas d’entrée pour un domaine frère ou si l’entrée de domaine frère n’a pas pu s’authentifier, le capteur traverse la liste par tourniquet (round robin) et tente de s’authentifier auprès de chacune des entrées jusqu’à ce qu’elle réussisse. Les entrées GMSA DSA ont une priorité plus élevée que les entrées DSA normales.

    Par exemple, le capteur essaie les entrées DSA dans l’ordre suivant :

    1. Correspondance entre le nom de domaine DNS du domaine cible (par exemple, emea.contoso.com) et le domaine de l’entrée GMSA DSA (par exemple, emea.contoso.com).
    2. Correspondance entre le nom de domaine DNS du domaine cible (par exemple, emea.contoso.com) et le domaine de l’entrée régulière DSA (par exemple, emea.contoso.com).
    3. Correspondance dans le nom DNS racine du domaine cible (par exemple, emea.contoso.com) et le nom de domaine de l’entrée GMSA DSA (par exemple, contoso.com)
    4. Correspondance dans le nom DNS racine du domaine cible (par exemple, emea.contoso.com) et le nom de domaine de l’entrée régulière DSA (par exemple, contoso.com)
    5. Recherchez un « domaine frère » : nom de domaine cible (par exemple, emea.contoso.com) et nom de domaine d’entrée GMSA DSA (par exemple, apac.contoso.com).
    6. Recherchez un « domaine frère » : nom de domaine cible (par exemple, emea.contoso.com) et nom de domaine d’entrée régulière DSA (par exemple, apac.contoso.com).
    7. Tourniquet (round robin) toutes les autres entrées GMSA DSA
    8. Tourniquet toutes les autres entrées régulières DSA

    Un autre exemple, s’il s’agit des entrées DSA configurées :

    • DSA1.northamerica.contoso.com
    • DSA2.EMEA.contoso.com
    • DSA3.fabrikam.com

    Voici ensuite les capteurs, et quelle entrée DSA sera utilisée en premier :

    Nom de domaine complet du contrôleur de domaine Entrée DSA qui sera utilisée
    DC01.contoso.com Tourniquet
    DC02.fabrikam.com DSA3.fabrikam.com
    DC03.emea.contoso.com DSA2.emea.contoso.com
    DC04.contoso.com Tourniquet

    Notes

    • Dans une forêt à plusieurs domaines, il est recommandé de créer le compte DSA dans le domaine avec le plus grand nombre de contrôleurs de domaine.
    • Dans les environnements multi-domaines à forêts multiples, envisagez de créer une entrée DSA pour chaque domaine de l’environnement afin d’éviter l’enregistrement des authentifications ayant échoué en raison de la méthode round robin.

    Important

    Si un capteur n’est pas en mesure de s’authentifier via LDAP auprès du domaine Active Directory au démarrage à l’aide de l’un des comptes DSA configurés, le capteur n’entre pas dans un état d’exécution et une alerte d’intégrité est créée. Pour plus d’informations, consultez alertes d’intégrité Defender pour Identity.

    Comment créer un compte gMSA à utiliser avec Defender pour Identity

    Vous pouvez suivre les étapes suivantes pour créer un compte gMSA à utiliser comme entrée DSA pour Defender pour Identity. Cela ne fournit pas de conseils complets sur les comptes gMSA. Pour plus d’informations, consultez Prise en main des comptes de service gérés de groupe.

    Notes

    • Dans un environnement à forêts multiples, nous vous recommandons de créer les GMSA avec un nom unique pour chaque forêt ou domaine.

    Octroi des autorisations pour récupérer le mot de passe du compte gMSA

    Avant de créer le compte gMSA, envisagez d’attribuer des autorisations pour récupérer le mot de passe du compte.

    Lorsque vous utilisez une entrée gMSA, le capteur doit récupérer le mot de passe du compte gMSA à partir d’Active Directory. Pour ce faire, vous pouvez l’affecter à chacun des capteurs ou à l’aide d’un groupe.

    • Dans un déploiement à forêt unique, à domaine unique, si vous ne prévoyez pas d’installer le capteur sur des serveurs AD FS, vous pouvez utiliser le groupe de sécurité contrôleurs de domaine intégré.

    • Dans une forêt avec plusieurs domaines, lors de l’utilisation d’un seul compte DSA, il est recommandé de créer un groupe universel et d’ajouter chacun des contrôleurs de domaine (et serveurs AD FS) au groupe universel.

      Notes

      Si vous ajoutez un compte d’ordinateur au groupe universel une fois que l’ordinateur a reçu son ticket Kerberos, il ne pourra pas récupérer le mot de passe du compte gMSA jusqu’à ce qu’il demande un nouveau ticket Kerberos. Le ticket Kerberos contient une liste de groupes dont une entité fait partie d’un membre lors de l’émission du ticket. Dans ce cas, vous pouvez :

      • Attendez que le nouveau ticket Kerberos soit émis. (Les tickets Kerberos sont normalement valides pendant 10 heures)
      • Redémarrez le serveur, lorsque le serveur est redémarré, un nouveau ticket Kerberos est demandé avec la nouvelle appartenance au groupe.
      • Videz les tickets Kerberos existants. Cela force le contrôleur de domaine à demander un nouveau ticket Kerberos. À partir d’une invite de commandes d’administrateur sur le contrôleur de domaine, exécutez la commande suivante : klist purge -li 0x3e7

    Créer un compte gMSA

    Dans les étapes suivantes, vous allez créer un groupe spécifique qui peut récupérer le mot de passe du compte, créer un compte gMSA, puis tester que le compte est prêt à être utilisé.

    Exécutez les commandes PowerShell suivantes en tant qu’administrateur :

    # Set the variables:
    $gMSA_AccountName = 'mdiSvc01'
    $gMSA_HostsGroupName = 'mdiSvc01Group'
    $gMSA_HostNames = 'DC1', 'DC2', 'DC3', 'DC4', 'DC5', 'DC6', 'ADFS1', 'ADFS2'
    
    # Import the required PowerShell module:
    Import-Module ActiveDirectory
    
    # Create the group and add the members
    $gMSA_HostsGroup = New-ADGroup -Name $gMSA_HostsGroupName -GroupScope Global -PassThru
    $gMSA_HostNames | ForEach-Object { Get-ADComputer -Identity $_ } |
        ForEach-Object { Add-ADGroupMember -Identity $gMSA_HostsGroupName -Members $_ }
    
    # Create the gMSA:
    New-ADServiceAccount -Name $gMSA_AccountName -DNSHostName "$gMSA_AccountName.$env:USERDNSDOMAIN" `
    -PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroup.Name
    

    Autorisations requises pour le DSA

    La DSA nécessite des autorisations de lecture sur tous les objets dans Active Directory, y compris le conteneur d’objets supprimés. Les autorisations en lecture seule sur le conteneur Objets supprimés permettent à Defender for Identity de détecter les suppressions d’utilisateurs de votre Active Directory.

    L’octroi des autorisations de lecture requises sur le conteneur Objets supprimés peut être effectué à l’aide de l’exemple de code suivant :

    # Declare the *user* or *group* that needs to have read access to the deleted objects container
    # Note that if the identity you want to grant the permissions to is a Group Managed Service Account (gMSA), 
    # you need first to create a security group, add the gMSA as a member and list that group as the identity below
    $Identity = 'CONTOSO\mdisvc'
    
    # Get the deleted objects container's distinguished name:
    $distinguishedName = ([adsi]'').distinguishedName.Value
    $deletedObjectsDN = 'CN=Deleted Objects,{0}' -f $distinguishedName
    
    # Take ownership on the deleted objects container:
    $params = @("$deletedObjectsDN", '/takeOwnership')
    C:\Windows\System32\dsacls.exe $params
    
    # Grant the 'List Contents' and 'Read Property' permissions to the user or group:
    $params = @("$deletedObjectsDN", '/G', "$($Identity):LCRP")
    C:\Windows\System32\dsacls.exe $params
    

    Pour plus d’informations sur la configuration des autorisations en lecture seule sur le conteneur Objets supprimés, consultez la section Modification des autorisations sur un conteneur d’objets supprimés de l’article Afficher ou Définir des autorisations sur un objet Directory .

    Installer le compte gMSA

    Pour installer le compte gMSA, exécutez localement (en tant qu’administrateur) sur chacun des serveurs, la commande suivante :

    # Import the required PowerShell module:
    Import-Module ActiveDirectory
    
    # Install the gMSA account
    Install-ADServiceAccount -Identity 'mdiSvc01'
    

    Comment vérifier que le contrôleur de domaine peut récupérer le mot de passe du compte gMSA

    Pour vérifier que le serveur dispose des autorisations requises pour récupérer le mot de passe de gMSA, exécutez la commande PowerShell suivante :

    Test-ADServiceAccount -Identity 'mdiSvc01'
    

    S’il dispose des autorisations, la commande renvoie un message True .

    Notes

    Si vous recevez un message d’erreur lors de l’exécution de Test-ADServiceAccount, redémarrez le serveur ou réexécutez klist purge -li 0x3e7 et réessayez.

    Vérifiez que le compte gMSA dispose des droits requis (si nécessaire)

    Le service de capteur (Capteur Azure Advanced Threat Protection) s’exécute en tant que LocalService et effectue l’emprunt d’identité du compte DSA. L’emprunt d’identité échoue si la stratégie de connexion en tant que service est configurée, mais que l’autorisation n’a pas été accordée au compte gMSA et que vous recevez une alerte d’intégrité : les informations d’identification de l’utilisateur des services d’annuaire sont incorrectes.

    Si vous recevez l’alerte, vous devez vérifier si la stratégie de connexion en tant que service est configurée.

    La stratégie de connexion en tant que service peut être configurée dans un paramètre stratégie de groupe ou dans une stratégie de sécurité locale.

    • Pour vérifier la stratégie locale, exécutez secpol.msc et sélectionnez Stratégies locales. Sous Attribution des droits utilisateur, accédez au paramètre de stratégie de connexion en tant que service . Si la stratégie est activée, ajoutez le compte gMSA à la liste des comptes qui peuvent se connecter en tant que service.

    • Pour vérifier si le paramètre est défini dans stratégie de groupe, exécutez rsop.msc et vérifiez si le paramètre Configuration ordinateur ->Paramètres Windows -Paramètres de sécurité ->Stratégies locales ->>Attribution des droits utilisateur ->Se connecter en tant que service est défini. Si le paramètre est configuré, ajoutez le compte gMSA à la liste des comptes qui peuvent se connecter en tant que service dans l’éditeur de gestion stratégie de groupe.

    Connectez-vous en tant que service dans GPMC.

    Connectez-vous en tant que propriétés de service.

    Configurer le compte de service d’annuaire dans Microsoft 365 Defender

    Pour connecter vos capteurs à vos domaines Active Directory, vous devez configurer des comptes de service d’annuaire dans Microsoft 365 Defender.

    1. Dans Microsoft 365 Defender, accédez à Paramètres, puis Identités.

      Accédez à Paramètres, puis Identités.

    2. Sélectionnez comptes de service d’annuaire. Vous verrez quels comptes sont associés aux domaines.

      Comptes de service d’annuaire.

    3. Si vous sélectionnez un compte, un volet s’ouvre avec les paramètres de ce compte.

      Paramètres du compte.

    4. Pour ajouter les informations d’identification du compte de service d’annuaire, sélectionnez Ajouter des informations d’identification et renseignez le nom du compte, le domaine et le mot de passe du compte que vous avez créé précédemment. Vous pouvez également choisir s’il s’agit d’un compte de service administré de groupe (gMSA) et s’il appartient à un domaine d’étiquette unique.

      Ajoutez des informations d’identification.

      Champ Commentaires
      Nom du compte (obligatoire) Saisissez le nom d'utilisateur AD en lecture seule. Par exemple : DefenderForIdentityUser. Vous devez utiliser un compte d’utilisateur ou gMSA AD standard. N’utilisez pas le format UPN pour votre nom d’utilisateur. Quand vous utilisez un gMSA, la chaîne utilisateur doit se terminer par le symbole « $ », par exemple « mdisvc$ ».
      REMARQUE : Nous vous recommandons d’éviter d’utiliser des comptes attribués à des utilisateurs spécifiques.
      Mot de passe (requis pour les comptes d’utilisateur AD standard) Pour les comptes d’utilisateur AD uniquement, entrez le mot de passe de l’utilisateur en lecture seule. Par exemple : Pencil1.
      Compte de service géré de groupe (requis pour les comptes gMSA) Pour les comptes gMSA uniquement, sélectionnez Compte de service administré de groupe.
      Domaine (obligatoire) Entrez le domaine de l’utilisateur en lecture seule. Par exemple : contoso.com. Il est important d’entrer le nom de domaine complet où se trouve l’utilisateur. Par exemple, si le compte de l’utilisateur se trouve dans le domaine corp.contoso.com, vous devez entrer corp.contoso.com pas contoso.com. Pour plus d’informations sur les domaines à étiquette unique, consultez prise en charge par Microsoft pour les domaines à étiquette unique.
    5. Sélectionnez Enregistrer.

    Notes

    Vous pouvez utiliser cette même procédure pour modifier le mot de passe des comptes d’utilisateur Active Directory standard. Aucun mot de passe n’est défini pour les comptes gMSA.

    Dépannage

    Étapes suivantes