Por qué una solicitud de proxy pide contraseña mientras Kerberos funciona para otras
Encuentre la regla de directiva que asigna un dominio de autenticación de proxy inesperado a una solicitud, incluso cuando otras solicitudes usan Kerberos correctamente.
Varias solicitudes usan Kerberos correctamente a través del proxy de la empresa. Una solicitud genera una petición de contraseña. Antes de sustituir un keytab, compruebe qué directiva de autenticación seleccionó esa solicitud en concreto.
Una pasarela puede elegir un dominio y esquemas compatibles mediante directiva. Dos transacciones que llegan al mismo proxy desde el mismo navegador no tienen por qué recibir los mismos requisitos de autenticación.
Considere este rastro hipotético:
| Transacción | Primera regla coincidente | Autenticación disponible |
|---|---|---|
| Documento principal | Regla de navegación administrada | Negotiate |
| Script de otro host | Excepción de destino anterior | Basic o NTLM |
El primer intercambio correcto demuestra que una ruta seleccionada funciona. No demuestra que la segunda transacción llegara a esa ruta. Una credencial puede ser válida mientras la regla que elige su mecanismo de autenticación es incorrecta.
Inspeccione la regla seleccionada y su orden
Correlacione el destino y la hora de la solicitud desafiada con el rastro de directiva de la pasarela. Identifique el dominio, las opciones de esquema y el modo de autenticación que produce la primera regla aplicable. Compare esos valores con una solicitud correcta del mismo cliente.
Una directiva basada en una identidad asociada a una IP también puede comportarse de forma distinta a una que exige autenticación en la conexión. No suponga que la ausencia de un nuevo handshake signifique que se eligió el mismo dominio.
Si el recurso cayó en una excepción no deseada, corrija esa regla o su alcance y revise el rastro resultante. Ampliar los métodos de autenticación permitidos en todas partes puede ocultar la discrepancia, pero cambia el comportamiento de acceso del tráfico no relacionado.
Si se elige el dominio previsto y el intercambio esperado falla, continúe con las pruebas de la cuenta y de Kerberos. Es entonces cuando el ticket, el nombre del servicio o el diagnóstico del backend pasan a ser relevantes.