Contas de serviço de diretório para o Microsoft Defender for Identity

Este artigo descreve como o Microsoft Defender for Identity usa contas de serviço de diretório (DSAs).

Embora um DSA seja opcional em alguns cenários, recomendamos que você configure um DSA para o Defender for Identity para cobertura total de segurança.

Por exemplo, quando você tem um DSA configurado, o DSA é usado para se conectar ao controlador de domínio na inicialização. Um DSA também pode ser usado para consultar o controlador de domínio em busca de dados sobre entidades vistas no tráfego de rede, eventos monitorados e atividades ETW monitoradas

Um DSA é necessário para os seguintes recursos e funcionalidades:

• Ao trabalhar com um sensor instalado num servidor AD FS / AD CS.

• Solicitar listas de membros para grupos de administradores locais a partir de dispositivos vistos no tráfego de rede, eventos e atividades ETW através de uma chamada SAM-R feita para o dispositivo. Os dados recolhidos são utilizados para calcular potenciais trajetórias de movimento lateral.

• Acessando o contêiner DeletedObjects para coletar informações sobre usuários e computadores excluídos.

• Mapeamento de domínio e confiança, que ocorre na inicialização do sensor e novamente a cada 10 minutos.

• Consultar outro domínio via LDAP para obter detalhes, ao detetar atividades de entidades nesses outros domínios.

Quando você estiver usando um único DSA, o DSA deve ter permissões de Leitura para todos os domínios nas florestas. Em um ambiente não confiável de várias florestas, uma conta DSA é necessária para cada floresta.

Um sensor em cada domínio é definido como o sincronizador de domínio e é responsável por controlar as alterações nas entidades no domínio. Por exemplo, as alterações podem incluir objetos criados, atributos de entidade rastreados pelo Defender for Identity e assim por diante.

Opções de conta DSA suportadas

O Defender for Identity suporta as seguintes opções de DSA:

Uso da entrada DSA

Esta seção descreve como as entradas DSA são usadas e como o sensor seleciona uma entrada DSA em qualquer cenário. As tentativas do sensor diferem, dependendo do tipo de entrada DSA:

A seguinte lógica é aplicada:

1. O sensor procura uma entrada com uma correspondência exata do nome de domínio para o domínio de destino. Se uma correspondência exata for encontrada, o sensor tentará autenticar usando as credenciais nessa entrada.

2. Se não houver uma correspondência exata ou se a autenticação falhar, o sensor procurará na lista uma entrada para o domínio pai usando o FQDN DNS e tentará autenticar usando as credenciais na entrada pai.

3. Se não houver uma entrada para o domínio pai ou se a autenticação falhar, o sensor procurará na lista uma entrada de domínio irmão, usando o FQDN DNS, e tentará autenticar usando as credenciais na entrada irmã.

4. Se não houver uma entrada para o domínio irmão ou se a autenticação falhar, o sensor revisará a lista novamente e tentará autenticar novamente com cada entrada até que ela seja bem-sucedida. As entradas DSA gMSA têm prioridade mais alta do que as entradas DSA regulares.

Lógica de exemplo com um DSA

Esta seção fornece um exemplo de como o sensor experimenta as entires DSA quando você tem várias contas, incluindo uma conta gMSA e uma conta regular.

A seguinte lógica é aplicada:

1. O sensor procura uma correspondência entre o nome de domínio DNS do domínio de destino, como emea.contoso.com e a entrada DSA gMSA, como emea.contoso.com.

2. O sensor procura uma correspondência entre o nome de domínio DNS do domínio de destino, como emea.contoso.com e o DSA de entrada regular do DSA, como emea.contoso.com

3. O sensor procura uma correspondência no nome DNS raiz do domínio de destino, como emea.contoso.com e o nome de domínio de entrada DSA gMSA, como contoso.com.

4. O sensor procura uma correspondência no nome DNS raiz do domínio de destino, como emea.contoso.com e o nome de domínio de entrada regular DSA, como contoso.com.

5. O sensor procura o nome de domínio de destino para um domínio irmão, como emea.contoso.com e o nome de domínio de entrada DSA gMSA, como apac.contoso.com.

6. O sensor procura o nome de domínio de destino para um domínio irmão, como emea.contoso.com e o nome de domínio de entrada regular DSA, como apac.contoso.com.

7. O sensor executa um round robin de todas as entradas DSA gMSA.

8. O sensor executa um round robin de todas as entradas regulares do DSA.

A lógica mostrada neste exemplo é implementada com a seguinte configuração:

• Entradas DSA:

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

• Sensores e a entrada DSA que é usada primeiro:

  FQDN do controlador de domínio	Entrada DSA usada
  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

Conceder permissões DSA necessárias

O DSA requer permissões somente leitura em todos os objetos no Ative Directory, incluindo o Contêiner de Objetos Excluídos.

As permissões somente leitura no contêiner Objetos Excluídos permitem que o Defender for Identity detete exclusões de usuários do Ative Directory.

Use o exemplo de código a seguir para ajudá-lo a conceder as permissões de leitura necessárias no contêiner Objetos Excluídos , independentemente de você estar usando ou não uma conta 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

Para obter mais informações, consulte Alterando permissões em um contêiner de objeto excluído.

Teste suas permissões e delegações DSA via PowerShell

Use o seguinte comando do PowerShell para verificar se seu DSA não tem muitas permissões, como permissões de administrador poderosas:

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

Por exemplo, para verificar as permissões para a conta mdiSvc01 e fornecer detalhes completos, execute:

Test-MDIDSA -Identity "mdiSvc01" -Detailed

Para obter mais informações, consulte a referência do PowerShell DefenderForIdentity.

Próximo passo