 |  |
21.6. NTLM Domains
NTLM domains provide user and group authentication for Windows machines. It is not clear exactly what "NTLM" stands for, although presumably it's something like "NT Logon anager". Until Windows 2000, these were simply called domains.The term domain is used in an unfortunately large number of contexts in the networking world. There are DNS domains, NIS domains, NTLM domains, and now Kerberos domains, all of them similar (in that they indicate regions of administrative control) and yet distinctively different. NTLM domains, like NIS domains and Kerberos realms, control information about users and groups. They are not tied to machine names but are a source of authentication and authorization information.
Under Windows NT, domain means an NTLM domain. Under Windows 2000, domain by default means a Kerberos realm. However, Windows 2000 machines are able to authenticate in NTLM domains, and Windows 2000 domain controllers can be configured to provide both Kerberos and NTLM services (for instance, to allow older operating systems to authenticate).
The computers that hold the information are called domain controllers. An NTLM domain has one computer that is a primary domain controller and may have one or more computers that are backup domain controllers. Any domain controller can do user authentication, but database changes (password changes, user additions or deletions, changes to group membership) all take place on the primary domain controller and are distributed from there to the backup domain controllers.
When a user wishes to log in to a computer that is part of an NTLM domain using a user account that is in a NTLM domain, the user provides a username, a password, and the name of a domain. The computer passes the provided information to the computer's domain controller. If the domain controller is able to authenticate the user with that information, it returns a security identifier; if not, it returns an error. The computer then checks the access permissions of the security identifier to see if that security identifier is permitted to log in, and if so, continues the login process. Note that this procedure separates authentication from authorization; it is possible to authenticate correctly and still be unable to log in because there is no authorization to do so.
If authentication is successful, the client will cache the information locally. If a user tries to log in and no domain controller is available, the client will use the cached information. If a domain controller is available, the cache will not be consulted. ost clients cache 10-15 sets of credentials (the default is 10, but it is modifiable). If you remove a user account from a domain, the user will still be able to log into any computer they have recently logged into, as long as they first disconnect it from the network. In addition, anybody with Administrator access to the machine can read the cached credentials. Because the cached credentials are stored in a doubly hashed form, standard password crackers will not work against them; on the other hand, it would be possible to write a cracker for them, and presumably somebody eventually will. In security-critical environments, you should disable credential caching; in Windows NT 4, it can be done by setting the following registry key to 0:
Normally, the domain controller will authenticate the user locally. However, there are two cases where the domain controller will ask another domain controller for information. First, if the domain the user wants to authenticate in is not the one controlled by the domain controller, the domain controller may be able to forward the request to an appropriate domain controller. Second, if the domain controller is a backup domain controller and authentication fails, the backup domain controller will forward the request to the primary domain controller just in case there's been an update that has not yet been distributed.HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\winlogon\ Cached Logons Count
In order for a domain controller to forward an authentication request into another domain, the two domains must have a pre-existing relationship called a trust relationship. If you are willing to accept another domain's authentication, you trust that domain. Trust relationships are one-way; if the domain "sheep" decides to trust the domain "wolves", it does not require "wolves" to trust "sheep".[137] In NTLM domains, trusts are also nontransitive: if "sheep" trusts "wolves", and "wolves" trusts "lions", it does not mean that "sheep" trusts "lions". (Windows 2000 domains are Kerberos realms, and Kerberos trust relationships are transitive.)
[137]You will hear "bidirectional trusts" mentioned; this is actually just a convenient shorthand for a pair of trusts.
21.6.1. Finding a Domain Controller
There are two ways to find a domain controller: broadcast and WINS (for more information about NetBIOS naming and WINS, see Chapter 20, "Naming and Directory Services"). Clients that are configured to use broadcast name resolution will also use broadcast to find domain controllers, although the broadcasts are different (they are sent to the NETLOGON name). Clients that are configured to use WINS for name resolution will use WINS name resolution to find domain controllers by looking up the NetBIOS group with the name of the domain and the type 1C (for the domain "sheep", it would be "SHEEP<1C>"). Once a client has used WINS to get a list of domain controllers, it sends a directed packet to each domain controller in the list. Regardless of the way that a client looks for domain controllers, it selects the first domain controller to respond.
21.6.2. The Logon Process
There are two ways for the actual logon process to occur: one based on SMB and one based on Microsoft RPC. Most machines use the SMB-based process; machines running Windows NT Server use the icrosoft RPC process. In the SMB-based process, once a machine has identified a domain controller, it makes an SMB connection to the domain controller, using standard SMB authentication of the user, and connects to the IPC$ share. It then uses remote API calls to finish the process of getting a security token for the user. The Microsoft RPC process is similar; it sets up a secure channel (described in the next section) and then uses remote API calls across it.Regardless of which way the initial logon is done, the machine will connect to the domain controller with SMB to look for a policy file. In fact, this will be done even if the user is authenticated locally, without involving the domain controller at all.
21.6.3. Secure Channel Setup
Each Windows NT server that is part of a Windows NT domain sets up a secure channel to a domain controller when the computer starts up. In addition, at startup time, each backup domain controller sets up a secure channel to its primary domain controller. A secure channel is also used for the communication between domains that have a trust relationship. A secure channel is simply an authenticated connection over Microsoft RPC where the two ends have a shared secret that can be used to encrypt data. Depending on the service pack that is installed and the configuration of the machine, some or all of the information sent across the secure channel will be encrypted with the shared secret.The username and password information is passed across the secure channel in a decryptable form. No challenge-response and no hashing is used; the domain controller will decrypt the password and use it in cleartext form. If the domain controller is compromised, the intruder will be able to log passwords. (Note that a compromised domain controller already gives the intruder control of the site; it is a minor addition to the thousands of horrible things that somebody can do when they control the domain.)
In some implementations, when a server initially joins a domain, it uses a well-known password to set up the first secure channel. An attacker who can eavesdrop on this initial conversation can decrypt it and can read all the information in it, including the password change to a new password that will be used for future secure channels. At this point, the attacker can decrypt all information in the secure channel, including passwords, until there is a password change that they don't manage to eavesdrop on. It is critical to protect this initial secure channel from eavesdroppers (for instance, by putting the server and the domain controller on a switched network where other machines cannot see the traffic); the secure channel is believed to be reasonably secure as long as the password is unknown and is changed with reasonable frequency, but once a password is compromised, the channel is completely insecure. Service Pack 6 for Windows NT 4 addresses this problem, which is also fixed in Windows 2000.
21.6.4. SMB Authentication
When an SMB client connects to an SMB server, the client and server negotiate which dialect of SMB they are going to use. This negotiation mainly controls the method used to exchange authentication data. There are four ways to exchange user authentication data (listed here in order from oldest to newest, which is also from weakest to strongest):
- Cleartext
- The client sends the server the username and the unencrypted password (an ASCII string up to 24 characters long).
- LanMan 1.2
- Challenge-response, using LanMan password hashing. The server sends a challenge; the client takes an ASCII password, uppercases it, converts it to exactly 14 characters (truncating or padding with spaces as necessary), uses the result as a key to encrypt a fixed 8-byte string, appends five nulls, uses the result as a key to encrypt the challenge, and returns that value.
- NT LM 0.12
- Challenge-response, using Windows NT password hashing and verifying
only the client. The server sends a challenge; the client takes the
password, represented in Unicode,[138]
calculates a 16-byte MD4 message digest of it, appends five nulls,
uses the result as a key to encrypt the challenge, and returns the
value. The server calculates the same value and verifies the user if
they match.
[138]Unicode is a system for representing text that allows a larger character set than the ASCII encoding normally used for English text. Although this authentication method would theoretically allow for passwords in Unicode, vastly increasing the available characters that could be used in passwords, most systems will allow only users to enter ASCII characters. This may be different in clients designed for languages that do not have adequate ASCII representations.
- NT LM++
- Challenge-response, using Windows NT encryption with mutual verification. The server sends a challenge; the client sends back its own challenge, and the server's challenge, encrypted with a value derived from the password. The server calculates the same result and verifies the user if they match. The server then calculates a different value based on the password, encrypts the client's challenge with it, and returns it to the client, which can then verify that the server also knows the password.
21.6.5. Accessing Other Computers
A user may want to access a computer other than the one he or she originally logged into (for instance, to use a printer, access files remotely, or use a program like the Event Viewer). When this happens, a Windows NT machine will usually try four ways of authenticating on the remote computer, in order:
- Provide the username, password, and domain information the user originally used. This will work only if the remote computer is a member of the same domain or a trusting domain.
- Provide the username and password without the domain information. This will work if the remote computer has an account with the same username and password.
- Ask the user for a new password and provide the original username with the new password. This will work if the remote computer has an account with the same username but a different password.
- Request guest access to the remote computer.
In some circumstances, you will be able to specify username, password, and domain information explicitly. In particular, you can usually specify this information when accessing files but not when running programs.
21.6.6. Alternate Authentication Methods
Windows NT machines are not required to use NetLogon to authenticate users. The authentication process is handled by a module called the Graphical Identification and Authorization (GINA) module, and other modules can be used instead of the normal NetLogon process. (Note that this is authentication for local resources only; using resources from other servers will require reauthentication.) The most common use of it in mixed Windows NT-Unix networks is something called NISGINA, which allows Windows NT machines to use NIS for authentication.An attacker who has Administrator access to a Windows NT machine can use this feature to install additional authentication modules. It is particularly easy to write a module that saves the provided username and password information for the attacker's future use.
If the relevant registry keys do not have the correct permissions, it may be possible for an attacker to install additional authentication modules without first having Administrator access. As shipped, these keys are protected, but it's important to make sure that protection is maintained if you change anything, particularly on the following key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
21.6.7. Controller-to-Controller Communication
Domain controllers speak to each other for a number of purposes:
- Communication within domains
- Primary domain controllers replicate information to backup domain
controllers; they transfer authentication information via NetLogon
and profiles and policies via directory replication.
At startup, backup domain controllers establish a secure channel to the primary controller, used for pass-through authentication and for replication.
- Communication between domains
- The secure channel is used for pass-through authentication between
trusted domains.
In addition, once a week, the primary domain controller contacts the primary domain controller for each trusted domain controller to change the password used to establish secure channels with that domain.
21.6.8. The User Manager
Changing user information (adding and removing users, changing passwords and rights) needs to be done via different protocols from those used for authentication. Administrators manage accounts using the User Manager for Domains, which connects to the primary domain controller using SMB transactions.
21.6.9. Packet Filtering, Proxying, and Network Address Translation Characteristics of NTLM Domain Authentication
Windows NT domain authentication is based on SMB and Microsoft RPC, which are discussed in Chapter 14, "Intermediary Protocols", and on Microsoft name services, which are discussed in Chapter 20, "Naming and Directory Services". We will call machines that use domain authentication but not secure channels domain participants ; this includes machines running Windows 98, for instance. Machines that use the secure channel are full-fledged domain members; this is what Windows NT machines usually are.If a firewall is between a domain participant and its domain controller, it needs to provide:
- A way to find the controller (either by having a working WINS configuration or passing NetLogon broadcasts)
- SMB to the domain controller
- A way to find the controller (either by having a working WINS configuration or passing NetLogon broadcasts)
- SMB to the domain controller
- Microsoft RPC to the domain controller
- SMB between the controllers
- Microsoft RPC between the domain controllers
- A way to find the controllers (either by having a working WINS configuration or passing NetLogon broadcasts)
- Microsoft RPC between the domain controllers
21.6.10. Summary of Recommendations for NTLM Domain Authentication
|  | |
| 21.5. Kerberos |  | 21.7. Remote Authentication Dial-in User Service |
