Some of you may be stuck in the uncomfortable position I was in (until recently) of having an AD environment that still permits NTLMv1. If so, you probably have done a little research to figure out what might break if you turned it off, but having been there, I know that you have found very little online that is detailed or even much in the way of resources that would allow you to move forward.
To be clear, having any NTLM turned on is not recommended–see http://msdn.microsoft.com/en-us/library/cc236715(v=PROT.10).aspx, where Microsoft says ““applications are generally advised not to use NTLM.” But many of us can’t completely turn off NTLMv2 quite yet (mostly because of Microsoft applications that don’t follow Microsoft’s own advice), but probably can get rid of NTLMv1, which is more heinous (than NTLMv2) in terms of the risk it poses. If you need any additional motivation, take a peek at www.cloudcracker.com, with its NTLMv1 rainbow tables available for any individual to use to crack a NTLMv1 hash in milliseconds.
I’ve got two resources to share with folks who want to turn off NTLMv1 but aren’t sure how to proceed.
First, I’ve got a document that lists known problems and potential workarounds. See https://itconnect.uw.edu/wares/msinf/other-help/lmcompatibilitylevel/ntlmv1-removal-known-problems-and-workarounds/ for that.
There’s a bit of background reading noted at the top of that document which is recommended for understanding the architecture and relevant settings. The NTLM referrals bit noted there is particularly important to understand, and it has a significant consequences on where NTLMv1 events are logged (hint: only at the initial server the client contacts), as well as where the LMCompatibilityLevel settings actually matter (hint: for the “server” aspect, turning off NTLMv1 on a domain joined computer doesn’t mean anything except to the local user accounts of that computer). If you don’t understand that bit, you will make the mistake I made in the summer of 2013 when I turned off NTLMv1 on our domain controllers because there were no NTLMv1 events on our domain controllers, and then had to roll that change back when lots of people still dependent on NTLMv1 couldn’t access various services.
Also let me highlight a couple significant potential gotchas within the known problems list:
- Non-Windows browsers don’t support NTLMv2. To my knowledge, there is only a single exception to this statement: Safari on MacOS with an obscure Samba setting. You can find more details in the document above, as well as various workarounds we came up with. This led me to realize that for IIS, Integrated Windows Authentication is a dead end (b/c very few folks actually get Kerberos working on those non-Windows clients) that I should actively discourage within my organization.
- IAS/RRAS/MS-CHAPv2 & the native MacOS VPN client. The native MacOS VPN client doesn’t support NTLMv2. Only known workaround is a 3rd party VPN client.
If anyone has additional known problems/workarounds they’d like to contribute to this document, please let me know & I’ll add them.
Second, we have a PowerShell script we created to parse the security event log for the important bits from NTLMv1 events. It can be used remotely. See https://itconnect.uw.edu/wares/msinf/other-help/lmcompatibilitylevel/using-get-ntlmv1logonevents-ps1/ for that. We leveraged this extensively to identify misconfigured clients which we then contacted.
I hope this info is helpful—I know I would have really appreciated this kind of info back when I first started down this road. 🙂