¿Por qué un servidor en un entorno AD permitiría el acceso al Registro remoto mediante FQDN, pero negaría y bloquearía cuentas a través de la dirección IP?

¿Por qué un servidor en un entorno AD permitiría el acceso al Registro remoto mediante FQDN, pero negaría y bloquearía cuentas a través de la dirección IP?

Tenemos una situación en la que no se puede instalar una aplicación de software porque la cuenta de administrador utilizada durante la instalación queda bloqueada durante las comprobaciones de requisitos previos. Después de investigar un poco, encontramos la causa: la verificación de requisitos previos analiza la configuración del registro remoto de otros servidores mediante una llamada RPC a la dirección IP del servidor en lugar de su FQDN y, por alguna razón, esto provoca que la autenticación falle y bloquee la cuenta.

Validamos esto haciendo lo siguiente:

  • Cuando usa regedit e intenta conectarse al registro de otro servidor AD usando el FQDN del servidor, se conecta sin problemas.
  • Cuando intentamos la misma conexión usando la dirección IP del servidor, solicita nuevas credenciales.
  • Todas las credenciales de AD fallarán y eventualmente bloquearán la cuenta que se está utilizando, pero usar una cuenta de administrador local no tiene problemas.

También realizamos esta prueba desde otros servidores del entorno, pero no tuvieron problemas para conectarse y autenticarse por IP. Comparamos las configuraciones de NIC/DNS/WINS, pero no hubo diferencias notables. Estamos en el punto de verificar la configuración de GPO, pero no esperamos encontrar nada.

Obviamente podríamos usar cuentas de administrador local, pero queremos entenderpor quéuna llamada RPC que utiliza una dirección IP en lugar del FQDN provoca que la autenticación de AD falle y bloquee las cuentas de AD. ¿Algunas ideas?

Respuesta1

Si bloquea la cuenta, definitivamente tienes un problema de contraseña. De lo contrario, puede deberse a que no se utilizará Kerberos y NTLM está deshabilitado o algo así. Debe verificar el registro de seguridad del servidor de origen y de destino y proporcionar cualquier entrada de registro que pueda estar relacionada con el problema de autenticación.

También puedes probar esto. Sin embargo, cambiar cosas cuando ni siquiera sabes la razón por la que algo no funciona no es muy eficiente y puede estropear otras cosas.

A partir de Windows 10 versión 1507 y Windows Server 2016, los clientes Kerberos se pueden configurar para admitir nombres de host IPv4 e IPv6 en SPN.

De forma predeterminada, Windows no intentará la autenticación Kerberos para un host si el nombre del host es una dirección IP. Recurrirá a otros protocolos de autenticación habilitados como NTLM. Sin embargo, las aplicaciones a veces están codificadas para usar direcciones IP, lo que significa que la aplicación recurrirá a NTLM y no usará Kerberos. Esto puede causar problemas de compatibilidad a medida que los entornos se mueven para deshabilitar NTLM.

Para reducir el impacto de deshabilitar NTLM, se introdujo una nueva capacidad que permite a los administradores usar direcciones IP como nombres de host en los nombres principales del servicio.

Lea mas en

https://docs.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip

información relacionada