Active Directory (AD) is the epitome of a mission-critical infrastructure system. Often, the highest-level AD object—a forest—corresponds to the enterprise itself. One mistake can cause an enterprisewide catastrophe. The more administrators you have, the greater the chance that "too many chefs can spoil the stew." Obviously, you need effective AD monitoring, and the need becomes even more evident when you take into account intrusion attempts from the outside and by disgruntled IT staff members.
Additionally, you can take advantage of AD's delegation-of-control features to empower local administrators and managers to assign group memberships and perform other simple maintenance tasks that you've always performed because you've been afraid of losing control over them. The ability to effectively monitor what the people you delegate authority to are doing with it helps you to assuage your fear and stay in command.
You can stay on top of what's happening in AD and who's changing what by using two audit categories: account management and directory service access. Account management auditing provides notification of high-level changes (i.e., creations, deletions, and other changes) to user accounts, computer accounts, and groups. Account management auditing also tracks some account policy-related changes.
Directory service access auditing provides low-level, field-by-field change notification. For any high-level change that account management auditing tracks, directory service access auditing generates several events, but when available, account management events are almost always easier to understand and are more informative. Therefore, the general rule of thumb is to use account management auditing when available and directory service access auditing for activity that account management auditing doesn't track. If you're interested in monitoring local users and groups on a member server, you can use account management auditing but not directory service access auditing.
Account Management Auditing
To enable account management auditing, select Domain Controller Security Policy under Administrative Tools; maneuver to Security Settings, Local Policies, Audit Policy; and enable Audit account management for success and failure. Account management auditing provides discrete event IDs for creation of, deletion of, and changes to users, computer, and group accounts. Table 1 lists account management event IDs.
Account management creation events can help you keep AD clear of redundant or nonstandard users, computers, and groups. Cleaning up redundant or unneeded objects soon after their creation is much easier than doing so down the road when no one remembers what the object was intended for or why it was created. You can spot-check creation events and audit new users, groups, and computers' compliance with your organization's policies and procedures. A new computer account means that someone is rolling out a new workstation or server into your domain. You can verify event ID 645 against your new-computer provisioning process to make sure the computer being added is authorized. You can use event ID 624 to track new users being added to the domain. Verify that the new accounts are legitimate user accounts, and enforce any policies you might have for naming conventions, employee/contractor documentation, or shared or application accounts.
You can also watch for event IDs 631, 635, and 658 to enforce naming convention policies on groups and to make sure that each group has a clearly indicated owner who's responsible for approving member additions and removals. A good place to document the owner of a group is the Managed By tab on the group's Properties dialog box, which lets you link a group to an AD user account. Most other AD objects' Properties dialog boxes also have a Managed By tab.
One problem with large AD deployments is keeping track of which access levels and resources a given group extends to its members. You can document this information in English in the Notes field of the General tab on the group's Properties dialog box. Or, you can use the two-level group method for access control that I wrote about in "Effective Access Control for Win2K and NT," October 2000, http://www.winnetmag.com, InstantDoc ID 15482.
Deletion of users, groups, or computers rarely presents a security risk, so you typically don't need to perform ongoing monitoring for deletion events. However, these events can be useful when you need to track down who accidentally deleted an important account or group or if you're worried about someone performing mass deletions of users or groups in a Denial of Service (DoS) attack.
Previous
Register
