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

O Defender para Identidade utiliza Contas de Serviço de Diretório (DSAs) para ler dados do Active Directory, como consultar objetos, controlar alterações e resolver entidades. Isto é separado da conta de ação, que executa ações de remediação, como desativar utilizadores ou repor palavras-passe.

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 em um servidor AD FS, AD CS ou Microsoft Entra Connect.

• Solicitar listas de membros dos grupos de administradores locais de dispositivos observados no tráfego de rede, em eventos e em atividades ETW, por meio de uma chamada SAM-R feita ao dispositivo.

• 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 você estiver usando um único DSA, esse DSA deve 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:

Uso de DSA de entrada

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 tentará se autenticar usando as credenciais dessa 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 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.

É 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 entrada DSA regular, 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 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 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 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	Rodízio

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, consulte a referência do PowerShell do DefenderForIdentity.

Próxima etapa