Delen via

Directoryserviceaccounts voor Microsoft Defender for Identity

  • Artikel

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

Opmerking

Ongeacht de adreslijstserviceaccounts die zijn geconfigureerd, wordt de sensorservice uitgevoerd onder de LocalService-identiteit en de updater-service werkt onder de LocalSystem-identiteit.

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

Wanneer u bijvoorbeeld een DSA hebt geconfigureerd, wordt de DSA gebruikt om bij 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 werkt met een sensor die is geïnstalleerd op een AD FS/AD CS-server.

  • Het aanvragen van ledenlijsten 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 wordt uitgevoerd bij het opstarten van de sensor, en elke 10 minuten opnieuw.

  • Query's 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 domeinsynchronisatiefunctie 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.

Opmerking

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

Ondersteunde DSA-accountopties

Defender for Identity ondersteunt de volgende DSA-opties:

Optie Beschrijving Configuratie
Beheerd serviceaccount voor groep gMSA (aanbevolen) Biedt een veiligere implementatie en wachtwoordbeheer. Active Directory beheert het maken en roteren van het wachtwoord van het account, net als 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 om aan de slag te gaan en eenvoudiger leesmachtigingen te configureren tussen vertrouwde forests, maar vereist extra overhead voor wachtwoordbeheer.

Een gewoon 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.
Opmerking:
  • SAM-R-query's voor mogelijke laterale verplaatsingspaden die niet worden 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

    Opmerking

    Hoewel het lokale serviceaccount standaard met de sensor wordt gebruikt en een DSA in sommige scenario's optioneel is, raden we u aan 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 Beschrijving
    gMSA-account De sensor probeert het gMSA-accountwachtwoord 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 wachtwoord.

    De volgende logica wordt toegepast:

    1. De sensor zoekt een vermelding met een exacte overeenkomst van de domeinnaam voor het doeldomein. Als er een exacte overeenkomst wordt gevonden, probeert de sensor 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 in het bovenliggende domein met behulp van DE DNS-FQDN en probeert de sensor in plaats daarvan 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 van een broer of zus, met behulp van de DNS-FQDN, en probeert de sensor in plaats daarvan te verifiëren met behulp van de referenties in de vermelding tussen broers en zussen.

    4. Als er geen vermelding is voor het domein van de broer of zus 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 normale DSA-vermeldingen.

    Voorbeeldlogica met een DSA

    In deze sectie vindt u een voorbeeld van hoe de sensor de gehele DSA probeert uit te voeren wanneer u meerdere accounts hebt, waaronder zowel een gMSA-account als een gewoon 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 en de domeinnaam van de DSA gMSA-vermelding, zoals contoso.com.

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

    5. De sensor zoekt naar de doeldomeinnaam voor een domein met een broer of zus, zoals emea.contoso.com en de DSA gMSA-vermeldingdomeinnaam, zoals apac.contoso.com.

    6. Met de sensor wordt gezocht naar de doeldomeinnaam voor een domein met een broer of zus, zoals emea.contoso.com en de reguliere DSA-vermeldingsdomeinnaam, zoals apac.contoso.com.

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

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

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

    • DSA-vermeldingen:

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

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

      Domeincontroller FQDN 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 Active Directory-domein bij het opstarten, krijgt de sensor geen actieve status en wordt er een statusprobleem gegenereerd. Zie Statusproblemen met Defender for Identity 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 de vereiste leesmachtigingen te verlenen voor de container Verwijderde objecten , ongeacht of u een gMSA-account gebruikt of niet.

    Tip

    Als de DSA waaraan u de machtigingen wilt verlenen een gMSA (Group Managed Service Account) is, moet u eerst een beveiligingsgroep maken, de gMSA toevoegen als lid en de machtigingen toevoegen aan die groep. 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 wijzigen voor een verwijderde objectcontainer 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 DefenderForIdentity PowerShell-verwijzing voor meer informatie.

    Volgende stap

    Een directoryserviceaccount configureren voor Defender for Identity met een gMSA »