NTLM (NT Lan Manager) has been around for quite some time and is a source of problems for network defenders as there are a number of issues with this form of authentication. NTLM credentials are usually stored in memory and can be easily extracted by an attacker using a tool like Mimikatz and the credentials can be also be used in pass the hash attacks. Tools like Responder can harvest NTLM credentials over the network just by pretending to be that network share a user tried to access within your network. So, getting rid of NTLM should be a priority for many but where do you start?
Even though Kerberos is now the default authentication protocol, most companies and organisations cant simply turn off NTML support. There are a lot of applications and systems that rely on NTML authentication to function properly.
So, what can you do as a security administrator to move away from NTLM? The number one thing is to get the facts on who and what is actually using NTLM for authentication. In Active Directory, there is a specific GPO setting that actually allows you to audit all those NTLM requests that would be blocked if NTLM was not allowed. Those events are logged and can be viewed in the Event Viewer on your domain controller or member server. By enabling this audit trail you can start to see what is actually using NTLM for authentication. If you have large environment with legacy applications my guess is that there will be a lot of entries in that particular log. The GPO as well as the other two GPO’s mentioned later on in this post are located at:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Network Security: Restrict NTLM: Audit NTLM authentication in this domain You can set the value to audit only domain accounts or all accounts. If you use local accounts, make sure to set the value to all accounts for a complete log of NTLM use in your environment. Once the GPO is active, the NTLM authentication requests are logged to the operational log located in Application and Services\Microsoft\Windows\NTLM log on every server where the GPO is set.
Second, once you know who and what that uses NTLM in your environment, see if you can migrate them to use kerberos instead, perhaps by using SPN. From personal experience, even really big commercial products sometimes have yet to migrate from using NTLM to Kerberos, some products require an upgrade or configuration changes. It all comes down to knowing which applications are relying on NTLM authentication which you now have a way of logging and find out.
Some applications will probably not be possible to migrate and if you have to keep them running, you can make an exception for just those applications, that is the third step. By allowing an exception, you can allow a particular server ot use NTLM for authentication even if NTLM has been disabled in your domain. This is very useful for minimising your NTLM authentication needs to a minimum. Look at the GPO listed below.
Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain
Now that you know what uses NTLM, have either migrated or made an exception for them, you can finally disable NTLM all together by setting this GPO.
Restrict NTLM: NTLM authentication in this domain
This is the final step required to disable NTLM for your domain all together except for the exceptions you are forced to make for legacy applications. Hopefully you do not have to make any exceptions at all.
Be aware though that if you have missed something, it is a good chance that “something” will break. Also, this is not something you configure on friday morning and expect to be done by friday afternoon, it takes time. However, once complete, you have made it harder for the attackers as NTLM is no longer available as an attack vector at all or at least severely reduced. Kerberos is not without issues either, but that will be discussed in another blog post.