Introduction
WIN, short for win.mit.edu, is the MIT centrally-maintained Windows Domain. This document explains some Windows authentication issues important to especially the WIN Container Adminstrator.
NTLM Authentication to/from Member Servers Overview Details Recommendations More Information Some NTLM Cross-Platform Test Results Null Sessions Overview Registry and Group Policy Settings Our Defaults in the WIN Domain NTLM (NT LAN Manager) Authentication to/from Member Servers
Overview
When accessing resources on a Microsoft Windows 2000 or XP-based (below shortened to Windows) machine, the client provides credentials in the form of either Kerberos v5 tickets or a challenge/response authentication mechanism. The Kerberos tickets are used between Windows machines within trusted domains. Stand-alone (non-domain) Windows machines, those in untrusted domains, and "downlevel" clients (Windows 95/98/NT and Unix-like operating systems), however, must use challenge/response. Microsoft supports three main types of challenge/response:
LAN Manager (LM) NT LAN Manager (NTLM) version 1 NT LAN Manager (NTLM) version 2
LM is an old protocol and very easily subverted. NTLM is a significant improvement over LM, but is still relatively susceptible. NTLM v2 adds several enhancements to v1 that make it much more secure.
Details
In LM authentication, the password is case-INsensitive, restricting each character to either a special character or one of the 26 letters. Additionally, long passwords (up to 14 characters) are divided into 7-character chunks. The combination of a small character space and password division result in a very small overall key space. Dictionary attacks on passwords used in LM authentication are very fast (case insensitive!) and even complete brute force attacks can succeed in relatively little time.
Recognizing this vulnerability, Microsoft introduced the NTLM protocol which simply adds case sensitivity and removes the password-division. Dictionary attacks on this protocol are still very good for weak passwords, but Microsoft claims that 100 2GHz machines would still take 5.5 years to obtain the password by brute force. Fortunately for attackers (unfortunately for you), the protocol does not offer any signing or encryption of the exchange of messages between the client and the server. Thus, the protocol is susceptible to message injection by an attacker, allowing "chosen plaintext" attacks.
To further improve the challenge/response mechanism, Microsoft introduced NTLM v2. This protocol expands the key space to 128-bits, increasing the difficulty of exhaustive brute force attacks (according to Microsoft). The protocol also enables the establishment of a secure channel (signing and/or encryption) between the client and the server prior to the challenge/response. The secure channel is established using a key set created specifically for that purpose (i.e., not the password-derived key) and effectively eliminates chosen-plaintext attacks. Encryption can also effectively obscure the messages, preventing the offline cracking attempts that work so well against LM and NTLM authentication.
The configuration of this authentication resides in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\LSA\LMCompatibilityLevel registry key which can assume the following values:
0 - Send LM & NTLM responses 1 - Send LM & NTLM - use NTLMv2 session security if negotiated 2 - Send NTLM response only 3 - Send NTLMv2 response only 4 - Send NTLMv2 response only\refuse LM 5 - Send NTLMv2 response only\refuse LM & NTLM
While settings 0-2 are obvious, the distinction between the last three is less clear. In all of them (3-5), machines will use only NTLMv2 to outgoing authentication. With a value of 3, however
Office 2010, servers will accept all forms of incoming authentication, while they will deny LM with a value of 4, and both LM & NTLM with a value of 5.
Conveniently, this setting can also be configured through the group policy or local security MMC snap-ins under "Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\LAN Manager Authentication Level" in Windows 2000 and "Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Network Security: LAN Manager Authentication Level" in Windows XP.
Recommendations
Windows 2000 and XP
LM should never, ever, ever be allowed as authentication to or from a member server. NTLM v2 should be required whenever possible (that is
Genuine Office 2007, whenever it does not break required functionality - see Special Cases below). To require NTLMv2 authentication from the member server and require at least NTLMv1 authentication to the member server:
Set the LAN Manager Authentication Level security option to "4 - Send NTLMv2 response only\refuse LM"
Special Cases
Mixed Environments
NTLMv2 can be used by Windows NT 4 machines only with Service Pack 4 or higher installed. Similarly, it can be used by only Windows 95/98/Me machines that have the Directory Services Client installed (available on the Windows 2000 CD-ROM). With NTLMv2 required and LM/NTLM refused (level 5), the server will not be able to perform authentication on downlevel clients that do not meet the above criteria (Windows machines work fine). With level 4, Windows NT4 machines should be able to successfully authenticate to the server even without SP4 (although 95/98/Me clients still require the DS Client). If communication with 95/98/Me or other LM-only machines is absolutely required, the setting can be reduced to "3 - Send NTLMv2 response only." This compatibility comes at the expense of security as detailed above. AFS Client
The AFS client used in the WIN domain currently does not support NTLMv2. Therefore, restricting outgoing authentication to NTLMv2 will result in an inability to obtain AFS tokens from the server. In most cases there is no need to access AFS from the server, but if your environment requires it, you must reduce the NTLM level to "2 - Send NTLM response only". Again, this comes at the expense of security.
More Information
General
Microsoft's Description of NTLM
Windows XP
Setting the LAN Manager Authentication Level on a Network that Includes RIS
Downlevel Clients
How to Disable LM Authentication on Windows NT
How to Enable NTLM 2 Authentication
Some NTLM Cross-Platform Test Results
Server OS
Server Setting
Client OS
Client Setting
Result
2K SP3
v2 ONLY (5)
XP SP1
v2 (3)
Success
2K SP3
v2 ONLY (5)
XP SP1
v1 (2)
Failure
2K SP3
v2 ONLY (5)
XP SP1
any (1)
Failure
2K SP3
v2\no LM (4)
XP SP1
v2 (3)
Success
2K SP3
v2\no LM (4)
XP SP1
v1 (2)
Success
2K SP3
v2\no LM (4)
XP SP1
any (1)
Success
2K SP3
v2 (3)
XP SP1
v2 (3)
Success
2K SP3
v2 (3)
XP SP1
v1 (2)
Success
2K SP3
v2 (3)
XP SP1
any (1)
Success
2K SP3
v1 (2)
XP SP1
v2 (3)
Success
2K SP3
v1 (2)
XP SP1
v1 (2)
Success
2K SP3
v1 (2)
XP SP1
any (1)
Success
2K SP3
any (1)
XP SP1
v2 (3)
Success
2K SP3
any (1)
XP SP1
v1 (2)
Success
2K SP3
any (1)
XP SP1
any (1)
Success
XP SP1
v2 ONLY (5)
2K SP3
v2 (3)
Success
XP SP1
v2 ONLY (5)
2K SP3
v1 (2)
Failure
XP SP1
v2 ONLY (5)
2K SP3
any (1)
Failure
XP SP1
v2\no LM (4)
2K SP3
v2 (3)
Success
XP SP1
v2\no LM (4)
2K SP3
v1 (2)
Success
XP SP1
v2\no LM (4)
2K SP3
any (1)
Success
XP SP1
v2 (3)
2K SP3
v2 (3)
Success
XP SP1
v2 (3)
2K SP3
v1 (2)
Success
XP SP1
v2 (3)
2K SP3
any (1)
Success
XP SP1
v1 (2)
2K SP3
v2 (3)
Success
XP SP1
v1 (2)
2K SP3
v1 (2)
Success
XP SP1
v1 (2)
2K SP3
any (1)
Success
XP SP1
any (1)
2K SP3
v2 (3)
Success
XP SP1
any (1)
2K SP3
v1 (2)
Success
XP SP1
any (1)
2K SP3
any (1)
Success
Null Sessions
Overview
A null session is a NetBIOS connection made to a server by an anonymous client. Since the connection is anonymous, the client's identification field is null (hence the name) and the session is unauthenticated. As a system administrator, you should consider all information which can be obtained via a null session to be essentially public information, whether you intended this or not. Furthermore any functions which can be performed remotely via a null session may be executed by anyone, from anywhere, and you won't be able to determine who did it. Therefore it is recommended that you restrict null session access to the minimum level necessary to meet your needs.
If the clients you deal with are all running Windows 2000 or higher, you probably have little need to allow null sessions on your server machines. Null sessions should be necessary only to support Windows NT 4.0 clients and possibly some unfortunately-designed third-party software.
The domain itself is already configured to prevent anonymous connections from enumerating domain accounts and groups. However, it is possible to configure the machines in your container to either permit or prohibit the anonymous enumeration of local SAM accounts and shares. If this access is permitted, anonymous users can get a list of the names of the local accounts on the machine. This information could be used as a springboard for a remote password-cracking attack. Also, anonymous users can get a list of the machine's shared folders. It is generally a good idea to prevent anonymous users from having this access.
Windows XP and Server 2003 by default forbid the anonymous enumeration of local SAM accounts (although this access can be enabled), but allow the anonymous enumeration of local shares. Windows 2000 by default allows anonymous enumeration of both local SAM accounts and shares. In order to prevent exploitation of these privileges on your machines, we have changed the default settings (via Group Policy) in the Win.Mit.Edu domain so that all such access is disabled on all three operating systems. Our settings thus provide the maximum default security level for restricting null session access.
Registry and Group Policy Settings for Null Sessions
The following section details the various registry and group policy settings which affect anonymous enumeration of SAM accounts and/or shares. Note well: It is very confusing, for the following reasons:
These settings are different for Windows 2000 and for Windows XP/Server 2003. When you edit group policy on one operating system, you are given choices appropriate to just that operating system. However, the choices you make affect all machines to which the group policy object applies. This "crosstalk" makes the situation very messy. The different registry keys and different group policy settings are easy to get confused or switched, as their names are misleading and maddeningly similar to each other.
If you are encountering problems that you think might be related to the disabling of null sessions then the following section will allow you to understand the settings in more detail. We hope that most container administrators will find our default settings sufficient and not need to delve into this any further. For those who must do so, however, please read on.
Settings in Windows 2000
Windows 2000 machines have a single registry value HKLM\System\CurrentControlSet\Control\Lsa\Restrict Anonymous which controls this behavior. This is a DWORD value which be set to either zero ( 0), one ( 1), or two ( 2):
When RestrictAnonymous is set to 0 (or does not exist), no restrictions are placed on null sessions. This is the factory-default setting. When RestrictAnonymous is set to 1
Microsoft Office Standard 2007, SAM accounts and shares cannot be enumerated by null sessions. When RestrictAnonymous is set to 2, null sessions have no access without explicit anonymous permissions.
When you edit a group policy object from a Windows 2000 machine, there is a setting located under Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options called Additional restrictions for anonymous connections. If you enable this setting, you are given three choices, which cause the machines affected by the group policy object to set their HKLM\System\CurrentControlSet\Control\Lsa\Restrict Anonymous in the following way:
If you select "None. Rely on default permissions", affected machines set RestrictAnonymous to 0. If you select "Do not allow enumeration on SAM accounts and shares", affected machines set RestrictAnonymous to 1. If you select "No access without explicit anonymous permissions"
microsoft Office 2010 License, affected machines set RestrictAnonymous to 2.
If you have only Windows 2000 machines in your container, this makes sense, because the machines affected by your group policy object will all behave appropriately when HKLM\System\CurrentControlSet\Control\Lsa\Restrict Anonymous is set this way. Unfortunately, any Windows XP and Server 2003 machines in your container will also receive these registry settings, which may not be the effect you intended.
Settings in Windows XP and Server 2003
Windows XP and Server 2003 machines have three registry values which control this behavior: The aforementioned HKLM\System\CurrentControlSet\Control\Lsa\Restrict Anonymous, and new values called HKLM\System\CurrentControlSet\Control\Lsa\Restrict AnonymousSAM and HKLM\System\CurrentControlSet\Control\Lsa\Everyone IncludesAnonymous. These are all DWORD values which be set to either zero ( 0), or one ( 1):
When RestrictAnonymous is set to 0 (or does not exist), null sessions can enumerate shares. This is the factory-default setting. When RestrictAnonymous is set to 1, null sessions cannot enumerate shares. (Setting RestrictAnonymous to 2 has the same effect as setting it to 1.) When RestrictAnonymousSAM is set to 0 (or does not exist), null sessions can enumerate local SAM accounts. When RestrictAnonymousSAM is set to 1, null sessions cannot enumerate local SAM accounts. This is the factory-default setting. When EveryoneIncludesAnonymous is set to 0 (or does not exist), null sessions have no special rights. This is the factory-default setting. When EveryoneIncludesAnonymous is set to 1, null sessions are considered part of the Everyone group, and are given the corresponding rights.
When you edit a group policy object from a Windows XP or Server 2003 machine, there are three relevant settings located under Computer Configuration/ Windows Settings/Security Settings/Local Policies/Security Options, which correspond to these keys:
If you disable Network Access: Do not allow anonymous enumeration of SAM accounts and shares, affected machines set RestrictAnonymous to 0. If you enable Network Access: Do not allow anonymous enumeration of SAM accounts and shares, affected machines set RestrictAnonymous to 1. If you disable Network Access: Do not allow anonymous enumeration of SAM accounts, affected machines set RestrictAnonymousSAM to 0. If you enable Network Access: Do not allow anonymous enumeration of SAM accounts, affected machines set RestrictAnonymousSAM to 1. If you disable Network Access: Let Everyone permissions apply to anonymous users, affected machines set EveryoneIncludesAnonymous to 0. If you enable Network Access: Let Everyone permissions apply to anonymous users
Microsoft Office Home And Business 2010, affected machines set EveryoneIncludesAnonymous to 1.
Again, if you have only Windows XP or Server 2003 machines in your container, this makes sense, because the machines affected by your group policy object will all behave appropriately when the registry keys are set this way. Unfortunately, any Windows 2000 machines in your container will also receive these registry settings, which may not be the effect you intended.
Our Defaults in the WIN Domain
We have set HKLM\System\CurrentControlSet\Control\Lsa\Restrict Anonymous to 2 via Group Policy. This prevents Windows 2000 machines from giving any access to null sessions. For Windows XP and Server 2003 machines, this prevents null sessions from enumerating local shares. Since XP and Server 2003 set RestrictAnonymousSAM to 1 and EveryoneIncludesAnonymous to 0 by default, these operating systems also give no access to null sessions. (Although the effective access level for null sessions in this case is the same for all three operating systems, there is still a slight difference in behavior. Windows 2000 will actually reject an anonymous connection outright, whereas the newer operating systems will accept the connection but refuse to allow any privileged access.)
Thus our default settings provide the maximum security level. In order to reduce this level, you will need to override the defaults in some way.
How to Override Our Defaults
If you want different settings for the different operating systems, you may need to request multiple group policy objects and set access control on them using our OS Groups to make each object apply to just one operating system. This is very complicated, so you might prefer to come up with a single configuration which yields desirable behavior on all operating systems. (Note that if you introduce the two new registry keys into Windows 2000, they will have no effect, but they do not harm anything either.)
For RestrictAnonymous:
If you want to set RestrictAnonymous to 0, edit your group policy object. If you do so from Windows 2000, set Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options/Additional restrictions for anonymous connections to "None. Rely on default permissions". If you do so from Windows XP or Windows Server 2003, set Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options/Network Access: Do not allow anonymous enumeration of SAM accounts and shares to Disabled. If you want to set RestrictAnonymous to 1, edit your group policy object. If you do so from Windows 2000, set Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options/Additional restrictions for anonymous connections to "Do not allow enumeration on SAM accounts and shares". If you do so from Windows XP or Windows Server 2003, set Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options/Network Access: Do not allow anonymous enumeration of SAM accounts and shares to Enabled.
For RestrictAnonymousSAM:
If you want to set RestrictAnonymousSAM to 0, you can directly edit the registry on the machines in question. If you'd like to do it for all machines in your container via group policy, edit your group policy object via Windows XP or Server 2003. (You cannot edit the group policy object from Windows 2000.) Set Computer Configuration/Windows Settings /Security Settings/Local Policies/Security Options/Network Access: Do not allow anonymous enumeration of SAM accounts to Disabled.
For EveryoneIncludesAnonymous:
If you want to set EveryoneIncludesAnonymous to 1, you can directly edit the registry on the machines in question. If you'd like to do it for all machines in your container via group policy, edit your group policy object via Windows XP or Server 2003. (You cannot edit the group policy object from Windows 2000.) Set Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options/Network Access: Let Everyone permissions apply to anonymous users to Enabled. Back To Top
None. Rely on default permissions"
Threaded Mode