Varför en proxybegäran begär lösenord medan Kerberos fungerar för andra
Hitta policyregeln som tilldelar en begäran en oväntad proxyautentiseringsdomän, även när andra begäranden använder Kerberos framgångsrikt.
Flera begäranden använder Kerberos framgångsrikt via företagets proxy. En begäran ger en lösenordsfråga. Innan du byter ut en keytab, kontrollera vilken autentiseringspolicy just den begäran valde.
En gateway kan välja en domän och stödda scheman via policy. Två transaktioner som når samma proxy från samma webbläsare behöver inte få samma autentiseringskrav.
Betrakta detta hypotetiska spår:
| Transaktion | Första matchande policy | Tillgänglig autentisering |
|---|---|---|
| Huvuddokument | Hanterad surfregel | Negotiate |
| Skript från en annan värd | Tidigare destinationsundantag | Basic eller NTLM |
Det första lyckade utbytet visar att en vald väg fungerar. Det visar inte att den andra transaktionen nådde den vägen. En autentiseringsuppgift kan vara giltig medan regeln som väljer dess autentiseringsmekanism är fel.
Undersök den valda regeln och dess ordning
Korrelera den utmanade begärans destination och tid med gatewayens policyspår. Identifiera domänen, schemavalen och autentiseringsläget som den första tillämpliga regeln producerar. Jämför dessa värden med en lyckad begäran från samma klient.
En policy baserad på en IP-kopplad identitet kan också bete sig annorlunda än en som kräver autentisering på en anslutning. Anta inte att avsaknaden av ett nytt handskakning betyder att samma domän valdes.
Om resursen hamnade i ett oavsiktligt undantag, korrigera den regeln eller dess omfattning och granska spåret som uppstår. Att utöka tillåtna autentiseringsmetoder överallt kan dölja avvikelsen men ändrar åtkomstbeteendet för orelaterad trafik.
Om den avsedda domänen väljs och det förväntade utbytet misslyckas, fortsätt till bevisen för kontot och Kerberos. Då blir biljetten, tjänstenamnet eller backenddiagnostiken relevant.