What is the new Event Stamping feature in DRA 9.1?

Event Stamping in DRA

 

When Active Directory Domain Services (AD DS) auditing (https://technet.microsoft.com/en-us/library/cc731607(v=ws.10).aspx)) is enabled events generated by DRA will be logged as having been generated by either the DRA service account or the domain access account if one is configured. Due to this we have no way of knowing which DRA Assistant Admin (AA) actually performed the operation.

 

To provide this information in the AD DS audit logs we have introduced a new feature called Event Stamping which will generate an additional AD DS event for each DRA operation that supports this feature. This additional event will contain information that specifies among other things the AA who actually performed the operation.

 

This event is a standard AD DS event so it will be available to any application, such as Change Guardian, that wishes to use it.

 

The list of DRA operations that support event stamping are listed at the end of this document.

 

Enabling Event Stamping

 

For these events to be generated you must configure AD DS auditing and enable event stamping in DRA.

 

To enable event stamping open the Delegation and Configuration console as a DRA administrator and go to Configuration Management > Update Administration Server Options > Event Stamping.

 

Select an object type and click Update. You can then select an attribute to use for event stamping for that object type. DRA currently supports event stamping for users, groups, contacts, computers and Organizational Units.

 

The attributes that are available for event stamping are Unicode String attributes with a minimum length of 400 characters. This ensures the selected attributes can contain the data generated by DRA.

 

DRA also requires that the attributes exist in the AD schema for each of your managed domains. You should be aware of this if you add managed domains after configuring event stamping. If you were to add a managed domain that does not contain a selected attribute operations from that domain would not be audited with the event stamping data.

 

DRA will be modifying these attributes so you should select attributes that are not used by DRA or any other application in your environment.

 

How Does Event Stamping Work

 

When you configure an attribute for an object type and DRA performs one of the supported operation that attribute will be updated (stamped) with DRA specific information (AA who performed the operation, etc.) which will cause AD to generate an audit event for that attribute change.

 

As an example let’s assume you selected the attribute extensionAttribute1 as your user attribute and you have AD DS auditing configured. Whenever an AA updates a user DRA will update the extensionAttribute1 attribute with the event stamping data. This means that along with the AD DS events for each attribute the AA updated (e.g. description, name, etc.) there will be an additional AD DS event for the extensionAttribute1 attribute.

 

Each of these events will contain a Correlation ID that is the same for each attribute that was changed when the user was updated. This is how applications can associate the event stamping data (AA who performed the operation, etc.) with the other attributes that were updated.

 

The AD DS Event

 

You will see an event such as this in the Windows Security event log any time DRA executes a supported operation.

 

LDAP Display Name:       extensionAttribute1

                Syntax (OID):     2.5.5.12

                Value:   <dra-event user="DRDOM300\drauseradmin" sid="S-1-5-21-53918190-1560392134-2889063332-1914" tid="E0E257E6B4D24744A9B0FE3F86EC7038" SubjectUserSid="S-1-5-21-4224976940-2944197837-1672139851-500" ObjectDN="CN=admin_113,OU=Vino_113,DC=DRDOM113,DC=LAB"/>+a+02ROO+bJbhyPbR4leJpKWCGTp/KXdqI7S3EBhVyniE7iXvx+IT6eB6IdcXQ5StkbIAHJgKzLN5FCOM5fZcITxyAPLWhbstaA7ZA0VbVC9MGlVIaAcjl3z7mpF9GKXsfDogbSeNlmHliXvH5KpOX3/29AKMPj/zvf6Yuczoos=

 

The event value consists of two pieces. The first is an XML string containing the event stamping data. The second is a signature of that data that can be used to validate the data was actually generated by DRA. To validate the signature an application must have the public key for the signature.

 

The XML string consists of the following information:

 

User	The Assistant Administrator who performed the operation
Sid	The SID of the Assistant Administrator who performed the operation
Tid	The DRA auditing transaction ID to ensure each event is unique
SubjectUserSid	The SID of the DRA service account or access account that actually updated AD
ObjectDN	The distinguished name of the object that was modified

 

 

Supported Operations

 

User

 

·         Create

·         Rename

·         Modify

·         Clone

 

Group

 

·         Create

·         Rename

·         Modify

·         Clone

 

Contact

 

·         Create

·         Rename

·         Modify

·         Clone

 

Computer

 

·         Create

·         Enable

·         Disable

·         Rename

·         Modify

 

Organizational Unit

 

·         Create

·         Rename

·         Clone

 

 

Unsupported Operations

 

The following operations are not currently supported.

 

·         Exchange related operations.

·         Password set and change operations.