Chapter 8
Account Management Events

The Account Management security log category is particularly valuable. You can use these events to track maintenance of user, group, and computer objects in AD as well as to track local users and groups in member server and workstation SAMs. This category is also very easy to use: Windows uses a different event ID for each type of object and operation.

You can use Account Management events to track things such as new user accounts, password resets, and new members being added to groups. Monitoring the maintenance of domain users and groups can be a key aspect of compliance with legislation such as the Sarbanes-Oxley (SOX) Act and Health Insurance Portability and Accountability Act (HIPAA); access to private or financially significant information is controlled largely through group membership and based on user-account authentication. When you enable this category on DCs, each DC will begin recording maintenance events that are executed against users, group, and computer objects on that DC. To get a complete record of all Account Management events for AD objects, you’ll need to combine this category’s activity from all your DC Security logs. The table below shows all the subcategories that are associated with Account Management.

Account Management Subcategories	Comment
User Account Management	Track changes to server local user and AD user accounts
Computer Account Management	Track changes to AD computer accounts
Security Group Management	Track changes to AD security groups and local server groups
Distribution Group Management	Changes to mail accounts for exchange
Application Group Management	Role-based authorization groups for applications
Other Account Management Events	Policy change events

Account Management Events

The description fields of Account Management events are, for the most part, self-explanatory or similar to description fields from the categories that I've already discussed. Windows uses the Target field to identify the user, group, or computer that is the object of the event and identifies the object’s name and domain. Windows uses the Subject field to identify the user who performed the action.

User Account Management

The User Account Management subcategory tracks changes to local user accounts on member servers and to AD domain user accounts on DCs. The subcategory uses several event IDs shown below to track user account changes.

Note event ID 4738 (A user account was changed). User Account Management logs this event for any type of change. No list exists of the descriptions of all possible changes, so to filter instances of event ID 4738 for a certain type of change you’ll need to execute that change on a sample user account, find the event ID 4738 instance, and capture the text description that is in the Changed Attributes field. Before going to that trouble, look at the other events in this subcategory to determine whether any of them match the specified change. User Account Management provides additional, change-specific event IDs that make it easier to identify certain types of user-account changes. The first description field of these events usually provides a brief text description of what about the account was changed. For example, when you reset a user’s password, the first description string might say “password reset.” Note the difference between password changes (event ID 4723) and password resets (event ID 4724). Password changes occur when a user changes his or her password. Password resets indicate that an administrator or other support person reset the password for a user.

Event ID	Title
4720	A user account was created.
4722	A user account was enabled.
4723	An attempt was made to change an account's password.
4724	An attempt was made to reset an accounts password.
4725	A user account was disabled.
4726	A user account was deleted.
4738	A user account was changed.
4740	A user account was locked out.
4767	A user account was unlocked.
4780	The ACL was set on accounts which are members of administrators groups.
4781	The name of an account was changed:
4794	An attempt was made to set the Directory Services Restore Mode administrator password.
5376	Credential Manager credentials were backed up.
5377	Credential Manager credentials were restored from a backup.

User Account Management’s coverage of user account maintenance is well laid out, but be aware of one significant caveat. When you create a user account, you'll find an expected instance of event ID 4720 (User account created). But because of the way that the MMC Active Directory Users and Creators snap-in interacts with AD, you’ll also see a series of event ID 4738 instances interspersed with an instance of event ID 4722 (User account enabled) and event ID 4724 (An attempt was made to reset an accounts password). Unless your event-log management solution can perform multi-event correlations, these “extra” instances of event ID 4738, event ID 4722, and event ID 4724 can throw off reports or alerts that you’ve set up. If possible, filter out instances of these three event IDs when they are preceded within a couple seconds by an instance of event ID 4720 that shares the same target user name.

One more word about Event ID 4738: Windows provides granular information about which user account attributes were changed, including the options and restrictions that are found on the Account tab of the user account's Properties dialog box in the MMC Active Directory Users and Computers snap-in.

Computer Account Management

Events in the Computer Account Management category are logged only on DCs and indicates changes to AD computer accounts.

Event ID	Title
4741	A computer account was created.
4742	A computer account was changed.
4743	A computer account was deleted.

Security Group Management

Group management is one of the most important actions that you can monitor with the Security log. The events in the Security Group Management subcategory are logged on both member servers and DCs. Keep in mind that if you are monitoring group changes for AD, you must monitor all DCs because the Security log does not replicate between DCs.

Event ID	Title
4727	A security-enabled global group was created.
4728	A member was added to a security-enabled global group.
4729	A member was removed from a security-enabled global group.
4730	A security-enabled global group was deleted.
4731	A security-enabled local group was created.
4732	A member was added to a security-enabled local group.
4733	A member was removed from a security-enabled local group.
4734	A security-enabled local group was deleted.
4735	A security-enabled local group was changed.
4737	A security-enabled global group was changed.
4754	A security-enabled universal group was created.
4755	A security-enabled universal group was changed.
4756	A member was added to a security-enabled universal group.
4757	A member was removed from a security-enabled universal group.
4758	A security-enabled universal group was deleted.
4764	A groups type was changed.

Windows logs different event IDs for each type and scope of group. You select the group’s scope and type when you create the group.

AD supports two types of groups: distribution and security. Distribution groups serve as distribution lists (DLs) for Microsoft Outlook and Microsoft Exchange Server users. These groups are irrelevant to security; you can’t grant permissions or rights to distribution groups or use them for any security-related purpose. Security groups, as the name indicates, are used to grant or deny access; for what it’s worth, security groups can also be used as distribution groups.

In the descriptions of Account Management events, Windows describes security groups as Security Enabled and distribution groups as Security Disabled. The group type can be changed after a group is created. No matter which type a group is (or was), a group-change event is always logged as the Security Group Management subcategory event 4764.

A group is also configured to be one of four scopes. A group’s scope determines the computers on which the group can be used to control access and the types of users and groups that can be members of the group. Changing a group’s scope (even a distribution group) will produce event 4764 in the Security Group Management subcategory.

Scope	Potential Members	Permissions Granted	Where Defined	Where Logged
Universal	Users and global or universal groups from any domain in the forest	Anywhere in the forest	AD	DCs
Global	Users and other global groups from same the domain	Anywhere in the forest	AD	DCs
Domain Local	Users and global or universal groups from any domain in the forest and domain local groups from the same domain	Within the same domain	AD	DCs
Machine Local	Global or universal groups and users from any domain in the forest	Within the same system	Local SAM	Member servers and workstations

Account Management events also provide important information for member servers. Because of the maintenance and weak-authentication issues that arise from using local accounts, the use of local SAM users and groups on member servers should be avoided if domain accounts could be used instead. Local user accounts are the first target of intruders, who know that these accounts are less likely than domain accounts to be secure. A successful intruder often creates a legitimate local user account to avoid detection during future intrusions.

Given the risks of local accounts, you need to know when any activity that is associated with the creation or modification of local users and groups occurs. This is especially true when you have a policy against using local accounts. Enabling the Audit account management policy on member servers provides exactly such information. Because the local SAM contains no distribution, global, or universal groups, event IDs that are associated with these domain-only groups are not logged on member servers.

Distribution Group Management

As previously mentioned, distributions groups are used only in AD. These groups are used for integration with Exchange Server and cannot be assigned permissions or rights. However, a distribution group can be changed to a security group, so you might want to monitor additions to distribution groups. An alternative would be to monitor for event 4764 (group type change) and then to check the membership in AD if such a change occurs.

Event ID	Title
4744	A security-disabled local group was created.
4745	A security-disabled local group was changed.
4746	A member was added to a security-disabled local group.
4747	A member was removed from a security-disabled local group.
4748	A security-disabled local group was deleted.
4749	A security-disabled global group was created.
4750	A security-disabled global group was changed.
4751	A member was added to a security-disabled global group.
4752	A member was removed from a security-disabled global group.
4753	A security-disabled global group was deleted.
4759	A security-disabled universal group was created.
4760	A security-disabled universal group was changed.
4761	A member was added to a security-disabled universal group.
4762	A member was removed from a security-disabled universal group.
4763	A security-disabled universal group was deleted.

Application Group Management

Application groups are part of Windows' role-based access control for applications. These groups are maintained in the MMC Authorization Manager snap-in. We have noted a problem with the events in the Application Group Management subcategory: These events do not report the common name (cn) of the group. You probably are accustomed to seeing the cn in Authorization Manager, where application groups are maintained. This oversight is serious because it means that the account name that Application Group Management events report isn't displayed anywhere in Authorization Manager. To determine the cn of a group, look for Directory Service Changes subcategory events (which fall under the Directory Service Access audit category and which do report the cn) immediately following an application group management event. We’ll talk more about Directory Service Changes events in Chapter 9.

Event ID	Title
4783	A basic application group was created.
4784	A basic application group was changed.
4785	A member was added to a basic application group.
4786	A member was removed from a basic application group.
4787	A non-member was added to a basic application group.
4788	A non-member was removed from a basic application group.
4789	A basic application group was deleted.
4790	An LDAP query group was created.
4791	A basic application group was changed.
4792	An LDAP query group was deleted.

Other Account Management Events

Account Management logs just two other events, both under the Other Account Management Events subcategory. Event ID 4739 (Domain Policy was changed) is a little misleading. This event means that the computer's effective Account Policy or Account Lockout Policy (under Security Settings) was modified through either Local Security Policy or Group Policy/Domain Policy in AD.

Such a change on a DC affects domain accounts, and you can expect to see the same event logged on other DCs as the modified GPO replicates around the domain. This event on a member server affects only the local accounts on that server. In the case of local servers, the domain is the name of the local server.

A few other operations can generate this event, including the following:

• Raising the domain functional level
• Changing the Network security: Force logoff when logon hours expire security option

Unfortunately, this event’s Subject field doesn’t identify who actually changed the policy. The policy isn't directly configured by administrators but is instead edited in a GPO, which is then applied to the computer. Because the computer is the security principal under which gpupdate runs, this event always shows the local computer as the entity that changed the policy. GPOs such as Domain Policy are better monitored through the Directory Service Access category, which is discussed in Chapter 9.

Don’t completely ignore event ID 4739. Just use it for local server policy changes.

Event ID	Title
4739	Domain Policy was changed.
4793	The Password Policy Checking API was called.

The other subcategory event, event ID 4793, can be ignored as noise. According to Microsoft, the behavior that this event logs is typical behavior.

Bottom Line

Account Management is one of the best-designed Security log categories. You can use this category to track important maintenance to user accounts and groups. The category's use of many distinct event IDs simplifies the filtering process. (Don’t forget about the “extra” events that Windows logs in connection with user-account creations.)

Account Management does a good job of auditing changes to users, groups, and computers, but what about important AD objects such as OUs, GPOs, and domains? The Directory Service Access category provides granular tracking of any class of object in AD, even down to the attribute level.