Del via

Katalogtjenestekonti for Microsoft Defender for Identity

  • Artikel

I denne artikel beskrives det, hvordan Microsoft Defender for Identity bruger DSA'er (Directory Service Accounts).

Bemærk!

Uanset hvilke katalogtjenestekonti der er konfigureret, vil sensortjenesten fungere under LocalService-identiteten, og opdateringstjenesten fungerer under LocalSystem-identiteten.

Selvom en DSA er valgfri i nogle scenarier, anbefaler vi, at du konfigurerer en DSA for Defender for Identity til fuld sikkerhedsdækning.

Når du f.eks. har konfigureret en DSA, bruges DSA til at oprette forbindelse til domænecontrolleren ved start. En DSA kan også bruges til at forespørge domænecontrolleren om data på enheder, der ses i netværkstrafik, overvågede hændelser og overvågede ETW-aktiviteter

Der kræves en DSA til følgende funktioner og funktioner:

  • Når du arbejder med en sensor, der er installeret på en AD FS/AD CS-server.

  • Anmoder om medlemslister for lokale administratorgrupper fra enheder, der ses i netværkstrafik, hændelser og ETW-aktiviteter via et SAM-R-opkald , der foretages til enheden. Indsamlede data bruges til at beregne potentielle tværgående bevægelsesstier.

  • Adgang til objektbeholderen DeletedObjects for at indsamle oplysninger om slettede brugere og computere.

  • Domæne- og tillidstilknytning, som forekommer ved sensorstart og igen hvert 10. minut.

  • Hvis du forespørger på et andet domæne via LDAP for at få flere oplysninger, når du registrerer aktiviteter fra objekter i disse andre domæner.

Når du bruger en enkelt DSA, skal DSA have læserettigheder til alle domænerne i skovene. I et miljø med flere områder, der ikke er tillid til, kræves der en DSA-konto for hver skov.

Én sensor i hvert domæne er defineret som domænesynkronfunktionen og er ansvarlig for at spore ændringer af enhederne i domænet. Ændringer kan f.eks. omfatte objekter, der er oprettet, enhedsattributter, der spores af Defender for Identity osv.

Bemærk!

Som standard understøtter Defender for Identity op til 30 legitimationsoplysninger. Hvis du vil tilføje flere legitimationsoplysninger, skal du kontakte support til Defender for Identity.

Understøttede DSA-kontoindstillinger

Defender for Identity understøtter følgende DSA-indstillinger:

Valgmulighed Beskrivelse Konfiguration
GMSA til gruppeadministrerede tjenestekonti (anbefales) Giver en mere sikker installation og administration af adgangskoder. Active Directory administrerer oprettelsen og rotationen af kontoens adgangskode på samme måde som en computerkontos adgangskode, og du kan styre, hvor ofte kontoens adgangskode ændres. Du kan få flere oplysninger under Konfigurer en katalogtjenestekonto for Defender for Identity med en gMSA.
Almindelig brugerkonto Let at bruge, når du kommer i gang, og nemmere at konfigurere Læse-tilladelser mellem skove, der er tillid til, men kræver ekstra udgifter til administration af adgangskoder.

En almindelig brugerkonto er mindre sikker, da det kræver, at du opretter og administrerer adgangskoder, og det kan føre til nedetid, hvis adgangskoden udløber og ikke opdateres for både brugeren og DSA.		 Opret en ny konto i Active Directory, der skal bruges som DSA med læserettigheder til alle objekterne, herunder tilladelser til objektbeholderen DeletedObjects . Du kan få flere oplysninger under Tildel påkrævede DSA-tilladelser.
Lokal tjenestekonto Den lokale tjenestekonto bruges som standard, når der ikke er konfigureret en DSA.
Seddel:
  • SAM-R-forespørgsler for potentielle tværgående bevægelsesstier understøttes ikke i dette scenarie.
  • LDAP-forespørgsler er kun inden for det domæne, som sensoren er installeret på. Forespørgsler til andre domæner i den samme skov eller på tværs af områder mislykkes.
    		•  Ingen

    Bemærk!

    Selvom den lokale tjenestekonto bruges sammen med sensoren som standard, og en DSA er valgfri i nogle scenarier, anbefaler vi, at du konfigurerer en DSA for Defender for Identity til fuld sikkerhedsdækning.

    Brug af DSA-post

    I dette afsnit beskrives det, hvordan DSA-poster bruges, og hvordan sensoren vælger en DSA-post i et givet scenarie. Sensorforsøg varierer, afhængigt af typen af DSA-post:

    Type Beskrivelse
    gMSA-konto Sensoren forsøger at hente adgangskoden til gMSA-kontoen fra Active Directory og logger derefter på domænet.
    Almindelig brugerkonto Sensoren forsøger at logge på domænet ved hjælp af det konfigurerede brugernavn og den konfigurerede adgangskode.

    Følgende logik anvendes:

    1. Sensoren søger efter en post med et nøjagtigt match af domænenavnet for destinationsdomænet. Hvis der findes et nøjagtigt match, forsøger sensoren at godkende ved hjælp af legitimationsoplysningerne i den pågældende post.

    2. Hvis der ikke er et nøjagtigt match, eller hvis godkendelsen mislykkedes, søger sensoren på listen efter en post til det overordnede domæne ved hjælp af DNS FQDN og forsøger at godkende ved hjælp af legitimationsoplysningerne i den overordnede post i stedet.

    3. Hvis der ikke er en post for det overordnede domæne, eller hvis godkendelsen mislykkedes, søger sensoren på listen efter en sidestillet domænepost ved hjælp af DNS FQDN og forsøger at godkende ved hjælp af legitimationsoplysningerne i den sidestillede post i stedet.

    4. Hvis der ikke er en post for det sidestillede domæne, eller hvis godkendelsen mislykkedes, gennemser sensoren listen igen og forsøger at godkende hver post igen, indtil det lykkes. DSA gMSA-poster har højere prioritet end almindelige DSA-poster.

    Eksempellogik med en DSA

    Dette afsnit indeholder et eksempel på, hvordan sensoren forsøger hele DSA, når du har flere konti, herunder både en gMSA-konto og en almindelig konto.

    Følgende logik anvendes:

    1. Sensoren søger efter et match mellem destinationsdomænets DNS-domænenavn, f.eks emea.contoso.com . og DSA gMSA-posten, f.eks emea.contoso.com. .

    2. Sensoren søger efter et match mellem destinationsdomænets DNS-domænenavn, f.eks emea.contoso.com . og DSA's almindelige post-DSA, f.eks. emea.contoso.com

    3. Sensoren søger efter et match i destinationsdomænets rod-DNS-navn, f.eks emea.contoso.com . og domænenavnet for DSA gMSA-posten, f.eks contoso.com. .

    4. Sensoren søger efter et match i destinationsdomænets rod-DNS-navn, f.eks emea.contoso.com . og det almindelige DSA-postdomænenavn, f.eks contoso.com. .

    5. Sensoren søger efter destinationsdomænenavnet for et sidestillet domæne, f.eks emea.contoso.com . og DSA gMSA-postens domænenavn, f.eks apac.contoso.com. .

    6. Sensoren søger efter destinationsdomænenavnet for et sidestillet domæne, f.eks emea.contoso.com . og det almindelige DSA-postdomænenavn, f.eks apac.contoso.com. .

    7. Sensoren kører en round robin af alle DSA gMSA-poster.

    8. Sensoren kører en round robin af alle DSA almindelige poster.

    Den logik, der vises i dette eksempel, implementeres med følgende konfiguration:

    • DSA-poster:

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

    • Sensorer og DSA-posten, der bruges først:

      FQDN for domænecontroller DSA-post er brugt
      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

    Vigtigt!

    Hvis en sensor ikke kan godkende via LDAP til Active Directory-domænet ved start, vil sensoren ikke gå ind i en kørende tilstand, og der genereres et tilstandsproblem. Du kan få flere oplysninger under Problemer med identitetstilstand.

    Tildel påkrævede DSA-tilladelser

    DSA kræver skrivebeskyttede tilladelser til alle objekter i Active Directory, herunder objektbeholderen Slettet objektbeholder.

    De skrivebeskyttede tilladelser til objektbeholderen Slettede objekter gør det muligt for Defender for Identity at registrere brugersletninger fra dit Active Directory.

    Brug følgende kodeeksempel til at hjælpe dig med at tildele de påkrævede læsetilladelser til objektbeholderen Slettede objekter , uanset om du bruger en gMSA-konto eller ej.

    Tip

    Hvis den DSA, du vil tildele tilladelserne til, er en gMSA (Group Managed Service Account), skal du først oprette en sikkerhedsgruppe, tilføje gMSA som medlem og føje tilladelserne til den pågældende gruppe. Du kan få flere oplysninger under Konfigurer en katalogtjenestekonto for Defender for Identity 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

    Du kan få flere oplysninger under Ændring af tilladelser for en objektbeholder til sletning.

    Test dine DSA-tilladelser og -delegationer via PowerShell

    Brug følgende PowerShell-kommando til at bekræfte, at din DSA ikke har for mange tilladelser, f.eks. effektive administratortilladelser:

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

    Hvis du f.eks. vil kontrollere tilladelserne for mdiSvc01-kontoen og angive fuldstændige oplysninger, skal du køre:

    Test-MDIDSA -Identity "mdiSvc01" -Detailed

    Du kan få flere oplysninger i PowerShell-referencen til DefenderForIdentity.

    Næste trin

    Konfigurer en katalogtjenestekonto for Defender for Identity med en gMSA »