Tiu eraro pri LDAP-pasvorto eble tute ne rilatas al la pasvorto de la uzanto
Malsukceso de bind povas veni de la serva konto aŭ de la serĉamplekso, ne de la uzanto. Apartigu la bind-ojn antaŭ ol restarigi la pasvorton de iu ajn.
Restarigi la pasvorton de uzanto estas la malĝusta unua paŝo, kiam la protokolo nur diras, ke bind estis rifuzita. Ĉe kataloga kromaĵo estas pli ol unu bind en unu ensaluto, kaj la rifuzo povas aparteni al la serva konto, kiu faras la serĉon. Restarigi la akreditaĵojn de la uzanto en tiu kazo ŝanĝas nenion. Ĝi ankaŭ ŝlosas iun, kiu neniam estis la problemo.
Unu ensaluto, pluraj bind-oj
Agordo kun dediĉita kataloga konto kutime plenumas kvar paŝojn en ordo, kaj iu ajn el ili povas fini la ensaluton.
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 groupsLa kromaĵo konstruas sian uzantan akreditan konekton per la sama helpilo, kiu administras la unuan konekton, do tiu helpilo povas malsukcesi dum konektado, dum intertraktado de TLS aŭ dum bind kiel la serva konto. La alta mesaĝo pri pasvorto estas generita poste, kaj ĝi ne portas, kiu identeco estis implikita. Tial la erarteksto sola ne povas diri al vi, ĉu la uzanto aŭ la serva konto estis rifuzita.
Legu la liniojn antaŭ la mesaĝo kaj notu la momenton, kiam la malsukceso okazis. Rifuzo ĉe ekfunkciigo, antaŭ ol iu uzanto alvenas, indikas la agorditan konton aŭ la finpunkton. Rifuzo, kiu aperas nur por unu persono, post sukcesa serĉo, indikas la rikordon aŭ kontostaton de tiu persono.
Parigu la eraron kun identeco
La praktika regulo estas registri tri aferojn kune: kiam ĝi malsukcesis, kiu operacio funkciis kaj kiu identeco estis prezentita. Sen tiu triopo, du tre malsamaj paneoj aspektas identaj en protokolo, kiu konservas nur la lastan frazon.
| 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 |
Se la agordita konto malsukcesas, inspektu tiun konton kaj la konekton antaŭ ol tuŝi iun ajn uzantrikordon. Se la uzanta bind malsukcesas post sukcesa serĉo, ekzamenu la rikordon, kiun la serĉo redonis, anstataŭ tiun, kiun vi supozis, ke ĝi redonos. La du vojoj dividas mesaĝon kaj nenion alian. Notu, kiun vi ekskludis, ĉar la sekva persono demandos ĝuste tion.
La distingiga nomo estas dateno, ne konjekto
Ŝanĝi nomkomponanton ĉar ĝi aspektas nekonata estas ofta maniero rompi funkciantan agordon. La defaŭlta loko por uzantobjektoj en Active Directory estas ujo nomata Users, kaj ujo ne estas la sama speco de objekto kiel organiza unuo kun simila nomo.
Petu de la kataloga administranto la realan distingigan nomon de la konto, aŭ legu ĝin el la objekto mem. Ambaŭ el la sekvaj povas esti ĝustaj en sia propra katalogo, tial neniu el ili estu tajpita el memoro.
CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=exampleMovo aŭ renomigo ŝanĝas tiun valoron dum la konto kaj pasvorto restas validaj, do agordo, kiu funkciis la pasintan kvaronjaron, povas malsukcesi ĉi tiun, sen ke iu ajn tuŝas akreditaĵon. Komparu la agorditan ĉenon kun la nuna atributo de la katalogo post iu ajn reorganizado. Faru tion ankaŭ post kvieta migrado, ne nur post raportita paneo.
Serĉobazo ne estas serva konto
La bind-identeco kaj la serĉobazo respondas malsamajn demandojn: kiel la kromaĵo aŭtentikigas kaj kie ĝi serĉas homojn. Sukcesa bind sekvata de neniu kongrua uzanto estas problemo de amplekso, filtrilo aŭ legrajto, kaj anstataŭigi la distingigan nomon de la konto per la bazo de la uzantoj ŝanĝas nenion pri tio.
Konfirmu, ke la servo ŝargis la agordon, kiun vi redaktis, kaj ke ĝia finpunkto, TLS-fido kaj aŭtentiga reĝimo kongruas kun funkcianta administra testo. Mana serĉo kun alia konto aŭ kontraŭ alia domajna regilo ne estas ekvivalenta eksperimento.
Kontrolu la konservitan sekreton, kaj kontrolu, ĉu la konto estas ebligita, eksvalidiĝinta aŭ ŝlosita, sen presi la pasvorton ie ajn. Eksvalidiĝo facile mankas, ĉar la konto daŭre funkcias ĝis la tago, kiam ĝi ne plu funkcias. Ŝloso heredita de nerilata servo estas same silenta. Neniu el la du kondiĉoj produktas mesaĝon, kiu nomas la servan konton.
Grupaj reguloj venas laste
Rajtigo funkcias post kiam la bind-oj sukcesas, do grupa kontrolo ne povas esti la kaŭzo de bind-malsukceso, kaj forigi la grupan postulon ne povas ripari ĝin. Se la ensaluto nun atingas la grupan stadion, la restanta problemo estas membreco, ne akreditaĵoj.
Doni al la serva konto larĝajn katalogajn rajtojn por igi la eraron malaperi ŝanĝas la alirpolitikon de la tuta deplojo. Traktu tion kiel sekurecan decidon kun propra revizio, ne kiel riparon por mesaĝo, kiun vi ankoraŭ ne atribuis al identeco.