Learn AD in 15 Minutes a Week: Active Directory Domains and Trusts MMC

Friday Apr 18th 2003 by Jason Zandri
Share:

Jason Zandri continues his series with a first look at the Active Directory Domains and Trusts Microsoft Management Console (MMC), an important tool for your Windows domain controller.

Welcome to the 19th installment of "Learn Active Directory Design and Administration in 15 Minutes a Week," a weekly series aimed at current IT professionals preparing to write the new Windows Active Directory Design and Administration exams (70-219 and 70-217 respectively), as well as newcomers to the field who are trying to get a solid grasp on this new and emerging directory service from Microsoft.

This installment is going to take a first look at the Active Directory Domains and Trusts Microsoft Management Console and offer a review of some of the concepts surrounding the tool's use and functionality. The Active Directory Domains and Trusts Microsoft Management Console (MMC) is part of the administrative tools that are installed by default on systems that have been configured as domain controllers.

The tool can also be installed on a Windows 2000 Professional or Windows XP Professional workstation in order to administer the domain from a console other than the domain controllers themselves by installing and utilizing the proper ADMINPAK administrative tools (Adminpak.msi).

[NOTES FROM THE FIELD] - In order to maintain either a Windows 2000 domain or a Server 2003 domain from a Windows 2000 Professional or an XP Professional workstation, you should download and install the appropriate Adminpak (Adminpak.msi) when the CDROM you need is not available. Windows 2000 Administration Tools must only be installed on Windows 2000 computer, (Server or Professional) and only used to manage a Windows 2000 Active Directory.

Windows Server 2003 Administration Tools may be installed on either a Windows Server 2003 server or a Windows XP Professional workstation. These tools can manage Windows 2000 and Windows Server 2003 Active Directories. Windows .NET Administration Tools cannot be installed on a Windows 2000-based computer.

The Adminpak.msi tools can NOT be installed on any earlier operating system such as NT4.

When you install the Administration Pack, all of the available tools in the Administration Pack are installed by default. You can also opt to install individual, specific Server Administration Tools by using Windows Installer command line switches:

msiexec /i adminpak.msi ADDLOCAL= /qb

TOOLNAME is the name of the Server Administration Tool that you want to install singly.

In order to install the Active Directory Domains and Trusts Microsoft Management Console you would enter:

msiexec /i adminpak.msi ADDLOCAL= FeADTools /qb

This would actually install all three of the Active Directory Tools at once;

  • Active Directory Domains and Trusts
  • Active Directory Sites and Services
  • Active Directory Users and Computers

A Review of Domains

Windows 2000 Domains are the core unit of the logical structure in Active Directory and the structure of the domain can be such that it is made up of one or more domains. Windows 2000 domains can span more than one physical location as well.

All network objects exist within a domain, and each domain stores information only about the objects it contains.

By definition, a Windows 2000 domain is an administrator-defined logical grouping of computer systems, servers and other hardware which share a common directory database.

Windows 2000 domains must have a unique name within the Active Directory forest.

Windows 2000 domains provide access to domain user accounts, domain security group accounts and domain distribution group accounts maintained by the domain administrator, or other system administrators, as appointed by the domain or enterprise administrators through delegation of authority.

A domain is also a security boundary of sorts. It is not a "total" security boundary, as Enterprise Administrators authority is able to transcend the limits of domains within a single forest, but it is to a degree when you consider things such as user and computer accounts, security identifiers, GUIDs and domain wide security settings.

You also need to consider that a domain is also an object in the Active Directory and where group policy is concerned.

Objects in the Active Directory have a Security Descriptor that stores information about the object's owner and the groups to which the owner belongs.

The discretionary access control list (DACL) of the object, lists the security principals (users, groups, and computers) that have access to the object and their level of access.

The system access control list (SACL) lists the security principals that should trigger (if any) audit events when accessing the list.

The discretionary access control list for an object specifies the list of users and groups that are authorized to access the object and also what levels of access they have. The kinds of access that can be assigned to an object (or denied) depend on the object type. (You cannot assign the manage documents access right to a file server as this right is assigned to printers only.)

The discretionary access control list for an object consists of a list of access control entries (ACEs) which can apply to a class of objects, an object, or an attribute of an object. Each access control entry specifies the security identifier (SID) of the security principal to which the ACE applies, as well as the level of access to the object permitted for the security principal.

[NOTES FROM THE FIELD] - In plain English this means, your user account, (SID), can access a specific file on a file server or print to a printer, (object), because the permissions that are set for the object, (the access control entries (ACEs) in the discretionary access control list for the object) allow you the right to read the file or print to the printer.

In Windows 2000 domains, objects include files, folders, shares, printers, and other Active Directory objects. All security policies and settings do not cross from one domain to another and the domain administrator has absolute rights to set permissions and policies only within that specific domain. (Unless they are specifically granted administrative control in other domains or are also members of the Enterprise Administrators group.) [NOTES FROM THE FIELD] - Much of this information is an Exam Requirement for both the 70-217 AND the 70-219 exams. Some would argue it is more so for the 217 and I would agree, but if you do not have the underpinnings from the Administration pieces of 70-217, you'll be hard pressed to pull off the Design requirements for 70-219.

Domains are also units of replication. Domain controllers for the domain contain a replica of Active Directory and can receive changes to information in Active Directory and replicate these changes to all of the other domain controllers in the domain.

A Review of Trees

By definition, a Windows 2000 Active Directory domain tree is a set of Windows 2000 domains connected together via a two-way transitive trust, sharing a common schema, configuration, and global catalog.

In order to be considered a true Windows 2000 domain tree, the domains must form a contiguous hierarchical namespace with one domain being the domain root.

The first Windows 2000 domain installed in a tree is considered the root domain of that tree. It would only be considered the forest root domain if it was also the first domain in the forest.

Let's say zandri.net is the first Windows 2000 domain in a pristine forest. This would make zandri.net the first Windows 2000 domain installed in the forest and as such it would be considered as the forest root domain. Since it is also the first Windows 2000 domain installed in this tree, it is considered to be the root domain of the zandri.net tree.

[NOTES FROM THE FIELD] - A single domain, where there is but a single domain in a tree is called a stand alone domain tree. That single tree constitutes a forest of one tree.

After the zandri.net domain has been deployed, a child domain called northamerica.zandri.net is then created as well as southamerica.zandri.net. Since these two new domains are children of the parent, zandri.net, they would be located below it in the hierarchy and it would look as it does below with the zandri.net domain at the top.

If we were to then create a new domain tree called gunderville.com in the same forest and two child domains, the higher part of the forest structure near the root domain would look something like this:

The root of this forest is zandri.net. The root of the zandri.net tree is zandri.net. The root of the gunderville.com tree is gunderville.com.

A Review of Trust Relationships

All of the domains in a domain tree and all of the trees in a single forest have the connectivity benefit of the two-way, transitive trust relationship, which is the default trust relationship between Windows 2000 domains. A two-way, transitive trust by definition is really the combination of a transitive trust and a two-way trust. This complete trust between all domains in an Active Directory domain hierarchy helps to form the forest as a single unit via its common schema, configuration, and global catalog.

Transitive trusts are a relationship that extends from one domain to the next, to the next, and so on. In the above example, northamerica.zandri.net indirectly trusts southamerica.zandri.net because the trust relationship travels from northamerica.zandri.net to zandri.net to southamerica.zandri.net. Because northamerica.zandri.net to zandri.net is a direct trust and zandri.net to southamerica.zandri.net is a direct trust and all trusts in a Windows 2000 Active Directory are transitive by default, northamerica.zandri.net indirectly trusts southamerica.zandri.net.

This is also the same relationship of northamerica.zandri.net to southamerica.gunderville.com.

Since they are all in the same forest and connected by a common schema, configuration, and global catalog and the fact that all Windows 2000 Active Directory are transitive by default, the following is true:

Since northamerica.zandri.net directly trusts zandri.net and zandri.net directly trusts gunderville.com and gunderville.com directly trusts southamerica.gunderville.com then northamerica.zandri.net indirectly trusts southamerica.gunderville.com.

A two-way trust can be simply looked at as two one way trusts between two domains. When zandri.net trusts northamerica.zandri.net this is a one way trust. When northamerica.zandri.net trusts zandri.net this is another one way trust. It is considered two way because each trust the other in the same reverse manner that they are trusted.

This would also be where zandri.net trusts gunderville.com and gunderville.com trusts zandri.net. Since these two domain trees are in the same forest, they each trust the other and all of their child domains. (two way and transitively.)

Again, all of the domains in a domain tree and all of the trees in a single forest have the connectivity benefit of the two-way, transitive trust relationships, which are the default trust relationships between Windows 2000 domains.

This IS NOT true of domains and domain trees OUTSIDE of the forest. (This is referred to as an External trust.)

For example, if zandri.net were corroborating a project with 2000trainers.com, where users in the 2000trainers.com Windows 2000 domain needed access to resources within the zandri.net Windows 2000 domain, the domain administrator for zandri.net would have to manually set up a trust relationship with 2000trainers.com where zandri.net trusted 2000trainers.com so that users in 2000trainers.com could gain access to the resources they needed. This would not give users in zandri.net access to any resources in 2000trainers.com, as the manual setup of a one way trust does not automatically allow for the "reverse" one way trust, making 2000trainers.com trust the users of zandri.net

This could be done with the Active Directory Domains and Trusts MMC. You would either log on locally to one of the domain controllers in zandri.net or from any workstation that had the tools installed with a domain administrator account (or equivalent) and select the domain and choose properties.

[NOTES FROM THE FIELD] - When you are logged in to a workstation you will need to connect to a domain controller to manage these trusts.

Once you select Properties and choose the Trusts tab you can configure domains that are trusted by this domain in the upper box and domains that trust this domain in the lower box.

For our scenario we will need to Add 2000trainers.com to our Domains trusted by this domain list.

Once we select Add, the Add Trusted Domain box will appear and we can enter 2000trainers.com and the needed password to add this domain to our trusted list.

Also, the trust is in no way transitive. None of the resources in the child domains in the zandri.net tree nor any of the domains of the gunderville.com tree are available to users of 2000trainers.com nor any of the users of forums.2000trainers.com. Even though 2000trainers.com and forums.2000trainers.com share a common schema, configuration, and global catalog in the 2000trainers.com Active Directory only the trusted domain of 2000trainers.com has access to the specified resources and only in the zandri.net domain.

If users of forums.2000trainers.com need to access resources in zandri.net then another one way external trust would need to be created. If users in 2000trainers.com needed to have access to resources to northamerica.zandri.net (or any other domain in the zandri.net forest) another one way external trust would need to be created.

External trusts can be created between different Windows 2000 forests or to a Windows NT domain (sometimes called a down-level domain) or a Kerberos version 5 realm.

You can combine two one-way trusts to create a two-way trust relationship, where 2000trainers.com trusts zandri.net and zandri.net trusts 2000trainers.com, however, even these are NOT TRANSITIVE, since they are from different Windows 2000 Active Directory forests.

[NOTES FROM THE FIELD] - This subject matter is HEAVILY tested upon in both the 70-217 AND the 70-219 exams.

The Active Directory Domains and Trusts Microsoft Management Console is also used to change the mode of the domain from mixed to native mode by right-clicking the domain that you want to convert to Native mode and choosing Properties and selecting Change Mode on the General tab.

After you choose "Yes" to the "Are you sure you want to change this domain to native mode" dialog box, your domain will begin the process of moving to native mode and this change will need to be replicated to all of the domain controllers in the forest.

[NOTES FROM THE FIELD] - Best practices are that you should reboot the domain controller where the mode change has taken place and, once the other domain controllers begin to show native mode rather than mixed mode when you view the properties information these too should be rebooted.

I make mention that this change "could" be performed from any Windows workstation with the appropriate Adminpak tools installed on it but I would not recommend doing it this way. Unforeseen network issues could have unpredictable results. It is always better to be working from a local login on a domain controller.

You can make your change from mixed mode to native mode only once, this action cannot be reversed.

[NOTES FROM THE FIELD] - In our example of the zandri.net forest, we could change the mode of the zandri.net domain from mixed mode to native mode and leave all of the domains in the gunderville.com tree and all of the child domains in the zandri.net tree in mixed mode.

If we decided to run the entire forest in native mode we would have to go to a domain controller (or connect to a domain controller) in each domain to effect the change.

Once you change your domain from mixed mode to native mode there are a number of infrastructure changes that occur.

The domain controller that holds the role of PDC operations master can not synchronize data with any Windows NT BDCs that may still be active on the network. This means that any legacy clients that might still hit those systems to authenticate will be doing so with out of date information, in theory.

[NOTES FROM THE FIELD] - It is a best practice to NOT update a domain to native mode until all NT4 BDCs have either been upgraded to Windows 2000 Server or retired.

Running Windows NT4 member servers is fine from a domain mode perspective.

The PDC Emulator Domain Controller acts as a Windows NT Primary Domain Controller when there is a domain environment that contains both NT4 BDCs and Windows 2000 DCs. It processes all of the NT4 password changes from clients and replicates domain updates to the down-level BDCs. Once the domain is in Native Mode the existing domain controllers no longer support NTLM replication nor can any new Windows NT4 BDCs be added to the environment.

The PDC emulator still performs certain singular duties that no other DCs in the domain handle. The PDC Emulator receives preferential replication of password changes performed by other domain controllers in the domain. When passwords are changed, that change takes time to replicate to every domain controller in the domain and that synchronization delay might cause an authentication failure at a domain controller that hadn't yet received the change. Before that domain controller denies access to whatever is trying to perform the access, it will forward the authentication request to the PDC Emulator before rejecting the logon attempt, as the PDC Emulator may have different information (e.g. a new password. Think of it like a domain controller double check. Making sure it's proper to deny access before actually doing it.)

Well, that wraps up this section of Learn Active Directory Design and Administration in 15 Minutes a Week. I hope you found it informative and will return for the next installment.

If you have any questions, comments or even constructive criticism, please feel free to drop me a note. I want to write good, solid technical articles that appeal to a large range of readers and skill levels and I can only be sure of that through your feedback.

Until then, best of luck in your studies and remember,

"For common sense to be truly common one would expect to see it more often."

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved