Delen via

Adreslijstserviceaccounts voor Microsoft Defender for Identity

  • Artikel

In dit artikel wordt beschreven hoe Microsoft Defender for Identity gebruikmaakt van DSA's (Directory Service Accounts).

Notitie

Ongeacht de geconfigureerde directoryserviceaccounts, werkt de sensorservice onder de localservice-identiteit en wordt de updaterservice uitgevoerd onder de LocalSystem-identiteit.

Hoewel een DSA in sommige scenario's optioneel is, raden we u aan om een DSA voor Defender for Identity te configureren voor volledige beveiligingsdekking.

Wanneer u bijvoorbeeld een DSA hebt geconfigureerd, wordt de DSA gebruikt om tijdens het opstarten verbinding te maken met de domeincontroller. Een DSA kan ook worden gebruikt om een query uit te voeren op de domeincontroller voor gegevens over entiteiten die worden gezien in netwerkverkeer, bewaakte gebeurtenissen en bewaakte ETW-activiteiten

Een DSA is vereist voor de volgende functies en functionaliteit:

  • Wanneer u met een sensor werkt die is geïnstalleerd op een AD FS-/AD CS-server.

  • Ledenlijsten aanvragen voor lokale beheerdersgroepen van apparaten die worden gezien in netwerkverkeer, gebeurtenissen en ETW-activiteiten via een SAM-R-aanroep naar het apparaat. Verzamelde gegevens worden gebruikt om mogelijke laterale verplaatsingspaden te berekenen.

  • Toegang tot de Container DeletedObjects om informatie te verzamelen over verwijderde gebruikers en computers.

  • Domein- en vertrouwenstoewijzing, die plaatsvindt bij het opstarten van de sensor, en opnieuw om de 10 minuten.

  • Een query uitvoeren op een ander domein via LDAP voor meer informatie bij het detecteren van activiteiten van entiteiten in die andere domeinen.

Wanneer u één DSA gebruikt, moet de DSA leesmachtigingen hebben voor alle domeinen in de forests. In een niet-vertrouwde omgeving met meerdere forests is een DSA-account vereist voor elk forest.

Eén sensor in elk domein wordt gedefinieerd als de domeinsynchronisatieroutine en is verantwoordelijk voor het bijhouden van wijzigingen in de entiteiten in het domein. Wijzigingen kunnen bijvoorbeeld objecten bevatten die zijn gemaakt, entiteitskenmerken die worden bijgehouden door Defender for Identity, enzovoort.

Notitie

Defender for Identity ondersteunt standaard maximaal 30 referenties. Als u meer referenties wilt toevoegen, neemt u contact op met de ondersteuning van Defender for Identity.

Ondersteunde DSA-accountopties

Defender for Identity ondersteunt de volgende DSA-opties:

Optie Omschrijving Configuratie
Groep beheerd serviceaccount gMSA (aanbevolen) Biedt een veiligere implementatie en wachtwoordbeheer. Active Directory beheert het maken en rouleren van het wachtwoord van het account, net zoals het wachtwoord van een computeraccount, en u kunt bepalen hoe vaak het wachtwoord van het account wordt gewijzigd. Zie Een Directory Service-account configureren voor Defender for Identity met een gMSA voor meer informatie.
Normaal gebruikersaccount Eenvoudig te gebruiken wanneer u aan de slag gaat en eenvoudiger leesmachtigingen configureert tussen vertrouwde forests, maar vereist extra overhead voor wachtwoordbeheer.

Een normaal gebruikersaccount is minder veilig, omdat u hiervoor wachtwoorden moet maken en beheren. Dit kan leiden tot downtime als het wachtwoord verloopt en niet wordt bijgewerkt voor zowel de gebruiker als de DSA.		 Maak een nieuw account in Active Directory om te gebruiken als de DSA met leesmachtigingen voor alle objecten, inclusief machtigingen voor de Container DeletedObjects . Zie Vereiste DSA-machtigingen verlenen voor meer informatie.
Lokaal serviceaccount Het lokale serviceaccount wordt standaard gebruikt wanneer er geen DSA is geconfigureerd.
Notitie:
  • SAM-R-query's voor mogelijke laterale verplaatsingspaden worden niet ondersteund in dit scenario.
  • LDAP-query's alleen binnen het domein dat de sensor is geïnstalleerd. Query's naar andere domeinen in hetzelfde forest of meerdere forests mislukken.
    		•  Geen

    Notitie

    Hoewel het lokale serviceaccount standaard wordt gebruikt met de sensor en een DSA in sommige scenario's optioneel is, raden we u aan om een DSA voor Defender for Identity te configureren voor volledige beveiligingsdekking.

    DSA-invoergebruik

    In deze sectie wordt beschreven hoe DSA-vermeldingen worden gebruikt en hoe de sensor een DSA-vermelding selecteert in een bepaald scenario. Sensorpogingen verschillen, afhankelijk van het type DSA-vermelding:

    Type Description
    gMSA-account De sensor probeert het wachtwoord van het gMSA-account op te halen uit Active Directory en meldt zich vervolgens aan bij het domein.
    Normaal gebruikersaccount De sensor probeert zich aan te melden bij het domein met behulp van de geconfigureerde gebruikersnaam en het geconfigureerde wachtwoord.

    De volgende logica wordt toegepast:

    1. De sensor zoekt naar een vermelding met een exacte overeenkomst van de domeinnaam voor het doeldomein. Als er een exacte overeenkomst wordt gevonden, probeert de sensor zich te verifiëren met behulp van de referenties in die vermelding.

    2. Als er geen exacte overeenkomst is of als de verificatie is mislukt, zoekt de sensor in de lijst naar een vermelding naar het bovenliggende domein met behulp van DNS-FQDN en probeert deze te verifiëren met behulp van de referenties in de bovenliggende vermelding.

    3. Als er geen vermelding is voor het bovenliggende domein of als de verificatie is mislukt, zoekt de sensor in de lijst naar een domeinvermelding op hetzelfde niveau, met behulp van de DNS-FQDN en probeert deze te verifiëren met behulp van de referenties in de vermelding op hetzelfde niveau.

    4. Als er geen vermelding is voor het domein op hetzelfde niveau of als de verificatie is mislukt, controleert de sensor de lijst opnieuw en probeert deze opnieuw te verifiëren bij elke vermelding totdat deze is geslaagd. DSA gMSA-vermeldingen hebben een hogere prioriteit dan reguliere DSA-vermeldingen.

    Voorbeeldlogica met een DSA

    In deze sectie ziet u een voorbeeld van hoe de sensor de hele DSA probeert uit te voeren wanneer u meerdere accounts hebt, inclusief zowel een gMSA-account als een normaal account.

    De volgende logica wordt toegepast:

    1. De sensor zoekt naar een overeenkomst tussen de DNS-domeinnaam van het doeldomein, zoals emea.contoso.com en de DSA gMSA-vermelding, zoals emea.contoso.com.

    2. De sensor zoekt naar een overeenkomst tussen de DNS-domeinnaam van het doeldomein, zoals emea.contoso.com en de reguliere DSA-vermelding DSA, zoals emea.contoso.com

    3. De sensor zoekt naar een overeenkomst in de DNS-hoofdnaam van het doeldomein, zoals emea.contoso.com de DSA gMSA-vermelding domeinnaam, zoals contoso.com.

    4. De sensor zoekt naar een overeenkomst in de DNS-hoofdnaam van het doeldomein, zoals emea.contoso.com en de reguliere DSA-vermeldingsdomeinnaam, zoals contoso.com.

    5. De sensor zoekt naar de doeldomeinnaam voor een domein op hetzelfde niveau, zoals emea.contoso.com de DSA gMSA-vermeldingdomeinnaam, zoals apac.contoso.com.

    6. De sensor zoekt naar de doeldomeinnaam voor een domein op hetzelfde niveau, zoals emea.contoso.com de reguliere DSA-vermeldingsdomeinnaam, zoals apac.contoso.com.

    7. De sensor voert een round robin van alle DSA gMSA-vermeldingen uit.

    8. De sensor voert een round robin van alle reguliere DSA-vermeldingen uit.

    De logica die in dit voorbeeld wordt weergegeven, wordt geïmplementeerd met de volgende configuratie:

    • DSA-vermeldingen:

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

    • Sensoren en de DSA-vermelding die eerst wordt gebruikt:

      FQDN van domeincontroller DSA-vermelding gebruikt
      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

    Belangrijk

    Als een sensor niet kan worden geverifieerd via LDAP bij het opstarten van het Active Directory-domein, voert de sensor geen actieve status in en wordt er een statusprobleem gegenereerd. Zie Defender for Identity Health-problemen voor meer informatie.

    Vereiste DSA-machtigingen verlenen

    De DSA vereist alleen-lezenmachtigingen voor alle objecten in Active Directory, inclusief de container Verwijderde objecten.

    Met de alleen-lezenmachtigingen voor de container Verwijderde objecten kan Defender for Identity gebruikersverwijderingen uit uw Active Directory detecteren.

    Gebruik het volgende codevoorbeeld om u te helpen bij het verlenen van de vereiste leesmachtigingen voor de container Verwijderde objecten , ongeacht of u een gMSA-account gebruikt.

    Tip

    Als de DSA waaraan u de machtigingen wilt verlenen een door een groep beheerd serviceaccount (gMSA) is, moet u eerst een beveiligingsgroep maken, de gMSA toevoegen als lid en de machtigingen aan die groep toevoegen. Zie Een Directory Service-account configureren voor Defender for Identity met een gMSA voor meer informatie.

    # 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

    Zie Machtigingen voor een verwijderde objectcontainer wijzigen voor meer informatie.

    Uw DSA-machtigingen en -delegaties testen via PowerShell

    Gebruik de volgende PowerShell-opdracht om te controleren of uw DSA niet te veel machtigingen heeft, zoals krachtige beheerdersmachtigingen:

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

    Als u bijvoorbeeld de machtigingen voor het mdiSvc01-account wilt controleren en volledige details wilt opgeven, voert u het volgende uit:

    Test-MDIDSA -Identity "mdiSvc01" -Detailed

    Zie de naslaginformatie over DefenderForIdentity PowerShell voor meer informatie.

    Volgende stap

    Een Directory Service-account configureren voor Defender for Identity met een gMSA »