Comptes de service d’annuaire pour Microsoft Defender pour Identity

Cet article décrit comment Microsoft Defender pour Identity utilise les 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é 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 supervisées

Un DSA est requis pour les fonctionnalités suivantes :

• Lorsque vous travaillez avec 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é sur 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.

• 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 disposer d’autorisations de lecture sur tous les domaines dans les forêts. Dans un environnement multi-forêts non approuvé, un compte DSA est requis pour chaque forêt.

Un capteur dans chaque domaine est défini en tant que synchronisateur de domaine et est responsable du suivi des modifications apportées aux entités dans le domaine. Par exemple, les modifications peuvent inclure des objets créés, des attributs d’entité suivis par Defender pour Identity, etc.

Options de compte DSA prises en charge

Defender pour Identity prend en charge les options DSA suivantes :

Utilisation des entrées 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 :

La logique suivante est appliquée :

1. 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 dans cette entrée.

2. S’il n’y a 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 de l’entrée frère à la place.

4. S’il n’y a 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’ADS lorsque vous avez plusieurs comptes, y compris un compte gMSA et un compte standard.

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, telle que 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’application DSA d’entrée régulière DSA, comme emea.contoso.com

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

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

5. Le capteur recherche le nom de domaine cible d’un domaine frère, tel que emea.contoso.com et le nom de domaine d’entrée gMSA DSA, tel que apac.contoso.com.

6. Le capteur recherche le nom de domaine cible d’un domaine frère, tel que emea.contoso.com et le nom de domaine d’entrée régulière DSA, tel que 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 indiqué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)

Accorder les autorisations DSA requises

L’application 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 de 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.

# 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 ne dispose pas d’un trop grand nombre d’autorisations, telles que des 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