10.1. Joining a Domain
Adding a new machine to a domain is much like adding a new user. In the case of a human user, the new account is first created on the domain controller. Then the user is informed of his login name and credentials. The user remembers this password in order to access available network services such as email or printing. When a computer joins a domain, it also establishes a random password that is known only by the domain controllers and itself. The client stores this password locally, in the registry or some other local database.
We described the process used to authenticate a connection request to a share on a standalone server in Chapter 1. If necessary, now might be a good time to review the section "Connecting to a CIFS File Share" as a refresher on session setup requests. Standalone servers provide an excellent starting point for examining domain authentication, because the basics of the connection process are identical for both standalone and member servers. The primary difference is how the server ultimately validates the credentials sent by the client.
Samba 3.0 and Windows NT 4.0 domain controllers use a Remote Procedure Call (RPC) mechanism, by which a member server can establish a secure means of communication and then request that the DC authenticate a user session. This concept is illustrated in simplified diagram shown in Figure 10-1. The client, named \\FOX, connects to the file server \\HOUND, who in turn asks the domain controller \\RABBIT to authenticate a session request for the user rose. The NetRequestChallenge( ) and NetAuth2( ) RPCs used the password stored as part of the domain join process to establish the identity of \\HOUND. The third RPC, NetSamLogon( ) , is the authentication request on behalf of the user. After receiving the NetSamLogon( ) reply from the domain controller, the file server either responds successfully or returns the error code, such as Logon Failure or Password Expired, specified by the DC.
Figure 10-1. Connecting to a domain file server using NTLM and RPC
When participating in an AD domain, Windows 2000 and later clients are capable of using Kerberos 5 (Krb5) authentication services.[*] We say "capable," because Active Directory domains still support NTLM authentication and the RPC mechanisms just described. A full discussion of Kerberos is beyond the scope of this book. Two excellent sources of information on the subject are Kerberos: The Definitive Guide, by Jason Garman (O'Reilly), and Network Security: Private Communication in a Public World, by Charlie Kaufman et al. (Prentice Hall). The former discusses implementation issues for Kerberos administrators and the latter is an in-depth examination of Kerberos and other security protocols.
Figure 10-2 illustrates what occurs when a user connects to a file server using Kerberos authentication. Again, the client machine \\FOX connects to the server \\HOUND, except this time a domain controller is not needed to authenticate the session request. The file server decrypts the Kerberos ticket locally, therefore verifying that the user has been previously authenticated by the DC.
Figure 10-2. Connecting to a file server in an Active Directory domain