Loginscript om logins bij te houden

[Operations]

Ik heb (mbv google) een login script in elkaar gezet. Wat ik graag wil bereiken is:

Een txt file met username die per dag logt wanneer de user inlogt en op welke pc.(dus NIET alleen de last logging date)

Het opslaan zoals ik zei in een txt met de username per dag. Het script zoals ik hem nu heb, pakt het datum stuk niet en overschrijft telkens de regel in de TXT file. Hij noteert telkens de last logging date (zo lijkt het) ipv netjes onder elkaar de login momenten.


:: Strip the leading day of the week from the date FOR %%A IN (%Date%) DO SET Today=%%A
:: Remove the date delimiters SET Today=%Today:/=% SET Today=%Today:-=%
:: Create a directory for today if it does not exist IF NOT EXIST \\Server01\LogLogins$\%Today% MD \\Server01\LogLogins$\%Today%
:: Log the computer name and the date and time in a file with the user's name
>> \\Server01\LogLogins$\%Today%\%UserName%.log ECHO %ComputerName%,%Date%,%Time%

Iemand enig idee hoe ik dit op kan lossen?

P.S. kleine stukje toelichting over de waarom:

De medewerkers zijn nu vrij om zelf hun werkplek te kiezen en mij is gevraagd om te kijken wie er vaak waar en met wie zit om zodoende een keuze te kunnen maken voor de projectsamenstelling voor het nieuwe project (je wil niet altijd de beste vrienden bij elkaar, rekening houden met parttimers, combineren van verschillende kwaliteiten etc.). De aanpassingen die je in de audit policies moet doen hiervoor heb ik gedaan (weet niet zeker of dit noodzakelijk is).

[MAX3400]

Is het niet veel simpeler om op je domain-controllers een custom eventlog-view te maken (al dan niet met subscription) waar je event 4624 en eventuele andere events groepeert?

[Operations]

MAX3400 schreef op donderdag 15 maart 2018 @ 16:08:
Is het niet veel simpeler om op je domain-controllers een custom eventlog-view te maken (al dan niet met subscription) waar je event 4624 en eventuele andere events groepeert?

Dat heb ik eerst geprobeerd, maar op de een of andere manier als ik filter op 4624 staan er ook heel veel niet door echte gebruikers meldingen tussen (wat ik uiteraard wel snap). en als ik dan zoek op username krijg ik 0 resultaten. Plus het workstation regeltje blijft leeg. Staat wel een IP, dat zou ik eventueel via DHCP leases wel kunnen vertalen naar workstation. Maar goed ik kreeg er niet het gewenste resultaat uit.

[HKLM_]

Klinkt als een berg werk om later uit te zoeken wie waar heeft gezeten met allemaal losse .txt files. Is dit misschien niet iets waar je wat meer mee kunt: Real-Time Monitoring of User Logon Actions

Tracking account logon activity, one system at a time for an entire Active Directory network is next to impossible. Real-time user logon audit reports from ADAudit Plus lists all user logon actions in a single report.

[ Voor 47% gewijzigd door HKLM_ op 15-03-2018 16:17 ]

[Operations]

HKLM_ schreef op donderdag 15 maart 2018 @ 16:15:
Klinkt als een berg werk om later uit te zoeken wie waar heeft gezeten met allemaal losse .txt files. Is dit misschien niet iets waar je wat meer mee kunt: Real-Time Monitoring of User Logon Actions

Leek mij juist aan de hand van die username txt's wel makkelijk. Gaat niet om honderden gebruikers, en hoef geen maanden te loggen.

[HKLM_]

Operations schreef op donderdag 15 maart 2018 @ 16:17:
[...]


Leek mij juist aan de hand van die username txt's wel makkelijk. Gaat niet om honderden gebruikers, en hoef geen maanden te loggen.

Dan nog als zijn het er 10 je moet alle .txt files openen en handmatig per pc een tabel er van maken. Het was een tip met je login script kan ik je niet helpen helaas.

[YellowOnline]

Eitje met Powershell. Zonder te testen:

PowerShell:

$LogFile = '\\blablabla\BigBrother'+$(Get-Date -Format "yyyyMMdd")+'.log'
if (!(Test-Path $LogFile)) {New-Item $Logfile -ItemType File}
$(Get-Date -Format "yyyy-MM-dd HH:mm:ss")+' '+$env:USERDNSDOMAIN+'\'+$env:USERNAME+' logged on from '+$env:COMPUTERNAME | Out-File -FilePath $LogFile -Encoding UTF8 -Append

Laat deze code uitvoeren als logon script. Je krijgt dan op je centrale locatie (zie je logpad) een .log per dag voor alle gebruikers en computers.

Edit: Typfout (&LogFile ipv $LogFile ... teveel HTML entities gezien vandaag)

[ Voor 19% gewijzigd door YellowOnline op 15-03-2018 20:12 ]

[Operations]

YellowOnline schreef op donderdag 15 maart 2018 @ 18:48:
Eitje met Powershell. Zonder te testen:

PowerShell:

$LogFile = '\\blablabla\BigBrother'+$(Get-Date -Format "yyyyMMdd")+'.log'
if (!(Test-Path $LogFile)) {New-Item $Logfile -ItemType File}
$(Get-Date -Format "yyyy-MM-dd HH:mm:ss")+' '+$env:USERDNSDOMAIN+'\'+$env:USERNAME+' logged on from '+$env:COMPUTERNAME | Out-File -FilePath &LogFile -Encoding UTF8 -Append

Laat deze code uitvoeren als logon script. Je krijgt dan op je centrale locatie (zie je logpad) een .log per dag voor alle gebruikers en computers.

Dit zal ik testen, dank hiervoor.
Dit kan ik toch samen in een batchfile zetten met een aantal net use regels erboven?

[YellowOnline]

Operations schreef op donderdag 15 maart 2018 @ 19:37:
[...]


Dit zal ik testen, dank hiervoor.
Dit kan ik toch samen in een batchfile zetten met een aantal net use regels erboven?

Het is mij niet duidelijk wat je met net use aanvangen wil, maar: doe het uitvoeren via GPO - dat is netter en ondersteunt native powershell. Als je het via een ouderwetse batch doet kan je beter een bestand oproepen:

Batchfile:

@echo off
powershell.exe -NoLogo -File \\blablabla\scriptje.ps1 -Windowstyle Hidden -NoProfile -ExecutionPolicy Bypass

[Operations]

YellowOnline schreef op donderdag 15 maart 2018 @ 19:50:
[...]


Het is mij niet duidelijk wat je met net use aanvangen wil, maar: doe het uitvoeren via GPO - dat is netter en ondersteunt native powershell. Als je het via een ouderwetse batch doet kan je beter een bestand oproepen:

Batchfile:

@echo off
powershell.exe -NoLogo -File \\blablabla\scriptje.ps1 -Windowstyle Hidden -NoProfile -ExecutionPolicy Bypass

Wat ik bedoelde was of ik een aantal net use regels (shares koppelen) kon combineren met jouw scriptje in 1 batchfile.
Maar ik doe het wel op de boven genoemde manier. Ben benieuwd of het werkt

[akimosan]

Ook geen net use in één of meer batchfiles. Gebruik ook daarvoor GPO (eigenlijk GPP, group policy preferences en group policy targeting) om de shares te koppelen. Daar kan het veel gerichter mee

En ook geen tig shares koppelen met 1 of meerdere servers, daarvoor hebben we tegenwoordig DFS. Kun je gewoon 1 driveletter koppelen aan desnoods de root en de rest van de indeling geheel logisch houden ook al verhuis je de shares naar een andere fileserver of bestaan de shares op verschillende fileservers.

Het is verdorie geen 1999 meer. En ook geen 2003, excuses voor de DFS link naar Server 2003 maar het blijft een nuttig en leerzaam artikel en nog steeds te gebruiken in Server 2016

[ Voor 18% gewijzigd door akimosan op 15-03-2018 20:34 ]

[Operations]

Het is gelukt, script van @YellowOnline werkt! Thanks.
Tips over GPP (dan wel DFS) ga ik zeker later deze maand iets mee doen. Ook dank daarvoor.

[Rolfie]

Ik zou dit verzoek ook even langs de juridische afdelingen bij jullie laten lopen.

Dit soort verzoeken komen erg dicht bij de privacy van je eindgebruikers, zeker icm de aankomende wetgevingen zou ik heel erg uitkijken wat je doet en hoe je dit doet.

Dit soort verzoeken zouden bij ons meteen afgekeurd worden zonder specifiek akkoord vanuit Informatiebeveiliging.

[JustSys]

Rolfie schreef op vrijdag 16 maart 2018 @ 12:51:
Ik zou dit verzoek ook even langs de juridische afdelingen bij jullie laten lopen.

Dit soort verzoeken komen erg dicht bij de privacy van je eindgebruikers, zeker icm de aankomende wetgevingen zou ik heel erg uitkijken wat je doet en hoe je dit doet.

Dit soort verzoeken zouden bij ons meteen afgekeurd worden zonder specifiek akkoord vanuit Informatiebeveiliging.

interessant, dus ik als "eindgebruiker" kan eisen om mijn login/track gegevens niet op te slaan?

[MAX3400]

JustSys schreef op vrijdag 16 maart 2018 @ 14:20:
[...]


interessant, dus ik als "eindgebruiker" kan eisen om mijn login/track gegevens niet op te slaan?

Ligt eraan wat er in het ICT-beleid (voor jou) staat maar dit topic is begonnen om mensen eerst te tracken op basis van een functionele behoefte om bepaalde veranderingen in samenstelling/plaatsing van werkplekken te faciliteren.

Wat mij betreft not done maar ongetwijfeld zal @Operations een getekende verklaring hebben liggen dat HR & directie verantwoording nemen voor deze scripting en er zorg wordt gedragen voor (tijdige) vernietiging van de gegenereerde data.

[JustSys]

MAX3400 schreef op vrijdag 16 maart 2018 @ 14:26:
[...]

Ligt eraan wat er in het ICT-beleid (voor jou) staat maar dit topic is begonnen om mensen eerst te tracken op basis van een functionele behoefte om bepaalde veranderingen in samenstelling/plaatsing van werkplekken te faciliteren.

Wat mij betreft not done maar ongetwijfeld zal @Operations een getekende verklaring hebben liggen dat HR & directie verantwoording nemen voor deze scripting en er zorg wordt gedragen voor (tijdige) vernietiging van de gegenereerde data.

Ik denk dat HR niet altijd op de hoogte is, en indien ze toch een akkoord hebben dien ik als "eindgebruiker" ook niet te tekenen?

[Yodocus]

Rolfie schreef op vrijdag 16 maart 2018 @ 12:51:
Ik zou dit verzoek ook even langs de juridische afdelingen bij jullie laten lopen.

Dit soort verzoeken komen erg dicht bij de privacy van je eindgebruikers, zeker icm de aankomende wetgevingen zou ik heel erg uitkijken wat je doet en hoe je dit doet.

Vraag dan meteen of auditing op je domain controllers nog aan mag staan. En of je TCP/IP pakketten nog een mac adres mogen bevatten. En of NTFS nog een toegestaan bestandssysteem is.

[Rolfie]

YellowOnline schreef op donderdag 15 maart 2018 @ 18:48:
Eitje met Powershell. Zonder te testen:

PowerShell:

$LogFile = '\\blablabla\BigBrother'+$(Get-Date -Format "yyyyMMdd")+'.log'
if (!(Test-Path $LogFile)) {New-Item $Logfile -ItemType File}
$(Get-Date -Format "yyyy-MM-dd HH:mm:ss")+' '+$env:USERDNSDOMAIN+'\'+$env:USERNAME+' logged on from '+$env:COMPUTERNAME | Out-File -FilePath $LogFile -Encoding UTF8 -Append

Laat deze code uitvoeren als logon script. Je krijgt dan op je centrale locatie (zie je logpad) een .log per dag voor alle gebruikers en computers.

Waarbij je logfile door iedereen te lezen is. Dit zou bij ons meteen een security incident zijn. Als dit actief zou zijn, zouden een aantal personen zich mogen verantwoorden waarom ze dit geïmplementeerd hebben op deze manier.
Je mag niet even bijhouden wanneer iemand even in (en eventueel uit) logt voor dit soort doeleinden.
De gebruikers privacy moet je hier goed in de gaten houden. Immers dit soort informatie kan ook misbruikt kan worden tegen gebruikers.

Yodocus schreef op vrijdag 16 maart 2018 @ 16:20:
[...]

Vraag dan meteen of auditing op je domain controllers nog aan mag staan.

Dat is heel wat anders. Een beheerder mag dit soort informatie vergaren. Echter gebruiken van dit soort informatie is een heel ander iets. Zeker voor bepaalde doeleinden.

Het huidige verzoek gaat gewoon tegen de privacy in, mag zonder toestemming gewoon niet uitgevoerd worden. TS begeeft zich hier op glad ijs.

Technisch stelt het verzoek niet zoveel voor, maar privacy en juridisch gezien is het een stuk complexer.

En of je TCP/IP pakketten nog een mac adres mogen bevatten. En of NTFS nog een toegestaan bestandssysteem is.

Logica zie ik even niet hierin?

[Wim-Bart]

Dit soort login scripts zijn gewoonweg verboden. De reden is dat je een login script in user context draait waardoor de logfile user schrijfbaar is. Consequentie is dat bij een user altijd onweerlegbaar kan zeggen dat iemand anders de file heeft aangepast of zelf de file kan aanpassen. En auditing gaat ook niet werken, want dan zul je discrepantie krijgen tussen file inhoud en audit data waardoor beide in twijfel getrokken kunnen worden.

De einige nette Methode is via een eventlog op werkstation of op de domein controller. Op de domein controller kan je netjes zien wie ingelogd is en waar deze inlog (via welk device) met exacte tijdcode. Je moet het wel aanzetten in je GPO.

[Thijs B]

Wim-Bart schreef op zondag 18 maart 2018 @ 18:00:
Dit soort login scripts zijn gewoonweg verboden. De reden is dat je een login script in user context draait waardoor de logfile user schrijfbaar is. Consequentie is dat bij een user altijd onweerlegbaar kan zeggen dat iemand anders de file heeft aangepast of zelf de file kan aanpassen. En auditing gaat ook niet werken, want dan zul je discrepantie krijgen tussen file inhoud en audit data waardoor beide in twijfel getrokken kunnen worden.

De einige nette Methode is via een eventlog op werkstation of op de domein controller. Op de domein controller kan je netjes zien wie ingelogd is en waar deze inlog (via welk device) met exacte tijdcode. Je moet het wel aanzetten in je GPO.

Wat een totale onzin reacties, alsof je als systeembeheerder of werkgever niet zou mogen loggen op welke werkplek/computer je personeel inlogt en wanneer, dit heeft niets met privacy inbreuk te maken.

[MAX3400]

Thijs B schreef op zondag 25 maart 2018 @ 20:45:
[...]


Wat een totale onzin reacties, alsof je als systeembeheerder of werkgever niet zou mogen loggen op welke werkplek/computer je personeel inlogt en wanneer, dit heeft niets met privacy inbreuk te maken.

Leg eens uit waarom een systeembeheerder werkstations inzichtelijk moet maken op fysieke lokatie en daarna op "voornaam & achternaam" gaat loggen wie erop inlogt? Samen met de vraag in de topicstart "om te kijken wie er vaak waar en met wie zit om zodoende een keuze te kunnen maken voor de projectsamenstelling", is daadwerkelijk een inbreuk op privacy.

Waarom? Het script zou niet nodig zijn als de werkgever vaste plekken heeft in het kantoor en dus uit project-overwegingen mensen van kantoortje/etage kan verhuizen. Er worden nu beslissingen genomen die een efficiente/optimale samenwerking tussen mensen moet realiseren door "af te luisteren" wie waar en wanneer werkt.

Dat mag niet. Punt.

Directie / raad van commissarissen / HR moet hier een aankondiging van doen in het bedrijf; juist vanwege het feit dat "flexplek" gekozen is als bedrijfsmodel maar men nu mensen wil "volgen" of & waar ze met wie werken.

[Croga]

Thijs B schreef op zondag 25 maart 2018 @ 20:45:
Wat een totale onzin reacties, alsof je als systeembeheerder of werkgever niet zou mogen loggen op welke werkplek/computer je personeel inlogt en wanneer, dit heeft niets met privacy inbreuk te maken.

Zodra je het gaat gebruiken voor de doeleinden die TS aan geeft (quote: "je wilt niet altijd de beste vrienden bij elkaar") is het wel degelijk inbreuk op de privacy.

Alles staat of valt met dat soort zinsnedes. Je mag op geen enkele manier discrimineren anders dan op kennis. En hier wordt gediscrimineerd op basis van sociale contacten en parttime contracten. Dat is bij wet verboden.

Daarnaast is het ook zinloos. Als je een zo goed mogelijk team op wilt zetten is je voornaamste eis langdurigheid. Zo lang je over projecten praat is de invloed van andere factoren al dusdanig minimaal dat dergelijke selectie niets gaat opleveren.

MAX3400 schreef op zondag 25 maart 2018 @ 20:52:
Directie / raad van commissarissen / HR moet hier een aankondiging van doen in het bedrijf; juist vanwege het feit dat "flexplek" gekozen is als bedrijfsmodel maar men nu mensen wil "volgen" of & waar ze met wie werken.

Dat maakt de loging wellicht legaal, het gebruik van het log is op geen enkele manier legaal te maken. Discriminatie is, zelfs na bekendmaking, altijd illegaal.

[ Voor 20% gewijzigd door Croga op 25-03-2018 20:54 ]

[MAX3400]

Croga schreef op zondag 25 maart 2018 @ 20:53:
[...]
Dat maakt de loging wellicht legaal, het gebruik van het log is op geen enkele manier legaal te maken. Discriminatie is, zelfs na bekendmaking, altijd illegaal.

Meh, ik snap wat je zegt etc maar uit efficiency-overwegingen, kan ik me voorstellen dat sommige logging (nader te bepalen) zeker kan bijdragen aan kortere doorlooptijden van bepaalde werkzaamheden en dus een verhoogde productiviteit & omzet

[Croga]

MAX3400 schreef op zondag 25 maart 2018 @ 20:56:
Meh, ik snap wat je zegt etc maar uit efficiency-overwegingen, kan ik me voorstellen dat sommige logging (nader te bepalen) zeker kan bijdragen aan kortere doorlooptijden van bepaalde werkzaamheden en dus een verhoogde productiviteit & omzet

Ik praat niet over "sommige logging", ik praat over wat TS hier voorstelt. En wat TS hier voorstelt kan nooit legaal gemaakt worden.

[Wim-Bart]

Thijs B schreef op zondag 25 maart 2018 @ 20:45:
[...]


Wat een totale onzin reacties, alsof je als systeembeheerder of werkgever niet zou mogen loggen op welke werkplek/computer je personeel inlogt en wanneer, dit heeft niets met privacy inbreuk te maken.

Staat het in het personeelshandboek? Is het medegedeeld toen de gebruiker zijn/haar login kreeg? Zijn er generieke accounts voor bepaalde applicaties? Weten gebruikers dat ze gelogd worden en dat het consequenties heeft wanneer zij hun login afgeven aan een collega tijdens vakantie? Heeft P&O een procedure waarin is vastgelegd waarin is opgenomen wie welke informatie mag gebruiken en opvragen binnen het bedrijf? Zijn de log gegevens integer en niet te manipuleren?

En zo kan ik verder gaan. Ben in de praktijk een aantal keren tegen gekomen dat een werknemers flinke schade vergoedingen hebben gekregen omdat een werkgever deze gegevens gebruikt heeft tegen een werknemer. Als werkgever heb je geen poot om op te staan.

Zolang er niets goed is ingeregeld, niks procedureel is vastgelegd, een werknemer niet op de hoogte is en zelfs geen toestemming heeft gegeven is de vraag van een chef/collega/directeur naar bijvoorbeeld "Ik wil graag weten wat de inlog tijden zijn van persoon X" al redenen om een werkgever aan te pakken. En wanneer een werkgever dit dan ook nog gebruikt om een werknemer te ontslaan kan dit grote financiële consequenties hebben voor de werkgever.

[Jazzy]

MAX3400 schreef op zondag 25 maart 2018 @ 20:52:
[...]
Directie / raad van commissarissen / HR moet hier een aankondiging van doen in het bedrijf

Dat zijn drie compleet verschillende dingen, als je het niet precies weet dan kun je misschien beter de werkgever of organisatie zeggen.

Hier trouwens een pagina van de Autoriteit Persoonsgegevens met meer info over het controleren van medewerkers: https://autoriteitpersoon...ng/controle-van-personeel

Complimenten voor YellowOnline in "Loginscript om logins bij te houden". Dat laat maar weer eens zien hoe enorm krachtig PowerShell is en dat je eigenlijk alles kunt zodra je een beetje bekend bent met de syntax.