Compartilhar via


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

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, esse DSA é usado para 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, esse 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 para Identidade, 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 o 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.
Conta de serviço local A Conta de serviço local vem pronta para uso e é usada por padrão quando não há DSA configurado.
Observação:
  • Consultas SAM-R para possíveis caminhos de movimento lateral não contam com suporte neste cenário.
  • O LDAP consulta somente dentro do domínio onde o sensor está instalado. As consultas a outros domínios na mesma floresta ou floresta cruzada irão falhar.
  • Nenhum

    Observação

    Embora a conta de serviço local seja usada com o sensor por padrão e um DSA seja opcional em alguns cenários, recomendamos que você configure um DSA para o Defender para Identidade para obter cobertura total de segurança.

    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, depois, 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:

    1. 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.

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

    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 de gMSA da 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 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 no nome de domínio da entrada de gMSA da DSA, como contoso.com.

    4. 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.

    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 da entrada de gMSA da DSA, como apac.contoso.com.

    6. 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.

    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 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 o seu DSA não tem excesso de 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 saber mais, consulte a referência do PowerShell DefenderForIdentity.

    Próxima etapa