Чаму адзін запыт праз праксі патрабуе пароль, калі Kerberos працуе для іншых
Знайдзіце правіла палітыкі, якое прызначае нечаканы рэал аўтэнтыфікацыі праксі аднаму запыту, нават калі іншыя запыты паспяхова выкарыстоўваюць Kerberos.
Некалькі запытаў паспяхова выкарыстоўваюць Kerberos праз карпаратыўны праксі. Адзін запыт выдае запыт пароля. Перш чым замяняць keytab, праверце, якую палітыку аўтэнтыфікацыі абраў менавіта гэты запыт.
Шлюз можа выбраць рэал і падтрыманыя схемы праз палітыку. Дзве транзакцыі, якія трапляюць на той жа праксі з таго ж браўзера, не абавязаны атрымліваць аднолькавыя патрабаванні аўтэнтыфікацыі.
Разгледзім гэты гіпатэтычны след:
| Транзакцыя | Першае адпаведнае правіла | Даступная аўтэнтыфікацыя |
|---|---|---|
| Галоўны дакумент | Кіраванае правіла аглядання | Negotiate |
| Скрыпт з іншага хоста | Папярэдняе выключэнне прызначэння | Basic або NTLM |
Першы паспяховы абмен паказвае, што адзін выбраны шлях працуе. Ён не паказвае, што другая транзакцыя дасягнула гэтага шляху. Уліковыя дадзеныя могуць быць слушнымі, а правіла, якое выбірае механізм аўтэнтыфікацыі, — не.
Праверце выбранае правіла і яго парадак
Супвяжыце прызначэнне і час запыту, які атрымаў выклік, са следам палітыкі шлюза. Вызначце рэал, выбраныя схемы і рэжым аўтэнтыфікацыі, якія стварае першае дастасавальнае правіла. Параўнайце гэтыя значэнні з паспяховым запытам таго ж кліента.
Палітыка, заснаваная на ідэнтычнасці, звязанай з IP, таксама можа паводзіць сябе інакш, чым палітыка, якая патрабуе аўтэнтыфікацыі на злучэнні. Не думайце, што адсутнасць новага рукапоціску азначае выбар таго ж рэалу.
Калі рэсурс трапіў у ненаўмыснае выключэнне, выпраўце гэтае правіла або яго межы і перагледзьце атрыманы след. Пашырэнне дазволеных метадаў аўтэнтыфікацыі паўсюль можа схаваць неадпаведнасць, але зменіць паводзіны доступу для непаўязанага трафіку.
Калі выбраны патрэбны рэал, а чаканы абмен не ўдаецца, перайдзіце да сведчанняў уліковага запісу і Kerberos. Менавіта тут становяцца важнымі білет, імя службы або дыягностыка бэкенда.