Conta de serviço SQL incomum - O serviço não foi iniciado devido a uma falha de logon

Question

Isso élouco, por favor tenha paciencia comigo. Esta NÃO é uma senha incorreta.

Tenho uma conta de serviço SQL que NÃO autentica. Sou um servidor experiente e tentei todos os conceitos básicos com alguns colegas experientes (mesmo que sejam orientados pela Cisco).

Cenário:

1. Active Directory em 3 sites, cada um com 2 DCs e 1 DC raiz no Server 2008 R2
2. Não há problemas de DNS e a replicação do site está correta. Qualquer alteração na conta acontece em segundos.
3. O SQL 2016 R2 recém-construído, implantado em 2 servidores Server 2012 R2 no domínio que reside em uma UO onde o SQL 2005 no Server 2008 R2 também reside.
4. TODOS os servidores SQL estão em sua própria vlan, DC em outra. Não há problemas de firewall entre eles, mas não podemos ver nenhum log, pois eles são hospedados por terceiros em clusters ESX com contratos Cisco entre vlans.
5. O servidor SQL 2005 não tem problemas de autenticação com DCs na outra vlan.

A configuração de uma conta de serviço AD SQL estabelecida nos novos servidores SQL falha devido ao Erro 1069: O serviço não foi iniciado devido a uma falha de logon.

O evento nos logs de eventos nos DCs (qualquer um dos 2 que estiver autenticando a conta) declara o seguinte:

Falha na pré-autenticação Kerberos. Informações da conta: ID de segurança: DOMAIN\sqlsvcaccount$ Nome da conta: sqlsvcaccount$ (não o nome real da conta) Informações do serviço: Nome do serviço: krbtgt/DOMAIN (não é nosso nome de domínio, é claro) Informações de rede: Endereço do cliente: ::ffff:10.30 .xx (nosso endereço IPv4) Porta do cliente: 49464 Informações adicionais: Opções de ticket: 0x40810010 Código de falha: 0x18 Tipo de pré-autenticação: 2

Informações do certificado: Nome do emissor do certificado:
Número de série do certificado:
Impressão digital do certificado:

Agora, 0x18 normalmente é uma senha incorreta, mas como mencionei, as contas estão bem e quando elas são desativadas eu as reativo, redefino a senha, blá, blá. Posso executar RunAs em um aplicativo no novo servidor SQL e isso funciona bem.

Eu configurei uma política de grupo de computadores para permitir os direitos da conta de serviço para serviços, etc. e executei um gpresult para confirmar se o GPO foi aplicado.

Faça backup de arquivos e diretórios DOMAIN\sqlsvcaccount$ Faça logon como uma tarefa em lote DOMAIN\sqlsvcaccount$ Faça logon como um serviço DOMAIN\sqlsvcaccount$

Até tinha um GPO de computador restrito e colocava a conta de domínio como administrador local (o que teria negado a necessidade do GPO de serviços).

Criou uma nova UO de usuário para a conta de serviço com herança bloqueada e moveu a conta de serviço para lá, novamente gpupdate /force e executou gpresult novamente para html e tudo parece OK.

Também reiniciando algumas vezes entre as coisas, o normal.

Executamos o Wireshark, que nunca mostrou nada de errado, movemos o servidor SQL para a mesma vlan dos DCs e, como mencionado anteriormente, o servidor SQL 2005 na vlan do banco de dados não apresenta problemas de autenticação.

Por fim, criei uma nova UO de computador, bloqueei a herança de política e tentei tudo isso novamente, mas ainda não tive prazer em tentar iniciar o SQL Server ou o serviço Agent.

Eu tentei a ferramenta SQL Management para editar serviços como deveria ser e até mesmo apenas Windows Services.msc.

A última coisa que começamos a analisar foram as cifras e se o Server 2012 está tentando autenticar usando RC4 e desabilitando as cifras. Mas ainda não fizemos muito com isso.

Então, alguém tem alguma ideia do que pode estar acontecendo? Agradeço QUALQUER feedback ou outro caminho que eu possa tentar.

Existe uma caixa virtual de cerveja para quem tem a resposta?

Answer 1

Contas de serviço gerenciadas(MSA) resolveu isso. O Server 2012 AD usa gMSA, então isso me surpreendeu:

No AD (com opções avançadas), em Novacroft, há uma UO chamada Contas de serviço gerenciadas. Você encontra seus MSA criados lá, uma vez criados com o Powershell.

Então, para instalar uma conta de serviço:

1. Você cria a conta (sem $) usando o Powershell.
2. Em seguida, associe a conta a um servidor - novamente usando o Powershell.
3. No servidor de destino, instale o Powershell e o módulo AD em recursos e ferramentas AD. Instale também o .NET 3.5
4. No servidor de destino no Powershell, importe a conta para o host.
5. Em seguida, configure os serviços (você precisa adicionar $ no final agora) e deixe a senha em branco.

Agradável e fácil, hein (se você souber como)? Crédito para NedPyle [MSFT] Artigo completoAQUI Espero que isso ajude alguém :-)