Auditing Users and Groups with the Windows Security Log

Active Directory is one of the most important areas of Windows that should be monitored for intrusion prevention and the auditing required by legislation like HIPAA and Sarbanes-Oxley. I say that because Active Directory is home to objects most associated with user access: user accounts, groups, organizational units and group policy objects. This article deals with monitoring users and groups using the Windows Security Log.
New user accounts are important to audit to verify that they correspond to a legitimate employee, contractor or application. Outside intruders often create new user accounts to facilitate continued access to the penetrated system. Certain changes to user accounts are important to audit since they can be a tip-off to compromised accounts. For instance, both insider and outsider computer criminals often gain access to a system by socially engineering the help desk to a user’s password. Or a previously disabled account being re-enabled may be suspicious depending on the history and type of the account. Group changes, especially changes to the group’s membership, are very useful to track since groups are used to control access to resources, link security policies and control wireless and remote access all over a Windows network. Changes to an organizational unit’s Security tab usually corresponds to delegation of administrative authority over that OU but also occurs when you change normal user access to directory objects. Examples include delegating password reset or user account creation authority over the NYC OU. Any change to a group policy object or changes to the Group Policy tab of an OU, can result in wide reaching changes to the security policies applied to the computers in that OU or changes to desktop restrictions for the user accounts in that OU. In this article I’ll focus on auditing changes to users and groups.
To track changes to users and groups you must enable “Audit account management” on your domain controllers. The best way to do this is to enable this audit policy in the “Default Domain Controllers” GPO which is linked to your Domain Controllers OU as seen in figure 1. “Audit account management events” provides specific event IDs for important operations that can be performed on users and groups.   

User account auditing

The basic operations of creation, change and deletion of user accounts in AD are tracked with event IDs 624, 642 and 630, respectively. Each of these event IDs provides the name of the user who performed the operation and the name of the user account that was affected as you can see below in the example of event ID 642 which was taken from a Windows 2000 domain controller:
User Account Changed:

 -
 Target Account Name:alicej
 Target Domain:ELMW2
 Target Account ID:ELMW2\alicej
 Caller User Name:Administrator
 Caller Domain:ELMW2
 Caller Logon ID:(0x0,0x1469C1)
 Privileges:-

Note that event ID 624 (user account created) replaces “Target” with “New” in the above sample. For changed user accounts, Window 2000 sometimes documents the type of change made to the account in the first line after “User Account Changed”. With Windows Server 2003, Microsoft added a bunch of new fields to the description of event ID 642 as shown below.
User Account Changed:

 -
 Target Account Name:alicej
 Target Domain:ELMW2
 Target Account ID:ELMW2\alicej
 Caller User Name:Administrator
 Caller Domain:ELMW2
 Caller Logon ID:(0x0,0x1469C1)
 Privileges:-
 Changed Attributes:
 Sam Account Name:-
 Display Name:-
 User Principal Name:-
 Home Directory:-
 Home Drive:-
 Script Path:-
 Profile Path:-
 User Workstations:-
 Password Last Set:-
 Account Expires:9/7/2004 12:00:00 AM
 Primary Group ID:-
 AllowedToDelegateTo:-
 Old UAC Value:-
 New UAC Value:-
 User Account Control:-
 User Parameters:-
 Sid History:-
 Logon Hours:-

In the above example you can see that Administrator set Alicej’s account expiration date to 9/7/2004. These new fields are a real advance since Windows 2000 was pretty inconsistent about which account property changes it documented and which it left blank in the event’s description. Sometimes all you knew was that the account was changed but not what changed. Most of the fields are self explanatory but “Old UAC Value” and “New UAC Value” bear some discussion. UAC stands for user account control and is a 4-byte field whose bits correspond to the check boxes on the user’s account seen in figure 2. At first I thought it was necessary to isolate the individual check boxes from the UAC value. However that is not necessary because the next field, User Account Control, graciously lists in plain English which options where checked or unchecked. For instance in the case of a user account being enabled, User Account Control specifies “Account Enabled”.
Windows Server 2003, and to a lesser degree Windows 2000, also has a number of event IDs devoted to specific user account maintenance operations. When a user changes his own password Windows Server 2003 logs event ID 627, “Change Password Attempt” as shown below.
Change Password Attempt:

 Target Account Name:bob
 Target Domain:ELMW2
 Target Account ID:ELMW2\bob
 Caller User Name:bob
 Caller Domain:ELMW2
 Caller Logon ID:(0x0,0x130650)
 Privileges:-

When an administrator resets some other user’s password such as in the case of forgotten password support calls, Windows Server 2003 logs event ID 628.
User Account password set:

 Target Account Name:harold
 Target Domain:ELM
 Target Account ID:ELM\harold
 Caller User Name:timg
 Caller Domain:ELM
 Caller Logon ID:(0x0,0x158EB7)

Notice that the “caller” fields identify the user, timg, who reset the “target” user account, harold. Windows 2000 acts a little differently. Despite MS documentation, Windows 2000 logs event ID 627 for both password resets and password changes by the same user. To distinguish between password changes and resets, compare the caller username to the target user name. If they match, you know that the user changes his/her own password.
When Windows locks a user account after repeated logon failures, you’ll see event ID 644 in the security log of the domain controller where the logon failures occurred. 
User Account Locked Out:

 Target Account Name:alicej
 Target Account ID:ELMW2\alicej
 Caller Machine Name:W3DC
 Caller User Name:W2DC$
 Caller Domain:ELMW2
 Caller Logon ID:(0x0,0x3E7)

When the user contacts the help desk or administrator to have his password reset, Windows Server 2003 logs event ID 671, “User account unlocked”. Windows 2000 does not log this event. 

Group auditing

Auditing changes to groups is very easy. Windows provides different event IDs for each combination of group type, group scope and operation. In AD, you have 2 types of groups. Distribution groups cannot be assigned rights or permissions. Distribution groups are reserved exclusively for distribution lists in Exchange 2000. In the security log distribution groups are referred to as “security disabled” groups. Security groups are the more familiar type of group and the only group type that you can assign permissions and rights. Security groups are referred to as “security enabled” groups in the security log. Groups also have 1 or 3 scopes: Universal, Global and Local. The chart below illustrates the difference between the 3 scopes.

Scope	Can have as members	Can be grantedpermissions
Universal	Users and global or universal groups from any domain in the forest	Anywhere in the forest
Global	Users and other global groups  from same the domain	Anywhere in the forest
Domain local	Users and global or universal groups from any domain in the forest and domain local groups from the same domain	Only within the same domain

Windows logs 5 different event IDs for each group type and scope combination. The 5 events correspond to the 5 operations Windows audits for each group: creation, change, deletion, member added and member removed.

Type	Scope	Created	Changed	Deleted	Member
					Added	Removed
Security	Local	635	641	638	636	637
	Global	631	639	634	632	633
	Universal	658	659	662	660	661
Distribution	Local	648	649	652	650	651
	Global	653	654	657	655	656
	Universal	663	664	667	665	666

From an access control auditing perspective, the most important column would have to member added since that operation usually corresponds to a user being granted new access.
As you can see, “Audit account management” provides a wealth of information for tracking changes to your users and groups in Active Directory. Remember though, you must monitor and/or collect these events from each domain controller within your domain since the only domain controllers that logs an account management event is the one where the change was actually executed. While a change to a user or group does get replicated to all the other domain controllers, replication does not trigger any events in the security log. For effective use of the security log you need someway of collecting events into a single database for monitoring and reporting purposes using some home grown scripts or an event log management tool such as GFI’s LanGuard SELM.