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

Os sensores do Defender for Identity v2.x utilizam Contas de Serviço de Diretório (DSAs) para ler dados do Active Directory, como consultar objetos, acompanhar mudanças e resolver entidades específicas. Isso é separado da conta de ação, que executa ações de correção, como desabilitar usuários ou redefinir senhas.

Para sensores v2.x, um DSA é opcional em alguns cenários, mas recomendamos configurar um 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 monitoradas de ETW.

Para sensor v2.x, é necessário um DSA para os seguintes recursos e funcionalidades:

• Ao trabalhar com um sensor instalado em um servidor AD FS, AD CS ou Microsoft Entra Connect.

• Solicitando listas de membros para grupos de administradores locais a partir de dispositivos vistos em tráfego de rede, eventos e atividades ETW via uma chamadaSAM-R feita ao dispositivo.

• Acessar 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 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 e com várias florestas, uma conta DSA é necessária para cada floresta.

Um sensor em cada domínio atua como sincronizador de domínio e acompanha mudanças nas entidades do domínio, como novos objetos e alterações nos atributos da entidade.

Opções de conta DSA com suporte

Para sensores v2.x, o Defender for Identity suporta as seguintes opções de DSA:

Uso de DSA de entrada

Um sensor v2.x seleciona uma entrada DSA com base no domínio de destino e nas credenciais configuradas. As tentativas de autenticação variam conforme o tipo de 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 pesquisará a lista em busca de 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 pesquisará a lista em busca de uma entrada de domínio irmão, usando o FQDN DNS, e tentará autenticar usando as credenciais na entrada 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 novamente com cada entrada até obter êxito. As entradas DSA gMSA têm prioridade mais alta do que as entradas DSA normais.

Lógica de exemplo com uma DSA

O exemplo a seguir mostra como o sensor tenta usar as entradas de DSA quando você configura um gMSA e uma conta comum.

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 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 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 de um domínio irmão, como emea.contoso.com, e o nome de domínio da entrada regular do DSA, 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 regulares do DSA.

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 DSA usada primeiro:

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

Conceda as permissões DSA necessárias

O 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 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 Alterar permissões em um contêiner de objeto excluído.

Testar suas permissões e delegações de DSA por meio do PowerShell

Use o seguinte comando do PowerShell para verificar se o 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 da conta mdiSvc01 e exibir todos os detalhes, execute:

Test-MDIDSA -Identity "mdiSvc01" -Detailed

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

Próxima etapa