Por que unha solicitude de proxy pide contrasinal mentres Kerberos funciona para outras
Atope a regra de política que asigna un dominio de autenticación de proxy inesperado a unha solicitude, aínda que outras solicitudes usan Kerberos correctamente.
Varias solicitudes usan Kerberos correctamente a través do proxy da empresa. Unha solicitude xera unha solicitude de contrasinal. Antes de substituír un keytab, comprobe que política de autenticación seleccionou esa solicitude en concreto.
Unha pasarela pode elixir un dominio e esquemas compatibles mediante política. Dúas transaccións que chegan ao mesmo proxy desde o mesmo navegador non teñen por que recibir os mesmos requisitos de autenticación.
Considere este rastro hipotético:
| Transacción | Primeira regra coincidente | Autenticación dispoñible |
|---|---|---|
| Documento principal | Regra de navegación xestionada | Negotiate |
| Script doutro host | Excepción de destino anterior | Basic ou NTLM |
O primeiro intercambio correcto demostra que unha ruta seleccionada funciona. Non demostra que a segunda transacción chegase a esa ruta. Unha credencial pode ser válida mentres a regra que escolle o seu mecanismo de autenticación é incorrecta.
Inspeccione a regra seleccionada e a súa orde
Correlacione o destino e a hora da solicitude desafiada co rastro de política da pasarela. Identifique o dominio, as opcións de esquema e o modo de autenticación que produce a primeira regra aplicable. Compare eses valores cunha solicitude correcta do mesmo cliente.
Unha política baseada nunha identidade asociada a un IP tamén pode comportarse de forma distinta a unha que esixe autenticación na conexión. Non supoña que a ausencia dun novo handshake significa que se escolleu o mesmo dominio.
Se o recurso caeu nunha excepción non desexada, corrixa esa regra ou o seu alcance e revise o rastro resultante. Ampliar os métodos de autenticación permitidos en todas partes pode ocultar a discrepancia, pero cambia o comportamento de acceso do tráfico non relacionado.
Se se escolle o dominio previsto e o intercambio esperado falla, continúe coas probas da conta e de Kerberos. É entón cando o ticket, o nome do servizo ou o diagnóstico do backend pasan a ser relevantes.