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.
Previous
Register
htckav March 12, 2008 (Article Rating: