The Importance of a Domain (Page 1 of 11 )
This article explains the evolution of domains, their functionality, and how to handle them with the Active Directory. It is taken from chapter one of the book
Windows Server 2003 Active Directory Design and Implementation: Creating, Migrating, and Merging Networks by John Savill (PACKT Publishing, 2005; ISBN: 1904811086).
The Importance of a Domain
I would assume since you're reading this book you already know you need a domain and are looking for advice and guidance on the best configuration for your environment. (If you have not bought the book and are just reading at the book shop you're taking food from my child's mouth and should stop now).
Usually people don't realize the full potential of a domain and exactly what it can offer their organization. Many times the Active Directory is simply used as a replacement for an NT 4 SAM domain without offering any additional benefits but we will discuss that in much more detail throughout this book.
Let us begin with a brief history of how the concept of domains originated and how its use has evolved up to the current state. At this point, we will investigate the current levels of functionality available. It is vital to understand where domains came from to appreciate the evolution that has occurred and the factors to consider when implementing Active Directory, which is the final destination of our adventure.
In the Beginning
The first version of Windows released in 1985 featured an amazing 256-color display and the ability to maximize windows but not a great deal more. As the versions progressed, support for memory larger than 640KB (Windows 2.x), a neater 3D interface (Windows 3.x), and an enhanced shell (the program manager) were introduced. However up to version 3.1 Windows was still nothing more than an application sitting on top of DOS with no concept of users or a network.
A network component for MS-DOS was available but this used up a large amount of memory (640KB of RAM) making it an unattractive option in addition to running Windows. To share information, users were forced to use disk media and the concept of security of the data on the removable media meant not letting it out of your sight.
Windows for Workgroups introduced built-in network support specifically around the NetBEUI protocol but also had an optional TCP/IP suite available (which interestingly can still be downloaded from Microsoft although I doubt you would receive much support). The IPX/SPX protocol used by Novel NetWare was also supported to allow connectivity to the then dominant Network Operating System (NOS).
With this built-in network support peer-to-peer networking was possible which allowed the sharing of files and printers over the network. This sharing was not very granular; access could be read-only, or full control with some password permissioning but it was very limited. This method of resource sharing required the user to browse the network and see all machines that were network enabled and a list of shares on each visible machine. In a larger network this browsing became very cumbersome and time consuming; a method was needed to group the machines into logical or business units, hence the advent of the workgroup.
No permissions were needed to join a workgroup; you just set your machine to be part of a workgroup, e.g. sales. If you somehow misspelled the name of the workgroup (which with a name like sales would not be that easy) you would have created a brand new workgroup, and that would be your browsing start point; you would see all the machines in your new workgroup: salad (it's the closest name to sales I could think of!). When you browsed in a workgroup, you would initially see the machines in your workgroup, cutting down the number of machines that were visible. However, it was still possible to browse outside your workgroup by selecting the relevant workgroup name.
In this figure, under Windows for Workgroups, you can see the separate workgroups. In this case, the workgroups are actually domains. However, the domains also provide a workgroup-compatible interface. The Windows 98 machine is in a workgroup of the same name as one of the domains. This is a useful technique to maintain a simpler view for machines not actually in the domain.
The workgroup concept continued to evolve, including a full account database under the NT suite of products on each of the computers called the Security Access Manager database or the SAM database, allowing accounts to be managed on a per-machine basis and allowing groups of users to be created, easing resource authorization management.
There was, however, no central user database with a workgroup; each machine held its own user and password database. This meant if you had four machines with four users, all the users would have to be created on all four machines and their passwords manually synchronized. Every time a new user was added, the addition had to be performed on all machines, and if groups were used, the group membership had to be maintained on each machine separately.
This figure is an example of workgroup configuration showing the separate user databases stored on each workgroup member machine. Because MachineC has a different password for user Hal, this may cause problems in accessing data depending on how the access has been defined.
The multiple user account databases are the primary weakness of a workgroup, which is not practical for anything over 10 machines and requires another solution.
As mentioned earlier, Novel had successful NOS called NetWare with a centralized account database system, which overcame the limitations of the workgroup model. Microsoft needed to counter this, and in collaboration with 3COM released LAN Manager (based on an even earlier NOS MS-NET, which was not very good). Originally, LAN Manager could not offer the same level of performance as NetWare but it was improving and had introduced the concept of a domain, which reworked the whole concept of user/group databases.
Newer versions of LAN Manager were released up to version 3.1 (at which point it was renamed to Windows NT) but all maintained the core concept of a domain. This domain concept remained all the way up to Windows NT 4 Server, which will be discussed here.
It is important to remember that although workgroups have now been removed from the Windows product line, even in Windows 2003 it is possible to run the machines in a workgroup configuration. For a small number of users this is simpler than the infrastructure required to run a domain. However, in most situations a domain is best suited, as we will see.
Next: Who's SAM? >>
More IIS Articles
More By PACKT Publishing
|
 This article is taken from chapter one of the book Windows Server 2003 Active Directory Design and Implementation: Creating, Migrating, and Merging Networks by John Savill (PACKT Publishing, 2005; ISBN: 1904811086). Check it out at your favorite bookstore. Buy this book now.
|
|
