Comptes de service d’annuaire pour Microsoft Defender pour Identity
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 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 : |
Aucun |
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 :
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.
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.
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.
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 :
Le capteur recherche une correspondance entre le nom de domaine DNS du domaine cible, tel que
emea.contoso.comet l’entrée GMSA DSA, par exempleemea.contoso.com.Le capteur recherche une correspondance entre le nom de domaine DNS du domaine cible, tel que
emea.contoso.comet l’entrée DSA régulière, par exempleemea.contoso.com.Le capteur recherche une correspondance dans le nom DNS racine du domaine cible, tel que
emea.contoso.comet l’entrée du nom de domaine GMSA DSA, par exemplecontoso.com.Le capteur recherche une correspondance dans le nom DNS racine du domaine cible, tel que
emea.contoso.comet l’entrée du nom de domaine DSA régulière, par exemplecontoso.com.Le capteur recherche le nom de domaine cible pour un domaine frère, tel que
emea.contoso.comet l’entrée du nom de domaine GMSA DSA, par exempleapac.contoso.com.Le capteur recherche le nom de domaine cible pour un domaine frère, tel que
emea.contoso.comet l’entrée du nom de domaine DSA régulier, par exempleapac.contoso.com.Le capteur exécute un tourniquet de toutes les entrées GMSA DSA.
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.comDSA2.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.comDSA1.emea.contoso.comDC02.contoso.comDSA1.emea.contoso.comDC03.fabrikam.comDSA2.fabrikam.comDC04.contoso.localTourniquet (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
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour