Microsoft Defender para Identidade recomendações da Conta de Serviço de Diretório

Introdução

A DSA (Conta de Serviços de Diretório) no Defender para Identidade é usada pelo sensor para executar as seguintes funções:

  • Na inicialização, o sensor se conecta ao controlador de domínio usando LDAP com as credenciais da conta DSA.

  • O sensor consulta o controlador de domínio para obter informações sobre entidades vistas no tráfego de rede, eventos monitorados e atividades de ETW monitoradas.

  • Um sensor em cada domínio será definido como o "sincronizador de domínio" e é responsável por acompanhar as alterações nas entidades no domínio, como objetos criados, atributos de entidade rastreados pelo Defender para Identidade e assim por diante.

  • Se o sensor vir atividades de entidades em outros domínios, ele consultará esse domínio via LDAP para obter informações sobre a entidade.

  • O Defender para Identidade solicita a lista de membros do grupo de administradores local de dispositivos vistos em tráfego de rede, eventos e atividades ETW. Isso é feito fazendo uma chamada SAM-R para o dispositivo. Essas informações são usadas para calcular possíveis caminhos de movimento lateral.

Observação

Por padrão, o Defender para Identidade dá suporte a até 30 credenciais. Caso deseje adicionar mais credenciais, entre em contato com o suporte do Defender para Identidade.

Permissões necessárias para o DSA

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

Observação

Recomendação de contêiner objetos excluídos: a DSA deve ter permissões somente leitura no contêiner Objetos Excluídos. As permissões somente leitura neste contêiner permitem que o Defender para Identidade detecte exclusões de usuários do Active Directory. Para obter informações sobre como configurar permissões somente leitura no contêiner Objetos Excluídos, confira a seção Como alterar permissões em um contêiner de objetos excluídos do artigo Exibir ou definir permissões em um objeto do directory.

Tipos de contas DSA

Há dois tipos de DSA que podem ser usados:

  • GMSA (Conta de Serviço Gerenciado de Grupo) – recomendado

  • Conta de usuário regular no Active Directory

Tipo de DSA Vantagens Desvantagens
gMSA
  • Implantação mais segura desde que o Active Directory gerencia a criação e a rotação da senha da conta, como a senha de uma conta de computador.
  • Você pode controlar a frequência com que a senha da conta é alterada.
  • Requer etapas de instalação adicionais.
  • Conta de usuário regular
  • Dá suporte a todas as versões do sistema operacional compatíveis com o sensor.
  • Fácil de criar e começar a trabalhar.
  • Fácil de configurar permissões de leitura entre florestas confiáveis.
  • Menos seguro, pois requer a criação e o gerenciamento de senhas.
  • Pode levar ao tempo de inatividade se a senha expirar e a senha não for atualizada (tanto na configuração do usuário quanto da DSA).
  • Número de entradas DSA

    Quantas entradas DSA são necessárias?

    Um mínimo de uma entrada DSA é exigido pelo Defender para Identidade. Ele deve ter permissões de leitura para todos os domínios nas florestas.

    Em um ambiente de várias florestas não confiável, uma conta DSA será necessária para cada floresta.

    Como o sensor escolhe qual entidade DSA usar?

    Quando o sensor for iniciado, ele obterá uma lista de entradas DSA configuradas no Defender para Identidade.

    Uma entrada DSA está configurada

    O sensor tentará usar a entrada DSA configurada durante a inicialização, como uma reação a um novo domínio que contate o controlador de domínio, sempre que uma consulta SAM-R for feita ou sempre que essa conexão precisar ser recriada.

    • Conta regular: o sensor tentará entrar no controlador de domínio usando o nome de usuário e a senha configurados.

    • Conta gMSA: – o sensor tentará recuperar a senha da conta gMSA do Active Directory (AD). Depois de recuperar a senha, o sensor tentará entrar no domínio.

    Duas ou mais entradas DSA são configuradas

    Quando houver duas ou mais entradas DSA, o sensor tentará as entradas DSA na seguinte ordem:

    1. Corresponda entre o nome de domínio DNS do domínio de destino (por exemplo, emea.contoso.com) e o domínio da entrada DSA gMSA (por exemplo, emea.contoso.com).
    2. Corresponda entre o nome de domínio DNS do domínio de destino (por exemplo, emea.contoso.com) e o domínio da entrada regular DSA (por exemplo, emea.contoso.com).
    3. Corresponda ao nome DNS raiz do domínio de destino (por exemplo, emea.contoso.com) e ao nome de domínio da entrada DSA gMSA (por exemplo, contoso.com)
    4. Corresponda ao nome DNS raiz do domínio de destino (por exemplo, emea.contoso.com) e ao nome de domínio da entrada regular DSA (por exemplo, contoso.com)
    5. Procure um "domínio irmão" – nome de domínio de destino (por exemplo, emea.contoso.com) e nome de domínio de entrada DSA gMSA (por exemplo, apac.contoso.com).
    6. Procure um "domínio irmão" – nome de domínio de destino (por exemplo, emea.contoso.com) e nome de domínio de entrada regular DSA (por exemplo, apac.contoso.com).
    7. Arredondar todas as outras entradas DSA gMSA
    8. Arredondar todas as outras entradas regulares da DSA

    Observação

    • Em uma floresta com um único espaço de nome DNS, é recomendável criar a entrada DSA no domínio raiz. Você deve conceder a essa conta permissões de leitura para todos os subdomínios.
    • Em uma floresta com mais de um namespace, é recomendável criar a entrada DSA no domínio raiz de cada namespace.

    Importante

    Se um sensor não for capaz de autenticar com êxito via LDAP para o domínio do Active Directory na inicialização usando qualquer uma das contas DSA configuradas, o sensor não entrará em um estado em execução e um alerta de integridade será criado. Para obter mais informações, consulte alertas de integridade do Defender para Identidade.

    Como criar uma conta gMSA para uso com o Defender para Identidade

    As etapas a seguir podem ser seguidas para criar uma conta gMSA a ser usada como a entrada DSA do Defender para Identidade. Isso não fornece diretrizes completas sobre contas gMSA. Para obter informações adicionais, examine Introdução às Contas de Serviço Gerenciado de Grupo.

    Observação

    • Em um ambiente de várias florestas, recomendamos criar gMSAs com um nome exclusivo para cada floresta ou domínio.

    Concedendo as permissões para recuperar a senha da conta gMSA

    Antes de criar a conta gMSA, considere como atribuir permissões para recuperar a senha da conta.

    Ao usar uma entrada gMSA, o sensor precisa recuperar a senha do gMSA do Active Directory. Isso pode ser feito atribuindo a cada um dos sensores ou usando um grupo.

    • Em uma implantação de domínio único de floresta única, se você não estiver planejando instalar o sensor em nenhum servidor do AD FS, poderá usar o grupo de segurança interno controladores de domínio .

    • Em uma floresta com vários domínios, ao usar uma única conta DSA, é recomendável criar um grupo universal e adicionar cada um dos controladores de domínio (e servidores AD FS) ao grupo universal.

      Observação

      Se você adicionar uma conta de computador ao grupo universal depois que o computador receber seu tíquete Kerberos, ele não poderá recuperar a senha do gMSA até que solicite um novo tíquete Kerberos. O tíquete Kerberos tem uma lista de grupos dos quais uma entidade faz parte quando o tíquete é emitido. Nesse caso, você pode:

      • Aguarde a emissão do novo tíquete Kerberos. (Os tíquetes Kerberos normalmente são válidos por 10 horas)
      • Reinicialize o servidor, quando o servidor for reinicializado, um novo tíquete Kerberos será solicitado com a nova associação de grupo.
      • Limpe os tíquetes Kerberos existentes. Isso forçará o controlador de domínio a solicitar um novo tíquete Kerberos. Em um prompt de comando do administrador no controlador de domínio, execute o seguinte comando: klist purge -li 0x3e7

    Criar uma conta gMSA

    Nas etapas a seguir, você criará um grupo específico que pode recuperar a senha da conta, criar uma conta gMSA e testar se a conta está pronta para uso.

    Execute os seguintes comandos do PowerShell como administrador:

    # Set the variables:
    $gMSA_AccountName = 'mdiSvc01'
    $gMSA_HostsGroupName = 'mdiSvc01Group'
    $gMSA_HostNames = 'DC1', 'DC2', 'DC3', 'DC4', 'DC5', 'DC6', 'ADFS1', 'ADFS2'
    
    # Install the required PowerShell module:
    Install-Module ActiveDirectory
    
    # Create the group and add the members
    $gMSA_HostsGroup = New-ADGroup -Name $gMSA_HostsGroupName -GroupScope Global -PassThru
    $gMSA_HostNames | ForEach-Object { Get-ADComputer -Identity $_ } |
        ForEach-Object { Add-ADGroupMember -Identity $gMSA_HostsGroupName -Members $_ }
    
    # Create the gMSA:
    New-ADServiceAccount -Name $gMSA_AccountName -DNSHostName "$gMSA_AccountName.$env:USERDNSDOMAIN" `
    -PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroup.Name
    

    Instalar a conta gMSA

    Para instalar a conta gMSA, execute localmente (como administrador) em cada um dos servidores, o seguinte comando:

    # Install the required PowerShell module:
    Install-Module ActiveDirectory
    
    # Install the gMSA account
    Install-ADServiceAccount -Identity 'mdiSvc01'
    

    Como validar que o controlador de domínio pode recuperar a senha do gMSA

    Para validar se o servidor tem as permissões necessárias para recuperar a senha do gMSA, execute o seguinte comando do PowerShell:

    Test-ADServiceAccount -Identity 'mdiSvc01'
    

    Se ele tiver as permissões, o comando retornará uma mensagem True .

    Observação

    Se você receber uma mensagem de erro ao executar Test-ADServiceAccount, reinicie o servidor ou execute klist purge -li 0x3e7 e tente novamente.

    Verifique se a conta gMSA tem os direitos necessários (se necessário)

    O serviço sensor (Sensor avançado de Proteção contra Ameaças do Azure) é executado como LocalService e executa a representação da conta DSA. A representação falhará se o logon como uma política de serviço estiver configurado, mas a permissão não tiver sido concedida à conta gMSA e você receberá um alerta de integridade: as credenciais do usuário dos serviços de diretório estão incorretas.

    Se você receber o alerta, deverá verificar se o logon como uma política de serviço está configurado.

    O logon como uma política de serviço pode ser configurado em uma configuração de Política de Grupo ou em uma Política de Segurança Local.

    • Para verificar a Política Local, execute secpol.msc e selecione Políticas Locais. Em Atribuição de Direitos de Usuário, vá para a configuração de política de logon como serviço . Se a política estiver habilitada, adicione a conta gMSA à lista de contas que podem fazer logon como um serviço.

    • Para verificar se a configuração está definida em Política de Grupo, execute rsop.msc e veja se a configuração configuração do computador ->Windows Configurações ->Security Configurações ->Local Policies ->User Rights Assignment ->Logon como um serviço está definida. Se a configuração estiver configurada, adicione a conta gMSA à lista de contas que podem fazer logon como um serviço no Editor de Gerenciamento do Política de Grupo.

    Log on as a service in GPMC.

    Log on as a service properties.

    Confira também