Share via

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

  • Article

Cet article explique comment créer un compte de service administré de groupe (gMSA) à utiliser comme entrée de compte de service d’annuaire (DSA) Defender pour Identity.

Pour plus d’informations, consultez Comptes de service d’annuaire Microsoft Defender pour Identity.

Conseil

Dans les environnements à plusieurs forêts et domaines, nous vous recommandons de créer les gMSA avec un nom unique pour chaque forêt ou domaine. Créez également un groupe universel dans chaque domaine, contenant tous les comptes d’ordinateur des capteurs afin que tous les capteurs puissent récupérer les mots de passe des gMSA et effectuer les authentifications inter-domaines.

Conditions préalables : accorder 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 gMSA à partir d’Active Directory. Cela peut se faire soit en attribuant un mot de passe à chacun des capteurs, soit en utilisant un groupe.

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

  • Dans une forêt avec plusieurs domaines, lors de l’utilisation d’un seul compte DSA, nous vous recommandons de créer un groupe universel et d’ajouter chacun des contrôleurs de domaine et des serveurs AD FS/AD CS au groupe universel.

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 gMSA tant qu’il ne reçoit pas de nouveau ticket Kerberos. Le ticket Kerberos contient une liste de groupes dont une entité est membre lorsque le ticket est émis.

Dans ces scénarios, effectuez l’une des opérations suivantes :

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

  • Supprimez définitivement les tickets Kerberos existants. Cela force le contrôleur de domaine à demander un nouveau ticket Kerberos.

    Pour supprimer définitivement les tickets, exécutez la commande suivante à partir de l’invite de commandes en tant qu’administrateur sur le contrôleur de domaine : klist purge -li 0x3e7

Créer un compte gMSA

Cette section explique comment 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é.

Mettez à jour le code suivant avec des valeurs de variable pour votre environnement. Puis, exécutez les commandes PowerShell en tant qu’administrateur :

# Variables:
# Specify the name of the gMSA you want to create:
$gMSA_AccountName = 'mdiSvc01'
# Specify the name of the group you want to create for the gMSA,
# or enter 'Domain Controllers' to use the built-in group when your environment is a single forest, and will contain only domain controller sensors.
$gMSA_HostsGroupName = 'mdiSvc01Group'
# Specify the computer accounts that will become members of the gMSA group and have permission to use the gMSA. 
# If you are using the 'Domain Controllers' group in the $gMSA_HostsGroupName variable, then this list is ignored
$gMSA_HostNames = 'DC1', 'DC2', 'DC3', 'DC4', 'DC5', 'DC6', 'ADFS1', 'ADFS2'

# Import the required PowerShell module:
Import-Module ActiveDirectory

# Set the group
if ($gMSA_HostsGroupName -eq 'Domain Controllers') {
    $gMSA_HostsGroup = Get-ADGroup -Identity 'Domain Controllers'
} else {
    $gMSA_HostsGroup = New-ADGroup -Name $gMSA_HostsGroupName -GroupScope DomainLocal -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

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.

Vérifier que le compte gMSA dispose des droits requis

Le service de capteur Defender pour Identity, Azure Advanced Threat Protection Sensor, s’exécute en tant que LocalService et effectue l’usurpation d’identité du compte DSA. L’usurpation d’identité échoue si la stratégie Connexion en tant que service est configurée, mais que l’autorisation n’a pas été accordée au compte gMSA. Dans ce cas, vous verrez le problème d’intégrité suivant : Les informations d’identification d’utilisateur des services d’annuaire sont incorrectes.

Si vous voyez cette alerte, nous vous recommandons de vérifier pour voir si la stratégie Connexion en tant que service est configurée. Si vous devez configurer la stratégie Connexion en tant que service, faites-le dans un paramètre de 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 de l’utilisateur, accédez au paramètre de stratégie Connexion en tant que service. Par exemple :

    Capture d'écran du volet des propriétés Ouvrir une session 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 configuré dans une stratégie de groupe : exécutez rsop.msc et vérifiez si la stratégie Configuration de l’ordinateur -> Paramètres Windows -> Paramètres de sécurité -> Stratégies locales -> Affectation des droits de l’utilisateur -> Se connecter en tant que service est sélectionnée. Par exemple :

    Capture d’écran de la stratégie de connexion en tant que service dans l’éditeur de gestion des stratégies de groupe.

    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 des stratégies de groupe.

Remarque

Si vous utilisez l’éditeur de gestion des stratégies de groupe pour configurer le paramètre Connexion en tant que service, veillez à ajouter NT service\Tous les services et le compte gMSA que vous avez créé.

Configurer un compte de service d’annuaire dans Microsoft Defender XDR

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

  1. Dans Microsoft Defender XDR, accédez à Paramètres > Identités. Par exemple :

    Capture d’écran des paramètres Identités dans Microsoft Defender XDR.

  2. Sélectionnez Comptes de services d’annuaire. Vous verrez quels comptes sont associés à quels domaines. Par exemple :

    Capture d’écran de la page des comptes du service d’annuaire.

  3. Pour ajouter les informations d’identification du compte de service d’annuaire, sélectionnez Ajouter des informations d’identification et entrez le nom de 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 nom de domaine en une seule partie. Par exemple :

    Capture d’écran du volet Ajouter des informations d’identification.

    Champ Commentaires
    Nom de compte (obligatoire) Entrez le nom d’utilisateur AD en lecture seule. Par exemple : DefenderForIdentityUser.

    - Vous devez utiliser un utilisateur AD ou compte gMSA 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’utilisateurs AD standard) Pour les comptes d’utilisateurs AD uniquement, générez un mot de passe fort pour l’utilisateur en lecture seule. Par exemple : PePR!BZ&}Y54UpC3aB.
    Compte de service administré par groupe (obligatoire pour les comptes gMSA) Pour les comptes gMSA uniquement, sélectionnez compte de service administré par groupe.
    Domaines (requis) Saisissez le domaine pour l’utilisateur en lecture seule. Par exemple : contoso.com.

    Il est important que vous saisissez le FQDN complet du domaine où l’utilisateur est localisé. Par exemple, si le compte d’utilisateur se trouve dans le domaine corp.contoso.com, vous devez entrer corp.contoso.com, et non contoso.com.

    Pour plus d’informations, consultez Prise en charge de Microsoft pour les noms de domaine en une seule partie.

  4. Sélectionnez Enregistrer.

  5. (Facultatif) Si vous sélectionnez un compte, un volet d’informations s’ouvre avec les paramètres de ce compte. Par exemple :

    Capture d’écran du volet des détails d’un compte.

Remarque

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

Dépannage

Pour plus d’informations, consultez Le capteur n’a pas pu récupérer les informations d’identification du gMSA.

Étape suivante

Configurer SAM-R pour activer la détection de chemins de mouvement latéral dans Microsoft Defender pour Identity »