Sziasztok!
Az alábbi problémába futottam bele:
Adott egy user, aki 5-ször elrontotta a jelszavát és így zárolásra került a fiókja. A szokásos módon próbáltam feloldani, viszont hiába pipáltam be a fiók zárolásának feloldását, a fiók továbbra is zárolva maradt.
Eddig amit próbáltam:
MS Account Lockout - szépen kiírja, hogy dc1-en zárolta magát a user, megvan az 5 rontott jelszó, illetve az utolsó elrontás dátuma, dc2-n pedig szintén látszódik, hogy zárolt a fiók. Ezzel feloldva látszólag megtörténik a feloldás (nincs hibaüzenet), viszont frissítés után ugyanúgy locked státuszt kapok mindkét dc-n.
Próbáltam kerülő úton ADSI edit-el is megpiszkálni a usert, de erre visszamagyarázott, hogy nem engedélyezett, mivel a tulajdonosa SAM (emlékeim szerint ezzel alapvetően nincs is baj).
Más felhasználó esetén természetesen működik a feloldás, specifikus GPO nincs a user-en.
Mint utolsó utáni lehetőség, természetesen a user újbóli létrehozása is játszik, de első körben azért jó lenne valami törlés mentes megoldást találni.
- 2340 megtekintés
Hozzászólások
Szia, esetleg a user account nincs megadva plusz helyen, pl levelezés telefonon stb, ahol egy korábbi jelszóval próbál csatlakozni?
- A hozzászóláshoz be kell jelentkezni
Szerencsére nincs. Az AD egyedül PC-re belépéshez van használva (PC-n/laptop-on kívül mást nem is lehet használni a céges policy miatt). Ami egyébként érdekes, hogy a zárolás feloldásán kívül minden működik (a két DC között a replikáció is fénysebességű annak ellenére, hogy földrajzilag is máshol vannak a kiszolgálók). Jelenleg is egy kezdeti jelszó van beállítva (egyelőre kényszerített jelszóváltoztatás nélkül).
- A hozzászóláshoz be kell jelentkezni
Érdemes akkor a logokban megnézni milyen hibával zárolja a felhasználót.
ha jól emlékszem van az ms-nek egy Account Lockout Status toolja amivel ellenőrizhető az account.
- A hozzászóláshoz be kell jelentkezni
Ezt írtam is, hogy ránéztem vele, a logokat pedig elemzem, de eddig nem sok használhatót találtam.
- A hozzászóláshoz be kell jelentkezni
Egészséges az AD infrastruktúra?
Üdv,
Marci
- A hozzászóláshoz be kell jelentkezni
DC-k egészségesek (dcdiag csak pár kikapcsolt szerver miatt panaszkodik), órák másodpercre pontosan megegyeznek (másfél perccel előrébb járnak, mint a normális idő, de AD szinten DC1 órájához szinkronizál minden kliens/szerver).
Jelenleg a logokban próbálok valami használhatót keresni.
- A hozzászóláshoz be kell jelentkezni
Ha van hozzáférésed a DC-hez, akkor nézd meg az eventlog-ban, hogy volt-e a nevében authentikációs kérés (ha igen, honnan).
Illete dcdiag-al érdemes lenne a replikaciót ellenőrizni.
- A hozzászóláshoz be kell jelentkezni
+1
Mintha a két DC összeveszett volna.
- A hozzászóláshoz be kell jelentkezni
Elsőre nekem is DC összeveszésnek tűnt, ezért is kezdtem azzal, hogy a replikáció működik-e, illetve nincs-e időzavar a két DC között, de ezek, mint ahogyan egy másik hsz-ben jeleztem, nem állnak fent.
Eddig ráadásul a logok sem túlságosan beszédesek.
Az egyedüli szerencsém, hogy 100%-os hozzáférésem van mindkét DC-hez és ha kell bármilyen szoftvert felrakhatok + ha kell, akkor a hétvégén bármikor újraindíthatom a DC-ket.
- A hozzászóláshoz be kell jelentkezni
Nekünk anno a lockoutstatus nevű tool segített... ez megjeleníti, hogy melyik DC mit tud az accountról, és unlockolhatod is vele DC-nként. Előfordult kb. tíz éve, hogy egy nagy forestben a
replikáció lassúsága miatt 'összevesztek' a DC-k egy accounton. Lásd:
https://community.spiceworks.com/how_to/48758-trace-the-source-of-a-bad…
Letöltés: https://www.microsoft.com/en-us/download/details.aspx?id=15201
- A hozzászóláshoz be kell jelentkezni
Esetemben, ahogyan több hozzászólásban is jeleztem, a replikáció, időszinkron és minden egyéb jól működik/működött. A hiba, mint kiderült részben user error volt (többször el lett mondva a kollégának, hogy ne az x-et nyomogassa, ha már nem futtatja a dolgait, de hétfőn valószínűleg megint muszáj lesz írni neki) részben pedig MS eredetű. Leválasztott, de nem megszüntett RDP session és menet közben megváltozott jelszó kombinációja volt az instant fiókzárolás oka.
- A hozzászóláshoz be kell jelentkezni
Értem. Ennek ellenére ez egy hasznos tool.
- A hozzászóláshoz be kell jelentkezni
Órák pontosak a DC-ken?
Üdv,
Marci
- A hozzászóláshoz be kell jelentkezni
Meglett a megoldás, amit röviden vázolnék is:
A user az egyik szerverre RDP-vel be volt jelentkezve, mivel van olyan szoftver, ami itt fut és praktikussági megfontolásból nem rakjuk fel kliens pc-re.
A user nem lépett ki a szerverről csak bezárta az rdp-t, így ez a sz..r reflexből tiltotta ki a usert közvetlenül a feloldás után. Amint kivágtam a usert a szerverről, egyből fel tudtam oldani a fiókját és be is tudok lépni vele, szóval hétfőn már használhatja a saját fiókját.
Mindenkinek köszönöm az ötletet, a megoldáshoz végül az eseménynapló és a 4740-es eseményazonosító (thx MS fórum) vezetett.
- A hozzászóláshoz be kell jelentkezni
GPO-ból tudod kényszeríteni h. adott disconnect time letelte után dobja ki az inaktív RDP session-t a szerver, így nem maradnak ott a végtelenségig. Azaz ilyen lockoutokat se tud okozni.
--
- A hozzászóláshoz be kell jelentkezni
Ezt feljegyzem...
- A hozzászóláshoz be kell jelentkezni
+1 a GPO-ból kidobásra, de úgy néz ki, hogy nem csak a user session időkorlátja lesz limitálva, hanem újra lesz tervezve a feladatok ezen része és megszűnik az RDP-zés.
- A hozzászóláshoz be kell jelentkezni