IT Connect
Information technology tools and resources at the UW

20130701: Removal of support for NTLMv1 authentication in the NETID domain

A service change is planned for the UWWI NETID domain service.


What and When:

On August 1 2013, we’ll remove support for the NTLMv1 authentication protocol from both the NETID domain controllers and at the domain level.


What you need to do:

If you have a service that is unable to support Kerberos or NTLMv2 authentication and uses user accounts that aren’t NETID domain user accounts, then you can turn on support for NTLMv1 at your OU level as a workaround. If you do this, we strongly recommend that you begin exploring alternatives as the threat profile for NTLMv1 has greatly increased.


If your service requires NETID domain authentication and NLTMv1, we’d be happy to explore alternative solutions with you. Based on an audit over a 24 hour period, we are unaware of any such services.


More info:

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 cloud-based NTLMv1 cracking tools mean it is time for NTLMv1 to be retired.


As implied above, we’ve audited NTLMv1 use via NETID domain user accounts for a 24 hour period and found no use of concern. So we believe this change to be of minimal impact.


We are unable to verify the configuration in domains trusting the NETID domain, and a configuration mismatch between trusting domains and the NETID domain is the most likely source of potential issues, but default settings make the possibility of problems unlikely. If you’d like to audit your own Windows domain for NTLMv1 use, if all of your DCs are WS2008 or better, we can share a PowerShell script with you that will extract relevant events over a 24 hour period. If your DCs are at a prior OS level, it is not possible to differentiate NTLMv1 use from NTLMv2 use without doing network captures.


Another possible source of issues are non-domain joined computers running Windows XP or previous in a default configuration. In that case, the configuration settings will be incompatible. Windows XP is no longer in mainstream support from Microsoft, and extended support ends in a year, so this potential source of problem should also be limited.


More background information about the LMCompatibilityLevel setting is available at