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

Artigo
01/17/2024

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, o DSA é usado para se 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, 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 rastrear 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.

Observação

Por padrão, o Defender para Identidade oferece suporte a até 30 credenciais. Para adicionar mais credenciais, entre em contato com o suporte do Defender para Identidade.

Opções de conta DSA com suporte

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

Opção	Descrição	Configuração
Conta de Serviço Gerenciado de Grupo gMSA (Recomendada)	Fornece uma implantação mais segura e gerenciamento de senhas. O Active Directory gerencia a criação e a rotação de senhas da conta, assim como as senhas de contas de computador, e você pode controlar a frequência com que a senha da conta é alterada.	Para obter mais informações, confira Configurar uma conta de serviço de diretório para o Defender para Identidade com uma gMSA.
Conta de usuário regular	Fácil de usar ao começar e mais simples de configurar permissões de Leitura entre florestas confiáveis, mas requer sobrecarga extra para o gerenciamento de senhas. Uma conta de usuário regular é menos segura, pois exige que você crie e gerencie senhas, e pode levar a tempo de inatividade se a senha expirar e não for atualizada para o usuário e a DSA.	Crie uma nova conta no Active Directory para usar como DSA com permissões de Leitura para todos os objetos, incluindo permissões para o contêiner DeletedObjects . Para obter mais informações, confira Conceder as permissões de DSA necessárias.

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:

Tipo	Descrição
Conta gMSA	O sensor tenta recuperar a senha da conta gMSA do Active Directory e, em seguida, entra no domínio.
Conta de usuário regular	O sensor tenta iniciar sessão no domínio usando o nome de usuário e a senha configurados.

A seguinte lógica é aplicada:

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.
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.
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ã.
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:

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.
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.
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.
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.
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.
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.
O sensor executa um round robin em todas as entradas de gMSA da DSA.
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

Importante

Se um sensor não conseguir autenticar com êxito via LDAP no domínio do Active Directory na inicialização, o sensor não entrará em um estado de execução e um problema de integridade será gerado. Para obter mais informações, confira Problemas de integridade do Microsoft Defender para Identidade.

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.

Dica

Se a DSA à qual você deseja conceder as permissões for uma Conta de Serviço Gerenciado de Grupo (gMSA), você deverá primeiro criar um grupo de segurança, adicionar a gMSA como membro e adicionar as permissões a esse grupo. Para obter mais informações, confira Configurar uma conta de serviço de diretório para o Defender para Identidade com uma 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 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óxima etapa

Configurar uma Conta de Serviço de Diretório para o Defender para Identidade com uma gMSA »