Setting Audit Policies in Windows

Endpoint Administration Guide for Windows › Monitoring and Auditing › What CA ControlMinder Audits › Setting Audit Policies in Windows

Setting Audit Policies in Windows

In addition to setting access rules for accessors and resources, you can specify Windows events that you want to write to the audit log. You can specify such audit policies for the entire organization, on a group basis, on a profile group basis, or on a user-by-user basis.

Example: Set an Audit Policy for All Members of a Profile Group

The following example shows you how you can set an audit policy for all users that are part of profile group:

Create a new profile group with the audit mode you require. For example:
```
newgrp profileGroup audit(failure) owner(nobody)
```
Create a new user and attach it to the profile group you created. For example:
```
newusr user1 profile(profileGroup) owner(nobody)
```
Remove the user's audit setting. For example:
```
chusr user1 audit-
```

You can now check whether this setting is effective:

Log on as the new user:
```
runas /user:user1 cmd.exe
```
From user1's command prompt window, enter the following:
```
secons -whoami
```
This command displays the information that is used for authorization and is held in the ACEE for user1.
```
ACEE audit mode is: Failure; Originated from Profile group definition
```
This message confirms that the audit policy is derived from the profile group the user is attached to.

Example: Set a Audit Policy for Group Members

In this example, a fictional company named Forward Inc wants to use CA ControlMinder to protect all files in the /production directory. The /production directory has full access permissions in the native environment.

Forward Inc wants to deny and audit any attempts to access the /production directory. However, Forward Inc permits read access to the /production directory for developers. This access is not audited. An attempt by a developer to write to the /production directory is denied and audited.

Developers can request full access to the /production directory. Forward Inc audits any activity that a user with full access performs in the /production directory.

The following process describes the steps Forward Inc takes to implement the previous scenario:

Create a group named Developers in the native environment. Join all the developers to this group.
Create a group named Dev_Access_All in the native environment. Do not join any users to this group.
Define a generic access rule for the /production directory, as follows:
```
authorize FILE /production/* access(none) uid(*)
```
This rule sets the default access as none.
Define a generic audit rule for the /production directory, as follows:
```
editres FILE /production/* audit(failure)
```
This rule audits any failed attempt to access the /production directory.
Define an access rule for the Developers group, as follows:
```
authorize FILE /production/* access(read) xgid(Developers) 
```
This rule permits members of the Developers group to have read access to the /production directory.

Note: The rule you set in Step 4 helps ensure that CA ControlMinder audits any failed access attempt by any user, including members of the Development group.
Define an access rule for the Dev_Access_All group, as follows:
```
authorize FILE /production/* access(all) xgid(Dev_Access_All)
```
This rule permits members of the Dev_Access_All group to have full access to the /production directory.
Define an audit rule for the Dev_Access_All group, as follows:
```
chxgrp Dev_Access_All audit(all)
```
This rule audits every action a member of the Dev_Access_All group performs.
When a member of the Developers group needs full access to the /production directory, add the user to the Dev_Access_All group in the native environment.
The user has full access to the /production directory, and CA ControlMinder audits every action the user performs.

Note: The user must start a new logon session for the change in group membership to take effect.
When the user has completed their task in the /production directory, remove the user from the Dev_Access_All group in the native environment.
The user now has read access to the /production directory. CA ControlMinder denies and audits any other access attempt on the /production directory by the user.

Note: The user must start a new logon session for the change in group membership to take effect.