What You Don't Know Can Hurt You: LAN Manager Might Be Supported
I have been preaching and teaching about the finer points of authentication protocols, anonymous, group membership, etc. for years. I have been talking about how these simple aspects of your overall Active Directory, overall domain, and server security are essential. Well, after a brief demo last week at a conference, I am here to tell you, again, to be concerned. There are so many security vulnerabilities that you don't think are important on a day to day basis, but the hackers of the world are exploiting these areas every day. Now it is over 12 years since Microsoft has released Active Directory and it is a shame that authentication protocols like LAN Manager are still supported and even by default in a fresh installation of Active Directory with Windows Server 2008 R2. With this lapse in security concern, I feel it is important to not only tell you where the settings are for you to ensure they are set properly, but to give you a best practice walk through on how to setup your domain, organizational units, and Group Policy settings correctly.
LAN Manager Defaults for Active Directory
There are two areas that your Active Directory domains (as well as local SAM) are affected with regard to LAN Manager. First, it is the idea that LAN Manager is set up to be used, if it needs to be used. Second, it is the idea that LAN Manager is establishing a foundation for use, even if it is not used.
The first concept of LAN Manager being setup, even if not used is due to the levels of authentication protocols that are supported and the fact LAN Manager might just be one that needs to be supported. Forget the fact that LAN Manager was first designed for Windows 3.11 (Yes that is Windows for Workgroups), it is still, in the year 2012, set up to be used. This setting is established in a Group Policy Object for your domain. If you go into the Default Domain Controllers policy and look down at the Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options, you will see a full list of security settings. About two-thirds down the list you will see an entry labeled "Network security: LAN Manager authentication level". You will notice that the default setting for this policy is set to "Send NTLMv2 response only". The other settings can be seen and configured by clicking on the drop down list within the policy window, as shown in Figure 1.
Figure 1: LAN Manager Authentication level defined in the Default Domain Controllers policy.
The second setting is going to be in the same general area as the first, however, it is located in a different default Group Policy Object. Instead of being located in the Default Domain Controllers policy, it is located in the Default Domain policy. When looking in the Default Domain policy for this setting, you go to the same path as the first setting, that is, Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options. The policy labeled as "Network Security: Do not store LAN Manager hash value on next password change" will be set to Enabled. (Note that this policy setting is simply "on or off", there are not more than two options like the first setting). You can see this policy setting in Figure 2.
Figure 2: LAN Manager hash storage setting in the Default Domain policy.
Proper Configuration of LAN Manager Authentication Protocol
There are two settings that we are dealing with in this article and both need to be checked for proper configuration. Now that you know how to check the setting, you need to be aware what the proper configuration should be.
First, if you check the settings above and find that your settings are not configured as shown above, then that is not necessarily an issue. Second, suggestions here must be tested and verified for your environment, as there are some environments where LAN Manager is still required, due to legacy applications and possibly legacy operating systems.
For the first setting, which is configured in the Default Domain Controllers policy, this setting really needs to be located in a different Group Policy Object and have a different set value. This setting should be located in the Default Domain policy. The reason is that all computers have the ability to authenticate users using LAN Manager. Yes, even desktops, as they have a local SAM (security accounts manager) and support LAN Manager as an option for authentication. As an option, as some administrators don't like to modify the default Group Policy Objects, you could create a new Group Policy Object and link it to the domain, then within the new Group Policy Object set the LAN Manager authentication level. As for the value, it should be set to the highest security level, which is the "Send NTLMv2 response only. Refuse LM and NTLM". This will now control not only the domain controllers, but every Windows computer in the domain to not allow the use of LM or NTLM as an authentication protocol.
As for the second setting, it is located in the proper level of Active Directory, which is the domain. It also has the proper value set, as defined in this article. So, if you don't have the LAN Manager hash storage policy set in a Group Policy Object linked to the domain, you should. Also, the value needs to be set to Enabled so that LAN Manager hashes are not stored in the user database. Even if you set the first setting to refuse LM, this setting could be storing those hashes, which is a security risk.
Now that we are in the year 2012 and network security is finally becoming a key concept to most organizations, it is time to ensure even the most basic settings are set properly. Not securing LAN Manager usage on your network could expose password hashes and create an attack surface for the disclosure of password hashes. Both settings mentioned in this article need to be addressed, as each address a different aspect of LAN Manager that cause security concerns. The first controls whether LAN Manager is accepted as an authentication protocol during logon and authentication. The second setting controls simply if the LAN Manager hash will be saved in the user database. Again, please test these settings thoroughly before pushing into production, as some applications that you currently run might still be requiring LAN Manager. If this is the case, an investigation of upgrading or fixing that application would be suggested.