Ez az LDAP jelszóhiba talán nem is a felhasználó jelszava

Egy felhasználó jelszavának visszaállítása rossz első lépés, amikor a napló csak annyit mond, hogy egy bind elutasítva. Egy könyvtár-bővítménynél egyetlen bejelentkezésben több bind is van, és az elutasítás a keresést végző szolgáltatásfiókhoz tartozhat. A felhasználó hitelesítő adatainak visszaállítása ebben az esetben semmit sem változtat. Sőt kizár valakit, aki soha nem volt a probléma.

Egy bejelentkezés, több bind

A dedikált könyvtáriókával rendelkező konfiguráció általában négy lépést hajt végre sorrendben, és bármelyikük befejezheti a bejelentkezést.

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

A bővítmény a felhasználói hitelesítési kapcsolatát ugyanazzal a segéddel építi fel, amely az első kapcsolatot kezeli, így ez a segéd meghiúsulhat kapcsolódás közben, a TLS egyeztetése közben vagy szolgáltatásfiókként végzett bind közben. A jelszóval kapcsolatos magas szintű üzenet később készül el, és nem hordozza, melyik identitás vett részt benne. Ezért a hibaüzenet önmagában nem mondhatja meg, hogy a felhasználót vagy a szolgáltatásfiókot utasították-e el.

Olvassa el az üzenet előtti sorokat, és jegyezze fel a hiba pillanatát. Az indítási elutasítás, mielőtt bármely felhasználó megérkezne, a beállított fiókra vagy a végpontra mutat. Az egy személynél, sikeres keresés után megjelenő elutasítás az illető bejegyzésére vagy fiókállapotára mutat.

Párosítsa a hibát identitással

A gyakorlati szabály három dolgot együtt rögzíteni: mikor hibázott, milyen művelet futott és milyen identitás jelent meg. E hármas nélkül két nagyon különböző hiba egyformán néz ki egy naplóban, amely csak az utolsó mondatot őrzi meg.

Ha a beállított fiók hibázik, vizsgálja meg azt a fiókot és a kapcsolatot, mielőtt bármely felhasználói rekordhoz nyúlna. Ha a felhasználói bind sikeres keresés után hibázik, vizsgálja meg a keresés által visszaadott bejegyzést, nem azt, amelyről feltételezte, hogy visszaadja. A két útvonal egy üzenetet oszt meg, és semmi mást. Jegyezze fel, melyiket zárta ki, mert a következő ember pontosan azt fogja kérdezni.

A megkülönböztető név adat, nem találgatás

Egy névösszetevő megváltoztatása, mert ismeretlennek tűnik, gyakori módja egy működő konfiguráció elrontásának. A felhasználói objektumok alapértelmezett helye az Active Directoryban egy Users nevű tároló, és a tároló nem ugyanolyan típusú objektum, mint egy hasonló nevű szervezeti egység.

Kérje meg a könyvtár rendszergazdáját a fiók tényleges megkülönböztető nevéért, vagy olvassa ki magából az objektumból. Mindkettő helyes lehet a saját könyvtárában, ezért egyiket sem szabad emlékezetből beírni.

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

Az áthelyezés vagy átnevezés megváltoztatja ezt az értéket, miközben a fiók és a jelszó érvényes marad, így egy múlt negyedévben működő konfiguráció ebben a negyedévben meghiúsulhat anélkül, hogy bárki hozzányúlna egy hitelesítő adathoz. Hasonlítsa össze a beállított karakterláncot a könyvtár aktuális attribútumával bármilyen átszervezés után. Tegye ezt csendes migráció után is, ne csak jelentett kiesés után.

A keresési alap nem szolgáltatásfiók

A bind identitás és a keresési alap különböző kérdésekre válaszol: kiként hitelesít a bővítmény, és hol keresi az embereket. A sikeres bind, amelyet nem követ megfelelő felhasználó, hatókör-, szűrő- vagy olvasási jogosultsági probléma, és a fiók megkülönböztető nevének a felhasználók alapjával való helyettesítése semmit sem változtat ezen.

Erősítse meg, hogy a szolgáltatás betöltötte a szerkesztett konfigurációt, és hogy a végpontja, TLS-bizalma és hitelesítési módja megfelel egy működő adminisztratív tesztnek. Egy kézi lekérdezés más fiókkal vagy más tartományvezérlő ellen nem egyenértékű kísérlet.

Ellenőrizze a tárolt titkot, és ellenőrizze, hogy a fiók engedélyezett, lejárt vagy zárolt-e, anélkül hogy a jelszót bárhol kinyomtatná. A lejáratot könnyű elnézni, mert a fiók addig működik, amíg egy nap nem működik tovább. Egy független szolgáltatástól örökölt zárolás ugyanolyan csendes. Egyik állapot sem hoz létre olyan üzenetet, amely megnevezné a szolgáltatásfiókot.

A csoportszabályok jönnek utolsóként

Az engedélyezés a sikeres bindek után fut, így egy csoportellenőrzés nem lehet a bind hiba oka, és a csoportkövetelmény eltávolítása sem javíthatja meg. Ha a bejelentkezés most eléri a csoport szakaszát, a fennmaradó probléma a tagság, nem a hitelesítő adatok.

Ha széles könyvtári jogokat ad a szolgáltatásfióknak, hogy a hiba eltűnjön, az a teljes telepítés hozzáférési szabályzatát változtatja meg. Kezelje ezt saját felülvizsgálattal járó biztonsági döntésként, nem pedig egy olyan üzenet javításaként, amelyet még nem tulajdonított identitásnak.