0

I manage a large enterprise environment, and while we try to advise users not to, there are inevitably users that need to have local admin access to their machines. The problem is that some of these users like to "fiddle" and sometimes screw up their machines in "wonderful" ways. Is there an easy way to log what a user does on a machine, specifically in the command prompt? Maybe there is 3rd party tools I could use to log this information?

With Linux that I used to use in past ages, you could look at a users bash history file to see what commands they have run. While I realise that specific log could also be altered by the user if they wanted to cover their tracks, that is the sort of log I'm looking for.

If there are other ways I can also log what other system configuration type changes they make as well (not necessarily command line based), that's also useful. I know about event/system logs and so on, but that doesn't necessarily catch all the information I need to figure out how the user has buggered their machine this time.

camster342
  • 101
  • 1

2 Answers2

1

It is fairly easy to use PowerShell plus WMI eventing to detect process creation (and exit). Then filter (heavily) before logging.

Both filesystem and registry operations can be audited (that's what the System ACL on each object is for once globally enabled), operations will be written to the system event log. This will generate a lot of data (even when what is audited is rather limited).

However I think you might be better with a different approach if your aim is to prevent fiddling. Of course these mechanisms can all be bypassed by a local admin (and so can any auditing mechanism of course).

Better to consider why they need local admin access: do they really need it, or is it some broken application? (For the latter, as I understand, compatibility shims can often resolve things).

In the end it might be a matter of telling them: with great power comes great responsibility.

Richard
  • 5,324
  • 1
  • 23
  • 20
1

You could use a keylogger (make sure the AV software has an exception for it) but really, this is a human management issue not a technical one. My suggestion would be to take any system that has been fiddled with to the point of causing a problem and simply re-imaging it. The more inconvenient it is for the culprit the sooner they'll learn.

John Gardeniers
  • 27,458
  • 12
  • 55
  • 109