Auditing key maintenance activity on user and group accounts is a crucial layer in any company's "defense-in-depth" strategy. Just consider some of the reasons why monitoring changes to user and group objects is important. For example, if an attacker penetrates all your preventive controls, monitoring provides a last-defense detective control that gives you room to respond to the threat. If your company is subject to recent legislation such as the Health Insurance Portability and Accountability Act (HIPAA), the Gramm Leach Bliley Act (GLBA), or the Sarbanes-Oxley Act (SOX), monitoring is a key aspect of compliance. In addition, auditing is one of the only real controls you have over rogue administrators. Finally, if your company has taken advantage of Active Directory's (AD's) increased ability to support delegation of authority, auditing account maintenance is mandatory for keeping track of delegates' actions.
The Windows Server 2003 Security log has two categories that let you monitor maintenance activity on users and groups: Directory Service Access and Account Management. Directory Service Access is low-level and detailed, whereas Account Management provides high-level, easy-to-understand events. Both categories provide value, but for tracking users and groups, Account Management can't be beat. Account Management provides extremely valuable audit information in the form of specific event IDs for most of the actions that can be performed on users, groups, and computers. I'll examine Directory Service Access in a future article. This time, let's look at how you can leverage Account Management to audit the maintenance activity on your users and groups.
Getting Started
Account Management uses different event IDs for the creation of, deletion of, and all changes to user and group objects, as Table 1 shows. To configure Windows to begin recording account management events, you need to enable the Audit account management policy either in the computer's Local Security Policy Microsoft Management Console (MMC) snap-in or, on multiple computers, through a Group Policy Object (GPO) in AD.
Keep in mind that you can enable Audit account management on domain controllers (DCs) as well as member servers and workstations. On DCs, Account Management tracks maintenance events on computer accounts and domain users and groups in AD. With multiple DCs, Account Management records events on the DC on which the user, group, or computer was initially changed; when the change replicates to other domain controllers, Account Management doesn't generate duplicate events because the change is applied to each DC's replica of AD. On member servers and workstations, Account Management tracks changes to local users and groups in the computer's SAM. Although most of your account-monitoring effort will center on your domain's users and groups, don't conclude that you should ignore member server and even workstation SAM accounts. A key method attackers use for opening well-hidden back doors is creating local users in the computer's SAM or granting themselves administrator authority through membership in the local Administrators group.
Monitoring User Account Maintenance
When you create a user account, Windows logs event ID 624, which Figure 1 shows. You can tell by the event's description that The Architect created this new user account and named it AgentSmith. The Caller logon ID is a number that corresponds to the logon ID that was specified when The Architect logged on to the DC with either logon event ID 528 or ID 540. The fields under Attributes list some of the account's attributes that were specified when the user was created. Notice under User Account Control that the account was initially disabled. However, in the Security event log, in close proximity to this event ID 624, you'll find several event ID 642s, one of which Figure 2 shows. Look at the User Account Control field, and you'll see AgentSmith's user account has been enabled.
Why the need for event ID 642? Evidently, when you create an account, Windows 2003 creates the account, then configures the various attributes you specified in the New Object?User wizard, which results in the subsequent occurrences of event ID 642. The list of attributes in event ID 624 and 642 correspond to the attributes in a classic SAM user account (you'll find most of these attributes on the Account tab of the user account's Properties dialog box) but don't include all the additional properties found on a user object in AD. In AD, all the attributes and operations supported by SAM accounts are translated into their Lightweight Directory Access Protocol (LDAP) equivalents. For most security needs, monitoring accounts at the SAM level is sufficient.
For certain user account changes, Windows 2003 logs specific event IDs according to the type of change. For example, when you enable a user account, Windows 2003 logs event ID 626, as Table 2 shows. The user account change events in Table 2 were significantly revised between Win2K and Windows 2003. Note the differences between event IDs 627 and 628, password changes and password resets, respectively. When a user chooses a new password for his own account (which prompts him to enter his old password for authentication purposes), Windows considers this action a password change event. When an administrator resets a password for a user for any reason, Windows considers the action a password reset event. As you can see in Table 2, Windows 2003 does a better job of distinguishing between these two events than Win2K does.
A final word about the relationship between event ID 642 and the events in Table 2. You will always find an occurrence of event ID 642 when a user account is changed. For other types of changes, you'll also see an occurrence of one of the events that Table 2 lists in close proximity to the original event in the Security event log. To monitor changes for which Windows logs a specific event ID, it's much simpler and more direct to monitor for that particular event ID than to configure your report or alert criteria to look for a certain string within event ID 642.
Monitoring Group Maintenance
Two characteristics distinguish domain groups in AD: type and scope. Type determines whether a group is a distribution or a security group. Scope determines how the group can be used. Distribution groups exist for the benefit of Exchange Server 2000 and later and have no security-related function: You won't find distribution groups in ACLs or any other security-related settings. Security groups are used in file permissions and other security-related settings; mail-enabled security groups can also be used as distribution groups in Exchange. A group's scope determines how broadly the group can be used on the network and limits the number of other groups to which the group can be added as a member. Universal groups can be granted access to objects on any computer in the AD forest and can include users and global or universal groups from anywhere in the forest as members. Global groups can be granted access to resources anywhere in the forest but can include as members only users and global groups from the group's own domain. Domain local groups can include users and groups from anywhere in the forest as members but can be granted access only to resources within their own domain. Windows logs distinct event IDs for each combination of type, scope, and operation. Group creations, changes, and deletions simply state the name of the group and show who executed the operation. Group membership additions and deletions specify the group itself, the new or deleted member, and the user who executed the membership change.
Practical Tips and Recommendations
What are the important user-and group-related events to watch for? Of all the events that Table 1 lists, I'd be most interested in user account changes (event ID 642) and member additions to security groups (event IDs 636, 632, and 660), with new user accounts (event ID 624) a close runner-up. If your security is compromised either accidentally or maliciously, one of these five events will often tip you off to the problem: Attackers usually either create new accounts for themselves or enable or otherwise compromise existing accounts. And because the usual way to grant access to a resource is through group permissions, monitoring new users that are added to a group is a key way to monitor the access control changes that are important to compliance with most information security?related legislation.
I recommend that you enable account management auditing on all the computers in your domain. What should you monitor and report on? If you use scripts or an Independent Software Vendor's (ISV's) application for event log monitoring, you can configure them to produce periodic reports and send you near real-time alerts. Save real-time alerts for high-priority events that occur infrequently and can indicate some type of breach. Use daily, weekly, or monthly reports for more common, less suspicious events. If possible, perform a weekly or monthly review of new user accounts and group membership changes logged on your DCs. For daily reports or real-time alerts, consider watching for accounts being enabled (event ID 626) and membership additions to specific, highly privileged accounts such as Administrators, Domain Admins, Account Operators, Backup Operators, Server Operators, Power Users, and other important groups specific to your network. If your company is small, with little turnover, you can afford to monitor daily for new user account creations, rather than review a report of them less frequently.
If you can, monitor for new user accounts and group membership changes on your member servers. If you follow best practice and refrain from using local users and groups, activity on the local SAM should be minimal. If the system does detect a new local user account or local group membership change, you should know about it.
If your company has a Help desk that handles routine tasks such as forgotten password resets, make sure your systems are configured to audit such events, then spot-check them frequently when you verify Security log events against the supporting documentation. Make sure your Help desk staff knows that such reviews take place. This process is an effective deterrent against any dishonest staff members exploiting their authority for dishonest purposes.
Connecting the Dots
Account Management events let you connect the changes made to users and groups to your company's official written record, which is important for compliance and is a simple best practice. You should be able to tie user account creations and grants of access through group membership additions to a corresponding record that justifies the change and documents the appropriate manager's approval. The recording mechanism might be your Help desk program or, if your company is small, an email message from a manager requesting a user account for a new hire. One small company I know that doesn't have a formal Help desk application for recording all support and administrative requests created a Windows SharePoint discussion board called Account and Access Control Requests. The systems administrator requires all such requests to be approved by the appropriate manager in the discussion board. If the request comes to the admin directly through a phone call or email message, he simply initiates a discussion on the board. All the company's managers are on the alert list for the board and consequently get an email message with a link to the new request. The appropriate manager has only to follow the link and respond with "I approve."
Randy Franklin Smith ([email protected]) is a contributing editor for Windows IT Pro, an information security consultant, and CEO of Monterey Technology Group. He teaches Monterey Technology Group's Ultimate Windows Security course series and is an SSCP, a CISA, and a Security MVP.
\[Author's Note: This article series is based on Monterey Technology Group's "Security Log Secrets" course.\]
