Ang error sa password ng LDAP ay maaaring hindi ang password ng user

Ang pag-reset ng password ng user ay maling unang hakbang kapag ang log ay nagsasabi lamang na tinanggihan ang isang bind. Sa isang plugin ng direktoryo may higit sa isang bind sa isang pag-login, at ang pagtanggi ay maaaring pagmamay-ari ng service account na nagsasagawa ng paghahanap. Ang pag-reset ng mga kredensyal ng user sa kasong iyon ay walang binabago. Ni-lock din nito ang isang taong hindi kailanman naging problema.

Isang pag-login, maraming bind

Ang isang configuration na may nakalaang account sa direktoryo ay karaniwang nagsasagawa ng apat na hakbang sa pagkakasunod-sunod, at alinman sa mga ito ay maaaring tapusin ang pag-login.

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

Binubuo ng plugin ang koneksyon nito para sa authentication ng user sa pamamagitan ng parehong helper na humahawak sa unang koneksyon, kaya ang helper na iyon ay maaaring mabigo habang kumokonekta, habang nakikipag-usap sa TLS, o habang nagbi-bind bilang service account. Ang mataas na antas na mensahe tungkol sa password ay nabuo mamaya, at hindi nito dala kung aling identity ang kasangkot. Kaya ang teksto ng error lamang ay hindi masasabi kung ang user o ang service account ang tinanggihan.

Basahin ang mga linya bago ang mensahe, at itala ang sandali nang nangyari ang pagkabigo. Ang pagtanggi sa pagsisimula, bago dumating ang sinumang user, ay tumuturo sa naka-configure na account o sa endpoint. Ang pagtanggi na lumilitaw lamang para sa isang tao, pagkatapos ng matagumpay na paghahanap, ay tumuturo sa entry o estado ng account ng taong iyon.

Iugnay ang error sa isang identity

Ang praktikal na tuntunin ay itala ang tatlong bagay nang sama-sama: kailan nabigo, anong operasyon ang tumatakbo, at anong identity ang iniharap. Kung wala ang triple na iyon, dalawang lubos na magkaibang fault ay magkamukha sa isang log na nag-iingat lamang ng huling pangungusap.

Kung mabigo ang naka-configure na account, siyasatin ang account na iyon at ang koneksyon bago hawakan ang anumang record ng user. Kung mabigo ang bind ng user pagkatapos ng matagumpay na paghahanap, suriin ang entry na ibinalik ng paghahanap, hindi ang inakala mong ibabalik nito. Ang dalawang landas ay nagbabahagi ng isang mensahe at wala nang iba. Isulat kung alin ang inalis mo, dahil ang susunod na tao ay magtatanong nang eksakto niyon.

Ang natatanging pangalan ay data, hindi haka-haka

Ang pagbabago ng isang bahagi ng pangalan dahil mukhang hindi pamilyar ay karaniwang paraan ng pagsira sa isang gumaganang configuration. Ang default na lokasyon ng mga user object sa Active Directory ay isang container na pinangalanang Users, at ang container ay hindi kaparehong uri ng object ng isang organizational unit na may katulad na pangalan.

Hilingin sa administrator ng direktoryo ang aktwal na natatanging pangalan ng account, o basahin ito mula sa object mismo. Pareho sa mga sumusunod ay maaaring tama sa kanilang sariling direktoryo, kaya wala sa kanila ang dapat i-type mula sa memorya.

CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example

Ang paglipat o pagpapalit ng pangalan ay nagbabago ng halagang iyon habang ang account at password ay nananatiling wasto, kaya ang isang configuration na gumana noong nakaraang quarter ay maaaring mabigo ngayong quarter nang walang sinumang humawak ng kredensyal. Ihambing ang naka-configure na string sa kasalukuyang attribute ng direktoryo pagkatapos ng anumang muling pagsasaayos. Gawin ito pagkatapos din ng tahimik na paglipat, hindi lamang pagkatapos ng iniulat na pagkawala.

Ang base ng paghahanap ay hindi service account

Ang identity ng bind at ang base ng paghahanap ay sumasagot sa magkaibang tanong: bilang sino nagpapatunay ng pagkakakilanlan ang plugin at saan ito naghahanap ng mga tao. Ang matagumpay na bind na sinusundan ng walang tugmang user ay problema sa saklaw, filter, o pahintulot sa pagbasa, at ang pagpapalit ng natatanging pangalan ng account ng base ng mga user ay walang binabago doon.

Kumpirmahin na na-load ng serbisyo ang configuration na in-edit mo at na ang endpoint, tiwala sa TLS, at mode ng authentication nito ay tumutugma sa isang gumaganang administratibong pagsubok. Ang manu-manong paghahanap gamit ang ibang account, o laban sa ibang domain controller, ay hindi katumbas na eksperimento.

Suriin ang nakaimbak na lihim, at suriin kung ang account ay pinagana, nag-expire, o naka-lock, nang hindi ipiniprinta ang password kahit saan. Ang pag-expire ay madaling makaligtaan dahil ang account ay patuloy na gumagana hanggang sa araw na hindi na. Ang lock na namana mula sa isang walang kaugnayang serbisyo ay kasing tahimik. Wala sa dalawang kondisyong iyon ang gumagawa ng mensaheng nagpapangalan sa service account.

Ang mga patakaran ng grupo ay huli

Ang awtorisasyon ay tumatakbo pagkatapos ng matagumpay na bind, kaya ang pagsusuri ng grupo ay hindi maaaring maging sanhi ng pagkabigo ng bind, at ang pag-alis ng kinakailangan sa grupo ay hindi makakapag-ayos nito. Kung ang pag-login ay umabot na ngayon sa yugto ng grupo, ang natitirang problema ay pagiging miyembro, hindi kredensyal.

Ang pagbibigay sa service account ng malawak na karapatan sa direktoryo upang mawala ang error ay nagbabago ng patakaran sa pag-access ng buong deployment. Ituring ito bilang desisyong pangseguridad na may sariling pagsusuri, hindi bilang pagwawasto para sa isang mensaheng hindi mo pa iniuugnay sa isang identity.