Using event collection systems for assessing authentication usage
Updated: November 21, 2012
Applies To: Windows 7, Windows 8, Windows Server 2008 R2, Windows Server 2012
This topic describes general strategies for accessing NTLM traffic when your organization uses an event collection system.
The goal of collecting authentication events is to provide an efficient and accurate way to analyze NTLM traffic for the initial reduction project as well as monitoring ongoing usage. The assessment of NTLM authentication attempts relies on historical data as recorded in the Operations log on separate computers dispersed throughout the target forest: client computers, member or remote servers, or domain controllers. Depending on your existing event collection system, additional tasks might be necessary to set up your environment, especially configuration steps. You might want to consider setting up a separate event collection system, such as Microsoft System Center Audit Collection Services to analyze NTLM (and Kerberos) authentication activity, and then monitor that activity after you implement your solution.
The following content describes the tasks necessary to collect and analyze authentication events. However, the specific steps required are dependent upon your collection system.
In this topic
Step 1: Prepare Active Directory and targeted forests
Step 2: Prepare Group Policy
Step 3: Configure your event collection system
Step 4: Assess and analyze NTLM authentication
Step 5: Fix obvious authentication issues
For information about evaluating and preparing your environment for collecting authentication attempt events, see Evaluating your environment for NTLM reduction and Preparations for assessing NTLM usage.
Step 1: Prepare Active Directory and targeted forests
You can use the Active Directory organizational unit (OU) structure to assist you in collecting event data for targeted domains and forests. For the particular event collection system you intend to use, you might have to create the appropriate service accounts and groups, and then set the membership to those groups. In addition, you might have to create OUs, security groups, or WMI filters to specifically support your auditing and analysis.
Step 2: Prepare Group Policy
Create and configure the Group Policy Objects to support the audit collection and forest search order for your solution. You might also need to update the DNS Suffix Search List for the targeted forests by editing the Default Domain Group Policy by using the Group Policy Management Console (GPMC).
For information about what NTLM audit policies are available to use in Group Policy, see Using Group Policies to audit NTLM traffic.
Step 3: Configure your event collection system
After you determine the scope of your assessment and install the required event collection software and components for your system, you will need to set up the collection system. This includes installing the required software and components for your system for the auditing of the domain controllers, member servers, and client computers within the forest, and then generating the audit reports.
Step 4: Assess and analyze NTLM authentication
When designing the audit reports, make sure they capture data that shows where the authentication request originates and the server where it was evaluated and downgraded to NTLM (if that is the case). You might have to experiment with the reports and modify them to capture the data you desire. You will be collecting:
NTLM traffic
Success Audit events Event ID 540 (for Windows Server 2003 and Windows XP) and Event ID 4624 (beginning with Windows Server 2008 and Windows Vista display the domain and the authentication package. The authentication package stipulates the security support provider used in the authentication attempt, such as Negotiate, Kerberos, or NTLM. By analyzing these events with the corresponding NTLM authentication package, you can determine that an NTLM-based network authentication has occurred.
Event ID 8001, 8002, 8003, and 8004 (beginning with Windows Server 2008 R2 and Windows 7)
Event ID 6038 (for Windows Server 2012 and Windows 8)
Kerberos SPN failures
Failure Audit Events 673 (for Windows Server 2003 and Windows XP) and Event ID 4772 (beginning with Windows Server 2008 and Windows Vista) show which authentication attempts were made to obtain a service ticket but failed. Failure indicates either a complete authentication failure or a failure that preceded the fallback to NTLM. This event displays the service name.
User authentications and authentication attempts
Application Verifier can be implemented to determine how NTLM is being used. For information about how to use the NTLM plug-in, see Using the NTLM Application Verifier Plug-in.
For information about the events to be evaluated, see Viewing events for assessing NTLM usage.
Step 5: Fix obvious authentication issues
There might be some servers or applications that must use NTLM, possibly because your organization will not or cannot fix it at this time. In this case, you can exempt those resources from this project by listing them on either one of the server exceptions Group Policies by using Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication or Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain.
You might be able to fix some Kerberos service principal name (SPN) failures simply by renaming computers.