Contas de serviço de diretório para o Microsoft Defender for Identity

  • Artigo

Este artigo descreve como o Microsoft Defender for Identity usa contas de serviço de diretório (DSAs).

Embora um DSA seja opcional em alguns cenários, recomendamos que você configure um DSA para o Defender for Identity 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 ETW monitoradas

Um DSA é necessário para os seguintes recursos e funcionalidades:

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

  • Solicitar 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 feita para o dispositivo. Os dados recolhidos são utilizados para calcular potenciais trajetórias de movimento lateral.

  • Acessando 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 detetar 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 controlar 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.

Nota

Por padrão, o Defender for Identity suporta até 30 credenciais. Para adicionar mais credenciais, entre em contato com o suporte do Defender for Identity.

Opções de conta DSA suportadas

O Defender for Identity suporta as seguintes opções de DSA:

Opção Description Configuração
Conta de Serviço Gerenciado de Grupo gMSA (Recomendado) Fornece uma implantação mais segura e gerenciamento de senhas. O Ative Directory gerencia a criação e a rotação da senha da conta, assim como a senha de uma conta de computador, e você pode controlar a frequência com que a senha da conta é alterada. Para obter mais informações, consulte Configurar uma conta de serviço de diretório para o Defender for Identity com um gMSA.
Conta de utilizador 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 gerenciamento de senhas.

Uma conta de usuário comum é 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 o DSA.		 Crie uma nova conta no Ative 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, consulte Conceder permissões DSA necessárias.

Uso da entrada DSA

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

Type Description
Conta gMSA O sensor tenta recuperar a senha da conta gMSA do Ative Directory e, em seguida, entra no domínio.
Conta de utilizador regular O sensor tenta entrar no domínio usando o nome de usuário e a senha configurados.

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 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 procurará na lista uma entrada de domínio irmão, usando o FQDN DNS, e tentará autenticar usando as credenciais na entrada irmã.

  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é que ela seja bem-sucedida. As entradas DSA gMSA têm prioridade mais alta do que as entradas DSA regulares.

Lógica de exemplo com um DSA

Esta seção fornece um exemplo de como o sensor experimenta as entires 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 e a entrada DSA gMSA, como emea.contoso.comemea.contoso.com.

  2. O sensor procura uma correspondência entre o nome de domínio DNS do domínio de destino, como e o DSA de entrada regular do DSA, como emea.contoso.comemea.contoso.com

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

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

  5. O sensor procura o nome de domínio de destino para um domínio irmão, como e o nome de domínio de entrada DSA gMSA, como emea.contoso.comapac.contoso.com.

  6. O sensor procura o nome de domínio de destino para um domínio irmão, como e o nome de domínio de entrada regular DSA, como emea.contoso.comapac.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 do DSA.

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

  • Entradas DSA:

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

  • Sensores e a entrada DSA que é usada primeiro:

    FQDN do controlador de domínio Entrada 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 Ative 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, consulte Defender para problemas de integridade de identidade.

Conceder permissões DSA necessárias

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

As permissões somente leitura no contêiner Objetos Excluídos permitem que o Defender for Identity detete exclusões de usuários do Ative 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.

Gorjeta

Se o DSA ao 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 o gMSA como membro e adicionar as permissões a esse grupo. Para obter mais informações, consulte Configurar uma conta de serviço de diretório para o Defender for Identity com um 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 Alterando permissões em um contêiner de objeto excluído.

Teste suas permissões e delegações 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óximo passo

Configurar uma conta de serviço de diretório para o Defender for Identity com um gMSA »