Cool Auditing Tricks in Vista and 2008

Hi, Ned here again. Today I’m going to show some interesting new features of Auditing in Windows Vista and Windows Server 2008 that can be used for troubleshooting problems or seeing what’s happening in your environment. I’ll be building upon some of the basic information Dave Beach talked about in ‘Introducing Auditing Changes in Windows 2008’. This is not designed to be the be-all, end-all (in fact, I hope to write some further follow-ups on this), but it should definitely help get the creative juices flowing and help people turn to auditing more often than they have in the NT-2003 days.

First, let’s quickly revisit the changes. Vista and 2008 now support granular auditing, meaning that instead of a couple large categories you can specify very specific elements to be audited. The advantage here is that instead of turning on Object Access auditing then wading through miles of chaff, you can get something as specific as just network file share usage information, or just account lockouts, or just process creation. To see all your options execute (from an elevated CMD prompt):

auditpol /list /subcategory:*

This will return all the new categories and subcategories. To deploy these types of changes in a Domain-based environment, follow ‘How to use Group Policy to configure detailed security auditing settings for Windows Vista client computers in a Windows Server 2003 domain or in a Windows 2000 domain’.

If you’re troubleshooting though and just want to make some specific audit changes to a computer in a domain, there’s an easier way:

Via GPEDIT.MSC

1. Open the Group Policy Object Editor (GPEDIT.MSC).
2. Expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Local Policies, and then click Security Options.
3. Double-click

Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings.

4. Click ENABLED, and then click OK.
5. Restart the machine.

Via REGEDIT.EXE

1. Open the Registry Editor (REGEDIT.EXE)
2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA

3. Add a new DWORD value of SCENoApplyLegacyAuditPolicy
4. Set the value data to 1
5. Close REGEDIT and restart the machine.

After making this change the computer will no longer apply auditing security policy even when specified in domain-based group policies; this way your changes won’t get overwritten as we proceed. You can read more about this in KB921468.

It’s critical to realize that something else important happened in Windows Vista and 2008 – Crimson. We finally rewrote the 15-year old Event Service first delivered in NT3.1, and now there are no longer the old scalability and reliability problems with event logs. Need a 16GB security log? No sweat, it can handle it. Plenty more on this here.

So let’s do some cool things with this new system…

Find out when users on Vista are elevating their programs with UAC

Here’s a common scenario: User Account Control is enabled and the users have been added to the Administrators group on their Vista clients. You need to know how often and for what reasons they are elevating their so-called ‘split tokens’. Maybe it’s for audit trail, maybe it’s to identify applications that might need to be updated or rewritten to not need admin credentials, or maybe you just want to prove that when a user complains he gets prompted ‘all the time’ you can respond with ‘Really? Seems like it was just twice this week!’

1. We enable the “Process Creation” subcategory of “Detailed Tracking” category with:

Auditpol.exe /set /subcategory:"process creation" /success:enable

2. We let things cruise for a few days with the user cranking away on his system.3. We connect to the machine with EVENTVWR.EXE using ‘Connect to Another Computer’
4. We set a filter by selecting Windows Logs -> Security then select Filter Current Log. We set a filter for Event ID of 4688 like so:

5. This removes everything from our view except Process Creation events.
6. We now do a Find for TokenElevationTypeFull (2)and we see things like:

Did I mention the actual audit descriptions are useful now? :) I might not have known what TokenElevationTypeFull meant, but the event is there to tell me all about it.

Find out who is making AD changes unrelated to Accounts, using Windows Server 2008

Another favorite is “who the heck has been messing with group policy?!” In this scenario we have a number of OU’s that are managed by branch and group policy administrators. These users have been delegated rights to control group policy for their respective only. After time though, you are finding that some of them are making changes that contravene IT policies and standards. What’s worse, there are several people with rights to make changes and no one is admitting anything. How can we figure this out?

By default, Active Directory OU’s are already configured with audit entries that track group policies being linked, blocked, or enforced – so we don’t have to muck around in ADSIEDIT or AD Users and Computers this time. So let’s get on with the rest:

1. Enable the auditing subcategory of “Directory Service Changes”, either via AUDITPOL on all DC’s or KB921469. This means going forward you’re tracking people making changes in DS, for anything you have configured to be auditable.

We wait for the hammer to drop…

2. Finally, someone makes one of these changes we don’t like. On any computer joined to that domain running Windows Support Tools, we execute:

repadmin /showmeta "ou=remote branch,dc=cohowinery,dc=com"

… which is the OU we cared about. It returns:

9 entries.
Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute
======= =============== ========= ============= === =========
<Snipped out goo>

22653 Default-First-Site-Name\2008SRV10 22653 2007-11-08 19:20:57 5 gPLink 22650 Default-First-Site-Name\2008SRV10 22650 2007-11-08 19:20:45 3 gPOptions

So now we know the when and the where – someone changed group policy links and enforcement on Nov 8 at 7:20PM. We need the who and the what.

We crack open the EVENTVWR on our Windows Server 2008 DC named (imaginatively named ‘2008SRV10’). We filter for 5136 events and see:

And:

GPoptions is an AD attribute that marks ‘Block Policy Inheritance’ – being set to 1 means that this OU will no longer receive policies linked at a higher level than itself. Since we’re setting some policies at the domain level, this is probably not cool!

GPLink is an AD attribute that lists out which policies are linked to an OU (or site, or domain) and whether it’s enforced or not (0 or 1). It contains a value that points to an actually policy object.

So above, we see now that Robert is our culprit. He’s been blocking corporate group policies specified at the domain, and he’s also linking policies at his own OU. Since he’s allowed to link, let’s see what he actually added. We can either run Windows Server 2008’s built-in ADSIEDIT.MSC or we can execute a command.

Executing (this is all one line):

dsquery * "cn={2CC9A70E-DAD5-4707-B1C1-3EE8DC565AC8},cn=policies,cn=system,DC=cohowinery,DC=com" -scope base -attr displayname

Which returns:

displayname
Install Specially Licensed Software

Well heck – he’s also linking a policy that installs some software that we have limited licensing. And of course, he’s not supposed to. But now we know…

Find out what is changing a registry value at random intervals

Finally, let’s discuss another common problem – at unpredictable intervals, something or someone is making registry changes on Vista computers. You suspect it’s a script or application, but you’re not sure how to figure out the source. Since it takes so long to happen you can’t just stare at the machine, so you decide to enable some auditing.

For this specific scenario, we have a handful of Vista machines that keep ending up in the wrong AD Logical Site. These machines were specially configured in the past to go to a specific site called FLURG rather than use dynamic site coverage.

So here’s what the registry looks like when everything is right:

1. We open REGEDIT and navigate to

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters

2. We right click and choose Permissions. We click Advanced, then Auditing. We add Everyone like below, making sure to only choose ‘This Key Only’ and Set Value for Successful. The reasoning here is that we only want this specific data and no sub-keys that might exist, we only want to see something writing data (certainly not querying!), and we don’t care if it fails.

3. We then enable the auditing subcategory of ‘Registry’ under ‘Object Access’ like so:

Auditpol.exe /set /subcategory:"Registry" /success:enable

We already know this isn’t going to happen for days, and we sure as heck don’t want to keep walking over to this machine every few hours, so let’s configure a subscription to tell us when things change.

4. We turn on the Windows Remote Management service on the affected machine:

winrm quickconfig

… which returns:

WinRM is not set up to allow remote access to this machine for management.
The following changes must be made:

Set the WinRM service type to delayed auto start.
Create a WinRM listener on https://* to accept WS-Man requests to any IP on this machine.
Enable the WinRM firewall exception.

Make these changes [y/n]? y <-- enter y here and hit <enter>

WinRM has been updated for remote management.

WinRM service type changed successfully.
Created a WinRM listener on https://* to accept WS-Man requests to any IP on this machine.
WinRM firewall exception enabled.

5. We start that Windows Remote Management service.

6. We then go into EVENTVWR on our own administrative machine(not the problem machine!) and click Subscriptions. We then select Create Subscription, which gives us a dialog we can fill out:

7. Make sure to hit advanced and add a user account with rights to access that machine. If you want to get alerts ASAP select the option for Minimize Latency.

8. We then choose ‘Select Events’ and add our filter so that we get Informational events (which Security events always fall under), matching 4657, and auditing success only.

So now, all Event 4657 occurrences on the problem machine will be forward to our own machine. But let’s not stop there; after all, I still don’t want to stare at Event Viewer all day at my desk. Let’s make it tell us when something interesting happens, by adding a special kind of scheduled task on our workstation:

schtasks /create /tn EventLog /tr eventvwr.exe /sc onevent /ec ForwardedEvents /mo *[System/EventID=4657]

This command adds a scheduled task which:

• Monitors the Forwarded Events log channel
• Looks for 4657 events showing up
• Starts Event Viewer for us when it all happens

So a few days go by and we’re sitting at our desk enjoying some light reading when suddenly Event Viewer opens. Woohoo! We look at the Forwarded Events and see:

There’s our guy. We walk over and chat with Billy Bob and he admits he’s got a script he’s been using that shells REG.EXE to make some registry changes. And wouldn’t you know it, there’s some old recycled code in it that explains our issue. High five.

I hope this post helped you get familiarized with Vista and Windows Server 2008 auditing capabilities. Please let us know one way or the other.

- Ned Pyle

Comments

• Anonymous
  November 17, 2007
  Not only is there fine-grained password control, there is also enhanced auditing. Vista and 2008 now support granular auditing, meaning that instead of a couple large categories you can specify very specific elements to be audited. The advantage here

• Anonymous
  November 30, 2007
  I hope this post will act as a good reference point to be able to quickly understand the good and bad

• Anonymous
  March 19, 2008
  A little while ago, I was investigating the customer experience data on elevations which we use to identify

• Anonymous
  April 14, 2008
  The comment has been removed

• Anonymous
  April 14, 2008
  The comment has been removed