Quando nossas contas gMSA são alternadas automaticamente, vemos falhas de login por cerca de 1 a 10 minutos. Isso é particularmente aparente para contas de clientes gMSA que se conectam ao servidor MS SQL, mas acho que também acontece com outras contas gMSA. O servidor MS SQL não está sendo executado como uma conta gMSA, mas nosso aplicativo usa gMSA para fazer uma conexão do cliente com SQL. Por padrão, ManagedPasswordIntervalInDays ocorre a cada 30 dias, portanto, vemos isso todos os meses no mesmo horário.
Quando verifico os logs do controlador de domínio, não vejo nenhuma falha de login para o usuário gMSA, mas o servidor SQL registra o seguinte erro
O handshake SSPI falhou com o código de erro 0x8009030c, estado 14 ao estabelecer uma conexão com segurança integrada; A conexão foi encerrada. Motivo: falha em AcceptSecurityContext. O código de erro do sistema operacional indica a causa da falha. A tentativa de logon falhou [CLIENTE: xxxx]
Pelo que descobri, esse erro geralmente indica a combinação errada de nome de usuário/senha.
Isso ocorre em vários clientes e cada um eventualmente começa a se conectar novamente após 1 a 10 minutos. Nem todos os clientes começam a se conectar ao mesmo tempo, mas parece que ocorre aleatoriamente dentro dessa janela de tempo.
Inicialmente pensei que poderia estar relacionado à replicação do AD da senha alterada, então modificamos o intervalo de replicação entre sites padrão para USE_NOTIFY para replicar imediatamente. Se a replicação fosse o problema, eu esperaria ver falhas de login nos controladores de domínio e não estou vendo falhas de logon nos controladores de domínio. Eu também pensei que talvez o servidor SQL esteja armazenando em cache o token de autenticação, mas se fosse esse o caso, eu esperaria ver todos os clientes resolvidos ao mesmo tempo (ou seja, quando o servidor SQL fosse atualizado). em um momento diferente, não parece estar no lado do servidor SQL, mas é mais provável que seja algo no lado do cliente. Talvez armazenar em cache a senha gMSA ou talvez algo relacionado ao tempo limite e novas tentativas.
Responder1
Estávamos gerando o mesmo erro devido a um problema de SPN que fazia com que o gMSA se autenticasse no SQL Server via NTLM em vez de Kerberos. Se você fizer login no SQL Server e verificar as sessões, sys.dm_exec_connectionsdeverá ver uma lista de sessões com NTLM
(você também pode usar klist sessionso CLI para visualizar as sessões)
Conseguimos correlacionar nossos erros com as alterações de senha com ferramentas de análise de log, então sabíamos que esse era o culpado. Não sei com que frequência o SCM atualiza sua cópia da senha, mas se o serviço estiver autenticando no SQL Server e usando Kerberos, acredito que as alterações de senha devem ser independentes do tempo de vida/renovação da sessão Kerberos, portanto, o erro gerado é uma pista sólida de que a senha está sendo enviada para o host do SQL Server via NTLM. Depois que corrigimos nosso problema de SPN (devido a um registro DNS A adicional), as sessões passaram para a autenticação Kerberos.
Responder2
Descobri que isso se devia à forma como o serviço do Windows foi configurado. O serviço do Windows foi configurado como um serviço padrão usando uma conta de usuário normal que era uma conta gMSA em vez do serviço do Windows usando uma conta gerenciada.
Isso pode ser verificado com:
>sc.exe qmanagedaccount ServiceName
[SC] QueryServiceConfig2 SUCCESS
ACCOUNT MANAGED : FALSE
Isso pode ser alterado executando
sc.exe managedaccount ServiceName TRUE
Depois de alterar o tipo de conta de serviço do Windows a ser gerenciada, os testes iniciais mostram que os logins agora foram bem-sucedidos durante a rotação da senha gMSA.