Гэтая памылка пароля LDAP можа быць зусім не паролем карыстальніка
Збой прывязвання можа паходзіць ад службовага ўліковага запісу або вобласці пошуку, а не ад карыстальніка. Раздзяляйце прывязванні, перш чым скідваць чыйсьці пароль.
Скідванне пароля карыстальніка — няправільны першы крок, калі журнал паведамляе толькі пра адмову ў прывязванні. У плагіне каталога за адзін уваход бывае больш за адно прывязванне, і адмова можа належаць службоваму ўліковаму запісу, які выконвае пошук. Скідванне ўліковых даных карыстальніка ў такім выпадку нічога не змяняе. Яно яшчэ і блакуе чалавека, які ніколі не быў прычынай праблемы.
Адзін уваход, некалькі прывязванняў
Канфігурацыя з асобным уліковым запісам каталога звычайна выконвае чатыры крокі па парадку, і любы з іх можа скончыць уваход.
connect to the directory and establish the configured TLS protection
bind as the configured service account
search for the user entry using the search base and filter
open a second connection and bind as that user, then evaluate groupsПлагін будуе сваё злучэнне для аўтэнтыфікацыі карыстальніка праз тую ж дапаможную функцыю, што абслугоўвае першае злучэнне, таму гэтая функцыя можа адмовіць падчас падключэння, падчас узгаднення TLS або падчас прывязвання як службовы ўліковы запіс. Паведамленне высокага ўзроўню пра пароль генеруецца пазней і не нясе інфармацыі пра тое, якая асоба была задзейнічана. Таму тэкст памылкі сам па сабе не можа сказаць, каму адмовілі — карыстальніку ці службоваму ўліковаму запісу.
Чытайце радкі перад паведамленнем і адзначце момант, калі адбыўся збой. Адмова пры запуску, перш чым з'явіцца хоць адзін карыстальнік, паказвае на наладжаны ўліковы запіс або на канчатковы пункт. Адмова, якая ўзнікае толькі для аднаго чалавека пасля паспяховага пошуку, паказвае на запіс гэтага чалавека або стан яго ўліковага запісу.
Спалучайце памылку з асобай
Практычнае правіла — запісваць тры рэчы разам: калі гэта здарылася, якая аперацыя выконвалася і якая асоба была прадстаўлена. Без гэтай тройкі два вельмі розныя збоі выглядаюць аднолькава ў журнале, які захоўвае толькі апошні сказ.
| What the log shows | Identity likely refused | First thing to check |
|---|---|---|
| Failure at start-up, no user yet | Service account | DN, password, expiry, lockout |
| Search returns nothing | None, the search scope is wrong | Search base and filter |
| Failure only for one user | That user's entry | Entry state, bind DN, group rules |
Калі наладжаны ўліковы запіс адмаўляе, агледзьце гэты запіс і злучэнне, перш чым кранаць любы запіс карыстальніка. Калі прывязванне карыстальніка не ўдалося пасля паспяховага пошуку, даследуйце запіс, які вярнуў пошук, а не той, які вы меркавалі атрымаць. Абодва шляхі маюць агульнае толькі паведамленне. Запішыце, які з іх вы выключылі, бо наступны чалавек спытае менавіта гэта.
Адметнае імя — гэта даныя, а не здагадка
Змяненне кампанента імя, таму што ён выглядае незнаёмым, — распаўсюджаны спосаб зламаць працоўную канфігурацыю. Прадвызначанае месца для аб'ектаў карыстальнікаў у Active Directory — гэта кантэйнер з назвай Users, а кантэйнер — не той самы тып аб'екта, што арганізацыйнае падраздзяленне з падобнай назвай.
Спытайце ў адміністратара каталога фактычнае адметнае імя ўліковага запісу або прачытайце яго з самога аб'екта. Абодва наступныя варыянты могуць быць правільнымі ў сваім каталозе, таму ні адзін з іх не варта ўводзіць па памяці.
CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=exampleПерамяшчэнне або перайменаванне змяняе гэтае значэнне, пакуль уліковы запіс і пароль застаюцца сапраўднымі, таму канфігурацыя, якая працавала ў мінулым квартале, можа не спрацаваць у гэтым, хоць ніхто не кранаў уліковыя даныя. Параўнайце наладжаны радок з бягучым атрыбутам каталога пасля любой рэарганізацыі. Зрабіце гэта і пасля ціхай міграцыі, а не толькі пасля заяўленага збою.
Вобласць пошуку — не службовы ўліковы запіс
Асоба прывязвання і вобласць пошуку адказваюць на розныя пытанні: ад чыйго імя аўтэнтыфікуецца плагін і дзе ён шукае людзей. Паспяховае прывязванне, пасля якога няма адпаведнага карыстальніка, — гэта праблема вобласці, фільтра або правоў на чытанне, і замена адметнага імя ўліковага запісу на базу карыстальнікаў нічога ў гэтым не змяняе.
Пераканайцеся, што служба загрузіла менавіта тую канфігурацыю, якую вы змянілі, і што яе канчатковы пункт, давер TLS і рэжым аўтэнтыфікацыі адпавядаюць працоўнай адміністрацыйнай праверцы. Ручны пошук з іншым уліковым запісам або на іншым кантролеры дамена — не эквівалентны эксперымент.
Праверце захаваны сакрэт і праверце, ці ўключаны ўліковы запіс, ці не скончыўся яго тэрмін і ці не заблакаваны ён, недзе не друкуючы пароль. Тэрмін лёгка прапусціць, бо запіс працягвае працаваць да таго дня, калі ўжо не. Блакаванне, атрыманае ў спадчыну ад незвязанай службы, такое ж ціхае. Ні адзін з гэтых станаў не дае паведамлення, якое называе службовы ўліковы запіс.
Правілы груп ідуць апошнімі
Аўтарызацыя выконваецца пасля паспяховых прывязванняў, таму праверка групы не можа быць прычынай збою прывязвання, і выдаленне патрабавання групы не можа яго выправіць. Калі ўваход цяпер дасягае этапу групы, астатняя праблема — членства, а не ўліковыя даныя.
Наданне службоваму ўліковаму запісу шырокіх правоў у каталозе, каб памылка знікла, змяняе палітыку доступу ўсяго разгортвання. Стаўцеся да гэтага як да рашэння па бяспецы з уласным аглядам, а не як да выпраўлення паведамлення, якое вы яшчэ не аднеслі да пэўнай асобы.