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).

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 avez configuré une DSA, la DSA est utilisée 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 une seule DSA, la DSA 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.

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. Par exemple, les modifications peuvent inclure des objets créés, des attributs d’entité suivis par Defender pour Identity, et ainsi de suite.

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 lors de la prise en main et plus simple pour configurer les autorisations de lecture entre les forêts approuvées, mais nécessite une surcharge supplémentaire pour la gestion 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 compte dans Active Directory à utiliser comme DSA avec des autorisations de lecture pour tous les objets, y compris les autorisations sur le conteneur DeletedObjects . Si vous souhaitez en savoir plus, veuillez consulter la rubrique Octroi des autorisations DSA requises.

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 à partir d’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 a échoué, le capteur recherche dans la liste une entrée de domaine frère, à l’aide du nom de domaine complet DNS et tente de s’authentifier à l’aide des informations d’identification dans l’entrée frère à la place.

  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 d’autorisations, telles que les autorisations d’administrateur puissantes :

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

Par exemple, pour case activée autorisations pour le compte mdiSvc01 et fournir des détails complets, exécutez :

Test-MDIDSA -Identity "mdiSvc01" -Detailed

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

Étape suivante

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