Using Standard NT Security Features in Windows 7 : WORKING DIRECTLY WITH WINDOWS NT SECURITY (part 3) - Auditing User Actions

5/14/2013 4:32:48 AM

3. Auditing User Actions

Windows 7 incorporates many forms of auditing. An audit simply tracks some system event and may not even have anything to do with the user specifically. For example, setting object access auditing tracks all access, not just the user's access. A virus could access an object, and auditing would make it possible to track the access. Incorrect object access by an errant application is also tracked. In short, auditing has all kinds of uses, not just reviewing user activity. The following sections describe how to build the User Audit example so you can see auditing in action.

3.1. Configuring the User Audit Example

The User Audit example shows the current settings for any auditing on the system. The example begins with a Windows Forms application that looks much like the example shown in Figure 10-4. In addition, you must add the following using statement to your code:

using System.Security.AccessControl;

Unlike user security settings, auditing settings are quite sensitive, so you have to have administrator rights to view them. With this in mind, you must also add a manifest file to your application.

3.2. Configuring the Registry for Audit Monitoring

The system auditing settings appear in the default value of the HKEY_LOCAL_MACHINE\SECURITY\Policy\PolAdtEv key of the registry. Microsoft is extremely paranoid about the auditing settings, so it takes even more precautions than usual. In this case, the registry actually blocks access to the settings, even to the administrator. The .NET Framework does provide methods for working with registry security, but it turns out that they don't work when the administrator is blocked from access. Your only option at this point is to manually set the required privileges using the following steps:

  1. Locate RegEdit.EXE in your Windows folder (normally C:\Windows).

  2. Right-click the file and choose Run as Administrator from the context menu. You'll see the normal UAC warning dialog box.

  3. Click Yes. The system will start RegEdit as an administrator.

  4. Right-click the HKEY_LOCAL_MACHINE\SECURITY key and choose Permissions from the Context menu. You'll see the Permissions for Security dialog box shown in Figure 9. Notice that the Administrators group has almost no permission — only the SYSTEM account can access this registry key.

    Figure 9. Change the Administrator privileges to allow full control.
  5. Check Full Control and click OK. You now have access to the HKEY_LOCAL_MACHINE\SECURITY\Policy\PolAdtEv key.

  6. Choose View => Refresh or press F5 to see the new keys you can access.

3.3. Writing the User Audit Code

This example shows how to read the audit settings from the registry. However, by knowing the locations of the registry settings, you can also write the audit settings. The audit settings are found in a Byte array. Each byte entry can have one of four values:

  • 0: Disabled

  • 1: Success auditing

  • 2: Failure auditing

  • 3: Both success and failure auditing

Some of the auditing settings have multiple Byte array entries, but the reason for the multiple entries isn't clear, and Microsoft has chosen not to document the Windows 7 settings. With this in mind, Table 1 shows the audit settings and the Byte array decimal indexes associated with each entry. You need to monitor only one of these bytes when reading the values, but you must set all of them when changing a value.


Microsoft has documented the audit settings in the past. In fact, you can find a Knowledge Base article on the topic at Unfortunately, this Knowledge Base article is incorrect for Windows 7, and there doesn't appear to be any documentation for the updated configuration.

Table 1. Registry Index Values for Audit Settings
Audit Account Logon Events110, 112, 114, 1166E, 70, 72, 74
Audit Account Management90, 92, 94, 96, 98, 1005A, 5C, 5E, 60, 62, 64
Audit Directory Service Access102, 104, 106, 10866, 68, 6A, 6B
Audit Logon Events22, 24, 26, 28, 30, 32, 34, 36, 3816, 18, 1A, 1C, 1E, 20, 22, 24, 26
Audit Object Access40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 6228, 2A, 2C, 2E, 30, 32, 34, 36, 38, 3A, 3C, 3E
Audit Policy Change78, 80, 82, 84, 86, 884E, 50, 52, 54, 56, 58
Audit Privilege Use64, 66, 6840, 42, 44
Audit Process Tracking70, 72, 74, 7646, 48, 4A, 4C
Audit System Events12, 14, 16, 18, 200C, 0E, 10, 12, 14

Now that you know where the information is located and what the byte values are, it's time to write some code to interact with the audit settings. Listing 4 shows the code used for this example.

Example 4. Performing a system-level user audit
private void btnCheck_Click(object sender, EventArgs e)
    // Clear the previous results.

    // Get the required key.
    RegistryKey Policies =


    // Obtain the default value.
    Byte[] AuditValues = (Byte[])Policies.GetValue("");

    // Output the auditing values.
    // Check account logon auditing.
    switch (AuditValues[110])
        case 0:
                "Audit Account Logon Events Disabled");
        case 1:
                "Audit Account Logon Events Success");
        case 2:
                "Audit Account Logon Events Failure");
        case 3:
                "Audit Account Logon Events Success and Failure");

    ... Other Cases ...

    // Close the registry.


The code begins by clearing any information from the list box. It then opens the appropriate registry key using the Registry.LocalMachine.OpenSubKey() method and places a reference to it in Policies. The default value isn't named, so you call GetValue() with a null string. The output is a Byte array named AuditValues. Checking for each of the nine audit settings is a matter of looking at the correct byte value at this point. The example code shows one switch statement used for the task. Remember to call Policies.Close() when the application ends.

3.4. Testing the User Audit Example

The audit policies checked by this example reside in the Security Settings\Local Policies\Audit Policy folder of the Local Security Policy console shown in Figure 10. You can find this console in the Administrative Tools folder of the Control Panel.

Figure 10. Use the Local Security Policy console to change audit settings for this example.

To change a setting, double-click its entry in the Local Security Policy console. You'll see a policy Properties dialog box similar to the one shown in Figure 11. The Explain tab tells you about the audit policy and what it monitors on your system. The dialog box has checkboxes that let you monitor successful events, failures, or both. Check the options that you want to try and click OK. Remember to return the settings to normal when you're done working with the example, or your event log will be filled with tons of unnecessary entries.

It's time to see how the application works. Because of the need for administrator privileges, you'll see the usual messages as you start the application. Click Check and you'll see the current audit policy settings. Change any setting and click Check again to see the change. Figure 12 shows typical output from this example.

Figure 11. Modify the audit policies as necessary for testing.

Figure 12. The example accurately reflects the current audit policy settings.
  •  Using Standard NT Security Features in Windows 7 : UNDERSTANDING BASIC NT SECURITY
  •  Windows Server 2008 R2 networking : Planning and Deploying a TCP/IP Network Infrastructure (part 2) - Policy-based QoS
  •  Windows Server 2008 R2 networking : Planning and Deploying a TCP/IP Network Infrastructure (part 1)
  •  Windows Server 2008 R2 networking : Overview of Windows Server 2008 R2 Networking
  •  Windows Server 2003 : Recovering from System Failure
  •  Windows Server 2003 : Advanced Backup and Restore (part 2) - Scheduling Backup Jobs, Shadow Copies of Shared Folders
  •  Windows Server 2003 : Advanced Backup and Restore (part 1) - Managing Media, Backup Options, The Ntbackup Command
  •  Windows Server 2003 : Managing and Implementing Disaster Recovery - Restoring Data
  •  Windows 7 : Networking and HomeGroup Sharing - Sharing Between PCs (part 2) - Old-School Sharing
  •  Windows 7 : Networking and HomeGroup Sharing - Sharing Between PCs (part 1) - HomeGroup Sharing
    Top 10
    Review : Sigma 24mm f/1.4 DG HSM Art
    Review : Canon EF11-24mm f/4L USM
    Review : Creative Sound Blaster Roar 2
    Review : Philips Fidelio M2L
    Review : Alienware 17 - Dell's Alienware laptops
    Review Smartwatch : Wellograph
    Review : Xiaomi Redmi 2
    Extending LINQ to Objects : Writing a Single Element Operator (part 2) - Building the RandomElement Operator
    Extending LINQ to Objects : Writing a Single Element Operator (part 1) - Building Our Own Last Operator
    3 Tips for Maintaining Your Cell Phone Battery (part 2) - Discharge Smart, Use Smart
    - First look: Apple Watch

    - 3 Tips for Maintaining Your Cell Phone Battery (part 1)

    - 3 Tips for Maintaining Your Cell Phone Battery (part 2)
    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
    Popular Tags
    Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8