This document explains how to use Novell Audit as a real-time IDM monitor to ensure your drivers are processing events.

The basic idea behind this system is use the Notification and Heartbeat Notification features to alert you in the absence of an event. The event that normally should occur is a single object that is updated at a scheduled time, for instance every 5 minutes. An IDM policy looks for this event; if the event occurs, the policy generates an Audit event to the SLS (Secure Logging Server) in order to alert the Heartbeat that the event happened. If there is a problem and this event is not received, the Heartbeat fires off a Notification - that is how you will be alerted.

Note: This document assumes you are familiar with Audit. If you are unclear on terminology or functions, please consult the documentation.

Let's get to it!

Setting Up the SMTP Channel

First, we need to set up an SMTP channel in Audit. Here is an example:

Figure 1 - Audit SMTP Channel

• • Host: Mail server you will send all e-mail traps to

• • Sender: Originating Address for the e-mails

• • Recipient: Address where you want to e-mail sent

• • Subject: Subject of the email. Here you can see that I am using a variable - "$ST". Variables are very useful and you will see them used later. In this example, I am using Text1(S) and Text2(T) event variables.

• Message: The message body. Here I am also using Text3(F) event variable.

After you have finished configuring the SMTP channel, you must reload Lengine:

If you are running NetWare:

1. Run "unload lengine"

2. Run "load lengine -d"

If you are running SLES:

1. Run "/etc/init.d/novell-naudit stop"

2. Run "/etc/init.d/novell-naudit start"

Creating a Monitoring Account

Now we move to the IDM side.

1. Create a special account, used only for monitoring, that you can synchronize to all your systems.

2. Once the account is created and synchronized to all your systems you want to monitor, set up a cron job to change a set attribute(for instance Title) to a random value.

You should use a random value so the change does not get optimized out and actually synchronizes. You also need to verify the attribute you are changing is in the filter of your systems.

Here is an example shell script that will randomly populate the Title attribute of the monitor account:

RANDOM=$$
ldapadd -H ldaps://server.test.test:636 -D cn=admin-monitor,o=acme -w password -x
 << EOF
dn: uid=monitor,o=acme
changetype: modify
replace: title
title: $RANDOM
EOF

In our example this must be cronned in less than 5 minutes, due to the trigger you will see later.

Creating an IDM Policy to Handle the Event Modification

Now we need to create an IDM policy that looks for this event modification and sends an Nsure Audit event when this modification is found.

Here is a example policy that is placed on the Input Transformation on the Publisher channel of an eDirectory driver:

<?xml version="1.0" encoding="UTF-8"?><policy>
	<rule>
		<description>Send Audit Heartbeat</description>
		<conditions>
			<and>
				<if-src-dn op="equal">\ACME-TREE\acme\monitor</if-src-dn>
			</and>
		</conditions>
		<actions>
			<do-generate-event id="1008" level="log-emergency">
				<arg-string name="target">
					<token-text xml:space="preserve">EDIRCD</token-text>
				</arg-string>
				<arg-string name="text1">
					<token-text xml:space="preserve">EDIRCD</token-text>
				</arg-string>
				<arg-string name="text2">
					<token-text xml:space="preserve">EDIRCD</token-text>
				</arg-string>
				<arg-string name="text3">
					<token-text xml:space="preserve">EDIRCD</token-text>
				</arg-string>
				<arg-string name="value1">
					<token-text xml:space="preserve">EDIRCD</token-text>
				</arg-string>
				<arg-string name="value2">
					<token-text xml:space="preserve">EDIRCD</token-text>
				</arg-string>
				<arg-string name="value3">
					<token-text xml:space="preserve">EDIRCD</token-text>
				</arg-string>
			</do-generate-event>
		</actions>
	</rule>
</policy>

We can see the only purpose of this policy is to look for the monitor account. When the monitor account is found, IDM will generate an event.

IDM user events range from 1000-1999. I found through trial and error that many times events are ignored if the text1,2,3 and value1,2,3 fields are empty or contain fewer than five characters. So I always populate them with at least six characters. The values you enter here are what will show up in the Nsure Audit log. They do not need to be the same, or meaningful in anyway. The only important value here is the 1008 event, which we will match up later.

There is also a policy on the Output Transformation of the Subscriber channel to catch this object as well, so you can monitor both sides of an eDirectory driver:

<?xml version="1.0" encoding="UTF-8"?><policy>
	<rule>
		<description>Send Audit Heartbeat</description>
		<conditions>
			<and>
				<if-operation op="equal">status</if-operation>
				<if-xpath op="true">object-dn/text()='\ACME-TREE\acme\monitor (acme\monitor)'</if-xpath>
			</and>
		</conditions>
		<actions>
			<do-generate-event id="1007" level="log-emergency">
				<arg-string name="target">
					<token-text xml:space="preserve">EDIRCD</token-text>
				</arg-string>
				<arg-string name="text1">
					<token-text xml:space="preserve">EDIRCD</token-text>
				</arg-string>
				<arg-string name="text2">
					<token-text xml:space="preserve">EDIRCD</token-text>
				</arg-string>
				<arg-string name="text3">
					<token-text xml:space="preserve">EDIRCD</token-text>
				</arg-string>
				<arg-string name="value1">
					<token-text xml:space="preserve">EDIRCD</token-text>
				</arg-string>
				<arg-string name="value2">
					<token-text xml:space="preserve">EDIRCD</token-text>
				</arg-string>
				<arg-string name="value3">
					<token-text xml:space="preserve">EDIRCD</token-text>
				</arg-string>
			</do-generate-event>
		</actions>
	</rule>
</policy>

Creating the Notification and Heartbeat Notification

So now we have an SMTP channel to send through, a monitor account that is being continuously updated, and an IDM policy that is looking for the monitor account to change. We now need to create the Notification and Heartbeat Notification in Nsure Audit to put this all together.

The Notification is used for sending and event to a channel, in this case our SMTP channel:

Figure 2 - SMTP Channel settings

Here our Notification is going to send through the SMTP channel if Text1 matches EDIRCDHBPUB. It is the job of the Heartbeat Notification to trigger Text1 to the Notification:

Figure 3 - Heartbeat Notification settings

This heartbeat is the most important part of this whole exercise. Let's go through each of these:

• • Description: Can be anything

• • EventID: Translated eventID(1008) that our policy sent. I have yet to figure out the translation; I merely looked in my Nsure Audit logs for the event as it was translated. 1009 will be 197617, and so on.

• • Interval: Number of seconds that the heartbeat will wait to receive the EventID before sending a notification

• • Originator: Can be anything

• • Text1: In our example, this is what our Notification is matching on. You may remember I am also using this variable in the SMTP channel.

• Text2-3, Value1,2,3: More variables you can use for your channel. They must each be at least five characters long.

So there you have it. You are now monitoring the Publisher channel of this eDirectory driver. If the driver stops for freezes or does not process events for 5 minutes, you will be notified via email.

Review

Now let's intuitively step through this process one more time:

1) A cron job kicks off at the two-minute interval, and the account monitor has its Title attribute randomly changed. The change synchronizes, and the policy on the Input Transformation on the Publisher channel picks it up the change. In the policy, an event do-generate-event id="1008" was generated.

2) Audit receives this event and matches EventID 197616. Since this event was received, nothing happens. The 300-second clock resets.

3) Suddenly the driver is frozen.

4) 300 seconds expire and the Heartbeat Notification listening for 197616 sends its notification. Part of this notification contains a Text1 value of "EDIRCDHBPUB".

5) A Notification filter monitors for a Text1 value of 'EDIRCDHBPUB". The notification sees this value and fires off the SMTP channel, which is set to alert you to the problem.

Enjoy!