Kvifor ei proxyførespurnad ber om passord medan Kerberos virkar for andre
Finn policyregelen som tildeler éi førespurnad eit uventa proxyautentiseringsområde, sjølv når andre førespurnader brukar Kerberos med hell.
Fleire førespurnader brukar Kerberos med hell gjennom proxyen til verksemda. Éi førespurnad utløyser ei passordførespurnad. Før du byter ut ein keytab, må du sjekke kva autentiseringspolicy nettopp den førespurnaden valde.
Ein gateway kan velje eit område og støtta skjema gjennom policy. To transaksjonar som når same proxy frå same nettlesar, treng ikkje få dei same autentiseringskrava.
Vurder dette hypotetiske sporet:
| Transaksjon | Fyrste samsvarande policy | Tilgjengeleg autentisering |
|---|---|---|
| Hovuddokument | Styrt nettlesarregel | Negotiate |
| Skript frå ein annan vert | Tidlegare destinasjonsunntak | Basic eller NTLM |
Den fyrste vellukka utvekslinga viser at éin vald veg fungerer. Ho viser ikkje at den andre transaksjonen nådde den vegen. Ein legitimasjon kan vere gyldig medan regelen som vel autentiseringsmekanismen, er feil.
Undersøk den valde regelen og rekkjefølgja
Korreler destinasjonen og tida for den utfordra førespurnaden med policysporet til gatewayen. Identifiser området, skjemavala og autentiseringsmodusen som den fyrste gjeldande regelen lagar. Samanlikn desse verdiane med ein vellukka førespurnad frå same klient.
Ein policy basert på ein IP-knytt identitet kan òg oppføre seg annleis enn ein som krev autentisering på ei tilkopling. Ikkje gå ut frå at fråværet av eit nytt handtrykk tyder på at same område vart valt.
Viss ressursen hamna i eit utilsikta unntak, rett opp den regelen eller omfanget hans og gå gjennom sporet som kjem ut. Å utvide tillatne autentiseringsmetodar overalt kan skjule misforholdet, men endrar tilgangsåtferda for urelatert trafikk.
Viss det tiltenkte området vert valt og den venta utvekslinga mislukkast, gå vidare til prova for kontoen og Kerberos. Då vert billetten, tenestenamnet eller backend-diagnostikken relevant.