Visão geral das Contas de Serviço Gerenciado delegadas
Um novo tipo de conta conhecido como dMSA (Conta de Serviço Gerenciado delegada) foi introduzido no Windows Server 2025, que permite a migração de uma conta de serviço tradicional para uma conta de computador com chaves gerenciadas e totalmente aleatórias, enquanto desabilita as senhas da conta de serviço original. A autenticação do dMSA está vinculada à identidade do dispositivo, o que significa que somente as identidades de máquina especificadas mapeadas no Active Directory (AD) podem acessar a conta. O uso doadMSA ajuda a impedir a coleta de credenciais usando uma conta comprometida (kerberoasting), que é um problema comum com contas de serviço tradicionais.
Comparação entre dMSA e gMSA
dMSAs e gMSAs são dois tipos de contas de serviço gerenciado usadas para executar serviços e aplicativos no Windows Server. Uma dMSA é gerenciada por um administrador e é usada para executar um serviço ou aplicativo em um servidor específico. Uma gMSA é gerenciada pelo AD e é usada para executar um serviço ou aplicativo em vários servidores. Ambas oferecem segurança aprimorada e gerenciamento simplificado de senhas. A dMSA difere-se por:
- Utilizar conceitos de gMSA para limitar o escopo de uso usando o Credential Guard para vincular a autenticação da máquina.
- O CG pode ser usado para aumentar a segurança na dMSA, fazendo a rotação automática das senhas e vinculando todos os tíquetes da conta de serviço. As contas herdadas são desativadas para melhorar ainda mais a segurança.
- Embora as gMSAs sejam protegidas com senhas geradas por computador e rotacionadas automaticamente, as senhas ainda não estão vinculadas ao computador e podem ser roubadas.
Funcionalidade da dMSA
A dMSA permite que os usuários os criem como uma conta autônoma ou substituam uma conta de serviço padrão existente. Quando uma dMSA substitui uma conta existente, a autenticação dessa conta existente usando sua senha é bloqueada. A solicitação é redirecionada para a LSA (Autoridade de Segurança Local) para autenticação usando a dMSA, que tem acesso a tudo o que a conta anterior poderia acessar no AD.
Durante a migração, a dMSA aprende automaticamente os dispositivos nos quais a conta de serviço será usada, que é usada para mover de todas as contas de serviço existentes.
A dMSA usa um segredo aleatório (derivado da credencial da conta do computador) que é mantido pelo DC (Controlador de Domínio) para criptografar tíquetes. O segredo pode ser ainda mais protegido por meio da habilitação do CG. Embora os segredos usados pela dMSA sejam atualizados periodicamente em uma época como uma gMSA, a principal diferença é que o segredo da dMSA não pode ser recuperado ou encontrado em outro lugar que não seja no DC.
Fluxo de migração para dMSA
Um conceito rápido do processo de fluxo de migração para uma dMSA envolve as seguintes etapas:
- A política de CG pode ser configurada para proteger a identidade dos computadores.
- Um administrador inicia e conclui a migração da conta de serviço.
- A conta de serviço atualiza o TGT (Servidor de Concessão de Tíquetes).
- A conta de serviço adiciona a identidade do computador para permitir princípios.
- A conta de serviço original torna-se desabilitada.
Anote o seguinte ao migrar dMSAs:
- Não é possível migrar de uma conta de serviço gerenciado ou de uma gMSA para uma dMSA.
- Aguarde pelo menos dois tempos de vida do tíquete (equivalente a 14 dias) após modificar o SD (Descritor de Segurança) antes de concluir a migração da dMSA. Recomenda-se manter um serviço no estado inicial por quatro tempos de vida útil do tíquete (28 dias). Atrase a migração se os DCs estiverem particionados ou se a replicação for interrompida durante a integração.
- Preste atenção aos locais em que os atrasos de replicação são maiores do que o tempo padrão de renovação do tíquete de 10 horas. O atributo groupMSAMembership é verificado e atualizado a cada renovação de ticket e sempre que a conta de serviço original faz logon durante o estado "migração inicial", que adiciona a conta de computador a groupMSAMembership da dMSA.
- Por exemplo, dois sites utilizam a mesma conta de serviço e cada ciclo de replicação leva mais de 10 horas por tempo de vida do tíquete. Nesse cenário, uma associação de grupo é perdida durante os ciclos iniciais de replicação.
- A migração requer acesso a um RWDC (Controlador de Domínio de Leitura-Gravação) para consultar e modificar o SD.
- A delegação irrestrita para de funcionar quando a migração for concluída se a conta de serviço antiga estiver usando-a. Se você estiver usando uma dMSA protegida por CG, a delegação irrestrita deixará de funcionar. Para saber mais, consulte Considerações e problemas conhecidos ao usar o Credential Guard.
Aviso
Se você for migrar para uma dMSA, todos os computadores que usam a conta de serviço precisarão ser atualizados para oferecer suporte à dMSA. Se isso não for verdade, os computadores que não oferecem suporte à dMSA falharão na autenticação com a conta de serviço existente quando a conta for desabilitada durante a migração.
Atributos de conta para dMSA
Esta seção descreve como os atributos da dMSA são alterados no esquema do AD. Esses atributos podem ser exibidos usando o snap-in Usuários e Computadores do Active Directory ou executando ADSI Edit no DC.
Observação
Os atributos numéricos definidos para a conta indicam que:
- 1 - a migração da conta já começou.
- 2 - a migração da conta foi concluída.
Executar Start-ADServiceAccountMigration executa as seguintes alterações:
- A conta de serviço recebe Leitura Genérica para todas as propriedades na dMSA
- A conta de serviço recebe a propriedade Write para msDS-groupMSAMembership
- msDS-DelegatedMSAState é alterado para 1
- msDS-ManagedAccountPrecededByLink é definido como a conta de serviço
- msDS-SupersededAccountState é alterado para 1
- msDS-SupersededManagedServiceAccountLink é definido como a dMSA
Executar Complete-ADServiceAccountMigration executa as seguintes alterações:
- A conta de serviço é removida de Leitura Genérica para todas as propriedades na dMSA
- A conta de serviço é removida da propriedade Write no atributo msDS-GroupMSAMembership
- msDS-DelegatedMSAState é definido como 2
- Os SPNs (Nomes da Entidade de Serviço) são copiados da conta de serviço para a conta dMSA
- msDS-AllowedToDelegateTo é copiado, se aplicável
- msDS-AllowedToActOnBehalfOfOtherIdentity, o descritor de segurança é copiado, se aplicável
- A política AuthN atribuída, msDS-AssignedAuthnPolicy, da conta de serviço é copiada
- A dMSA é adicionada a quaisquer silos de política AuthN dos quais a conta de serviço era membro
- O bit confiável da UAC (Controle de Conta do Usuário) de "Autenticação para Delegação" é copiado se tiver sido definido na conta de serviço
- msDS-SupersededServiceAccountState é definido como 2
- A conta de serviço é desabilitada por meio do bit de desabilitação do UAC
- O SPNs é removido da conta
Realms dMSA
Os realms servem como agrupamentos lógicos que definem limites de autenticação, comumente usados ao integrar diferentes versões do AD em domínios ou florestas. Eles são especialmente importantes em ambientes de domínio misto, onde alguns domínios podem não oferecer suporte total a todos os recursos do dMSA. Ao especificar regiões, a dMSA pode garantir a comunicação adequada e o fluxo de autenticação entre domínios.
Os administradores podem usar regiões para especificar quais domínios ou componentes de diretório podem autenticar e acessar a conta dMSA. Isso garante que até mesmo domínios filhos mais antigos, que podem não oferecer suporte nativo a recursos dMSA, possam interagir com as contas, mantendo os limites de segurança. Ao permitir uma transição e coexistência mais suaves de recursos em ambientes mistos, os realms ajudam a garantir a compatibilidade sem comprometer a segurança.
Por exemplo, se você tiver um domínio primário chamado corp.contoso.com em execução no Windows Server 2025 e um domínio filho mais antigo chamado legacy.corp.contoso.com em execução no Windows Server 2022, poderá especificar o domínio como legacy.corp.contoso.com.
Para editar essa configuração de política de grupo para seu ambiente, navegue até o seguinte caminho:
Computador Configuração\Modelos administrativos\Sistema\Kerberos\Habilitar logons de conta de serviço gerenciado delegado
