The Windows Server 2008 Failover Clustering auditing feature has been requested by customers and provides the capability to monitor, or audit, cluster access. The cluster auditing feature can be enabled to audit accesses (Success and\or Failure) of an object. The object, in this case, will be the Microsoft Failover Cluster. This is accomplished by auditing client accesses to a cluster using Cluster APIs. This basically means that a client trying to access a cluster using either the Failover Cluster Management snap-in (Cluadmin.msc), the cluster.exe command line or any custom application that calls cluster APIs, will be subjected to auditing events if configured.
The OpenCluster() call initiates a new client session by binding to an RPC Server endpoint (CluAPI RPC Endpoint). This means once a user binds to a CluAPI RPC endpoint either locally or remotely, the user will be authenticated to ensure they are a valid Cluster Administrator. This is accomplished by an AccessCheckAndAuditAlarm call inside cluster anytime there is an OpenCluster() or a Security Callback.
To demonstrate auditing in a Windows Server 2008 Failover Cluster, I will configure auditing on a 2-Node cluster. To facilitate the demonstration, I create a Domain Global Group called Cluster Admins and then place three domain users in that group (Bill, Ted and Chuck). The Cluster Admins global group will be added to each cluster node’s local administrators group so the domain users in the group will have permission to administer the cluster. A fourth Domain User, Tom, is not authorized to administer the cluster but will be used to demonstrate the auditing functionality (Tom has the Log on locally right to the cluster nodes). The auditing policy will be configured at the domain level and enabled in the cluster. Finally, we will walk through a typical scenario where this feature may come in handy.
Here is the membership for the Cluster Admins global group.
After configuring the Cluster Admins group and adding it to the local administrators group on each node, create and then configure the auditing policy on a Domain Controller.
Auditing is not enabled by default either locally, on a machine, or in the domain by way of a group policy object (GPO). Here I enable auditing at the domain level by way of a Group Policy Object (GPO) (recommended best practice) so it can be applied to various clusters distributed throughout the domain. Using the Group Policy Management snap-in, create a new GPO Link called Cluster Auditing.
Note: Consider setting the Enforced option if you want to ensure this policy is not disabled by another less restrictive policy.
Once the policy is created, Edit it to actually define the settings. The policy, as shown here, is set to audit Object access and is set to audit Successes and Failures (this is an individual\business decision and can be changed).
After the policy is configured, confirm the settings in the interface.
Then, apply the policy to the cluster nodes as shown here.
This restricts the policy to the defined objects in Active Directory. In this case, it is the Authenticated Users group and the Nodes in the 2-Node cluster.
On each node in the cluster, refresh the group policy by running the command shown here.
To verify the setting, run the gpresult /v command and examine the output.
The output also details the settings for the policy (Cluster Auditing). It should be the same as configured in the Domain.
Once the policy has been applied to the cluster nodes, configure auditing in the cluster. In the Failover Cluster Management snap-in, examine the Properties of the cluster itself. Selecting the Cluster Permissions tab, access the Advanced configuration options.
Select the Auditing tab and Add the objects you want to audit. Here, I have added the Cluster Admins, Domain Admins and Authenticated Users groups.
After completing this action, auditing is enabled. No restart of the cluster service is required. Here is an example from the Security log on one of the nodes in the cluster.
If a user (in this example Tom) that does not have permission to administer the cluster, tries to access the cluster using either the Failover Cluster Management snap-in (cluadmin.msc) or using the cluster.exe CLI, they receive an error as shown here.
The corresponding Audit Failure entry in the Security log is shown here.
Now that we have discussed how to configure a domain level auditing policy so cluster can take advantage of it, here is a simple scenario that demonstrates how this capability might be used.
Gary is an Administrator in a corporate IT Department. He notices a highly available File Server group hosted in one of the clusters in his organization is not running on the cluster node it is supposed to. He needs to find out what happened so he reviews the cluster node system logs and does not see a failure that would explain the group moving over to another node in the cluster. He knows auditing is configured so he starts his investigation.
The first place he looks is in the Failover Cluster Operational log for the node where the group should be Online. He finds the following event in the log.
This tells him when the File Server group (CONTOSO-FS1) was taken Offline. He then inspects the corresponding Operational log on the node currently hosting the group and finds –
This tells him when the group came Online on the node.
With this information in hand, Gary inspects the Security logs on the cluster nodes and discovers one of his Cluster Admins was working on the cluster during the same timeframe.
Gary follows up with Ted to find out why the group was moved – mystery solved.
There you have it – quick and dirty on how auditing can be used with Failover Clusters in windows Server 2008. I hope this information may be of some use to you. Let us know.
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support