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

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

Embora uma DSA seja opcional em alguns cenários, recomendamos que configure uma DSA para Defender para Identidade para cobertura de segurança completa.

Por exemplo, quando tem uma DSA configurada, a DSA é utilizada para ligar ao controlador de domínio no arranque. Uma DSA também pode ser utilizada para consultar o controlador de domínio para obter dados sobre entidades vistas no tráfego de rede, eventos monitorizados e atividades de ETW monitorizadas

É necessária uma DSA para as seguintes funcionalidades:

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

• Pedir 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 efetuada para o dispositivo. Os dados recolhidos são utilizados para calcular potenciais caminhos de movimento lateral.

• Aceder ao contentor DeletedObjects para recolher informações sobre utilizadores e computadores eliminados.

• Mapeamento de domínio e fidedignidade, que ocorre no arranque do sensor e novamente a cada 10 minutos.

• Consulte outro domínio através de LDAP para obter detalhes ao detetar atividades de entidades nesses outros domínios.

Quando estiver a utilizar uma única DSA, a DSA tem de ter permissões de Leitura para todos os domínios nas florestas. Num ambiente de várias florestas não fidedigno, é necessária uma conta DSA para cada floresta.

Um sensor em cada domínio é definido como o sincronizador de domínio e é responsável por controlar as alterações às entidades no domínio. Por exemplo, as alterações podem incluir objetos criados, atributos de entidade controlados pelo Defender para Identidade, etc.

Opções de conta DSA suportadas

O Defender para Identidade suporta as seguintes opções de DSA:

Utilização da entrada DSA

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

É aplicada a seguinte lógica:

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

2. Se não existir uma correspondência exata ou se a autenticação tiver falhado, o sensor procura na lista uma entrada no domínio principal com o DNS FQDN e tenta autenticar com as credenciais na entrada principal.

3. Se não existir uma entrada para o domínio principal ou se a autenticação tiver falhado, o sensor procura na lista uma entrada de domínio colateral, utilizando o FQDN de DNS e tenta autenticar com as credenciais na entrada de irmão.

4. Se não existir uma entrada para o domínio colateral ou se a autenticação falhar, o sensor revê novamente a lista e tenta autenticar novamente com cada entrada até ser bem-sucedida. As entradas DSA gMSA têm uma prioridade superior às entradas DSA normais.

Lógica de exemplo com uma DSA

Esta secção fornece um exemplo de como o sensor tenta a totalidade da DSA quando tem várias contas, incluindo uma conta gMSA e uma conta normal.

É aplicada a seguinte lógica:

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 GMSA 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 DSA de entrada regular DSA, como emea.contoso.com

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

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

6. O sensor procura o nome de domínio de destino para um domínio colateral, 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 da DSA.

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

• Entradas DSA:

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

• Sensores e a entrada DSA que é utilizada 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

Conceder as permissões de DSA necessárias

A DSA requer permissões só de leitura em todos os objetos no Active Directory, incluindo o Contentor de Objetos Eliminados.

As permissões só de leitura no contentor Objetos Eliminados permitem ao Defender para Identidade detetar eliminações de utilizadores do Active Directory.

Utilize o seguinte exemplo de código para o ajudar a conceder as permissões de leitura necessárias no contentor Objetos Eliminados , quer esteja ou não a utilizar 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, veja Alterar permissões num contentor de objeto eliminado.

Testar as permissões e delegações de DSA através do PowerShell

Utilize o seguinte comando do PowerShell para verificar se a DSA não tem demasiadas permissões, como permissões de administrador avançadas:

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

Por exemplo, para verificar as permissões da conta mdiSvc01 e fornecer todos os detalhes, execute:

Test-MDIDSA -Identity "mdiSvc01" -Detailed

Para obter mais informações, veja a referência do PowerShell defenderForIdentity.

Passo seguinte