[Server 2003] Opzoeken Locked Accounts

[YellowOnline]

Een klassieker. Op 2003 is alles altijd wat moeilijker.



Event 675 toont ons mislukte wachtwoordpogingen. Eigenlijk zou er een Event 644 moeten zijn op het moment dat een account effectief geblokkeerd word. Helaas: 644 is niet te vinden. Ik heb de GPO voor DCs aangepast en als ik het goed heb zou ik alles moeten hebben opdat dit gelogd wordt. Of niet?



Kontenverwaltung (Account Management) zou de juiste moeten zijn. En we willen Erfolgreich (Success) want het blokkeren van een account is een succesvolle actie.

[ Voor 31% gewijzigd door YellowOnline op 02-02-2016 17:08 ]

[Razwer]

probeer deze eens
https://www.microsoft.com...oad/details.aspx?id=18465

[YellowOnline]

Razwer schreef op dinsdag 02 februari 2016 @ 18:34:
probeer deze eens
https://www.microsoft.com...oad/details.aspx?id=18465

Die brengen mij geen stap verder - die zijn vooral handig als je wil uitvinden op welke DC een account gelockt is. Wat mij interesseert is de client! Uiteindelijk lezen die tools en scripts ook alleen maar de event viewer uit. Idem dito voor Netwrix Account Lockout Examiner trouwens: daar is het betreffende veld ("WORKSTATION") gewoon blanco.

[CMD-Snake]

Moet je niet eens die 2003 machine uit gaan zetten? Zeker domain controllers kan je nog relatief eenvoudig aflossen met een exemplaar wat een recentere versie draait van Windows Server. (En installeer het OS dan even in de Engelse taal. )

Welke client de foutieve logon plaats heeft gevonden komt wel terug in de logs, ook op de DC. Wel moet je kijken op een van de domain controllers die de foutieve logon afgehandeld heeft. Het lockout tooltje is daar heel handig voor.

Je moet zoeken op Event ID 529 voor Windows Server 2003 en eerder. Op Windows Server 2008R2 (en later) zoek je naar Event ID 4771.

Je wil de events hebben met een van bovenstaande ID's die Failure code 0x18 bevatten. Deze logmeldingen bevatten het IP adres van de client waar de foutieve logon plaats heeft gevonden. Dit staat onder het kopje Network Information.

Met het IP moet je redelijk snel de bron gevonden hebben. In jouw schermprintje zie ik de client IP adres ook staan.

Voor Windows 2003 had je daar ook nog een tooltje voor, eventcombmt.exe. Je kan het daar ook nog downloaden bij Microsoft zo te zien.

[YellowOnline]

CMD-Snake schreef op dinsdag 02 februari 2016 @ 19:44:
Moet je niet eens die 2003 machine uit gaan zetten? Zeker domain controllers kan je nog relatief eenvoudig aflossen met een exemplaar wat een recentere versie draait van Windows Server. (En installeer het OS dan even in de Engelse taal. )

Ik ben met de migratie bezig... nog een stuk of 40 DCs te gaan. De meeste van die krengen zijn ook nog DNS en DHCP naast andere rollen (Print Server! File Server!). En dat over 14 domeinen in 1 forest. Heb je al eens DHCP gemigreerd tussen verschillende taalversies? Dat is niet voor gevoelige zieltjes

Om maar te zeggen: helemaal akkoord, maar veel gemakkelijker gezegd dan gedaan.

Welke client de foutieve logon plaats heeft gevonden komt wel terug in de logs, ook op de DC. Wel moet je kijken op een van de domain controllers die de foutieve logon afgehandeld heeft. Het lockout tooltje is daar heel handig voor.

Je moet zoeken op Event ID 529 voor Windows Server 2003 en eerder. Op Windows Server 2008R2 (en later) zoek je naar Event ID 4771.

Je wil de events hebben met een van bovenstaande ID's die Failure code 0x18 bevatten. Deze logmeldingen bevatten het IP adres van de client waar de foutieve logon plaats heeft gevonden. Dit staat onder het kopje Network Information.

Met het IP moet je redelijk snel de bron gevonden hebben. In jouw schermprintje zie ik de client IP adres ook staan.

Noch 529 noch 644 komen voor (528 daarentegen wel) - vandaar dat ik rondneus in de Auditing GPO. Source IP staat inderdaad in de 675, maar de reden dat ik dit zoek is voor een automatisering - dwz. ik zoek een oplossing die ik in een logica kan gieten, niet die een mens visueel kan uitzoeken. Op basis van een 644 kan ik zeggen dat account X gelocked is op moment Y vanop computer Z. Met een 675 moet ik al fameus parsen om de gebruiker er uit te vissen, tellen hoeveel meldingen er zijn en dit vergelijken met de Account Lock Policy. Of zoiets. Niets praktisch in ieder geval.

Voor Windows 2003 had je daar ook nog een tooltje voor, eventcombmt.exe. Je kan het daar ook nog downloaden bij Microsoft zo te zien.

Dat is een deel van wat Razwer gepost had.

[YellowOnline]

't Is blijkbaar een kwestie van geduld. Al had ik alle DCs in dat domein herstart om de GPO-verandering door te voeren, sinds 9:00 vanochtend verschijnen de 644. Ik snap niet helemaal waarom dat zolang geduurd heeft

[CMD-Snake]

YellowOnline schreef op dinsdag 02 februari 2016 @ 20:06:
Noch 529 noch 644 komen voor (528 daarentegen wel) - vandaar dat ik rondneus in de Auditing GPO. Source IP staat inderdaad in de 675, maar de reden dat ik dit zoek is voor een automatisering - dwz. ik zoek een oplossing die ik in een logica kan gieten, niet die een mens visueel kan uitzoeken. Op basis van een 644 kan ik zeggen dat account X gelocked is op moment Y vanop computer Z. Met een 675 moet ik al fameus parsen om de gebruiker er uit te vissen, tellen hoeveel meldingen er zijn en dit vergelijken met de Account Lock Policy. Of zoiets. Niets praktisch in ieder geval.

Maar wat is je doel? Automatisch meldingen krijgen als een account gelocked is geraakt?

[SteeringWheel]

CMD-Snake schreef op woensdag 03 februari 2016 @ 19:31:
[...]


Maar wat is je doel? Automatisch meldingen krijgen als een account gelocked is geraakt?

Maar vooral vanaf welke client. Hier wordt je helpdesk blij van kan ik uit eigen ervaring vertellen als je met users te maken hebt die over meerdere devices roamen en er weer eens een account locked

[YellowOnline]

SteeringWheel schreef op woensdag 03 februari 2016 @ 20:23:
[...]

Maar vooral vanaf welke client. Hier wordt je helpdesk blij van kan ik uit eigen ervaring vertellen als je met users te maken hebt die over meerdere devices roamen en er weer eens een account locked

Inderdaad. In dit geval is er één account dat door tientallen laboranten gebruikt wordt. Daar is enigszins een rationale voor (een fan ben ik niet), maar heeft als nadeel dat heel veel mensen dat account kunnen blokkeren en dat de impact groot is als het gebeurt. Mijn script zendt naar de plaatselijke verantwoordelijke elke failed attempt (675) en lock (644) met daarin source address en netbios name, zodat hij of zij weet wie of wat de oorzaak is. Vervolgens deblokkeer ik ook die account weer. Een andere policy voor één account gaat niet in 2003.

[ Voor 6% gewijzigd door YellowOnline op 04-02-2016 08:17 ]

[CMD-Snake]

YellowOnline schreef op donderdag 04 februari 2016 @ 08:13:
Een andere policy voor één account gaat niet in 2003.

De goede oude tijd als je een apart domein moest maken als je een ander wachtwoord policy wilde hebben.