Hvorfor én proxyforespørsel ber om passord mens Kerberos virker for andre
Finn policyregelen som gir én forespørsel et uventet proxyautentiseringsområde, selv når andre forespørsler bruker Kerberos med hell.
Flere forespørsler bruker Kerberos med hell gjennom bedriftens proxy. Én forespørsel utløser en passordforespørsel. Før du erstatter en keytab, sjekk hvilken autentiseringspolicy akkurat den forespørselen valgte.
En gateway kan velge et område og støttede skjemaer gjennom policy. To transaksjoner som når samme proxy fra samme nettleser, trenger ikke få de samme autentiseringskravene.
Se for deg dette hypotetiske sporet:
| Transaksjon | Første samsvarende policy | Tilgjengelig autentisering |
|---|---|---|
| Hoveddokument | Administrert nettleserregel | Negotiate |
| Skript fra en annen vert | Tidligere destinasjonsunntak | Basic eller NTLM |
Den første vellykkede utvekslingen viser at én valgt vei virker. Den viser ikke at den andre transaksjonen nådde den veien. En legitimasjon kan være gyldig mens regelen som velger autentiseringsmekanismen, er feil.
Undersøk den valgte regelen og rekkefølgen
Korrelér den utfordrede forespørselens destinasjon og tid med gatewayens policyspor. Identifiser området, skjemavalgene og autentiseringsmodusen som den første anvendelige regelen produserer. Sammenlign disse verdiene med en vellykket forespørsel fra samme klient.
En policy basert på en IP-tilknyttet identitet kan også oppføre seg annerledes enn en som krever autentisering på en tilkobling. Ikke anta at fraværet av et nytt håndtrykk betyr at samme område ble valgt.
Hvis ressursen falt inn i et utilsiktet unntak, rett opp den regelen eller omfanget, og gjennomgå sporet som oppstår. Å utvide tillatte autentiseringsmetoder overalt kan skjule misforholdet, men endrer tilgangsatferden for urelatert trafikk.
Hvis det tiltenkte området velges og den forventede utvekslingen mislykkes, gå videre til bevisene for kontoen og Kerberos. Da blir billetten, tjenestenavnet eller backend-diagnostikken relevant.