The Importance of a Domain - What do I Need the Active Directory For?
(Page 4 of 11 )
So far, everything we have discussed has been around the domain model used for Windows NT 4 and it was a massive improvement over the workgroup model: but it still had some significant limitations of its own, which had to be addressed:
- 40MB maximum practical database size: 40MB may sound a lot if each account takes up around 1KB and a computer account is around 0.5KB. By the time you add groups you are looking at around 25,000 users per domain. It should be noted that 40MB was the Microsoft-supported maximum size; in reality, larger databases were possible depending on the specifications of the domain controller.
- Replication limitations: Very little control was given over the replication of database between the PDC and the BDCs. Some registry modifications could be made to change the period between pulses (how often BDCs are notified of changes), the number of BDCs notified at a time and other settings but these were very generic and domain controllers that were over slow WAN links could run into a lot of problems.
- No way to delegate control: There were effectively domain administrators (who could do everything) and everyone else (who could change nothing in the domain database). If you had helpdesk staff, who needed to reset user passwords you would have to make them domain administrators giving them a lot of power and exposing your domain to unnecessary risk.
- No concept of physical location: Domain Controllers and clients have no idea of where they reside physically and so clients could authenticate against any domain controller (although some workaround is possible by the use of the LMHOSTS file and the #PRE #DOM qualifiers to force remote clients to use a BDC at their location).
- Static database format: The SAM contained set fields: username, full name, but not much else. There was no way to add extra information and although Microsoft touted domains as a directory service this was purely for marketing reasons, to try to compete with NetWare which actually had a real directory service. If you wanted extra information you would need a separate directory/database.
There were other problems but these were the main factors in the requirement to create multiple domains (for example, if you needed more than 25,000 users or required a separate group to have control over their resources).
Once you have more than one domain you have multiple account databases. How do you enable users defined in one account database to have access to resources that are stored on computers that belong to a different domain? You just have to trust them.
Trust Relationships
We defined a domain as a set of machines that share a common account database and because of this common database, a domain also acts as a security boundary. Any machine not in the domain does not use our domains account database and thus cannot be granted access to our resources. Likewise, accounts in our domain cannot be granted access to resources in other domains.
Due to some of the limitations discussed above, multiple domains were a necessity in many corporate environments, but since the domains were still within one organization, a method was required to allow users in one domain to be granted access to resources in another domain. The domain that held the resources had to trust the domain containing the accounts (i.e. accept that the users had been properly authorized and were indeed entitled to an account).
This is exactly how inter-domain authorization was technically implemented: a trust relationship was created where one domain would trust another domain; the domain holding the resources would be the trusting domain (it is trusting the domain with the accounts) while the domain holding the accounts would be the trusted domain. This trust was an administrator-created communication channel to allow inter-domain authorization.
If both the domains involved need to trust each other (allowing users from either domain to be assigned access to resources in either domain), then a bi-directional trust would be created, which is actually two unidirectional trusts.
To create a trust an Administrator in the trusted domain would create a trust relationship with a password and then an Administrator in the trusting domain would complete the relationship by specifying the password set by the trusted domain Administrator. This ensured trust relationships were managed and could not be created without input from Administrators from both domains.
Another side effect of the trust relationship is any user who resides in a domain that is trusted by another domain would be able to sit down at a workstation that belongs to the trusting domain and log on to their local domain. At the main logon screen, the domain list would include the domain of which the workstation is a member and all domains its local domain trusts. As in the example shown in the figure that follows, if a user sits down at a workstation belonging to Domain A, the drop-down domain list would show Domain A and Domain B (although workstations that belong to Domain B would not list Domain A as a drop-down option since Domain A does not trust Domain B).
In this example, Domain A trusts Domain B so accounts in Domain B can be granted access to resources in Domain A.
One final important point about trust relationships is the relationship is not transitive, this means that if Domain A trusts Domain B and Domain B trusts Domain C, Domain A does not automatically trust Domain C; this relationship would have to be manually created. This is shown in the following figure.
You have to manually create every single trust relationship between all domains that require access to resources. In large environments, this could be extremely messy especially if there was no central IT strategy.
Domain Models
Because of trust relationships, a number of models arose that could describe nearly all environments. These models were based around the type of trust relationships and how they were assigned. Once you analyze your NT 4 environment, it will most likely fit one of the following models.
Single Domain Model
In a single domain model there is a single domain containing the accounts and the resources. This is the simplest model and is suitable for most environments that are not geographically spread and have less than 25,000 users. In a single domain model, the domain administrators can administer all of the network servers.
Single Master Domain Model
A single master domain is suitable when the number of accounts required is supported by a single domain, but resource management needs to be broken up by organization. In a single master domain model, the central IT department still centrally manages the accounts in the main domain (which is the 'master domain' or the 'account domain'). Resources such as printers and file shares are located in resource domains that trust the account domain; this means the users in the account domain can be granted access to resources in the resource domains.
Multiple Master Domain Model
The multiple master domain model is very similar to the single master domain model, except there were too many accounts to be stored in one domain and so multiple account domains were required. All of the account domains have a two-way trust between them. The resource domains also trust each of the account domains.
The exact implementation varies; accounts may be split equally between domain controllers, or different account domains in different geographical regions may be present, overcoming the replication limitations of Windows NT 4 domain implementations.
One IT group can still centralize administration of the account domains or various regions can each have control of their own account domain. Like the single master domain model, the resource domain's management can be delegated to various organizational areas to give them full control of their own resources.
Complete Trust Model
No company plans for the complete trust model. Every domain has its own accounts and resources and every domain has a bi-directional trust to every other domain. This means any account in any domain can be assigned access to any resource in any domain. There is no central management or control.
Complete trust domain models typically occur as all departments have their own IT department and create their own domains for accounts and resources, but then find that access to resources in other domains is required and so trust relationships are created as required, eventually spanning all domains.
This is the hardest environment to transfer to the Active Directory due to its lack of central control. This is, however, a requirement for a successful Active Directory implementation.
Next: The Main Event—Active Directory >>
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.
|
|
