Per què una sol·licitud de proxy demana contrasenya mentre Kerberos funciona per a altres
Trobeu la regla de política que assigna un regne d'autenticació de proxy inesperat a una sol·licitud, tot i que altres sol·licituds usen Kerberos correctament.
Diverses sol·licituds usen Kerberos correctament a través del proxy de l'empresa. Una sol·licitud provoca una petició de contrasenya. Abans de substituir un keytab, comproveu quina política d'autenticació ha seleccionat aquesta sol·licitud en concret.
Una passarel·la pot triar un regne i uns esquemes compatibles mitjançant la política. Dues transaccions que arriben al mateix proxy des del mateix navegador no han de rebre els mateixos requisits d'autenticació.
Considereu aquest registre hipotètic:
| Transacció | Primera regla coincident | Autenticació disponible |
|---|---|---|
| Document principal | Regla de navegació gestionada | Negotiate |
| Script d'un altre amfitrió | Excepció de destinació anterior | Basic o NTLM |
El primer intercanvi correcte demostra que un camí seleccionat funciona. No demostra que la segona transacció hagi arribat a aquest camí. Una credencial pot ser vàlida mentre la regla que tria el seu mecanisme d'autenticació és incorrecta.
Inspeccioneu la regla seleccionada i el seu ordre
Relacioneu la destinació i l'hora de la sol·licitud desafiada amb el registre de política de la passarel·la. Identifiqueu el regne, les opcions d'esquema i el mode d'autenticació que produeix la primera regla aplicable. Compareu aquests valors amb una sol·licitud correcta del mateix client.
Una política basada en una identitat associada a una IP també pot comportar-se de manera diferent d'una que requereix autenticació a la connexió. No assumiu que l'absència d'una nova negociació significa que s'ha triat el mateix regne.
Si el recurs ha caigut en una excepció no desitjada, corregiu aquesta regla o el seu abast i reviseu el registre resultant. Ampliar els mètodes d'autenticació permesos a tot arreu pot amagar la discrepància, però canvia el comportament d'accés de trànsit no relacionat.
Si s'ha triat el regne previst i l'intercanvi esperat falla, passeu a les proves del compte i de Kerberos. És llavors quan el tiquet, el nom del servei o el diagnòstic del backend esdevenen rellevants.