Katalogtjänstkonton för Microsoft Defender för identitet

  • Artikel

I den här artikeln beskrivs hur Microsoft Defender för identitet använder katalogtjänstkonton (DSA).

Även om en DSA är valfri i vissa scenarier rekommenderar vi att du konfigurerar en DSA för Defender för identitet för fullständig säkerhetstäckning.

När du till exempel har konfigurerat en DSA används DSA för att ansluta till domänkontrollanten vid start. En DSA kan också användas för att fråga domänkontrollanten efter data om entiteter som visas i nätverkstrafik, övervakade händelser och övervakade ETW-aktiviteter

En DSA krävs för följande funktioner:

  • När du arbetar med en sensor installerad på en AD FS/AD CS-server.

  • Begära medlemslistor för lokala administratörsgrupper från enheter som visas i nätverkstrafik, händelser och ETW-aktiviteter via ett SAM-R-anrop som görs till enheten. Insamlade data används för att beräkna potentiella laterala förflyttningsvägar.

  • Åtkomst till containern DeletedObjects för att samla in information om borttagna användare och datorer.

  • Domän- och förtroendemappning, som sker vid sensorstart, och igen var 10:e minut.

  • Fråga en annan domän via LDAP för mer information när du identifierar aktiviteter från entiteter i dessa andra domäner.

När du använder en enda DSA måste DSA ha läsbehörighet till alla domäner i skogarna. I en obetrodd miljö med flera skogar krävs ett DSA-konto för varje skog.

En sensor i varje domän definieras som domänsynkronisering och ansvarar för att spåra ändringar i entiteterna i domänen. Ändringar kan till exempel omfatta objekt som skapats, entitetsattribut som spåras av Defender för identitet och så vidare.

Kommentar

Defender for Identity stöder som standard upp till 30 autentiseringsuppgifter. Om du vill lägga till fler autentiseringsuppgifter kontaktar du Defender för identitetssupport.

DSA-kontoalternativ som stöds

Defender for Identity stöder följande DSA-alternativ:

Alternativ Description Konfiguration
Grupphanterat tjänstkonto gMSA (rekommenderas) Ger en säkrare distribution och lösenordshantering. Active Directory hanterar skapandet och rotationen av kontots lösenord, precis som ett datorkontos lösenord, och du kan styra hur ofta kontots lösenord ändras. Mer information finns i Konfigurera ett katalogtjänstkonto för Defender för identitet med en gMSA.
Vanligt användarkonto Lätt att använda när du kommer igång och enklare att konfigurera läsbehörigheter mellan betrodda skogar, men kräver extra omkostnader för lösenordshantering.

Ett vanligt användarkonto är mindre säkert eftersom du måste skapa och hantera lösenord och kan leda till stilleståndstid om lösenordet upphör att gälla och inte uppdateras för både användaren och DSA.		 Skapa ett nytt konto i Active Directory som ska användas som DSA med läsbehörighet för alla objekt, inklusive behörigheter till containern DeletedObjects . Mer information finns i Bevilja nödvändiga DSA-behörigheter.

DSA-postanvändning

I det här avsnittet beskrivs hur DSA-poster används och hur sensorn väljer en DSA-post i ett visst scenario. Sensorförsök skiljer sig åt beroende på typ av DSA-post:

Typ Beskrivning
gMSA-konto Sensorn försöker hämta gMSA-kontolösenordet från Active Directory och loggar sedan in på domänen.
Vanligt användarkonto Sensorn försöker logga in på domänen med det konfigurerade användarnamnet och lösenordet.

Följande logik tillämpas:

  1. Sensorn söker efter en post med en exakt matchning av domännamnet för måldomänen. Om en exakt matchning hittas försöker sensorn autentisera med autentiseringsuppgifterna i den posten.

  2. Om det inte finns någon exakt matchning, eller om autentiseringen misslyckades, söker sensorn i listan efter en post till den överordnade domänen med DNS FQDN och försöker autentisera med autentiseringsuppgifterna i den överordnade posten i stället.

  3. Om det inte finns någon post för den överordnade domänen, eller om autentiseringen misslyckades, söker sensorn i listan efter en domänpost på samma nivå med hjälp av DNS FQDN och försöker autentisera med autentiseringsuppgifterna i syskonposten i stället.

  4. Om det inte finns någon post för syskondomänen, eller om autentiseringen misslyckades, granskar sensorn listan igen och försöker autentisera igen med varje post tills den lyckas. DSA gMSA-poster har högre prioritet än vanliga DSA-poster.

Exempellogik med en DSA

Det här avsnittet innehåller ett exempel på hur sensorn försöker hela DSA när du har flera konton, inklusive både ett gMSA-konto och ett vanligt konto.

Följande logik tillämpas:

  1. Sensorn letar efter en matchning mellan DNS-domännamnet för måldomänen, till exempel emea.contoso.com och DSA gMSA-posten, till exempel emea.contoso.com.

  2. Sensorn söker efter en matchning mellan DNS-domännamnet för måldomänen, till exempel emea.contoso.com och DSA:s vanliga post-DSA, till exempel emea.contoso.com

  3. Sensorn letar efter en matchning i måldomänens rot-DNS-namn, till exempel emea.contoso.com och DSA gMSA-postdomännamnet, till exempel contoso.com.

  4. Sensorn söker efter en matchning i måldomänens rot-DNS-namn, till exempel emea.contoso.com och DSA-domännamnet för vanlig post, till exempel contoso.com.

  5. Sensorn söker efter måldomännamnet för en syskondomän, till exempel emea.contoso.com och DSA gMSA-postdomännamnet, till exempel apac.contoso.com.

  6. Sensorn söker efter måldomännamnet för en syskondomän, till exempel emea.contoso.com och DSA-domännamnet för vanlig post, till exempel apac.contoso.com.

  7. Sensorn kör en resursallokering av alla DSA gMSA-poster.

  8. Sensorn kör en resursallokering av alla vanliga DSA-poster.

Logiken som visas i det här exemplet implementeras med följande konfiguration:

  • DSA-poster:

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

  • Sensorer och DSA-posten som används först:

    FQDN för domänkontrollant DSA-post används
    DC01.emea.contoso.com DSA1.emea.contoso.com
    DC02.contoso.com DSA1.emea.contoso.com
    DC03.fabrikam.com DSA2.fabrikam.com
    DC04.contoso.local Resursallokering

Viktigt!

Om en sensor inte kan autentiseras via LDAP till Active Directory-domänen vid start går sensorn inte in i ett tillstånd som körs och ett hälsoproblem genereras. Mer information finns i Problem med hälsotillståndet för Defender för identiteter.

Bevilja nödvändiga DSA-behörigheter

DSA kräver skrivskyddade behörigheter för alla objekt i Active Directory, inklusive containern Borttagna objekt.

Med skrivskyddade behörigheter i containern Borttagna objekt kan Defender for Identity identifiera användarborttagningar från Active Directory.

Använd följande kodexempel för att ge nödvändiga läsbehörigheter för containern Borttagna objekt , oavsett om du använder ett gMSA-konto eller inte.

Dricks

Om den DSA som du vill bevilja behörigheter till är ett grupphanterat tjänstkonto (gMSA) måste du först skapa en säkerhetsgrupp, lägga till gMSA som medlem och lägga till behörigheterna i gruppen. Mer information finns i Konfigurera ett katalogtjänstkonto för Defender för identitet med en 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

Mer information finns i Ändra behörigheter för en borttagen objektcontainer.

Testa dina DSA-behörigheter och delegeringar via PowerShell

Använd följande PowerShell-kommando för att kontrollera att din DSA inte har för många behörigheter, till exempel kraftfulla administratörsbehörigheter:

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

Om du till exempel vill kontrollera behörigheter för mdiSvc01-kontot och ange fullständig information kör du:

Test-MDIDSA -Identity "mdiSvc01" -Detailed

Mer information finns i PowerShell-referensen för DefenderForIdentity.

Gå vidare

Konfigurera ett katalogtjänstkonto för Defender för identitet med en gMSA »