Autenticación de Windows integrada

Question

Estamos teniendo algunos problemas realmente extraños con la Autenticación de Windows integrada con IIS y no estoy seguro de si puedo ver un patrón o no.

Tenemos un registro DNS-Cname llamado Fred. Tenemos un sitio web de IIS con Fred configurado como encabezado de host. Cuando me conecto a este sitio me piden un desafío de credenciales. Esperaría que mis credenciales se hayan transmitido. Si ingreso mis credenciales, se me concede acceso.

Luego creo una entrada de host local llamada Betty y apunto el archivo de host a la misma dirección IP que Fred y cambio el encabezado de host a Betty. No hay ningún registro de CName asociado en ninguna parte. Cuando accedo a Betty, me autentican automáticamente y todo está bien.

Si intento omitir el registro CName y crear una entrada en el archivo de host local llamado Fred y cambiar el encabezado del host a Fred. Aún recibo un desafío de autenticación.

Según veo, tiene dos preguntas. ¿Cómo afecta este registro de CName a la resolución aquí o es una pista falsa? En segundo lugar, ¿qué está pasando con este desafío? Tenemos síntomas similares en otros lugares y nuestra preocupación es que nuestro token de autenticación esté siendo criticado en alguna parte. ¿Podría alguien recorrer el pedido con Autenticación? Es decir, qué paquetes se envían a qué máquinas. ¿Hay alguna manera de rastrear esto? (Estoy pensando en WireShark o algo similar). ¿Cómo puedo probar que mi token de autenticación se está aprobando y es válido?

Answer 1

El motivo del cuadro de autenticación es simple: Internet Explorer envía sus credenciales solo si cree que el host se encuentra en la zona "Intranet local" (se supone la configuración predeterminada). Si un host fuera de lo que IE considera "local" solicita credenciales NTLM, aparecerá un cuadro de autenticación y deberá autenticarse manualmente.

Si desea que sus credenciales se envíen automáticamente, asegúrese de que IE lo crea en "Intranet local". Verifique la información de la zona más a la derecha en la barra de estado para ver la zona actualmente activa.

IE tiene en cuenta varias cosas con el fin de decidir si un host se ha de considerar como "Intranet local":

1. es una dirección IP en la sub-red local - > SÍ
2. se trata de un simple nombre de host (es decir, "sin puntos") - > SÍ
3. en las opciones de IE: es en los "Sitios ..." lista de "Intranet local" - > SÍ
4. en las opciones de IE : está en la lista de exclusión de proxy - > SÍ
5. que es una ruta UNC - > SÍ
6. de otro modo: no
7. A veces, existe una contraseña antigua en la lista de contraseñas personales para ese nombre de host (accesible a través de Panel de control - > Cuentas de usuario). Si es incorrecto, pueden ocurrir problemas similares.

Mi sospecha es que su anfitrión "fred" no cumple con las condiciones # 2 a # 4, pero su caso de prueba "Betty" de alguna manera lo hace.

La forma en que se resolvió el nombre (registro CName, registro A, archivo hosts, otro) no hace diferencia, porque el método de resolución de nombre es opaco para la aplicación que realiza la llamada. IE solo pide el nombre "XYZ" y recupera una dirección IP.

Sin embargo, los cambios de configuración recientes pueden requerir que elimine la caché DNS local. Un ocasional ipconfig /flushdns ayudaría aquí, alternativamente puede detener el servicio de Cliente DNS por un tiempo.

La lógica interna descrita se aplica al nombre de host y la configuración de seguridad cambia en función del resultado.

Answer 2

CName sería una pista falsa. No tiene ningún efecto en la autenticación de Windows o no. La forma más fácil de rastrearlo es con el violín. Debería ver su solicitud seguida de una respuesta 401 (contiene la autenticación que admite el servidor), luego su solicitud nuevamente se envía con los detalles de autenticación (o se le solicita y luego se envía)