6

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?

djhaskin987
  • 388
  • 4
  • 14

6 Answers6

21

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.

Wesley
  • 32,690
  • 9
  • 82
  • 117
  • +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. http://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 03:21
11

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.

MDMarra
  • 100,734
  • 32
  • 197
  • 329
  • 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
  • @Jeff Ferland, you are choosing to trust the logs from the machines which potentially hostile users are given admin access on? If you suspect a machine has been compromised trusting anything you find on it is probably a bad idea. – Zoredache Aug 16 '11 at 18:13
  • 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
  • 2
    @djhaskin987 Thanks for the accept. If this works best for your environment, then I'm glad that I could help, but WesleyDavid's answer is far more reliable and robust. I appreciate the +15 rep, but it really belongs to him. – MDMarra Aug 16 '11 at 18:41
4

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.

Jeff Ferland
  • 20,547
  • 2
  • 62
  • 85
1

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 03:22
0

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.

TessellatingHeckler
  • 5,726
  • 3
  • 26
  • 44
0

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/

juFo
  • 423
  • 3
  • 11
  • 22