Account del servizio directory per Microsoft Defender per identità

Questo articolo descrive come Microsoft Defender per identità usa gli account del servizio directory.This article describe how Microsoft Defender per identità uses Directory Service Accounts (DSA).

Anche se in alcuni scenari un DSA è facoltativo, è consigliabile configurare un DSA per Defender per identità per una copertura di sicurezza completa.

Ad esempio, quando è configurato un DSA, il DSA viene usato per connettersi al controller di dominio all'avvio. Un DSA può essere usato anche per eseguire query sul controller di dominio per i dati sulle entità visualizzate nel traffico di rete, negli eventi monitorati e nelle attività ETW monitorate

È necessario un DSA per le funzionalità e le funzionalità seguenti:

• Quando si usa un sensore installato in un server AD FS/AD CS.

• Richiesta di elenchi di membri per i gruppi di amministratori locali dai dispositivi visualizzati nel traffico di rete, negli eventi e nelle attività ETW tramite una chiamata SAM-R effettuata al dispositivo. I dati raccolti vengono usati per calcolare i potenziali percorsi di spostamento laterale.

• Accesso al contenitore DeletedObjects per raccogliere informazioni su utenti e computer eliminati.

• Mapping di dominio e trust, che si verifica all'avvio del sensore e di nuovo ogni 10 minuti.

• Esecuzione di query su un altro dominio tramite LDAP per informazioni dettagliate, quando si rilevano attività da entità in tali altri domini.

Quando si usa un singolo DSA, il DSA deve disporre delle autorizzazioni di lettura per tutti i domini nelle foreste. In un ambiente multi-foresta non attendibile è necessario un account DSA per ogni foresta.

Un sensore in ogni dominio è definito come sincronizzatore di dominio ed è responsabile del rilevamento delle modifiche apportate alle entità nel dominio. Ad esempio, le modifiche possono includere oggetti creati, attributi di entità rilevati da Defender per identità e così via.

Opzioni dell'account DSA supportate

Defender per identità supporta le opzioni DSA seguenti:

Utilizzo voce DSA

Questa sezione descrive come vengono usate le voci DSA e come il sensore seleziona una voce DSA in uno scenario specifico. I tentativi del sensore variano a seconda del tipo di voce DSA:

Viene applicata la logica seguente:

1. Il sensore cerca una voce con una corrispondenza esatta del nome di dominio per il dominio di destinazione. Se viene trovata una corrispondenza esatta, il sensore tenta di eseguire l'autenticazione usando le credenziali in tale voce.

2. Se non è presente una corrispondenza esatta o se l'autenticazione non è riuscita, il sensore cerca nell'elenco una voce nel dominio padre usando l'FQDN DNS e tenta di eseguire l'autenticazione usando le credenziali nella voce padre.

3. Se non è presente una voce per il dominio padre o se l'autenticazione non è riuscita, il sensore cerca nell'elenco una voce di dominio di pari livello, usando il nome di dominio completo DNS e tenta di eseguire l'autenticazione usando le credenziali nella voce di pari livello.

4. Se non è presente una voce per il dominio di pari livello o se l'autenticazione non è riuscita, il sensore esamina nuovamente l'elenco e tenta di eseguire di nuovo l'autenticazione con ogni voce fino a quando non ha esito positivo. Le voci DSA gMSA hanno una priorità maggiore rispetto alle normali voci DSA.

Logica di esempio con un DSA

Questa sezione fornisce un esempio del modo in cui il sensore tenta l'intero account DSA quando si dispone di più account, inclusi un account gMSA e un account normale.

Viene applicata la logica seguente:

1. Il sensore cerca una corrispondenza tra il nome di dominio DNS del dominio di destinazione, ad emea.contoso.com esempio e la voce GMSA DSA, ad emea.contoso.comesempio .

2. Il sensore cerca una corrispondenza tra il nome di dominio DNS del dominio di destinazione, ad emea.contoso.com esempio e la voce regolare DSA DSA, ad esempio emea.contoso.com

3. Il sensore cerca una corrispondenza nel nome DNS radice del dominio di destinazione, ad emea.contoso.com esempio e nel nome di dominio della voce DSA gMSA, ad contoso.comesempio .

4. Il sensore cerca una corrispondenza nel nome DNS radice del dominio di destinazione, ad emea.contoso.com esempio e nel nome di dominio di immissione regolare DSA, ad contoso.comesempio .

5. Il sensore cerca il nome di dominio di destinazione per un dominio di pari livello, ad emea.contoso.com esempio e il nome di dominio della voce DSA gMSA, ad apac.contoso.comesempio .

6. Il sensore cerca il nome di dominio di destinazione per un dominio di pari livello, ad emea.contoso.com esempio e il nome di dominio della voce regolare DSA, ad apac.contoso.comesempio .

7. Il sensore esegue un round robin di tutte le voci GMSA DSA.

8. Il sensore esegue un round robin di tutte le voci regolari DSA.

La logica illustrata in questo esempio viene implementata con la configurazione seguente:

• Voci DSA:

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

• Sensori e voce DSA usata per prima:

  FQDN del controller di dominio	Voce DSA usata
  DC01.emea.contoso.com	DSA1.emea.contoso.com
  DC02.contoso.com	DSA1.emea.contoso.com
  DC03.fabrikam.com	DSA2.fabrikam.com
  DC04.contoso.local	Round robin

Concedere le autorizzazioni DSA necessarie

La DSA richiede autorizzazioni di sola lettura per tutti gli oggetti in Active Directory, incluso il contenitore Oggetti eliminati.

Le autorizzazioni di sola lettura nel contenitore Oggetti eliminati consentono a Defender for Identity di rilevare le eliminazioni degli utenti da Active Directory.

Usare l'esempio di codice seguente per concedere le autorizzazioni di lettura necessarie per il contenitore Oggetti eliminati , indipendentemente dal fatto che si usi o meno un account 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

Per altre informazioni, vedere Modifica delle autorizzazioni per un contenitore di oggetti eliminati.

Testare le autorizzazioni e le deleghe DSA tramite PowerShell

Usare il comando di PowerShell seguente per verificare che il DSA non disponga di troppe autorizzazioni, ad esempio autorizzazioni di amministratore avanzate:

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

Ad esempio, per controllare le autorizzazioni per l'account mdiSvc01 e fornire dettagli completi, eseguire:

Test-MDIDSA -Identity "mdiSvc01" -Detailed

Per altre informazioni, vedere le informazioni di riferimento su PowerShell DefenderForIdentity.

Passaggio successivo