Partage via

Comptes de service d’annuaire pour Microsoft Defender pour Identity

  • Article

Cet article explique comment Microsoft Defender pour Identity utilise des comptes de service d’annuaire (DSA).

Remarque

Quels que soient les comptes de service d’annuaire configurés, le service de capteur fonctionne sous l’identité LocalService et le service de mise à jour fonctionne sous l’identité LocalSystem.

Bien qu’un DSA soit facultatif dans certains scénarios, nous vous recommandons de configurer un DSA pour Defender pour Identity pour une couverture de sécurité complète.

Par exemple, lorsque vous configurez un DSA, celui-ci est utilisé pour se connecter au contrôleur de domaine au démarrage. Un DSA peut également être utilisé pour interroger le contrôleur de domaine pour obtenir des données sur les entités vues dans le trafic réseau, les événements surveillés et les activités ETW surveillées

Un DSA est requis pour les fonctionnalités et fonctionnalités suivantes :

  • Lors de l’utilisation d’un capteur installé sur un serveur AD FS / AD CS.

  • Demande de listes de membres pour les groupes d’administrateurs locaux à partir d’appareils vus dans le trafic réseau, les événements et les activités ETW via un appel SAM-R effectué à l’appareil. Les données collectées sont utilisées pour calculer les chemins de mouvement latéral potentiels.

  • Accès au conteneur DeletedObjects pour collecter des informations sur les utilisateurs et les ordinateurs supprimés.

  • Mappage de domaine et d’approbation, qui se produit au démarrage du capteur, et à nouveau toutes les 10 minutes.

  • L’interrogation d’un autre domaine via LDAP pour plus d’informations, lors de la détection d’activités à partir d’entités dans ces autres domaines.

Lorsque vous utilisez un seul DSA, celui-ci doit avoir des permissions 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.

Dans chaque domaine, un capteur est désigné comme synchroniseur de domaine et est chargé de suivre les modifications des entités du domaine. Par exemple, les modifications peuvent inclure la création d'objets, le suivi des attributs des entités par Defender pour l'identité, etc.

Remarque

Par défaut, Defender pour Identity prend en charge jusqu’à 30 identifiants. Pour ajouter d’autres informations d’identification, contactez le support Defender pour Identity.

Options de compte DSA prises en charge

Defender pour Identity prend en charge les options DSA suivantes :

Option Description Configuration
Compte de service administré de groupe gMSA (recommandé) Fournit un déploiement et une gestion des mots de passe plus sécurisés. Active Directory gère la création et la rotation du mot de passe du compte, tout comme le mot de passe d’un compte d’ordinateur, et vous pouvez contrôler la fréquence à laquelle le mot de passe du compte est modifié. Pour plus d’informations, consultez Configurer un compte de service d’annuaire pour Defender pour Identity avec un compte gMSA.
Compte d’utilisateur standard Facile à utiliser au début, et plus simple à configurer les permissions de lecture entre forêts de confiance, mais nécessite une gestion supplémentaire des mots de passe.

Un compte d’utilisateur standard est moins sécurisé, car il vous oblige à créer et gérer des mots de passe et peut entraîner un temps d’arrêt si le mot de passe expire et n’est pas mis à jour pour l’utilisateur et l’ASA.		 Créez un nouveau compte dans Active Directory à utiliser comme DSA avec des permissions de lecture pour tous les objets, y compris les permissions pour le conteneur DeletedObjects. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Octroi des autorisations DSA requises.
Compte de service local Le compte de service local est utilisé par défaut lorsqu'aucun DSA n'est configuré.
Remarque :
  • Les requêtes SAM-R pour des chemins potentiels de mouvement latéral ne sont pas prises en charge dans ce scénario.
  • Les requêtes LDAP ne sont possibles que dans le domaine où le capteur est installé. Les requêtes vers d'autres domaines de la même forêt ou inter-forêts échoueront.
    		•  Aucune

    Remarque

    Bien que le compte de service local soit utilisé par défaut avec le capteur et qu'une DSA soit facultative dans certains scénarios, nous vous recommandons de configurer une DSA pour Defender pour Identity afin d'obtenir une couverture de sécurité complète.

    Utilisation de l’entrée DSA

    Cette section décrit comment les entrées DSA sont utilisées et comment le capteur sélectionne une entrée DSA dans un scénario donné. Les tentatives de capteur diffèrent selon le type d’entrée DSA :

    Type Description
    Compte gMSA Le capteur tente de récupérer le mot de passe du compte gMSA depuis Active Directory, puis se connecte au domaine.
    Compte d’utilisateur standard Le capteur tente de se connecter au domaine à l’aide du nom d’utilisateur et du mot de passe configurés.

    La logique suivante est appliquée :

    1. Le capteur recherche une entrée avec une correspondance exacte du nom de domaine pour le 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.

    2. S’il n’existe pas de correspondance exacte ou si l’authentification a échoué, le capteur recherche dans la liste une entrée dans le domaine parent à l’aide du nom de domaine complet DNS et tente de s’authentifier à l’aide des informations d’identification dans l’entrée parente à la place.

    3. S'il n'y a pas d'entrée pour le domaine parent, ou si l'authentification échoue, le capteur recherche une entrée de domaine frère en utilisant le FQDN DNS, et tente de s'authentifier avec les identifiants de cette entrée.

    4. S’il n’existe pas d’entrée pour le domaine frère ou si l’authentification a échoué, le capteur révise la liste et tente de s’authentifier à nouveau avec chaque entrée jusqu’à ce qu’elle réussisse. Les entrées GMSA DSA ont une priorité plus élevée que les entrées DSA normales.

    Exemple de logique avec un DSA

    Cette section fournit un exemple de la façon dont le capteur tente l’intégralité de la DSA lorsque vous avez plusieurs comptes, y compris un compte gMSA et un compte normal.

    La logique suivante est appliquée :

    1. Le capteur recherche une correspondance entre le nom de domaine DNS du domaine cible, tel que emea.contoso.com et l’entrée GMSA DSA, par exemple emea.contoso.com.

    2. Le capteur recherche une correspondance entre le nom de domaine DNS du domaine cible, tel que emea.contoso.com et l’entrée DSA régulière, par exemple emea.contoso.com.

    3. Le capteur recherche une correspondance dans le nom DNS racine du domaine cible, tel que emea.contoso.com et l’entrée du nom de domaine GMSA DSA, par exemple contoso.com.

    4. Le capteur recherche une correspondance dans le nom DNS racine du domaine cible, tel que emea.contoso.com et l’entrée du nom de domaine DSA régulière, par exemple contoso.com.

    5. Le capteur recherche le nom de domaine cible pour un domaine frère, tel que emea.contoso.com et l’entrée du nom de domaine GMSA DSA, par exemple apac.contoso.com.

    6. Le capteur recherche le nom de domaine cible pour un domaine frère, tel que emea.contoso.com et l’entrée du nom de domaine DSA régulier, par exemple apac.contoso.com.

    7. Le capteur exécute un tourniquet de toutes les entrées GMSA DSA.

    8. Le capteur exécute un tourniquet de toutes les entrées régulières DSA.

    La logique montrée dans cet exemple est implémentée avec la configuration suivante :

    • Entrées DSA :

      • DSA1.emea.contoso.com
      • DSA2.fabrikam.com

    • Capteurs et entrée DSA utilisée en premier :

      Nom de domaine complet du contrôleur de domaine Entrée DSA utilisée
      DC01.emea.contoso.com DSA1.emea.contoso.com
      DC02.contoso.com DSA1.emea.contoso.com
      DC03.fabrikam.com DSA2.fabrikam.com
      DC04.contoso.local Tourniquet (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, le capteur n’entre pas dans un état d’exécution et un problème d’intégrité est généré. Pour plus d’informations, consultez Problèmes d’intégrité de Microsoft Defender pour Identity.

    Accorder des autorisations DSA requises

    Le DSA nécessite des autorisations en lecture seule 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 pour Identity de détecter les suppressions d’utilisateurs dans votre annuaire Active Directory.

    Utilisez l’exemple de code suivant pour vous aider à accorder les autorisations de lecture requises sur le conteneur Objets supprimés, que vous utilisiez ou non un compte gMSA.

    Conseil

    Si le DSA auquel vous souhaitez accorder les autorisations est un compte de service administré de groupe (gMSA), vous devez d’abord créer un groupe de sécurité, ajouter le compte gMSA en tant que membre et ajouter les autorisations à ce groupe. Pour plus d’informations, consultez Configurer un compte de service d’annuaire pour Defender pour Identity avec un compte gMSA.

    # Declare the identity that you want to add read access to the deleted objects container:
$Identity = 'mdiSvc01'

# If the identity is a gMSA, first to create a group and add the gMSA to it:
$groupName = 'mdiUsr01Group'
$groupDescription = 'Members of this group are allowed to read the objects in the Deleted Objects container in AD'
if(Get-ADServiceAccount -Identity $Identity -ErrorAction SilentlyContinue) {
    $groupParams = @{
        Name           = $groupName
        SamAccountName = $groupName
        DisplayName    = $groupName
        GroupCategory  = 'Security'
        GroupScope     = 'Universal'
        Description    = $groupDescription
    }
    $group = New-ADGroup @groupParams -PassThru
    Add-ADGroupMember -Identity $group -Members ('{0}$' -f $Identity)
    $Identity = $group.Name
}

# 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', ('{0}\{1}:LCRP' -f ([adsi]'').name.Value, $Identity))
C:\Windows\System32\dsacls.exe $params
  
# To remove the permissions, uncomment the next 2 lines and run them instead of the two prior ones:
# $params = @("$deletedObjectsDN", '/R', ('{0}\{1}' -f ([adsi]'').name.Value, $Identity))
# C:\Windows\System32\dsacls.exe $params

    Pour plus d’informations, consultez Modification des autorisations sur un conteneur d’objets supprimés.

    Tester vos autorisations et délégations DSA via PowerShell

    Utilisez la commande PowerShell suivante pour vérifier que votre DSA n'a pas trop de permissions, comme des permissions d'administrateur puissantes :

    Test-MDIDSA [-Identity] <String> [-Detailed] [<CommonParameters>]

    Par exemple, pour vérifier les permissions du compte mdiSvc01 et obtenir tous les détails, exécutez :

    Test-MDIDSA -Identity "mdiSvc01" -Detailed

    Pour plus d'informations, consultez la référence PowerShell de DefenderForIdentity.

    Étape suivante

    Configurer un compte de service d’annuaire pour Defender pour Identity avec un gMSA »