Pse një kërkesë proxy kërkon fjalëkalim ndërsa Kerberos funksionon për të tjerat
Gjeni rregullin e politikës që i cakton një kërkese një fushë autentikimi proxy të papritur, edhe kur kërkesat e tjera përdorin Kerberos me sukses.
Disa kërkesa përdorin Kerberos me sukses përmes proxy-t të kompanisë. Një kërkesë prodhon një kërkesë për fjalëkalim. Përpara se të zëvendësoni një keytab, kontrolloni cilën politikë autentikimi zgjodhi pikërisht ajo kërkesë.
Një gateway mund të zgjedhë një fushë dhe skema të mbështetura përmes politikës. Dy transaksione që arrijnë në të njëjtin proxy nga i njëjti shfletues nuk duhet domosdoshmërisht të marrin të njëjtat kërkesa autentikimi.
Merrni parasysh këtë gjurmë hipotetike:
| Transaksioni | Rregulli i parë që përputhet | Autentikimi i disponueshëm |
|---|---|---|
| Dokumenti kryesor | Rregulli i shfletimit të menaxhuar | Negotiate |
| Skript nga një host tjetër | Përjashtim i mëparshëm i destinacionit | Basic ose NTLM |
Shkëmbimi i parë i suksesshëm tregon se një rrugë e zgjedhur funksionon. Nuk tregon se transaksioni i dytë arriti në atë rrugë. Një kredencial mund të jetë i vlefshëm ndërsa rregulli që zgjedh mekanizmin e tij të autentikimit është i gabuar.
Shqyrtoni rregullin e zgjedhur dhe renditjen e tij
Ndërlidhni destinacionin dhe kohën e kërkesës së sfiduar me gjurmën e politikës së gateway-t. Identifikoni fushën, zgjedhjet e skemës dhe modalitetin e autentikimit që prodhon rregulli i parë i zbatueshëm. Krahasoni ato vlera me një kërkesë të suksesshme nga i njëjti klient.
Një politikë e bazuar në një identitet të lidhur me IP mund të sillet ndryshe nga një që kërkon autentikim në lidhje. Mos supozoni se mungesa e një shtrëngimi të re duhet të thotë se është zgjedhur e njëjta fushë.
Nëse burimi ra në një përjashtim të paqëllimshëm, korrigjoni atë rregull ose shtrirjen e tij dhe rishikoni gjurmën që rezulton. Zgjerimi i metodave të lejuara të autentikimit kudo mund të fshehë mospërputhjen, por ndryshon sjelljen e aksesit për trafikun e palidhur.
Nëse zgjidhet fusha e synuar dhe shkëmbimi i pritur dështon, vazhdoni te provat e llogarisë dhe Kerberos. Atëherë bëhen relevante bileta, emri i shërbimit ose diagnostifikimi i backend-it.