Del via

Katalogtjenestekontoer for Microsoft Defender for identitet

  • Artikkel

Denne artikkelen beskriver hvordan Microsoft Defender for identitet bruker DSAer (Directory Service Accounts).

Obs!

Uavhengig av hvilke katalogtjenestekontoer som er konfigurert, vil sensortjenesten operere under LocalService-identiteten, og oppdateringstjenesten vil fungere under LocalSystem-identiteten.

Selv om en DSA er valgfri i enkelte scenarioer, anbefaler vi at du konfigurerer en DSA for Defender for Identity for full sikkerhetsdekning.

Når du for eksempel har konfigurert en DSA, brukes DSA til å koble til domenekontrolleren ved oppstart. En DSA kan også brukes til å spørre domenekontrolleren etter data om enheter sett i nettverkstrafikk, overvåkede hendelser og overvåkede ETW-aktiviteter

En DSA kreves for følgende funksjoner og funksjonalitet:

  • Når du arbeider med en sensor installert på en AD FS / AD CS-server.

  • Ber om medlemslister for lokale administratorgrupper fra enheter sett i nettverkstrafikk, hendelser og ETW-aktiviteter via et SAM-R-anrop som er gjort på enheten. Innsamlede data brukes til å beregne potensielle laterale bevegelsesbaner.

  • Få tilgang til DeletedObjects-beholderen for å samle inn informasjon om slettede brukere og datamaskiner.

  • Domene- og klareringstilordning, som skjer ved oppstart av sensor, og igjen hvert 10. minutt.

  • Spør et annet domene via LDAP for detaljer når du oppdager aktiviteter fra enheter i de andre domenene.

Når du bruker én enkelt DSA, må DSA ha lesetillatelser for alle domenene i skogene. I et ikke-klarert miljø med flere skoger kreves en DSA-konto for hver skog.

Én sensor i hvert domene er definert som domenesynkronisering, og er ansvarlig for å spore endringer i enhetene i domenet. Endringer kan for eksempel omfatte objekter som er opprettet, enhetsattributter som spores av Defender for Identity og så videre.

Obs!

Defender for Identity støtter som standard opptil 30 legitimasjoner. Hvis du vil legge til mer legitimasjon, kontakter du Defender for identitetsstøtte.

Støttede DSA-kontoalternativer

Defender for Identity støtter følgende DSA-alternativer:

Alternativ Beskrivelse Konfigurasjon
GMSA for gruppeadministrert tjenestekonto (anbefales) Gir en sikrere distribusjon og passordbehandling. Active Directory administrerer oppretting og rotasjon av kontoens passord, akkurat som passordet til en datamaskinkonto, og du kan kontrollere hvor ofte passordet for kontoen endres. Hvis du vil ha mer informasjon, kan du se Konfigurere en katalogtjenestekonto for Defender for identitet med en gMSA.
Vanlig brukerkonto Enkel å bruke når du kommer i gang, og enklere å konfigurere lesetillatelser mellom klarerte skoger, men krever ekstra kostnader for passordbehandling.

En vanlig brukerkonto er mindre sikker, fordi den krever at du oppretter og administrerer passord, og kan føre til nedetid hvis passordet utløper og ikke oppdateres for både brukeren og DSA.		 Opprett en ny konto i Active Directory som skal brukes som DSA med lesetillatelser for alle objektene, inkludert tillatelser til DeletedObjects-beholderen . Hvis du vil ha mer informasjon, kan du se Gi nødvendige DSA-tillatelser.
Lokal tjenestekonto Den lokale tjenestekontoen brukes utenfor boksen og brukes som standard når det ikke er konfigurert DSA.
Notat:
  • SAM-R-spørringer for potensielle laterale bevegelsesbaner som ikke støttes i dette scenarioet.
  • LDAP-spørringer bare innenfor domenet sensoren er installert. Spørringer til andre domener i samme skog eller kryssskog vil mislykkes.
    		•  Ingen

    Obs!

    Selv om den lokale tjenestekontoen brukes med sensoren som standard, og en DSA er valgfri i enkelte scenarioer, anbefaler vi at du konfigurerer en DSA for Defender for identitet for full sikkerhetsdekning.

    Bruk av DSA-oppføring

    Denne delen beskriver hvordan DSA-oppføringer brukes, og hvordan sensoren velger en DSA-oppføring i et gitt scenario. Sensorforsøkene varierer avhengig av typen DSA-oppføring:

    Type: Beskrivelse
    gMSA-konto Sensoren prøver å hente gMSA-kontopassordet fra Active Directory, og logger deretter på domenet.
    Vanlig brukerkonto Sensoren prøver å logge på domenet ved hjelp av det konfigurerte brukernavnet og passordet.

    Følgende logikk brukes:

    1. Sensoren ser etter en oppføring med et nøyaktig samsvar med domenenavnet for måldomenet. Hvis det blir funnet et nøyaktig treff, forsøker sensoren å godkjenne ved hjelp av legitimasjonen i den oppføringen.

    2. Hvis det ikke finnes et nøyaktig samsvar, eller hvis godkjenningen mislyktes, søker sensoren i listen etter en oppføring til det overordnede domenet ved hjelp av DNS FQDN, og prøver å godkjenne ved hjelp av legitimasjonen i den overordnede oppføringen i stedet.

    3. Hvis det ikke finnes en oppføring for det overordnede domenet, eller hvis godkjenningen mislyktes, søker sensoren i listen etter en sideordnet domeneoppføring ved hjelp av DNS FQDN, og prøver å godkjenne ved hjelp av legitimasjonen i den sideordnede oppføringen i stedet.

    4. Hvis det ikke finnes en oppføring for det likestilte domenet, eller hvis godkjenningen mislyktes, ser sensoren gjennom listen på nytt og prøver å godkjenne på nytt med hver oppføring til den lykkes. DSA gMSA-oppføringer har høyere prioritet enn vanlige DSA-oppføringer.

    Eksempellogikk med en DSA

    Denne delen gir et eksempel på hvordan sensoren prøver DSA-helheten når du har flere kontoer, inkludert både en gMSA-konto og en vanlig konto.

    Følgende logikk brukes:

    1. Sensoren ser etter et samsvar mellom DNS-domenenavnet for måldomenet, for eksempel emea.contoso.com DSA gMSA-oppføringen, for eksempel emea.contoso.com.

    2. Sensoren ser etter et treff mellom DNS-domenenavnet for måldomenet, for eksempel emea.contoso.com DSA-DSA for vanlig oppføring, for eksempel emea.contoso.com

    3. Sensoren ser etter et treff i dns-rotnavnet for måldomenet, for eksempel emea.contoso.com DSA gMSA-oppføringsdomenenavnet, for eksempel contoso.com.

    4. Sensoren ser etter et treff i dns-rotnavnet for måldomenet, for eksempel emea.contoso.com DSA-domenenavnet for vanlig oppføring, for eksempel contoso.com.

    5. Sensoren ser etter måldomenenavnet for et sideordnede domene, for eksempel emea.contoso.com DSA gMSA-oppføringsdomenenavnet, for eksempel apac.contoso.com.

    6. Sensoren ser etter måldomenenavnet for et sideordnede domene, for eksempel emea.contoso.com DSA-domenenavnet for vanlig oppføring, for eksempel apac.contoso.com.

    7. Sensoren kjører en rund robin av alle DSA gMSA oppføringer.

    8. Sensoren kjører en rund robin av alle DSA vanlige oppføringer.

    Logikken som vises i dette eksemplet, implementeres med følgende konfigurasjon:

    • DSA-oppføringer:

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

    • Sensorer og DSA-oppføringen som brukes først:

      FQDN for domenekontroller DSA-oppføring brukt
      DC01.emea.contoso.com DSA1.emea.contoso.com
      DC02.contoso.com DSA1.emea.contoso.com
      DC03.fabrikam.com DSA2.fabrikam.com
      DC04.contoso.local Rund robin

    Viktig

    Hvis en sensor ikke klarer å godkjenne via LDAP til Active Directory-domenet ved oppstart, vil ikke sensoren angi en kjøretilstand, og det genereres et helseproblem. Hvis du vil ha mer informasjon, kan du se Defender for identitetsproblemer.

    Gi nødvendige DSA-tillatelser

    DSA krever skrivebeskyttede tillatelser for alle objektene i Active Directory, inkludert Beholder for slettede objekter.

    Med skrivebeskyttede tillatelser i beholderen Slettede objekter kan Defender for Identity oppdage brukerslettinger fra Active Directory.

    Bruk følgende kodeeksempel for å hjelpe deg med å gi de nødvendige lesetillatelsene i beholderen Slettede objekter , uansett om du bruker en gMSA-konto eller ikke.

    Tips

    Hvis DSA-en du vil gi tillatelsene til, er en gruppeadministrert tjenestekonto (gMSA), må du først opprette en sikkerhetsgruppe, legge til gMSA som medlem og legge til tillatelsene i denne gruppen. Hvis du vil ha mer informasjon, kan du se Konfigurere en katalogtjenestekonto for Defender for 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

    Hvis du vil ha mer informasjon, kan du se Endre tillatelser for en slettet objektbeholder.

    Test DSA-tillatelser og delegeringer via PowerShell

    Bruk følgende PowerShell-kommando til å bekrefte at DSA ikke har for mange tillatelser, for eksempel kraftige administratortillatelser:

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

    Hvis du for eksempel vil kontrollere tillatelser for mdiSvc01-kontoen og oppgi fullstendige detaljer, kjører du:

    Test-MDIDSA -Identity "mdiSvc01" -Detailed

    Hvis du vil ha mer informasjon, kan du se PowerShell-referansen for DefenderForIdentity.

    Neste trinn:

    Konfigurer en katalogtjenestekonto for Defender for identitet med en gMSA »