15.8 Random Notes on W2K and NT Domain Authentication

We have been delicately dancing around the role of the Domain Controller in authentication. It's time to face the music.

The concept is fairly simple: Take the password database that is normally kept locally by a standalone server and move it to a central authority so that it can be shared by multiple servers, then call the whole thing a "Domain." The central authority that stores the shared database is, of course, the Domain Controller. As shown in Figure 15.5, the result is that the SMB fileserver must now consult the Domain Controller when a user tries to access SMB services.

Figure 15.5. Centralized authentication

The D omain C ontroller (DC) wears a special hat. It keeps track of the common authentication database that is shared by the SMB servers in the Domain. The SMB servers query the DC when a client requests access to SMB services.

That general description applies to both NT and W2K Domains, even though the two are implemented in very different ways. Windows 2000 Domains are based on Active Directory and Kerberos, while Windows NT Domains make use of a S ecurity A ccounts M anager (SAM) Database and MS-RPC.

Let's see what bits of wisdom we can pull out of the hat regarding these two Domain systems...

15.8.1 A Quick Look at W2K Domains

As with Microsoft's Kerberos implementation, there is probably too much information available on this topic. A full description would also be very much beyond the stated scope of this book. So, as briefly as possible, here are some notes about W2K Domains and Domain Controllers:

• Windows 2000 Domains are based on the real thing: The Internet Domain Name Service (DNS). The DNS provides a hierarchical namespace, and W2K can take advantage of the DNS hierarchy to form collections of related W2K domains called "trees." Groups of separate W2K Domain trees are known as "forests."

• W2K Domain Controllers run the Active Directory service. A ctive D irectory (AD) is a database system that can be used to store all sorts of information, including user account data. The design of AD owes a lot to Novell's NDS architecture which, in turn , is based on OSI X.500.

• Data stored in the Active Directory may be accessed using the LDAP protocol.

• Microsoft's Kerberos implementation relies upon the data stored in the Active Directory. The two services are closely linked.

...and that barely begins to scratch the surface. CIFS client and server participation in a W2K Domain requires Kerberos support, but does not require a detailed understanding of Active Directory architecture. The above points are given here primarily for comparison with the NT Domain system notes, presented below.

15.8.2 A Few Notes about NT Domains

In contrast to W2K Domains, NT Domains have the following features:

• Windows NT Domains are built upon NetBIOS. The NetBIOS namespace is flat, not hierarchical, so there is no natural way to build relationships among NT Domains. Conceptually, NT Domains are standalone.

• NT authentication information is stored in the S ecurity A ccounts M anager (SAM) Database. The SAM is an extension of the Windows NT Registry database, and it is accessed using a Windows DLL.

• In an NT Domain, the shared SAM database is stored on the Domain Controller and may be accessed using RPC function calls. (Windows 2000, of course, stores the SAM data in the Active Directory, but it can also respond to the RPC calls for compatibility with the NT Domain system.)

There are two mechanisms that an SMB Server can use to ask a Domain Controller to validate a client logon attempt. These are known as pass-through and NetLogon authentication. The NetLogon mechanism uses MS-RPC, so we won't cover it here except to say that it provides a more intimate relationship between the SMB server and the Domain Controller than does the pass-through mechanism. There are several good sources for further reading listed in the References section. In particular:

• Start with the whitepaper More Than You Ever Wanted to Know about NT Login Authentication , by Philip Cox and Paul Hill. It provides a clear and succinct introduction to the Windows NT authentication system.

• Another good overview from a different perspective is provided in the whitepaper CIFS Authentication and Security by Bridget Allison (now Bridget Warwick).

• ...and once you're read that you'll be ready for the more in-depth NetLogon coverage in Luke's Leighton's book.

Pass-through, in contrast to NetLogon, is really quite simple. It is also documented in (yet) an(other) expired Leach/Naik IETF draft, titled CIFS Domain Logon and Pass Through Authentication , which can be found on Microsoft's CIFS FTP site (under the name cifslog.txt ).

Basically, pass-through authentication is a man-in-the-middle mechanism. It goes like this:

• The client attempts to log on to the server, but the server has no SAM database so it, in turn, attempts to create an SMB session with the Domain Controller.

• The server sends a NEGOTIATE PROTOCOL REQUEST to the DC. The DC returns a challenge which the server passes back to the client.

• The client does the hard work and generates the various responses (LM, NTLM, etc.), which are sent to the server. The server simply passes them through to the DC in its own SESSION SETUP REQUEST .

• If the DC returns a POSITIVE SESSION SETUP RESPONSE to the server, then the server will return a POSITIVE SESSION SETUP RESPONSE to the client. Likewise with a negative response.

It should be easy to capture an example of pass-through authentication using your network sniffer. Windows 9x systems (and possibly other Windows varieties) do not support NetLogon so they always use the pass-through method if they are part of an NT Domain. Samba can be configured to use either method.

Radical Rodent Alert

There is an obscure Windows SMB file transfer mode implemented by Windows 98, Windows Me, and possibly other Windows flavors. This mode is known in the community as "rabbit-pellet" mode, and it is triggered by various subtle combinations of conditions. In testing, it appears as though delays in pass-through authentication may be a factor.

In rabbit-pellet mode the client will send a file to the server in very small chunks , somewhere between 512 and 1536 bytes each (give or take). The client will wait for a reply to each write, and will also send a flush request after every one or two writes . This slows down file transfers considerably.

The condition is rare, which is good because it's really annoying when it happens. It's also bad because it has been a very difficult problem to track down.

15.8.3 It's Good to Have a Backup

In the NT Domain system, there is a single Domain Controller that is primarily responsible for the maintenance of the domain's SAM database. This Domain Controller is known as the (surprise) P rimary D omain C ontroller (PDC).

The domain may also have zero or more B ackup D omain C ontrollers (BDCs). The BDCs keep read-only replicas of the PDC's SAM database. BDCs can be used for authentication just as the PDC can, and if the PDC is accidentally thrown out of a twelfth-story window into an active volcano, a BDC can be "promoted" to fill the role of the dearly departed PDC.

Windows 2000 Domains do things differently. They do not distinguish between Primary and Backup DCs. Instead, Active Directory makes use of something called " multimaster replication." Updates to any replica are propagated to all of the other replicas, so there is no need any longer to specify one copy of the database as the primary.

15.8.4 Trust Me on This

This is one of those concepts that we have to cover because unless you're already familiar with it you'll read about it somewhere else and think to yourself "What the heck is that all about?"

Somewhere back a few paragraphs it was stated that NT Domains are, conceptually, standalone entities... and so they are, but it is possible to introduce them to one another and get them to cooperate. The agreements forged between the domains are known as " Inter-Domain Trust Relationships."

Let's use an example to explain what this is all about.

Consider a large corporate organization with several divisions, departments, committees , consultants , and such-like. In this corporation, the Business Units Reassignment Planning Division runs the BURP_DIV domain, and the Displacement Entry Department calls theirs the DISENTRY domain.

Now, let's say that the BURP_DIV folks need access to files stored on DISENTRY servers (so they can move the files around a bit). One way to handle this would be to create accounts for the BURP_DIV users in the DISENTRY domain. That would cause a bit of a problem, however, because the BURP_DIV users would need two accounts, one per domain. That is likely to result in things like passwords, preferences, and web browser bookmarks getting a bit out of sync. Also, the Benefits Reduction Committee will want to know why all of the BURP_DIV employees are moonlighting in the DISENTRY department and how they could possibly be doing two jobs at once. It could become quite a mess, resulting in the hiring of dozens of consultants to ensure that the problem is properly ignored.

The better way to handle this situation is to create a trust relationship between the DISENTRY and BURP_DIV domains. With inter-domain trust established, the BURP_DIV folks can log on to DISENTRY servers using their BURP_DIV credentials. As shown in Figure 15.6, the DISENTRY Domain Controller will ask the BURP_DIV Domain Controllers to validate the logon.

Figure 15.6. Inter-domain trust

1. A client in the BURP_DIV domain tries to access services on a DISENTRY server.

2. The server requests authentication services from a DISENTRY Domain Controller.

3. The DISENTRY Domain Controller trusts the BURP_DIV domain, so it requests authentication services from a BURP_DIV Domain Controller.

4. The BURP_DIV Domain Controller replies to the DISENTRY Domain Controller...

5. ...which replies to the server...

6. ...which replies to the client.

Note that, in the non-extended-security version of the SESSION SETUP REQUEST message, there is a field called PrimaryDomain . This field identifies the NT domain against which the client wishes to authenticate. That is, the PrimaryDomain field should contain the name of the NT Domain to which the user belongs.

Windows 2000 domains also support trust relationships. This is useful for creating trust between two separate W2K Domain trees, or between W2K Domains and NT Domains.

The mechanisms used to support inter-domain trust are very advanced topics, and won't be covered here.