 |
|
Authentication and SecurityIntroductionWIN, 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 (NT LAN Manager) Authentication to/from Member ServersWhen 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:
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. 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\Control\LSA\LMCompatibilityLevel registry key which can assume the following values:
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, 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. 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, 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:
Special Cases
General Windows XP Downlevel Clients
Some NTLM Cross-Platform Test Results
Null SessionsA 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:
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\RestrictAnonymous which controls this behavior. This is a DWORD value which be set to either zero (0), one (1), or two (2):
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\RestrictAnonymous in the following way:
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\RestrictAnonymous 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\RestrictAnonymous, and new values called HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM and HKLM\System\CurrentControlSet\Control\Lsa\EveryoneIncludesAnonymous. These are all DWORD values which be set to either zero (0), or one (1):
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:
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\RestrictAnonymous 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:
For RestrictAnonymousSAM:
For EveryoneIncludesAnonymous:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
