piloto de primeira implantacao gMSA: validar KDS antes da mudança

Um objeto gMSA ainda não é um serviço migrado

Um piloto de primeira implantacao gMSA deve terminar com um serviço funcional sob a nova identidade, uma decisão de reversão aprovada e evidências dos hosts que realmente o executam. Criar uma conta de serviço gerida por grupo no Active Directory estabelece uma conta. Não demonstra que uma carga de trabalho de produção utiliza essa conta, que todos os hosts necessários conseguem obter as suas credenciais ou que a carga de trabalho mantém o acesso adequado após a mudança.

Esta distinção importa quando uma auditoria indica que não há gMSAs em uso. Trate esse resultado como um motivo para investigar o inventário do diretório e o conjunto de serviços. Um novo objeto pode fazer desaparecer um sinal de inventário enquanto todos os serviços continuam a executar sob a identidade antiga. Por outro lado, uma recolha incompleta pode não detetar um objeto existente. Nenhum dos resultados responde à pergunta operacional: qual serviço foi migrado com sucesso?

Mantenha três registos separados: objetos do diretório, prontidão dos hosts e adoção pelos serviços. O primeiro identifica contas; o segundo regista se um determinado host pode utilizar a conta selecionada; o terceiro regista uma carga de trabalho testada que a utiliza. Este artigo propõe uma verificação de aprovação para a primeira adoção, com um serviço e um plano explícito de recuperação. Não pressupõe que todos os utilizadores com SPN representam serviços compatíveis e ativos.

Como funciona um piloto de primeira implantacao gMSA

Comece com um responsável pelo serviço e um inventário da carga de trabalho, em vez de um pedido de criação de conta. Registe o nome do serviço, a identidade atual, a lista de hosts, a versão da aplicação, a configuração de arranque, os clientes e os recursos a jusante. Pergunte ao responsável quais funções devem permanecer disponíveis e que evidências demonstrariam que a alteração funcionou. Um processo que arranca mas não consegue escrever a sua saída programada falhou o piloto.

A Microsoft documenta o suporte a gMSAs para serviços configurados através do Service Control Manager, pools de aplicações IIS, Agendador de Tarefas e produtos que suportam as APIs de contas geridas. O próprio serviço de Cluster não suporta gMSAs; serviços compatíveis executados sobre ele podem suportá-las. Confirme o produto exato e a topologia de implantação com o responsável antes de selecionar o piloto. Microsoft Learn — Gerir contas de serviço geridas por grupo.

Estruture o registo da alteração em torno destas verificações independentes:

São controlos propostos para o piloto, não resultados já medidos no seu ambiente. Atribua um responsável a cada verificação. O responsável pelo AD trata da dependência da floresta; o responsável pelo serviço aceita o comportamento da carga de trabalho; quem aprova a alteração autoriza a mudança e a recuperação. Registe quem pode interromper o piloto quando essas avaliações divergem.

Deteção: inspecionar objetos, prontidão do KDS e cada host

Conciliar um inventário do diretório baseado na classe

Utilize uma pesquisa independente por classe para verificar o significado do inventário do coletor. O exemplo seguinte, apenas de leitura, foi composto a partir dos parâmetros documentados de Get-ADServiceAccount. Substitua o DC e o DN de domínio ilustrativos pelo âmbito aprovado; repita para cada domínio incluído no piloto. Não foi executado contra o seu diretório.

Get-ADServiceAccount -LDAPFilter '(objectClass=msDS-GroupManagedServiceAccount)' -SearchBase 'DC=example,DC=com' -SearchScope Subtree -Server 'dc01.example.com' -ResultSetSize $null

-LDAPFilter seleciona a classe estrutural independentemente da heurística do coletor baseada no atributo de associação. -SearchBase, -SearchScope e -Server tornam explícitos os limites pretendidos; -ResultSetSize $null evita impor um limite total de resultados. Quando utilizado de forma mais geral, o cmdlet devolve tanto contas geridas autónomas como contas geridas por grupo, pelo que deve conservar a restrição por classe neste inventário. Microsoft Learn — Get-ADServiceAccount.

Registe as identidades devolvidas e o estado de ativação, juntamente com o âmbito e o resultado da consulta. Se esta pesquisa encontrar uma gMSA que o coletor não reconheceu, investigue permissões, atributos pedidos, limites da pesquisa e limites de resultados. Não resolva a divergência criando outra conta. Se a pesquisa falhar, conserve o erro como falha de recolha; uma consulta bem-sucedida sem resultados e uma consulta malsucedida são evidências diferentes.

Em seguida, associe cada objeto relevante a configurações reais de serviços. Pergunte se está sem uso, preparado, desativado ou em uso por uma carga de trabalho testada. Mantenha como não associado um objeto sem associação. O nome de uma conta do diretório, por si só, não permite identificar um responsável pelo serviço nem provar que algum host a utiliza.

Inspecionar as chaves KDS existentes antes de pedir uma nova

Num contexto administrativo autorizado com o módulo KDS, utilize o comando de leitura documentado:

Get-KdsRootKey

Obtém a lista de chaves raiz existentes, incluindo os valores das chaves. Inspecione-a no ambiente administrativo e conserve no registo da alteração apenas os identificadores necessários e a decisão sobre a prontidão; não cole material bruto de chaves num ticket geral. Este comando é uma etapa de inventário, não um teste de replicação. Microsoft Learn — Get-KdsRootKey.

A Microsoft descreve uma espera de até dez horas após a criação da chave raiz para que a replicação dos DCs possa convergir antes do uso da gMSA. Horários de replicação limitados ou falhas de replicação podem continuar a causar falhas de obtenção de credenciais. Peça ao responsável pelo AD que verifique a disponibilidade da chave e a integridade da replicação nos DCs que servem os hosts do piloto; o tempo decorrido, por si só, não constitui essa evidência. Microsoft Learn — Criar uma chave raiz KDS.

Se já existir uma chave adequada, o procedimento de gestão indica que deve omitir a criação da chave. Se não existir nenhuma, torne o processo documentado de criação da chave e replicação do responsável pelo AD um pré-requisito, com o seu próprio calendário e autorização. Não incorpore uma dependência da floresta numa alteração de conta de serviço que não foi revista.

Testar a prontidão nos hosts efetivamente autorizados

Reveja os principais aprovados para obter a palavra-passe e confirme que correspondem ao conjunto de hosts previsto. As orientações de gestão da Microsoft também exigem SPNs adequados, DNS, acesso à rede, sincronização dos relógios e tipos de encriptação Kerberos suportados. Trate-os como pré-requisitos a investigar, em vez de pressupor que uma pesquisa bem-sucedida no diretório os verifica.

Execute localmente o teste documentado da conta em cada host previsto, substituindo o nome de conta ilustrativo:

Test-ADServiceAccount -Identity 'svc-pilot'

A Microsoft define um teste bem-sucedido como prontidão para autenticar e aceder ao domínio com as credenciais atuais da conta. Registe host, momento, conta e resultado real. O teste não exercita as consultas à base de dados da aplicação, as escritas de ficheiros, a autenticação dos clientes ou o comportamento após reinício. Microsoft Learn — Test-ADServiceAccount.

Uma falha suspende a mudança. Investigue com os responsáveis competentes a autorização prevista para o host, o acesso ao diretório e a dependência de KDS/replicação. Alargar o acesso de obtenção de credenciais a um grupo amplo não é um atalho aceitável. A revisão existente das permissões de obtenção da palavra-passe gMSA explica por que o conjunto de leitores é um limite de segurança que merece uma revisão separada.

Correção: testar um serviço com reversão viável (Remediation)

1. Acordar os testes de aceitação e o caminho de recuperação

Escolha uma carga de trabalho compatível cujo responsável consiga observar tanto a operação normal como as falhas. Antes de alterar a identidade, conserve a configuração aprovada, as permissões existentes, o comportamento de arranque e os resultados de referência da carga de trabalho. Registe a janela de manutenção, a pessoa que aprova a alteração, a pessoa que executa a recuperação e as condições que a desencadeiam.

Defina condições específicas para o serviço: um cliente necessário não consegue autenticar, uma operação programada falha, um recurso esperado fica inacessível ou um reinício não restabelece o serviço. Defina o período de observação com o responsável, em vez de inventar uma duração universal. Uma carga de trabalho que só executa numa hora programada precisa de ter essa execução coberta pela decisão de aceitação.

2. Preparar o host autorizado e as permissões da conta

Reveja os direitos locais de serviço e as permissões a jusante do candidato antes da alteração. Peça as permissões necessárias às operações previstas da carga de trabalho; conserve as dependências da identidade antiga durante a janela de recuperação. Mantenha a autorização para obter a palavra-passe separada da autorização para aceder aos dados da aplicação. Passar no teste da conta não demonstra o conjunto completo de permissões da aplicação nem a sua configuração correta.

Depois de aprovadas as verificações do diretório e da autorização, o procedimento da Microsoft instala a conta em cada host onde o serviço executa. Execute localmente numa sessão PowerShell elevada, no âmbito da alteração aprovada:

Install-ADServiceAccount -Identity 'svc-pilot'

O cmdlet prepara a conta gerida existente no computador local. Não altera a identidade configurada na aplicação. A referência exige que a autorização de obtenção de credenciais esteja definida para uma gMSA. Microsoft Learn — Install-ADServiceAccount.

Repita o teste de prontidão da conta nesse host e conserve o resultado. Se a instalação ou o teste falhar, pare nesta verificação e investigue. Não registe a conclusão de um comando administrativo como uma migração de serviço bem-sucedida.

3. Efetuar a mudança através da configuração suportada pelo serviço

Utilize o procedimento de configuração de identidade suportado pelo produto para migrar o serviço selecionado. Um comando genérico não pode descrever com segurança todos os serviços Windows, pools de aplicações, tarefas e aplicações. Conserve esse procedimento específico do produto e os seus passos inversos no registo da alteração aprovada.

Verifique a identidade configurada e, em seguida, inicie ou reinicie a carga de trabalho conforme acordado. Peça ao responsável que execute operações representativas dos clientes e leituras ou escritas nos recursos a jusante. Compare os resultados com a referência e inspecione os erros reais da aplicação. Quando a autenticação for relevante, confirme o comportamento de autenticação esperado dos clientes e dos recursos através dos diagnósticos estabelecidos pela organização. Nenhum resultado isolado de arranque substitui estes testes.

Se os critérios de aceitação falharem, siga esses passos e documente tanto a falha que desencadeou a reversão como o comportamento do serviço restabelecido. Conserve as evidências para investigação. Deixar um objeto de conta no AD enquanto recupera a carga de trabalho não significa que o piloto teve sucesso.

4. Encerrar o piloto e acompanhar o restante conjunto de serviços

Após a aceitação, registe o serviço, os hosts, a nova identidade, os testes, os carimbos de data/hora, quem aprovou e as limitações não resolvidas. Reveja todos os consumidores restantes da identidade antiga antes de a retirar. Remova essa identidade apenas após a validação e o período de recuperação aprovado; o seu nome desaparecer de uma configuração de serviço não prova que nenhuma outra carga de trabalho depende dela.

A correção existente para contas de serviço que recomenda a migração para gMSA estabelece um motivo para migrar. Este piloto fornece as evidências operacionais para essa recomendação. Acompanhe separadamente os candidatos posteriores: a aceitação do primeiro serviço é um progresso, mas a adoção em todo o conjunto continua a exigir um inventário e uma decisão por serviço.

Como a EtcSec deteta esta situação

A verificação EtcSec relevante é GMSA_NOT_IN_USE. Na implementação revista do etc-collector, conta os utilizadores gMSA reconhecidos e os utilizadores ativados com pelo menos um SPN. Devolve um resultado de gravidade baixa com Count = 1 apenas quando a contagem de gMSAs reconhecidas é zero e a contagem de utilizadores ativados com SPN é positiva. Caso contrário, devolve Count = 0.

O reconhecimento é mais restrito do que um inventário por classe estrutural: User.IsGMSA é definido quando o atributo binário msDS-GroupMSAMembership não está vazio. O filtro LDAP de utilizadores inclui msDS-GroupManagedServiceAccount, mas o parser não utiliza essa classe para definir este indicador do utilizador. Um atributo de associação ausente ou ilegível pode, portanto, afetar o reconhecimento; um limite LDAP incompleto ou um limite MaxUsers pode afetar o inventário. Um erro GetUsers interrompe o motor, em vez de produzir um inventário vazio bem-sucedido.

Todas as gMSAs reconhecidas contribuem, incluindo objetos desativados. Um objeto reconhecido basta para tornar este sinal zero, mesmo que nenhum serviço tenha sido migrado. O valor zero também ocorre quando não foram recolhidos utilizadores ativados com SPN. Esta verificação não inspeciona chaves KDS, prontidão da replicação, instalação nos hosts, configuração dos serviços, compatibilidade das aplicações ou inícios de sessão reais dos serviços. Não mede a proporção de serviços que utilizam gMSAs nem o sucesso do piloto.