Windows Event viewer login events

[Nrt]

Beste Beyongamers,

Ik zou graag in mijn Event Viewer de succesvolle logins (Event ID 4624), failed logins (Event ID 4625) en de geblokkeerde accounts (Event ID 4740) willen terugzien. Maar hier slaag ik gewoon niet volledig in. Event ID 4625 en 4740 staan er vaak gewoon niet tussen en Event ID 4624 heeft vaak geen naam van de gebruiker die is ingelogd.

Hoe ga ik te werk: op mijn domain controler maak ik in de Group Policy Manager een GPO aan onder het domein. Daarna edit ik deze en ga door naar Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies.

Daar zet ik bij 'Audit Logon/Logoff' zowel 'Audit Logon' als 'Audit Account Lockout' op Succes and Failure.

Daarna zet ik bij 'Account Logon' ook nog de bovenste drie ( Audit credential validation, Audit Kerberos Authentication Service en Audit Kerberos Service Ticket Operations) op Succes and Failure.

Via de Command Prompt doe ik dan een Gpupdate /force.

Daarna begin het alle zaken met mijn clients te starten, maar zonder succes in de Event Viewer. Wat kan hier de oorzaak van zijn?

 

[Five-seveN]

Omdat je zegt "vaak niet" dus ook "vaak wel", kan je best een patroon zoeken wanneer wel en wanneer niet. Is gemakkelijk te testen denk ik?

 

[fomix]

Hoeveel domain controllers heb je?
Events worden niet gesynced tussen meerdere controllers.
LastLoginTimeStamp op een object is er ook zo eentje die niet synced.

Je audit op Kerberos Authentication Service -> heb je Kerberos authentication dan ook aan staan?
Het zou me niet verbazen als Kerberos events ook enkel gelogd worden op de domain controller die de KDC host.

Kerberos tickets zijn by default 8u geldig. Als een client aangelogd is zal je 8u moeten wachten alvorens hij een nieuw ticket aanvraagt of de client in kwestie herstarten.

Daarna begin het alle zaken met mijn clients te starten,

Tenzij je dat hier bedoelt, maar dat is me uit je zin niet helemaal duidelijk.

Weet ook dat als je deze policies aan de praat krijgt je overladen wordt met een bulk aan logging. De default van 32k lijnen zal rap volstaan op een domein met iets of wat clients. Vooral de succesvol logins. Of wil je een product genre Rapid7 aan de praat krijgen om analyse te doen op die data?
Wil je manueel door de data turven, beperk je dan eerste tot de foutieve loginpogingen. Just my 2 cents.

 

[Nrt]

Hoeveel domain controllers heb je?
Events worden niet gesynced tussen meerdere controllers.
LastLoginTimeStamp op een object is er ook zo eentje die niet synced.

Je audit op Kerberos Authentication Service -> heb je Kerberos authentication dan ook aan staan?
Het zou me niet verbazen als Kerberos events ook enkel gelogd worden op de domain controller die de KDC host.

Kerberos tickets zijn by default 8u geldig. Als een client aangelogd is zal je 8u moeten wachten alvorens hij een nieuw ticket aanvraagt of de client in kwestie herstarten.

Tenzij je dat hier bedoelt, maar dat is me uit je zin niet helemaal duidelijk.

Weet ook dat als je deze policies aan de praat krijgt je overladen wordt met een bulk aan logging. De default van 32k lijnen zal rap volstaan op een domein met iets of wat clients. Vooral de succesvol logins. Of wil je een product genre Rapid7 aan de praat krijgen om analyse te doen op die data?
Wil je manueel door de data turven, beperk je dan eerste tot de foutieve loginpogingen. Just my 2 cents.

Voor mij is het eigenlijk het belangrijkste dat ik de gefaalde en succesvolle inlogpogingen kan zien en van welke accounts deze pogingen komen.

Maar bij de succesvolle staan soms nog niet eens account ID's

Ook wil ik zien welke accounts geblokkeerd zijn. De rest maakt me niet zo uit.

 

[fomix]

Voor mij is het eigenlijk het belangrijkste dat ik de gefaalde en succesvolle inlogpogingen kan zien en van welke accounts deze pogingen komen.

Belangrijkste hier is, hoeveel domain controllers heb je? Loginpogingen worden niet gesynced tussen verschillende domain controllers.
Dus dan zou je nog al u logs dmv Powershell (of iets anders) moeten gaan consolideren om er dan rapportage op te doen. Als je meer dan één domain controller hebt kijk je al snel tegen een paar weken trial & error.

Ik zou zeggen, bespaar u die moeite van een paar weken/maanden en kijk naar een commercieel product genre ADAudit Plus of NinjaOne.
Dan heb je gelijk een poot voor op te staan als er ooit een audit komt na een datalek , hack of ....
En die 1000€ fee per jaar haal je er zo uit aan werkuren die jij niet moet spenderen aan fancy rapportjes of scripting.

 

[Nrt]

Belangrijkste hier is, hoeveel domain controllers heb je? Loginpogingen worden niet gesynced tussen verschillende domain controllers.
Dus dan zou je nog al u logs dmv Powershell (of iets anders) moeten gaan consolideren om er dan rapportage op te doen. Als je meer dan één domain controller hebt kijk je al snel tegen een paar weken trial & error.

Ik zou zeggen, bespaar u die moeite van een paar weken/maanden en kijk naar een commercieel product genre ADAudit Plus of NinjaOne.
Dan heb je gelijk een poot voor op te staan als er ooit een audit komt na een datalek , hack of ....
En die 1000€ fee per jaar haal je er zo uit aan werkuren die jij niet moet spenderen aan fancy rapportjes of scripting.

2 DC's.

En het is voor een schoolproject, dus ik kan daar geen 1000 euro aan geven.

 

[fomix]

En het is voor een schoolproject, dus ik kan daar geen 1000 euro aan geven.

Ik vermoedde het al .

Kan je dan ook is concreet u opdracht laten weten?

 

[Nrt]

Ik vermoedde het al .

Kan je dan ook is concreet u opdracht laten weten?

Op het vlak van Auditing moeten wij kunnen zien welke mensen succesvol inloggen, niet kunnen inloggen en uiteindelijk geblokkeerd worden.

Daarnaast moeten wij ook kunnen zien of iemand mappen of bestanden aanmaakt, maar ook of er bestanden worden verwijderd door bepaalde personen.

 

[fomix]

Kan je u testen is gedetailleerder omschrijven?
- Je stelt op elke DC in ?
- Je zorgt dat de policy op elke client/server doorkomt ?
- Verifieer dit is met 'GPREPORT'?
- Zoals steeds bij Windows -> If something fails, have you tried turning it off and on again?

Je blijkbaar ook twee types:
- Audit account logon events
- Audit logon events

Audit Policy - Windows Security

Provides information about basic audit policies that are available in Windows and links to information about each setting.

learn.microsoft.com

Deze zin springt eruit voor mij:
Account logon events are generated on domain controllers for domain account activity and on local devices for local account activity. If both account logon and logon audit policy categories are enabled, logons that use a domain account generate a logon or logoff event on the workstation or server, and they generate an account logon event on the domain controller.

Als ik het goed lees is het dus niet zeker dat u events worden bijgehouden op de DC maar mogelijks op de client. Het hangt af van welke account dat je gebruikt.

Alsook, om de audit logs te kunnen bekijken moet je security administrator zijn. Domain admins hebben die rol by default en gezien je in labo werkt ga ik er vanuit dat je met de domain admin aanlogt op u DC?
Even alle hoeken coveren .