We in our department are implementing a new admin policy: everyone in a department which we support will receive admin access to their computers. We need to know (while we are performing this "pilot program" policy on this department) who logged in, and when they did, on any machine. So how could I (using a powershell script, cmd script or other automatic means) find out who logged in to a given windows 7 or XP machine?


You could make a logon script and link it in Group Policy for those computers that echos %date% %time% %username% %computername% to a file on a hidden share somewhere. Then you'll have a centralized log of all logins.

  • 3
    Probably also want to note the logout time. "time in" is virtually useless without "time out" when you're trying to keep track of who had their fingers in the pie when it broke. – voretaq7 Aug 16 '11 at 17:59
  • 3
    Ah, but can you really trust %date% and %time%? Given that the users are admin they could have screwed around with the timezone, or even the date/time in a non-domain environment. – Zoredache Aug 16 '11 at 18:04
  • 2
    We did something like this before. MAKE SURE YOU POLICE THE SHARE or about a year and a half later you'll wonder why that server is screaming that it's out of disk space and you suddenly find a scattering of files all over with users and machine names littering an obscure directory... – Bart Silverstrim Aug 16 '11 at 18:06
  • 2
    Windows has this functionality built into the logging system if you turn it on. You can centrally pull logs from each machine. I feel that provides a much better trail and clearer tamper evidence. – Jeff Ferland Aug 16 '11 at 18:06
  • 2
    @Zoredache you're already trusting the machine to run a script that remotely push data to a server. How does this script result in a different level of trust? At least with audit logs, you may find somebody didn't fully clear things without leaving breadcrumbs. Happens all the time in forensics cases. – Jeff Ferland Aug 16 '11 at 18:26

Monitor the event logs on the domain controllers for event 672. It will show all successful logon events for AD users and which computer they logged on from. Filter by computer to get logon events for only those computers that you are interested in.

  • +1 - a much more reliable answer than mine. – MDMarra Aug 16 '11 at 18:20
  • Can this also show logoff times? That seems to be its only downfall... – voretaq7 Aug 16 '11 at 18:46
  • @Voretaq7 Unfortunately, to my knowledge, AD does not store logoff information. The Last-Logoff attribute is where one would think to look. Twistedly, it is dormant. msdn.microsoft.com/en-us/library/ms676822(VS.85).aspx If you have the pitchforks, I've got the torches. – Wesley Aug 16 '11 at 18:51
  • more reliable; however, I do not have access to the domain controllers. Otherwise this would be a natural choice, thanks! – djhaskin987 Aug 22 '11 at 3:21

I think what you're probably looking for is knowing whenever the domain controller / active directory authenticates a user. Some explanation may be found in http://www.windowsecurity.com/articles/windows-active-directory-auditing.html

Audit logon events – This will audit each event that is related to a user logging on to, logging off from, or making a network connection to the computer configured to audit logon events. A good example of when these events are logged is when a user logs on interactively to their workstation using a domain user account. This will generate an event on the workstation, but not on the domain controller that performed the authentication. In essence, logon events are tracked where the logon attempt occurs, not where the user account resides. This setting is not enabled for any operating system, except for Windows Server 2003 domain controllers, which is configured to audit success of these events. It is common and best practice to log these events on all computers on the network.

Enabled on all machines and used with a system that will pull the logs from all machines, I would consider that the most reliable.


Once you've granted access to the administrators group, you may basically "lose" the computer, and it may be difficult to get it back.

Back in a previous job, The Powers That Were (instead of Be) decided it was actually a bangup idea to FORCE me to be in the admin group for the XP Pro workstation assigned to me. As I was an admin of other systems joined to that domain, I had another account for admin purposes which I could use as I saw fit (occasional installation or updates of software, or things like that). It was impractical to swap the roles of those two accounts (Exchange, various servers' group memberships, FS object ACLs, and on and on). I just simply disagreed that I should be forced to log into the system day-to-day as admin. So as a matter of course, I used to set up the local computer's policy (gpedit) to run startup scripts asynchronously and visibly, and established one that ran CMD. Naturally, this showed its window on the logon winstation (I think I'm describing that right, not sure) with a superuser (SYSTEM) security token. From there I could do basically anything I wanted, including removing my day-to-day domain SID from the local admin group (after a fashion), adding my intended admin account to local admin, and setting up a recurring Task Scheduler job to do that every few hours (to get around automatic GPO refreshes).

Giving them admin would also allow them to create local accounts and use them instead of domain accounts, and simply use "net use /user:DOM\user" to authenticate against your domain for access to any network resources, and only when they wanted it. So anything like trying to monitor logons/logoffs might be a bit dicey and inaccurate. With admin access, if I'm not mistaken, it wouldn't be that difficult to "cover their tracks," at least locally (such as clearing the Event Logs, setting up the characteristics of the Event Logging Service, changing the audit policy, etc.)

I would think long and hard about why you're doing this, and maybe find some other way around giving them full admin access. The Windows security model is extremely fine-grained, and just about any object (file, service, registry entry, etc.) can have an ACL, and SIDs (e.g., groups) have a rich set of rights which can be granted them.

  • right you are. The only thing stopping them (and this is, admittedly, shaky) is that they are old bio professors who do 90% of their computer work with their mouse. It's not a good strategy to monitor them like I am, but hopefully it's only temporary :% – djhaskin987 Aug 22 '11 at 3:22

Local accounts, or domain? Do you mean their main accounts are administrators or they will get an admin account specifically for changes? If it's central on a domain you can check the security event logs on the domain controllers, and/or the security event logs on the local computers

Here is Microsoft Documentation of the security event log entries and what to look for. Be aware that if you check the local machines, the administrators might clear the logs.

Audit Logon is a good Google term for more reading.

  • their AD account will be added to an admin group. – djhaskin987 Aug 16 '11 at 18:12
  • In that case, wont the answer be "everyone, everyday"? – TessellatingHeckler Aug 16 '11 at 18:53

You could monitor who is logging in and logging out. Should work on Windows 7 and Windows Server 2008 R2: http://teusje.wordpress.com/2012/09/11/windows-server-logging-users-logon-and-logoff-via-powershell/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.