De ce o singură cerere prin proxy cere parolă când Kerberos funcționează pentru altele

Mai multe cereri folosesc Kerberos cu succes prin proxy-ul companiei. O cerere produce o solicitare de parolă. Înainte de a înlocui un keytab, verificați ce politică de autentificare a ales acea cerere anume.

Un gateway poate alege un domeniu și scheme acceptate prin politică. Două tranzacții care ajung la același proxy din același browser nu trebuie să primească aceleași cerințe de autentificare.

Luați în considerare această urmă ipotetică:

Primul schimb reușit arată că o cale selectată funcționează. Nu arată că a doua tranzacție a ajuns pe acea cale. O acreditare poate fi validă în timp ce regula care îi alege mecanismul de autentificare este greșită.

Examinați regula selectată și ordinea ei

Corelați destinația și ora cererii contestate cu urma de politică a gateway-ului. Identificați domeniul, opțiunile de schemă și modul de autentificare produse de prima regulă aplicabilă. Comparați acele valori cu o cerere reușită de la același client.

O politică bazată pe o identitate asociată cu IP poate să se comporte diferit de una care cere autentificare pe conexiune. Nu presupuneți că absența unui handshake nou înseamnă că s-a ales același domeniu.

Dacă resursa a căzut într-o excepție nedorită, corectați acea regulă sau domeniul ei și reexaminați urma rezultată. Lărgirea metodelor de autentificare permise peste tot poate ascunde nepotrivirea, dar schimbă comportamentul de acces pentru traficul nelegat.

Dacă se selectează domeniul dorit și schimbul așteptat eșuează, continuați cu dovezile despre cont și Kerberos. Atunci devin relevante biletul, numele serviciului sau diagnosticarea backend-ului.