The Importance of a Domain - Forests (Page 8 of 11 )
A forest is one or more trees connected at the tree roots by Kerberos bi-directional transitive trusts. As with a tree, this now means that every single domain in a forest trusts every other domain in the forest and in other trees.
As you can see, the two trees in the figure are connected via a transitive Kerberos trust, meaning all domains trust each other as if they had an explicit trust (the dotted lines). With a forest, you can have multiple namespaces and still enjoy the advantages of a single Active Directory structure.
When we looked at trees, there were a number of common features between all the domains in a tree. These common features are actually common between all domains in a forest (except for the contiguous namespace). This includes a common schema between all the domains in the forest and a single everyone group as well as the authenticated users group.
A new tree is added to the forest during the DCPROMO process; you cannot add an existing tree in its own forest to an existing forest for practical reasons. If they had different schemas and all domains in a forest had to share a common schema it would create a problem. However, Windows 2003 does introduce the ability to create a transitive trust between separate forests as long as all domains and forest are at full Windows 2003 functional level.
Organizational Units
Organizational Units (OU) are one of the greatest features of the Active Directory. They offer long-overdue functionality for Windows-based directory services and were a necessity for Microsoft in adding this functionality to organize our objects in a scalable way that is customizable and flexible for any business needs. Microsoft did a great job in adding this functionality to help simplify our design during the initial domain design phase and easing the process of altering the design well after it has been implemented, and thus increasing the ease of the network management going forward. As we will see, Organizational Units in many cases do away with the need of resource domains.
With previous domain implementations, users could be put into groups, enabling control over resource access authorization, but not much else. Groups still exist (and have been expanded) in the Active Directory for the purposes of simplified Access Control List (ACL) management but they do not help if you want to group users and resources for the purposes of management, of policy application or to actually hide objects.
Organizational Units are containers that can hold nearly any other type of objects including other Organizational Units to form a hierarchy. Organizational Units, as the name implies, are used to organize objects into logical groupings and it is important to understand that Organizational Units are an Administrators' tool; they should be created to ease the administration of your environment and primarily used for the following reasons:
- Delegation of Authority: It is possible to assign people/groups with administrative permissions over Organizational Units. These permissions are far more granular than under NT 4 domains. Instead of being a full administrator, it's now possible to delegate just the ability to reset users' passwords, or modify only the telephone number attribute of users. Delegation is also possible at other levels (for example, at domain level) but an OU is the smallest scope at which delegation can occur (you cannot delegate at a group level).
- Group Policy Application: Group Policy has replaced the old System Policies and can be assigned at multiple levels, one of which is group level. Since Organizational Units can be nested, Group Policy could be applied at all levels of the OU nesting giving a lot of flexibility (maybe too much) in the resultant policy applied to the computer or user.
- Hiding Objects: If you have Active Directory resources that should not be visible when browsing, you can place them in an Organizational Unit and then configure the OU so that certain groups of users cannot view the content.
- Logic grouping of resources to aid administration: It's possible to perform administrative functions on more than one object at a time; to ease this object selection you could place objects in OUs based on how they are typically administered. Care should be taken in this case and OU creation should primarily be based on the first three reasons (this reason can sometimes lead to a large number of OUs, which can eventually increase the complexity of an environment and adversely affect performance).
It is important to understand the difference in implementation of groups and OUs. When users are placed in a group, the actual user object is not moved but a reference is placed in the group to show membership; when an object is placed in an OU, it is actually moved to inside the OU, hence you cannot place an object in more than one OU. The exception is that since OUs can be nested, if an object is placed in OU B and OU B is in OU A then such an object would inherit settings (including delegation and group policy) applied to the OUs A and B.
Organizational Units are not used for ACLs; you cannot assign an OU to an ACL to allow all users in an OU access to a resource, you would still have to use a group for this purpose. OUs can have permissions assigned to them (for hiding etc.) but you cannot use them for ACL purposes.
OU structures are separate for each domain. Each domain can implement its own OU hierarchy, and it is not possible to share an OU structure between domains (even if they are in the same forest). An OU is stored in the domain partition, and is not available across domains.
In each domain one OU is created automatically: the 'Domain Controllers' OU into which all domain controllers are placed. This is because a default Group Policy Object exists for domain controllers which is applied to this default OU.
In the figure that follows, both domains contain separate OU structures, which in turn contain a mixture of resources:
Next: Sites >>
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.
|
|
