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:

• Utilizing gMSA concepts to limit scope of usage using Credential Guard (CG) to bind machine authentication.
• 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 os gMSAs sejam protegidos com senhas geradas pelo computador e autorotadas, as senhas ainda não são associadas 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:

1. A política de CG pode ser configurada para proteger a identidade dos computadores.
2. Um administrador inicia e conclui a migração da conta de serviço.
3. A conta de serviço atualiza o TGT (Servidor de Concessão de Tíquetes).
4. A conta de serviço adiciona a identidade do computador para permitir princípios.
5. 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. Keeping a service in the start state for four ticket lifetimes (28 days) is recommended. Atrase a migração se os DCs estiverem particionados ou se a replicação for interrompida durante a integração.
• Pay attention to sites where replication delays are longer than the default ticket renewal time of 10 hours. The groupMSAMembership attribute is checked and updated at every ticket renewal, and every time the original service account logs on during the "start migration" state, which adds the machine account to the groupMSAMembership of the 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.

Warning

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, máquinas que não oferecem suporte a dMSA falharão na autenticação com a conta de serviço existente assim que a conta for desativada 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.

Note

Os atributos numéricos definidos para a conta indicam:

• 1 - Account migration has begun.
• 2 - Account migration has completed.

Executar Start-ADServiceAccountMigration executa as seguintes alterações:

• The service account is granted Generic Read to all properties on the dMSA
• The service account is granted Write property to msDS-groupMSAMembership
• msDS-DelegatedMSAState is changed to 1
• msDS-ManagedAccountPrecededByLink is set to the service account
• msDS-SupersededAccountState is changed to 1
• msDS-SupersededManagedServiceAccountLink is set to the dMSA

Executar Complete-ADServiceAccountMigration executa as seguintes alterações:

• The service account is removed from Generic Read to all properties on the dMSA
• The service account is removed from Write property on the msDS-GroupMSAMembership attribute
• msDS-DelegatedMSAState is set to 2
• Os SPNs (Nomes da Entidade de Serviço) são copiados da conta de serviço para a conta dMSA
• msDS-AllowedToDelegateTo is copied over if applicable
• msDS-AllowedToActOnBehalfOfOtherIdentity the security descriptor is copied over if applicable
• The assigned AuthN policy, msDS-AssignedAuthnPolicy, of the service account are copied over
• 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 is set to 2
• A conta de serviço é desabilitada por meio do bit de desabilitação do UAC
• O SPNs é removido da conta

dMSA realms

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. Os reinos facilitam transições perfeitas e a coexistência de recursos em ambientes mistos, garantindo a compatibilidade entre domínios, mantendo alta segurança quando habilitados.

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

See also

Configuração de Contas de Serviço Gerenciado delegadas