11.4 Designing Auditing Schemes

Designing auditing schemes, in contrast to permissions, is a relatively easy process. Imagine the circumstances in which you may need to check what is happening in Active Directory, and then set things up accordingly.

You must remember that every Active Directory event that is audited causes the system to incur extra processing. Having auditing turned on all the time at the root for every modification by anyone is a great way to get all DCs to really slow down if a lot of Active Directory access occurs on those DCs. That point bears repeating. Auditing changes to anywhere in the domain Naming Context (NC) will propagate domainwide and cause logging to the security event log on every DC that services the Domain NC. Auditing changes to the Configuration NC or Schema NC will cause all DCs in a forest to begin auditing to their security event logs. You must have tools in place to retrieve logs from multiple DCs if you wish to see every security event that occurs. After all, if you have 100 DCs and are logging Configuration NC changes, then because changes can occur on any DC, you need to amalgamate 100 security event logs to gather a complete picture.[1] [1] Applications for consolidation of event logs are SeNTry by Mission Critical, Event Admin by Aelita, and AppManager by NetIQ. Also, note that Microsoft's WMI technology has excellent event logging, reporting, and notification capabilities if you wish to script such items yourself.

Here are a few examples where designing auditing schemes could come in handy:

• Someone complains that user details are being set to silly values by someone else as a joke.

• You notice that new objects you weren't expecting have been created or deleted in a container.

• The Active Directory hierarchy has changed and you weren't informed.

• You suspect a security problem.

In all these scenarios, you will need to set auditing options on a container or a leaf object. These auditing entries do not have to exist all the time, so you could write them up and then code them into a script that you run at the first sign of trouble. That way, the system is immediately updated and ready to monitor the situation. This can happen only if you are prepared.

You need to analyze the scenarios that you envisage cropping up and then translate them into exact sets of auditing entry specifications. After you have written up each scenario and an emergency occurs, you will be able to follow the exact instructions that you previously laid down and set up a proper rapid response, which is what auditing is all about.

Step one in a real emergency may be to turn all auditing on at the root to make sure that you capture everything to the security log. Step two may be to turn on auditing for the specific items that you need to audit, so that with step three you can finally remove the Audit-All at the root that normally would cause a severe slowdown. That way, you slow Active Directory briefly while setting up the auditing you actually require, but you don't lose any audit entries during that time. The point is that having a properly prepared set of scripts will save you trouble in the long run as you can quickly use your "Audit all object creations and deletions below a container" or "Audit this object only for any changes" scripts to take the object or container DN as a parameter and so make the scripts generic. Creating scripts is covered later in the book in Chapter 23.