20140716: NETID DCs no longer permit NTLMv1

Last updated: September 29, 2023
Audience: IT Staff / Technical

1. Tracking

(Instructions:  Approvers and acknowledgers of the change should enter the date (yyyy-mm-dd) when they have approved/acknowledged this Request for Change (RFC).)

Change Number: RFC-0033 Change Date: 07/16/2014 10am
Proposed By: Brian Arkills Proposal Date: 3/20/2014

UW-IT Service Approvals:

Approved By: UWWI service: barkills Approval Date: 3/20/2014
Approved By: UW Exchange service: dsnorton Approval Date: 06/05/2014 (via unodir)
Approved By: UW Sharepoint: dsnorton Approval Date: 06/05/2014 (via unodir)
Approved By: Authentication service: mbrogan Approval Date: 06/05/2014 (via unodir)

2. Change Description

The NETID domain controllers will be configured to no longer accept NTLMv1 authentication, i.e. the LMCompatibilityLevel will change from 4 to 5.

3. Reason for Change

At service inception in 2006, the NETID domain did not support NTLMv1 authentication. Due to customer requests, in 2007 NTLMv1 support was added after obtaining an exception to UW policies via the UW Privacy Assurance and System Security (PASS) Council.

Growing pressures due to UW identity assurance initiatives and a greatly increased threat profile based on readily available cloud-based NTLMv1 cracking tools mean it is past time for NTLMv1 to be retired.

4. Tickets and JIRA Cards

RT Tickets
JIRA Cards
  MI-536NTLMv1 retirement analysis Closed MI-482NTLMv1 support removed Closed MI-539NTLMv1: Draft RFC, get approvals Closed MI-540NTLMv1: Send customer announcement Closed MI-541NTLMv1: Create tools for assisting in NTLMv1 cleanup Closed MI-617NTLMv1: Write PS script to notify known users of needed action Closed MI-634NTLMv1: announce change date Closed MI-635NTLMv1: Remove support from DCs Closed MI-636NTLMv1: Repeatedly remind IT contacts Closed

5. Impacts to Customers

5a. Who are the customers or dependent services that could be impacted by this change:

Any customer of any service that leverages the NETID domain for authentication. The 56 trust contacts are among the representatives for those customers, as are UW Exchange and UW SharePoint.

5b. During the change process, the known or potential impacts are:

There is no impact during the change.

5c. After the change has been implemented, the impacts are:

Authentication attempts coming from client computers which are configured with a LMCompabilityLevel < 3 will fail.

Authentication attempts coming from servers in a given authentication chain (e.g. domain controllers or member servers hosting a service) that are configured with a LMCompabilityLevel < 5 will fail.

6. Risk Level

6a. Most severe incident that could result from this change (1, 2, or 3): 2 (impact severity scale)

6b. Estimated level of risk associated with this change (High, Medium, Low): High

6c. Comments:

This change was attempted previously on 8/1/2013 and was rolled back due to an unknown number and severity of customer impacts. This time around, risk will be mitigated via a number of proactive preparations:

  1. All trusts contacts are repeatedly notified of the change
  2. The two largest sources of customer reported problems from the prior attempt (UW Exchange and UW SharePoint) must approve the change.
  3. The largest source of misconfigured computers was identified (owning more than 50% of known misconfigured computers), and has committed to fixing their computers prior to the change.
  4. Analysis of known problems and workarounds has been completed. This information is available to IT contacts to apply both proactively before the change and reactively after the change. Powershell scripts have been developed to target the highest problem areas. These tools are available for use both proactively and reactively to the change. See Using Set-LMCompatibilityLevel.ps1 and Using Get-NtlmV1LogonEvents.ps1.
  5. Known users still using NTLMv1 are directly contacted with instructions on how to fix their misconfigured computer. A step-by-step document for end users is available.
  6. UW-IT Service Center is prepared to assist customers in fixing their misconfigured computer.

7. Code Check-in/Versioning


8. Test/Validation Plan

Service Component
Tested By
Status (Pass/Fail)
Each NETID Domain Controller Verify LMCompatibility setting is 5 barkills

9. Release/Deployment Checklist

Est. Start Time
10am Announce change is starting barkills
10am Change LMCompatibility setting from 4 to 5 on  NETID Domain Controller group policy object barkills
10:05am Announce change is complete barkills

10. Rollback/Recovery Plan

Change LMCompatibility setting from 5 to 4 on NETID Domain Controller group policy object barkills

11. Communication Plan

Acknowledgers for trusts are validated Validate that contact of record for each trust is correct email 4/1/2014  Complete
 IT-servicechange This RFC + known problems/workarounds + developed tools email 4/21/2014 Complete
All authorizers This RFC + known problems/workarounds + developed tools email 6/5/2014 Complete
UWWI service customers via uwwi-announce@uw.edu Change notification that includes known problems/workaround + developed tools email 4/26/2014 Complete
IT contact lists Reminder email 6/9/2014 Complete
User notification You are still using something that will break. email ?
IT contact lists Reminder email 6/23/2014 Complete
User notification You are still using something that will break. email ?
IT contact lists Reminder email 7/7/2014 Complete
UWWI service customers via uwwi-announce@uw.edu Change reminder email ?? 10am
UWWI service customers via uwwi-announce@uw.edu Change complete email ?? 10:05am

12. Outcomes

Change successfully completed with less than 5 customers reporting problems.