Temos uma situação em que um aplicativo de software não pode ser instalado porque a conta de administrador usada durante a instalação é bloqueada durante as verificações de pré-requisitos. Após alguma investigação, encontramos a causa: a verificação de pré-requisito analisa as configurações de registro remoto de outros servidores por chamada RPC para o endereço IP do servidor em vez de seu FQDN e, por algum motivo, isso faz com que a autenticação falhe e bloqueie a conta.
Validamos isso fazendo o seguinte:
- Ao usar o regedit e tentar conectar-se ao registro de outro servidor AD usando o FQDN do servidor, ele se conecta sem problemas.
- Quando tentamos a mesma conexão usando o endereço IP do servidor, ele solicita novas credenciais.
- Todas as credenciais do AD falharão e eventualmente bloquearão a conta que está sendo usada, mas usar uma conta de administrador local não apresenta problemas.
Realizamos esse teste também em outros servidores do ambiente, mas eles não tiveram problemas de conexão e autenticação por IP. Comparamos as configurações de NIC/DNS/WINS, mas não houve diferença notável. Estamos no ponto de verificar as configurações do GPO, mas não esperamos encontrar nada.
Obviamente, poderíamos usar apenas contas de administrador local, mas queremos entenderpor queuma chamada RPC usando um endereço IP em vez do FQDN faz com que a autenticação do AD falhe e bloqueie as contas do AD. Alguma ideia?
Responder1
Se bloquear a conta, você definitivamente está tendo um problema de senha. Caso contrário, pode ser porque o Kerberos não será usado e o NTLM está desabilitado ou algo assim. Você precisa verificar o log de segurança do servidor de origem e de destino e fornecer qualquer entrada de log que possa estar relacionada ao problema de autenticação.
Você também pode tentar isso. Porém, mudar as coisas quando você nem sabe o motivo pelo qual algo não funciona não é muito eficiente e pode quebrar outras coisas.
A partir do Windows 10 versão 1507 e do Windows Server 2016, os clientes Kerberos podem ser configurados para dar suporte a nomes de host IPv4 e IPv6 em SPNs.
Por padrão, o Windows não tentará a autenticação Kerberos para um host se o nome do host for um endereço IP. Ele recorrerá a outros protocolos de autenticação habilitados, como NTLM. No entanto, às vezes os aplicativos são codificados para usar endereços IP, o que significa que o aplicativo retornará ao NTLM e não usará o Kerberos. Isso pode causar problemas de compatibilidade à medida que os ambientes mudam para desabilitar o NTLM.
Para reduzir o impacto da desativação do NTLM, foi introduzido um novo recurso que permite aos administradores usar endereços IP como nomes de host em nomes principais de serviço.
Leia mais em
https://docs.microsoft.com/en-us/windows-server/security/kerberos/configurando-kerberos-over-ip