Auditing Users and Groups with the Windows Security Log

If you want even more advice from Randall F Smith, check out his seminar below:

Attend the only 2-day seminar devoted to 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)

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)
 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:-
 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)

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.


Can have as members

Can be granted


Users and global or universal groups from any domain in the forest

Anywhere in the forest


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.















































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.

Ultimate Windows Security: Information

Ultimate Windows Security is a 5 day hands-on, heads-down, technical course that covers each area of Windows security. The course focuses on Windows Server 2003 but Randy addresses each point relates to Windows 2000, XP and even NT. Ultimate Windows Security covers the Windows security foundation such as account policy, permissions, auditing and patch management on day one. On day 2 you focus on Active Directory and Group Policy security. Day 3 takes you on a highly technical tour of Certificate Services, Routing and Remote Access Services and Internet Authentication Services. On day 4 you learn how to put these 3 technologies together to solve real world security needs such as 2-factor VPN security, WiFi security with 802.1x and WPA, implementing Encrypting File System reliably and securely and using IPSec to handle a variety of network security issues. Day five takes you deep into the shrouded world of the Windows security log. Randy will unveil this woefully undocumented area of Windows and show you how to track authentication, policy changes, administrator activity, tampering, intrusion attempts and more. You can attend Ultimate Windows Security publicly at training centers across America or bring the course to you by scheduling an in-house/on-site event. To register or learn more browse to

Author’s Bio:
Randy Franklin Smith, president of Monterey Technology Group, Inc. and a Systems Security Certified Professional, specializes in Windows security. Randy is the creator and exclusive instructor for the Ultimate Windows Security seminar and the new Security Log Secrets course.

You can contact Randy at [email protected]

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top