Contas de Serviço de Diretório para o Microsoft Defender para Identidade

Este artigo descreve como o Microsoft Defender para Identidade usa Contas de Serviço de Diretório (DSAs).

Embora uma DSA seja opcional em alguns cenários, recomendamos que você configure uma DSA para o Defender para Identidade a fim de obter a cobertura total de segurança.

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

Uma DSA é necessária para os seguintes recursos e funcionalidades:

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

• Ao solicitar listas de membros para grupos de administradores locais de dispositivos vistos no tráfego de rede, eventos e atividades do ETW por meio de uma chamada SAM-R feita para o dispositivo. Os dados coletados são usados para calcular possíveis caminhos de movimentação lateral.

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

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

• Em consultas a outro domínio via LDAP para obter detalhes, ao detectar atividades de entidades nesses outros domínios.

Quando você estiver usando um único DSA, esse 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 rastrear as alterações nas entidades no domínio. Por exemplo, as alterações podem incluir objetos criados, atributos de entidade rastreados pelo Defender para Identidade, e assim por diante.

Opções de conta DSA com suporte

O Defender para Identidade oferece suporte às seguintes opções de DSA:

Uso de DSA de entrada

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

A seguinte lógica é aplicada:

1. O sensor procura uma entrada com uma correspondência exata do nome de domínio do 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 buscará na lista uma entrada de domínio irmão, usando o FQDN DNS, e tentará autenticar com as credenciais na entrada do irmão.

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 com cada entrada até encontrar uma que seja bem-sucedida. As entradas de gMSA da DSA têm prioridade mais alta do que as entradas de DSA regulares.

Lógica de exemplo com uma DSA

Esta seção fornece um exemplo de como o sensor tenta as entradas de 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 de gMSA da DSA, 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 a entrada de DSA regular, 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 no nome de domínio da entrada de gMSA da DSA, como contoso.com.

4. O sensor procura uma correspondência no nome DNS raiz do domínio de destino, como emea.contoso.com, e no nome de domínio de entrada de DSA regular, 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 da entrada de gMSA da DSA, 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 da entrada de DSA regular, como apac.contoso.com.

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

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

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

• Entradas de DSA:

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

• Sensores e a entrada de DSA usada primeiro:

  FQDN do controlador de domínio	Entrada de 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 as permissões de DSA necessárias

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

As permissões somente leitura no contêiner Objetos Excluídos permitem que o Defender para Identidade detecte exclusões de usuários do Active Directory.

Use o exemplo de código a seguir para ajudar você a conceder as permissões de leitura necessárias no contêiner Objetos Excluídos, independentemente de você estar ou não usando 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, confira Alterar as permissões em um contêiner de objetos excluídos.

Testar suas permissões e delegações de DSA via PowerShell

Use o seguinte comando do PowerShell para verificar se o seu DSA não tem excesso de 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 saber mais, consulte a referência do PowerShell DefenderForIdentity.

Próxima etapa