Enable auditing and local PowerShell script execution on Active Directory and Exchange servers

The Active Directory (AD) and Exchange modules of the Splunk App for Microsoft Exchange require that you enable certain features in your AD environment in order for the app to function optimally. This topic discusses how to enable auditing of AD events and execution of local PowerShell scripts.

Auditing overview

By default, Active Directory does not automatically audit certain security events. You must enable auditing of these events so that your domain controllers log them into the Security event log channel.

You do this by creating a Group Policy object (GPO) and deploying that GPO to all domain controllers (DCs) in your AD environment. Once you activate the GPO, your DCs log these security events into the Security event log. After you deploy universal forwarders with the appropriate add-ons onto your DCs, the forwarders collect the logs and forward them to the central Splunk App for Microsoft Exchange instance.

Note: This topic shows you how to create individual Group Policy objects (GPOs) for both sets of settings. If you wish, you can combine both the PowerShell and audit settings into a single GPO. For ease of administration, you should create and deploy these GPOs separately from other GPOs.

Important information on security event auditing and indexing volume

When you enable auditing of the Security Event Log on your domain controllers, the DCs generate a lot of data. These events significantly increase indexing volume and might cause indexing license violations. You might also see decreased performance on your domain controllers based on how much additional data the servers generate.

If you are concerned about the impact that enabling security event auditing might have on your indexing volume, you can tweak policy settings to generate only the data that is important to you. Refer to the table below to learn about which policy settings generate which event types, and how the Splunk App for Microsoft Exchange uses those events to populate its dashboards, reports and lookups.

If you choose to disable certain policy settings in an effort to curb indexing volume, you directly affect how much data gets sent to the Splunk App for Microsoft Exchange. The table below lists what data you do not collect if you decide not to enable a particular policy setting. This is not an all-inclusive list - the app correlates some lookups across various policy settings, as multiple events often derive a single knowledge object. Failure to enable all of the policy settings might cause the Splunk App for Microsoft Exchange to display incomplete or incorrect knowledge objects in its dashboards and reports.

Policy setting:	Required?	What the Splunk App for Microsoft Exchange uses it for:
Audit Account Logon Events	Yes	Administrator Audit dashboards Security->Logon dashboards Security->Reports->New (Computer or Domain) Accounts Session ID-to-User (tSessions) lookup Computer-to-IP Address (tHostinfo) lookup
Audit Account Management	No	Administrator Audit dashboards Change Management dashboards
Audit Logon Events	No	Administrator Audit dashboards Logon and access information
Audit Object Access	No	Administrator Audit dashboards Information on who changed a GPO and when
Audit Policy Change	No	Security->Reports->Group Policy Reports GPO Change Management dashboard
Audit System Events	No	Directory Services replication events

Advanced Audit Policy settings

You might alternatively want to use the Advanced Audit Policy (AAP) configuration settings to control which events your domain controllers send to the Splunk App for Microsoft Exchange. While we do support this method, it is outside the scope of this document to list all available AAP configuration options.

This is because of the number of available AAP configuration options and the fact that those options change with different Windows versions - for example, the options for the Windows Server 2003 family differ from those in the Windows Server 2008 and Server 2012 families. Windows Vista and earlier versions of Windows do not support AAP.

If you need more granularity in the types of audit events you want generated, you can review eventtypes.conf (located in the Splunk App for Microsoft Exchange installation at %SPLUNK_HOME%\etc\apps\splunk_app_windows_infrastructure\default) for the event codes that the app looks for. With that information, you can create a GPO that enables AAP and generates audit events for only those specific event codes.

Note: When you enable AAP, Windows disables configurations for standard Audit Policy.

Enable auditing

To enable auditing of security events in your AD domain or forest:

On Windows Server 2003 and Server 2003 R2

1. Create a new Active Directory GPO:

a. Click Start > Administrative Tools > Active Directory Sites and Services.

b. In the left pane, under "Sites", locate the forest for which you want to set group policy.

c. Right-click the site, then select Properties.

d. In the window that appears, click the Group Policy tab.

e. Click New.

f. Enter a unique name for your new GPO that you will remember.

2. Open the GPO for editing by clicking the Edit... button in the Group Policy properties window.

3. In the GPO Editor, select Computer Configuration > Windows Settings > Security Settings > Local Policy > Audit Policy.

4. Enable both Success and Failure auditing of the following policy settings:

• Audit account logon events
• Audit account management
• Audit directory service access
• Audit logon events
• Audit object access
• Audit policy change
• Audit privilege use
• Audit system events

5. Close the Group Policy Object Editor window to save your changes.

6. Deploy the GPO:

a. Open Active Directory Users and Computers. Click Start > Administrative Tools > Active Directory Users and Computers.

b. In the left pane of the window that appears, right-click Domain controllers then click Properties.

c. Click the Group Policy tab.

d. Click the Add... button.

e. In the dialog that appears the All tab.

f. Select the GPO you created in Step 1, then click OK.

g. Move your GPO up or down in the priority list to your liking.

h. Close the window to save changes.

On Windows Server 2008, Server 2008 R2, Server 2012, and Server 2012 R2

1. Create a new GPO:

a. Click Start > Administrative Tools > Group Policy Management.

b. In the left pane, under "Group Policy Management," expand the forest and domain for which you want to set group policy.

c. Right-click Group Policy objects and select New.

d. In the dialog window that opens, enter a unique name for your new GPO that you will remember in the Name field, and select None for the Source Starter GPO field.

2. Open the GPO for editing by right-clicking the newly created GPO In the Group Policy Objects window and selecting Edit.

3. In the GPO editor, select Computer Configuration > Policies > Windows Settings > Security Settings > Local Policy > Audit Policy.

4. Enable both Success and Failure auditing of the following policy settings:

• Audit account logon events
• Audit account management
• Audit directory service access
• Audit logon events
• Audit object access
• Audit policy change
• Audit privilege use
• Audit system events

5. Close the Group Policy Object Editor window to save your changes.

6. Deploy the GPO:

a. In Group Policy Management, in the left pane of the window, right-click on the Domain Controllers item and click Link an existing GPO..."

b. In the window that appears, select the GPO you created in Step 1.

c. Click OK. The GPMC will refresh to show that your GPO is now linked to the Domain Controllers organizational unit.

Enable local PowerShell script execution

The add-ons included in the Splunk App for Microsoft Exchange installation package contain PowerShell scripts that must run on the AD (domain controllers and DNS) and Exchange servers in your AD environment. You must configure your domain controllers to allow local execution of PowerShell scripts so that they can run.

To enable local execution of PowerShell scripts on your domain controllers:

1. If required, download Windows Management Framework (http://support.microsoft.com/kb/968929) from Microsoft's Support site and install it.

Note: All versions of Windows Server 2008 SP2 (except Core) and Windows Server 2008 R2 have PowerShell installed by default. All versions of Windows Server 2012 have PowerShell 3.0 installed by default. You might need to install Windows Management Framework on Windows Server 2003 family computers.

2. If required, download the Administrative Templates for Microsoft PowerShell (http://www.microsoft.com/en-us/download/details.aspx?id=25119) from Microsoft and install them.

Note: All versions of Windows Server 2008 (except Core) and later have the required templates for PowerShell installed.

3. Create a new Active Directory GPO:

4. Open the GPO for editing.

5. In the GPO editor, select Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell.

6. Right-click "Turn on script execution", then select "Edit".

7. In the window that appears, click the "Enabled" radio button.

8. In the "Execution Policy" drop-down, select Allow local scripts and remote signed scripts.

9. Click "OK" to accept the changes.

10. Close the Group Policy Object editor to save your changes.

11. Deploy the GPO.

GPO updates

Once you have deployed the GPOs, it can take up to 120 minutes before Active Directory applies the GPOs to the domain. If you want to deploy the GPOs faster, you must run the GPUPDATE /force command on every computer upon which you want to update Group Policy.