The Importance of a Domain - RID Master FSMO Role
(Page 10 of 11 )
Every object in the domain has a Security Identifier, known as a SID. This SID is composed of the SID of the domain the object resides in and a Relative Identifier (RID), which is unique in each domain.
These Relative Identifiers have to be unique in the domain. If each domain controller in the domain made up its own, there is a chance it would clash with that created by another domain controller. So, a single domain controller in each domain, the RID FSMO, gives batches of 500 RIDs to each domain controller. When a domain controller has only 100 RIDs left (20%), it requests another batch of 500 from the RID FSMO. However, with Windows 2000 Service Pack 4 and above, a new batch is requested when 50% (or 250) of the number of RIDs are left, improving resilience if the RID FSMO is not available.
The RID Master is also used when moving an object between domains (this is now possible quite easily, thanks to some tools that are supplied with Windows: for example, the movetree.exe utility). Even though you may not specifically run the utility on the RID server, the utility will automatically contact and use it.
This role is also per domain and so every domain has a RID Master FSMO server.
Infrastructure FSMO Role
It is possible for an object in one domain to be referenced by another domain. For example, when a user from domain A is placed in a local group in domain B, the reference information stored in the domain B group is:
- The Globally Unique Identifier (GUID) of the object (which never changes during the objects lifetime, even if it is moved between domains)
- The Security Identifier (SID) of the object (which would change if moved between domains)
- The Distinguished Name (DN) of the object (which changes if the object is moved in any way) This information is stored in a record known as a phantom record.
The Infrastructure FSMO is responsible for ensuring that the SIDs and DNs of the phantom records of objects referenced from other domains are kept up to date by comparing the content of its database with that of the Global Catalog. If the information it has stored for the GUID of the object is different from that of the Global Catalog, the phantom record is updated with the new information. This checking process runs periodically and it is possible that sometimes you may view a group and you will see grayed icons. This simply means the object with the DN cannot be found at present; it has probably moved and the infrastructure master has just not updated the phantom record yet. It is not a problem and would not affect the working of the group.
It is vital that the Infrastructure Master FSMO role is not a Global Catalog if you have more than one domain, since its database will never see anything different from the Global Catalog (since it is one). If you only have one domain, it does not matter since you will not have any objects from other domains referenced.
Again, this role is a one-per-domain deal.
Schema Master FSMO Role
We talked about the schema being the blueprint for every class and attribute within the entire forest and that it was policied so that only certain users could request a change (members of the Schema Admins group) and changes could only be requested through a particular domain controller, the Schema Master. This time, however, since the schema is forest wide only one domain controller in the entire forest has the role; only this machine has the ability to write to the schema, which is then replicated to every other domain controller in the entire forest.
Domain Naming Master FSMO Role
During the DCPROMO process, domains can be added to a tree or forest by selecting a parent domain. We need to ensure the same domain name is not used twice and that every domain name is unique in the forest. This is the responsibility of the Domain Naming Master FSMO, which has to be contacted before any domain can be added or removed from the forest. With Windows 2003, it is also used when moving domains around the forest structure (we can move domains around the forest, which is known as "prune and graft").
This figure shows that within the forest there is a single instance of the Schema and Domain Naming FSMOs (they happen to be on the same domain controller but this need not always be the case) and that every domain has its own PDC, RID, and Infrastructure FSMOs (again these do not have to be on the same server).
All of the domain-specific roles will be held by the first domain controller created in each domain, by default. The roles can be moved to any domain controller within the domain (but not to an NT 4 BDC) and can exist on the same server or split across multiple domain controllers. There are some best practices for their placement, which will be examined in more detail later.
The forest-specific roles will, by default, be held by the first domain controller ever created in the forest (which will be in the forest root domain). These roles can be moved too.
It is important to understand that these roles to not move automatically; if the server running one of these roles goes down, the functions it performs will not be possible: for example, if the RID FSMO is unavailable for an extended time you may no longer be able to create new objects in a domain.
Global Catalog
A Global Catalog server is a special domain controller that not only holds a full replica of its local domain partition but also a read-only copy of a subset of attributes of every object in every other domain. It is important to understand that Global Catalog is not an FSMO role, but rather an additional service running on specific domain controllers.
By default, the first domain controller created is a Global Catalog (GC). However, any domain controller can be configured as a GC and there are a number of best practices regarding this configuration, which will be examined later in the book.
The attributes stored in the Global Catalog are defined as the Partial Attribute Set (PAS) and the PAS can be modified by marking or unmarking attributes in the schema as replicated in the Global Catalog.
Each domain's domain controllers, as seen in the figure above, hold a full replica of the local domain's partition and the global catalogs also contain a subset of every other domain's partition.
The Global Catalog is used to locate resources within the enterprise. A domain contains full information about resources in its domain but trying to find resources in the rest of the forest would be very time consuming if a domain controller in each domain had to be located and queried for any search. Instead, enterprise queries are directed at a Global Catalog.
In addition to providing an enterprise search ability the Global Catalog is used to store a specific type of group, the Universal group, which is accessible from any server in the forest and can contain users for any domain in the forest. A Global Catalog is queried during logon to check for Universal Group membership. If a GC cannot be contacted, then users will not be able to logon unless a new feature of Windows 2003, the ability for sites to cache Universal Group membership, is used (although domain administrators can log on even without GCs).
Obviously the Global Catalog content has to be replicated between every Global Catalog in the entire forest. (There is only one 'version' of the Global Catalog; they should all share the same content assuming that the replication was instant. Nevertheless, there will be some minor differences due to replication latency.) The Knowledge Consistency Checker (KCC) creates additional connection objects for this GC replication, and connection objects to domain controllers in other domains, to ensure that a subset of every domain's partition content is available in the GC.
When a user provides a query to the Global Catalog, they first ask the DNS server for a Global Catalog. Once a Global Catalog is returned, they perform the query via port 3268 on the server (normally port 389 is used for a standard LDAP query). If the Global Catalog does not have the attribute being queried as part of the PAS, the query is referred to the normal LDAP Active Directory service.
Global Catalog servers will not return any data stored in an application directory partition that they hold a replica of: only information originating from domain partitions is returned via Global Catalogs.
Next: Domain and Forest Modes >>
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.
|
|
