user login time achterhalen?

[theduke1989]

Beste tweakers, ik zou graag jullie hulp willen.
Heb me een tijdje rot gezocht op google.
Maar kan het niet echt vinden, al heb ik het vermoeden dat het iets simpels.

Ik ben op zoek naar een PS script waarbij ik van bepaalde gebruikers kan inzien wanneer zij hebben ingelogd op onze systemen. Heb wel last logon, maar dat is niet wat ik zoek.

Is er iets van bijvoorbeeld dat je van augustus tot oktober iets kan terug vinden? De Audit log is er wel, maar moet via even viewer dan werken, en dat is niet echt praktisch aangezien er meer dingen daartussen staan.

[Bor]

Dit gaat om Windows systemen neem ik aan?

Wil je een manier om alle (interactieve) inlogs op te sommen binnen een bepaalde periode? Gaat het om een stand alone machine of bv machines in een domein? Je zal de security log moeten doorzoeken, ofwel van de stand alone machine of van de domain controllers. Dat kan gewoon met powershell.

Een andere aanpak is het maken van een login script dat de tijden etc wegschrijft op een door jou gekozen locatie. Minder fool proof.

[ Voor 5% gewijzigd door Bor op 27-10-2025 11:03 ]

[theduke1989]

Bor schreef op maandag 27 oktober 2025 @ 11:02:
Dit gaat om Windows systemen neem ik aan?

Wil je een manier om alle (interactieve) inlogs op te sommen binnen een bepaalde periode? Gaat het om een stand alone machine of bv machines in een domein? Je zal de security log moeten doorzoeken, ofwel van de stand alone machine of van de domain controllers. Dat kan gewoon met powershell.

Een andere aanpak is het maken van een login script dat de tijden etc wegschrijft op een door jou gekozen locatie. Minder fool proof.

Ik ben echt op zoek naar een script bijvoorbeeld van drievoud personen die vanaf een bepaalde tijd hebben ingelogd op ons domein. Dit zijn namelijk externe EY mensen, en willen inzien.
puur die bij ons inloggen op onze werklaptops
last logon is niet wat ik zoek, dat is alleen laaste login, wil een lijst generen met alle datums vna hun.

[Bor]

theduke1989 schreef op maandag 27 oktober 2025 @ 11:05:
[...]
last logon is niet wat ik zoek, dat is alleen laaste login, wil een lijst generen met alle datums vna hun.

Dan zal je de eventlog moeten queryen op signin pogingen / interactieve logon etc. Je begint bij het bepalen welke events je precies wilt zien en wat de bron kan zijn (AD of de stand alone machines). Dat is met Powershell relatief eenvoudig op te lossen.

[theduke1989]

Bor schreef op maandag 27 oktober 2025 @ 11:33:
[...]


Dan zal je de eventlog moeten queryen op signin pogingen / interactieve logon etc. Je begint bij het bepalen welke events je precies wilt zien en wat de bron kan zijn (AD of de stand alone machines). Dat is met Powershell relatief eenvoudig op te lossen.

bedankt zag inderdaad alles met evenIDs te maken heeft, had eentje gevonden
https://zecurit.com/scrip...shell-user-login-history/

# -----------------------------------------------------------------------------
# Script Name: Get-UserLoginHistory.ps1
# Description: Retrieves user login and logoff history from Windows security event logs.
# Author: Team Zecurit
# Date: September 8, 2025
# -----------------------------------------------------------------------------

# PARAMETERS:
# -Username: Specifies the username to search for. If not provided, it will search for all users.
# -ComputerName: Specifies the remote computer to run the script on. Defaults to the local host.
# -TimeSpan: Specifies the time period to search for events (e.g., '7 days', '1 month'). Defaults to '30 days'.

param(
[string]$Username = '*',
[string]$ComputerName = $env:COMPUTERNAME,
[string]$TimeSpan = '30 days'
)

# Define the security event IDs for login (4624) and logoff (4634)
$loginEventID = 4624
$logoffEventID = 4634

# Convert the timespan string to a DateTime object
$startTime = (Get-Date).AddDays(-([int]$TimeSpan.Split(' ')[0]))

# Search the security log for relevant events
Write-Host "Searching for login/logoff events for user '$Username' on '$ComputerName'..."
$events = Get-WinEvent -FilterHashtable @{
Logname = 'Security';
ID = $loginEventID, $logoffEventID;
StartTime = $startTime
} -ComputerName $ComputerName | Where-Object { $_.Properties.Value -like "*$Username*" }

# Process and format the events
$history = $events | ForEach-Object {
$eventData = $_.Properties.Value
$loginType = switch ($_.Id) {
$loginEventID { 'Login' }
$logoffEventID { 'Logoff' }
default { 'Unknown' }
}

$logonType = ''
if ($_.Id -eq $loginEventID) {
$logonType = switch ($eventData[8]) {
2 { 'Interactive (Console)' }
3 { 'Network (e.g., shared folder)' }
4 { 'Batch' }
5 { 'Service' }
7 { 'Unlock' }
10 { 'RemoteInteractive (e.g., RDP)' }
11 { 'CachedInteractive' }
default { 'Unknown' }
}
}

[PSCustomObject]@{
Timestamp = $_.TimeCreated
UserName = $_.Properties[5].Value
EventType = $loginType
LogonType = $logonType
Source = $_.MachineName
Status = 'Success'
}
}

# Output the results, sorted by timestamp
$history | Sort-Object -Property Timestamp | Format-Table -AutoSize

alleen gebruikersnaam aanpassen en de dagen. en dan zoals je zei met de event ID 4624 en 4634

[theduke1989]

PS had dat uitgevoerd, en krijg als results, alleen de login van vandaag te zien, niet 90 dagen zoals ik had aangegeven.

[Zwelgje]

gebruik je ook zaken als Ivanti workspace manager of een andere workspace management tool? die houden dat soort zaken ook bij namelijk

[krietjur]

theduke1989 schreef op maandag 27 oktober 2025 @ 11:43:
PS had dat uitgevoerd, en krijg als results, alleen de login van vandaag te zien, niet 90 dagen zoals ik had aangegeven.
[Afbeelding]

Is de maximum log size wel voldoende groot? Anders overschrijft hij oude events en kan je dus inderdaad niet meer terugkijken.

[theduke1989]

Zwelgje schreef op maandag 27 oktober 2025 @ 11:43:
gebruik je ook zaken als Ivanti workspace manager of een andere workspace management tool? die houden dat soort zaken ook bij namelijk

helaas niet, wij zijn knap bij budget met dit soort dingen. Ik zal wel even kijken of EPC dit ook bijhoudt, of alleen de laptop!. maar uit de script, de login en logoff zitten wel erg dicht op elkaar, betekend dit hij logt altijd uit ? kan me niet voorstellen.

[Bor]

theduke1989 schreef op maandag 27 oktober 2025 @ 11:47:
[...]


helaas niet, wij zijn knap bij budget met dit soort dingen. Ik zal wel even kijken of EPC dit ook bijhoudt, of alleen de laptop!. maar uit de script, de login en logoff zitten wel erg dicht op elkaar, betekend dit hij logt altijd uit ? kan me niet voorstellen.

Je systeem logged de hele dag in en uit. Moet je niet naar interactive signins kijken?

[ Voor 4% gewijzigd door Bor op 27-10-2025 11:53 ]

[theduke1989]

Bor schreef op maandag 27 oktober 2025 @ 11:52:
[...]


Je systeem logged de hele dag in en uit. Moet je niet naar interactive signins kijken?

ik had de gebruikersnaam voor die persoon ingevoerd in de .ps1 script. en je ziet ook de gebruikersnaam daar tussen staan,

[Bor]

Verdiep je even in de verschillende events die je kan vinden rond sign-in en authenticatie. Afgaande op wat je hier hebt getypt ben je op zoek naar interactive sign-ins. niet naar bv signins wanneer er een netwerk share of andere resource wordt opgevraagd.

[Question Mark]

theduke1989 schreef op maandag 27 oktober 2025 @ 11:00:
Ik ben op zoek naar een PS script waarbij ik van bepaalde gebruikers kan inzien wanneer zij hebben ingelogd op onze systemen. Heb wel last logon, maar dat is niet wat ik zoek

Wat is je usecase? Waarom wil je dit weten? Wat zijn "onze" systemen? Zijn dit ook SaaS-diensten, of bedoel je hier alleen (Windows?) werkplekken mee, of misschien ook Unix-systemen?

[theduke1989]

Question Mark schreef op maandag 27 oktober 2025 @ 16:24:
[...]

Wat is je usecase? Waarom wil je dit weten? Wat zijn "onze" systemen? Zijn dit ook SaaS-diensten, of bedoel je hier alleen (Windows?) werkplekken mee, of misschien ook Unix-systemen?

Is puur het inloggen op ons systeem (domain controller) Laptop.

Ik krijg niet de resultaten die ik wil op google.

Wat ik opgemerkt heb bij ons is dat de Audit gpo daarvoor maar op 2 weken staat of 2 maanden. Wat bewaard wordt. Dat is slecht bedacht volgens mij.

[ Voor 14% gewijzigd door theduke1989 op 27-10-2025 16:55 ]

[Question Mark]

theduke1989 schreef op maandag 27 oktober 2025 @ 16:50:
[...]
Is puur het inloggen op ons systeem (domain controller) Laptop.

Dat snap ik, maar waarom? Wat ga je doen met die informatie... Beetje zonde om nu allemaal moeite te doen voor iets wat nooit gebruikt gaat worden.

Wat bedoel je met inloggen? Is dat lokaal inloggen op de laptop (ook zonder verbinding met het bedrijfsnetwerk), of bedoel je authenticatie tegen de Domain Controller aan?

theduke1989 schreef op maandag 27 oktober 2025 @ 16:50:
[...]
Wat ik opgemerkt heb bij ons is dat de Audit gpo daarvoor maar op 2 weken staat of 2 maanden. Wat bewaard wordt. Dat is slecht bedacht volgens mij.

Waarom vind je dat? Inrichting wordt afgedwongen door requirements en vereisten. Als daaraan voldaan wordt is de inrichting prima.

Dat is nu ook net de reden waarom ik vroeg naar de usecase.

[F_J_K]

En dus: zelf in de event viewer kijken specifiek welke eventID's je nodig hebt (of in EntraID). Pas daarna is een script naar wens te maken of aan te passen. Ga niet (nooit) andermans scripts draaien zonder te herkennen wat het script doet.

En vergeet niet de privacy officer / de OR te betrekken. Al hoort degene dat te doen die voornoemde usecase heeft bedacht.

[snelcom]

Als ik je goed begrijp wil je (per gebruiker) alle interactieve logins over een periode zien, bij voorkeur aug–okt, en je script toont nu alleen “vandaag”.

Zo pak je het aan (kort)

Audit & retentie checken (via GPO op werk-laptops):
Computer Config → Security Settings → Advanced Audit Policy → Logon/Logoff → Audit Logon: Success.
Vergroot Security log size (Event Log → Security → Max size, bv. 256–512 MB). Anders heb je maar enkele dagen historie.

Filter op interactieve logons: gebruik Event ID 4624 met LogonType = 2 (Console) of 10 (RDP). Voor echte uitlog: 4647 (user-initiated). Vermijd 4634 (te veel ruis).

Query per werkstation (of centraal met WEF). Voor drie gebruikers en datumrange:

$Users = 'user1','user2','user3'
$Start = Get-Date '2025-08-01'
$End = Get-Date '2025-10-31 23:59:59'
$PCs = @('LAPTOP001','LAPTOP002') # of jouw lijst/OU

foreach($pc in $PCs){
foreach($u in $Users){
$xml = @"
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4624 or EventID=4647)
and TimeCreated[@SystemTime>= '$($Start.ToUniversalTime().ToString("o"))'
and @SystemTime<= '$($End.ToUniversalTime().ToString("o"))']]]
and *[EventData[(Data[@Name='TargetUserName']='$u' or Data[@Name='SubjectUserName']='$u')
and (Data[@Name='LogonType']='2' or Data[@Name='LogonType']='10' or not(Data[@Name='LogonType']))]]
</Select>
</Query>
</QueryList>
"@
Get-WinEvent -ComputerName $pc -FilterXml $xml | ForEach-Object {
$type = switch ($_.Id) {
4624 { if ($_.Properties[8].Value -eq 2) {'Logon (Interactive)'}
elseif ($_.Properties[8].Value -eq 10) {'Logon (RDP)'}
else {'Logon (Other)'} }
4647 { 'Logoff (User-initiated)' }
}
[pscustomobject]@{ Computer=$pc; User=$u; Time=$_.TimeCreated; Event=$type }
}
}
} | Sort-Object Time | Format-Table -AutoSize


Waarom je nu maar 1 dag ziet: je Security log overschrijft oude events door te kleine log/retentie. Vergroot die eerst; anders kun je niet 90 dagen terug.

Praktische tip: zet Windows Event Forwarding aan en verzamel 4624 (type 2/10) + 4647 centraal. Zo hou je historie én rapportage simpel.

[Question Mark]

snelcom schreef op dinsdag 28 oktober 2025 @ 10:40:
Computer Config → Security Settings → Advanced Audit Policy → Logon/Logoff → Audit Logon: Success.

Misschien blijf ik wat nitpicken, maar dit is dus sterk afhankelijk van de usecase. Vanuit security-perspectief vind ik succevolle aanmeldpogingen interessant, maar de niet-succesvolle (en account lock-outs) misschien nog veel meer.

Vanuit diverse wetgeving (oa. ISO 27001/BIO) is het ook verplicht om failed logonpogingen te auditten.

[Blokker_1999]

Als je zoiets wenst te auditen, moet je beginnen met een centrale logging op te zetten. Al onze domain controllers loggen al die security events naar 1 centraal systeem waar we een jaar lang deze data bijhouden. Op de domain controllers zelf houden de security logs, afhankelijk van het tijdstip, ergens tussen de 30 minuten en 4 uur aan data bij. De logs van Windows zijn namelijk van vaste grootte en als ze vol zijn verwijderen ze standaard de laatste events. En voor die 30 minuten aan logging heb ik al meerdere gigabytes aan data op een domain controller.

Hetzelfde op laptops en servers, de default log size van het security log is slechts 25MB als ik me niet vergis, zit dat vol, dan worden de oudste events verwijderd. Wil je langere tijd bijhouden? Dan moet je die log files groter maken of dus opnieuw centraliseren. En als je veel systemen hebt, wil je ook niet elk systeem 1 voor 1 beginnen aflopen, vandaar dus centralisatie van de logging.

Nu dus ineens zeggen dat je events van enkele maanden terug wenst te zien zonder dat er ooit goede logging is opgezet gaat je niet lukken. Daarvoor heb je simpelweg nooit de nodige retentie voorzien.

[XelaRetak]

Mochten ze ook Entra-ID enrolled zijn dan kan je ook prima op gebruikersnaam sign-in times and types terugvinden in Entra. Dat is ook een veel makkelijkere interface dan met scripts werken.

Let overigens wel goed op welke informatie je met welk doel tevoorschijn tovert, want er zitten nogal wat privacy haken en ogen aan het gebruik van dat soort data.

[theduke1989]

Ik heb inderdaad even het volgende vandaag nagekeken.
- de Audit gpo
- de event viewer grootte, kan alleen deze niet echt veel vergroten

De reden dat ik dit vraag is, dat mij. Teamleider dit vroeg.

De punt is dat we sinds enkele maanden veel en veel meer met de Big4 werken. Deloitte en EY op het moment van schrijven.

De manager van mijn teamleider wilt dit allemaal weten, wanneer ze zijn ingelogd.

We hebben een security team. Maar we zijn sinds de overname nog steeds niet in hun systemen volledig gemigreerd. We gebruiken R7, Cyberpark hardening van DCs etc van hun.
Maar nog niet intern.

Tot die tijd beheren wij dit. Ik ben pas ingerold in het bedrijf. Mijn andere collega heeft het ook niet kunnen zien aankomen dat we dit soort aanvragen krijgen. AUDIT ALS VOORBEELD was dus dusdanig vals opgebouwd.

[ Voor 5% gewijzigd door theduke1989 op 28-10-2025 13:25 ]

[Blokker_1999]

Ga in overleg met het security team, kijk wat zij vandaag doen voor dit type van logging en kijk dan na hoe snel het realistisch mogelijk is om dat ook voor je eigen omgeving ingeregeld te krijgen. Je wil zeker het warm water niet opnieuw uitvinden in een onderneming.

En laat aan je teamleider weten dat je vandaag niet de juiste logging hebt om die informatie te verzamelen uit het verleden en dat je binnen de onderneming gaat bekijken welke opties er zijn om dit op een gestandariseerde manier zo snel mogelijk in orde te krijgen.

[Blokker_1999]

XelaRetak schreef op dinsdag 28 oktober 2025 @ 12:41:
Mochten ze ook Entra-ID enrolled zijn dan kan je ook prima op gebruikersnaam sign-in times and types terugvinden in Entra. Dat is ook een veel makkelijkere interface dan met scripts werken.

Let overigens wel goed op welke informatie je met welk doel tevoorschijn tovert, want er zitten nogal wat privacy haken en ogen aan het gebruik van dat soort data.

Dan zie je enkel de sign-ins voor Azure gerelateerde resources, en als er geen log analytics is opgezet met log forwarding vanuit Entra, heb je daar ook enkel maar zicht op de laatste 30 dagen. Log retentie kost geld.

[Question Mark]

theduke1989 schreef op dinsdag 28 oktober 2025 @ 12:46:
De reden dat ik dit vraag is, dat mij. Teamleider dit vroeg.

Dat snap ik hoor, maar als ik zo'n vraag zou krijgen zou ik flink doorvragen naar de functionele wens die daarachter zit.

Nu heb je een technische vraag gekregen (bouw een PS-script wat dit en dit doet), terwijl de functionele vraag misschien op een veel betere manier ingevuld kan worden.

Sidenote... Als je als teamleider wilt controleren wanneer consultants van je trusted advisor aangelogd zijn, heb je denk ik wel een ander probleem.

Maar... Dit even relateren naar de functionele vraag. Kennelijk wil je teamleider niet de user login times van álle gebruikers weten, maar alleen van deze consultants? Dat is een aardig ander verzoek...

[theduke1989]

Question Mark schreef op woensdag 29 oktober 2025 @ 11:50:
[...]

Dat snap ik hoor, maar als ik zo'n vraag zou krijgen zou ik flink doorvragen naar de functionele wens die daarachter zit.

Nu heb je een technische vraag gekregen (bouw een PS-script wat dit en dit doet), terwijl de functionele vraag misschien op een veel betere manier ingevuld kan worden.

Sidenote... Als je als teamleider wilt controleren wanneer consultants van je trusted advisor aangelogd zijn, heb je denk ik wel een ander probleem.

Maar... Dit even relateren naar de functionele vraag. Kennelijk wil je teamleider niet de user login times van álle gebruikers weten, maar alleen van deze consultants? Dat is een aardig ander verzoek...

Het punt is dat manager van mijn teamleider nicht gelooft hoe lang en hoevaak de EY mensen inloggen op onze system om de werk/ audit uit te voeren. (Manager heeft argwaan bij EY, zo is me dat verteld.

Dat is eigenlijk de grote reden. Ik had mijn teamleider gezegd is vast wel mogelijk en ga er op zoek naar. Door jullie reacties en die van Google. Is het wel wat minder.
Aangezien we bijvoorbeeld de Audit logs hebben tot 90 dagen.

De EY komt njet van ons intern. Maar van Group. Maar gebruiken onze systemen. Sinds we omgekocht zijn is het helaas alles anders

[ Voor 5% gewijzigd door theduke1989 op 29-10-2025 13:26 ]

[XelaRetak]

theduke1989 schreef op woensdag 29 oktober 2025 @ 13:25:
[...]


Het punt is dat manager van mijn teamleider nicht gelooft hoe lang en hoevaak de EY mensen inloggen op onze system om de werk/ audit uit te voeren. (Manager heeft argwaan bij EY, zo is me dat verteld.

Dat is eigenlijk de grote reden. Ik had mijn teamleider gezegd is vast wel mogelijk en ga er op zoek naar. Door jullie reacties en die van Google. Is het wel wat minder.
Aangezien we bijvoorbeeld de Audit logs hebben tot 90 dagen.

De EY komt njet van ons intern. Maar van Group. Maar gebruiken onze systemen. Sinds we omgekocht zijn is het helaas alles anders

Kijk maar uit met die info zomaar uit de system trekken zonder je privacy officer te raadplegen.

[theduke1989]

XelaRetak schreef op woensdag 29 oktober 2025 @ 14:36:
[...]


Kijk maar uit met die info zomaar uit de system trekken zonder je privacy officer te raadplegen.

Hebben we niet, nog niet. Momenteel erg kleine groepje It. Daarom zou dit voor mij geen probleem moeten zijn. Maar als ik al heb gemerkt wegens audit events wat maar 3 maanden meegaat kan in die sowieso niet terug halen.

Al zou ik graag wel willen wat voor Powershell script dit kan doen.

[Question Mark]

theduke1989 schreef op woensdag 29 oktober 2025 @ 13:25:
[...]
Het punt is dat manager van mijn teamleider nicht gelooft hoe lang en hoevaak de EY mensen inloggen op onze system om de werk/ audit uit te voeren. (

Ah, we komen verder. Kennelijk wil de manager niet alleen weten wanneer ze aangemeld zijn, maar ook hoelang ze aangelogged zijn. Daarmee is het tijdstip van aanmelden slechts een deel van de puzzel. Kennelijk wil de manager ook weten wanneer ze afgemeld zijn?

Ontopic:

Eventid 4642 logt succesvolle aanmeldpogingen inclusief datum/tijd en username.

Via Google vind ik dit op een ander forum, waarbij een klein voorbeeldscript staat (tweede reply).

Dit script logt specifieke entry's uit eventid's, uit een specifiek Windows eventlog naar een csv-file. Als je dat aanpast naar het securitylog, en het juiste eventid en de namen, dan ben je al een heel eind.

offtopic: ik begrijp zulke managers niet. Als er sprake is van wantrouwen ga je met elkaar in gesprek. Ga in elk geval niet uit loggevens conclusies over gewerkte uren maken, als je brondata daar niks over kan vertellen....

[XelaRetak]

theduke1989 schreef op woensdag 29 oktober 2025 @ 15:02:
[...]


Hebben we niet, nog niet. Momenteel erg kleine groepje It. Daarom zou dit voor mij geen probleem moeten zijn. Maar als ik al heb gemerkt wegens audit events wat maar 3 maanden meegaat kan in die sowieso niet terug halen.

Al zou ik graag wel willen wat voor Powershell script dit kan doen.

Dat je geen privacy officer hebt betekend niet dat je dan maar de regels aan je laars mag lappen als organisatie.

Als niet in een regelement is vastgelegd dat de personen hierop gecontroleerd kunnen worden, het is ze niet duidelijk vooraf aangegeven of je hebt het niet met EY kortgesloten, heb je dikke kans dat je binnenkort grotere problemen hebt dan een werktijdengeschil.

[Blokker_1999]

XelaRetak schreef op woensdag 29 oktober 2025 @ 14:36:
[...]


Kijk maar uit met die info zomaar uit de system trekken zonder je privacy officer te raadplegen.

Dat speelt in dit geval net iets minder daar deze mensen niet voltijds voor je werken, maar tijdens 1 dag mogelijks zelfs bij meerdere klanten aanmelden. Bijkomend zeggen aan- en afmeldtijden ook nog altijd niet veel over hoe lang er nu effectief gewerkt is op dat systeem. Als ik in de ochtend aanmeld en heel de dag idle blijf aangemeld is het enorm afhankelijk van heel de setup wat er dan 's avonds geregistreerd wordt als ik mijn laptop sluit. Maar dat zal geen log-off zijn vermoed ik. Dan moet je alweer scripts gaan gebruiken die idle time gaan registreren om een sign-off te forceren. Iets wat onze remote access tool voor vendors trouwens wel degelijk doet. 1u inactief, en je verbinding wordt verbroken. Op die tool hebben we ook perfect logging van wie wanneer aanmeld, voor hoe lang en ook screen recordings. Maar dat is dan ook expliciet omdat het een remote access tool is voor vendors, en zij zijn zich daar op voorhand van bewust dat we dat doen en die data voor 3 maanden bijhouden. Want dat is natuurlijk wel weer belangrijk.

Het zou me trouwens niet verbazen dat in dit geval de baas is wakkergeschoten nadat EY in Australie een rapport had ingediend bij de overheid dat deels met behulp van AI was geschreven. Zie je maar weer wat zo 1 misstap teweeg kan brengen.

[F_J_K]

- ongeacht jullie grootte: EY heeft advocaten.
- grote kans dat er Tweakers zijn die er werken.

[XelaRetak]

Blokker_1999 schreef op woensdag 29 oktober 2025 @ 18:12:
[...]

Dat speelt in dit geval net iets minder daar deze mensen niet voltijds voor je werken, maar tijdens 1 dag mogelijks zelfs bij meerdere klanten aanmelden. Bijkomend zeggen aan- en afmeldtijden ook nog altijd niet veel over hoe lang er nu effectief gewerkt is op dat systeem. Als ik in de ochtend aanmeld en heel de dag idle blijf aangemeld is het enorm afhankelijk van heel de setup wat er dan 's avonds geregistreerd wordt als ik mijn laptop sluit. Maar dat zal geen log-off zijn vermoed ik. Dan moet je alweer scripts gaan gebruiken die idle time gaan registreren om een sign-off te forceren. Iets wat onze remote access tool voor vendors trouwens wel degelijk doet. 1u inactief, en je verbinding wordt verbroken. Op die tool hebben we ook perfect logging van wie wanneer aanmeld, voor hoe lang en ook screen recordings. Maar dat is dan ook expliciet omdat het een remote access tool is voor vendors, en zij zijn zich daar op voorhand van bewust dat we dat doen en die data voor 3 maanden bijhouden. Want dat is natuurlijk wel weer belangrijk.

Het zou me trouwens niet verbazen dat in dit geval de baas is wakkergeschoten nadat EY in Australie een rapport had ingediend bij de overheid dat deels met behulp van AI was geschreven. Zie je maar weer wat zo 1 misstap teweeg kan brengen.

Dat speelt onverminderd mee.

Er zit nu een duidelijk onwetende IT-er in de logs van een grote speler te graven en dat nog online bekend te maken ook, met daarbij de informatie dat er duidelijk geen protocollen voor zijn opgesteld of overeenkomsten met EY voor bekend zijn.

Je hoeft geen geleerde te zijn om te zien dat hier in vingers gesneden wordt en onwetendheid is geen excuus. EY's informatiebeveiligings- en privacyteam hebben die wetenschap echter wel, dus aan TS...

Stop met graven. Back to the drawing board.

[theduke1989]

F_J_K schreef op woensdag 29 oktober 2025 @ 19:00:
- ongeacht jullie grootte: EY heeft advocaten.
- grote kans dat er Tweakers zijn die er werken.

Klopt, maar dat maakt voor de request van de manager en teamleider niks uit op het moment.

Vindt het zonde dat er njet van echt gebakken tools hiervoor zijn.

Ben sowieso wakker geschud adat ik de Audit log gpos en alles heb ingezien. Die ga ik zeker aanpassen nu.

Probleem is nog steeds niet inzien. Ook de event viewer vergoten lukt niet echt nog steeds te klein .

Strafbaar is het niet. Je kan ook zeggen wij als bedrijf hebbrn gefaald op dit vlak qua monitoring en zijn wakker geschud. Wilt njet zeggen dat ik niet kan tracken om te kijken.

[ Voor 13% gewijzigd door theduke1989 op 29-10-2025 20:14 ]

[gambieter]

theduke1989 schreef op woensdag 29 oktober 2025 @ 20:13:
Klopt, maar dat maakt voor de request van de manager en teamleider niks uit op het moment.

Jij hoort de teamleider en manager te adviseren als ze iets doen wat niet mag, anders ben jij gewoon medeverantwoordelijk voor overtredingen. Bevel is bevel is nooit een excuus.

[XelaRetak]

theduke1989 schreef op woensdag 29 oktober 2025 @ 20:13:
[...]


Klopt, maar dat maakt voor de request van de manager en teamleider niks uit op het moment.

Vindt het zonde dat er njet van echt gebakken tools hiervoor zijn.

Ben sowieso wakker geschud adat ik de Audit log gpos en alles heb ingezien. Die ga ik zeker aanpassen nu.

Probleem is nog steeds niet inzien. Ook de event viewer vergoten lukt niet echt nog steeds te klein .

Strafbaar is het niet. Je kan ook zeggen wij als bedrijf hebbrn gefaald op dit vlak qua monitoring en zijn wakker geschud. Wilt njet zeggen dat ik niet kan tracken om te kijken.

Je kan in ieder geval nooit zeggen dat je niet gewaarschuwd bent door je medetweakers wiens vakgebied het is.

Succes