Effects of Losing an Operations Master (FSMO) Role Holder in Relation to an Active Directory Forest and/or Domain

/in /by

Introduction

THE PAGER just went off.  It’s 3am.  You’ve been asleep for two hours after just finishing a brutal online battle where you saved the world from an encroaching Evil.  So what is this pager thingy and why does it insist of beckoning for your attention in a loud, obnoxious fashion?

You look through sleepy eyes at the display.  Server down.  Ouch.  And with your organization shooting for 99.999% uptime to support 24/7 manufacturing operations, you are subliminally aware that the clock is ticking.  Thinking through the 3am fog, let’s see – this server was destined to be decommissioned as part of your schedule for next week.  All of the file shares and printers were relocated to another server last Fri.  It was performing no critical network services…  And, then you remember.  The server Decomm wasn’t complete yet because that server is the RID Master for your Active Directory domain and that role still needed to be transferred.

So .. the question becomes, is this a call you place to your Manager giving her a heads-up about your awareness of the server down, but assuring her that it can wait until morning without causing any inconveniences or is this something which requires immediate attention?

What if the downed server wasn’t the RID Master, but rather the domain’s PDC Emulator and your organization is still running a Mixed-Mode environment (thank you Sales and Marketing for not upgrading their Windows NT 4.0 Server Domain Controllers)?  How does this impact the need for expediency to resolve the server down situation?

Lost, but not Down

Schema Master (Forest Role)

All Domain Controllers contain a copy of the Active Directory Schema.  This Schema is essentially a template or listing of the various Active Directory object types and available attributes present within a given forest.  This template is used to refresh the Active Directory database where the actual objects are stored.

The loss of the Schema Master role holder in an Active Directory puts the forest into a state of stasis so no extensions (addition of object types and/or attributes) to the Schema can be made.  This would impair activities such upgrading an Active Directory domain from Windows Server 2000 to Windows Server 2003, installing Microsoft Exchange, and/or adding new attributes to an object.  All things considered, as this sort of activity does not happen on a daily basis, a forest could survive the loss of this role holder and continue with minimal inconvenience in most cases.

Domain Naming Master (Forest Role)

If the Domain Naming Master role holder is lost, domains won’t be able to be added or removed from the Active Directory forest.  DCPROMO is also affected, meaning that servers can neither be promoted nor demoted.

Though the loss of this role holder impacts some more common operations performed within an Active Directory forest and its contained domains, it is still doesn’t create highly visible issues within your environment.

RID Master (Domain Role)

If the Domain Controller performing as the RID Master goes down or becomes inaccessible, Windows 2000 and above domain controllers will have no place to acquire new RID pool assignments.  As this function is only called upon sporadically, unless you are adding security principals in bulk, this outage may not become apparent for some time.

A more noticeable occurrence may be the failure of the movetree.exe command to function properly as it relies upon the RID Master present in the domain that the object is coming from to actually perform the move.

Infrastructure Master (Domain Role)

In the event that the Infrastructure Master role holder is lost, the ramifications will vary based upon whether the forest is in itself a single domain, or if it contains multiple domains.  If everything within your Active Directory forest is contained within a single domain, the Infrastructure Master really doesn’t have anything to do as there are no cross-domain references to be maintained.

In a forest with multiple domains, the Infrastructure Master role holder plays a more vital role by maintaining cross-domain references (ie users from Domain A are members of a group in Domain B).  In Domain B, these references (the users from Domain A) are called phantoms.  If the Infrastructure Master for Domain B were to go down, changes to phantom objects would no longer be maintained and communicated to the Domain Controllers in Domain B.  So if one of the user objects in Domain A changes it’s UPN, that change will not be maintained across Domain B.  Now the kicker here, any server in Domain B that is a Global Catalog Server will be automatically maintained due to the intercommunications of the GC processes forest-wide.  This would make for an intermittent issue as some servers would have stale phantom references and others would be up-to-date.

PDC Emulator (Domain Role)

Okay, in short, the loss of any Domain Controller performing an Operations Master (FSMO) function will not be the end of your environment; but each does have a potential for impact given a sufficient window of absence.  In usual circumstances, however, the most crippling role to lose is the PDC Emulator.

In a mixed-mode environment, when the PDC Emulator goes down, you lose the bridgehead server for Windows NT 4.0 networks involved in trust relationships with that Active Directory domain.  You also lose any down-level updating of the SAM for your Windows NT 4.0 Backup Domain Controllers, therefore Active Directory account changes such as password changes, login name changes (somebody marries/divorces), etc are never communicated.

Regardless of the mode or functional-level of the domain, you stand the risk of losing time-synch within the domain (assuming that all of the hosts in the environment are configured in accordance with best practice).  Essentially, the PDC Emulator in the forest is to be synchronized to an outside, commonly recognized time source.  The PDC Emulators in the parent domains should look to the forest PDC Emulator for time synch.  The PDC Emulator in a child domain will look to its parent and so on and so forth.  The other hosts in each domain should, in turn, look to their authenticating Domain Controller for their time sync.  With component broken, it has the domino effect .. the more complex and distributed the domain/forest, the greater the potential of Kerberos failures as the clocks fall apart from one-another on the Domain Controllers or clients which were directly dependent upon the defunct PDC Emulator.

Any Domain sitting above Mixed Mode would still also be susceptible to password changes not being communicated across the domain in a timely fashion.  Let’s explore this…

Say a user at Site C calls the Help Desk requesting a password reset.  The Help Desk person (located in Site A, where the PDC Emulator is) goes to reset the user’s password.  This person realizes that the server he normally changes passwords is down, so he resets the user’s password on another Domain Controller located at Site A.  Once performed, the Help Desk person instructs the user to try to logon.  The user tries, and after a bit of delay, his logon still fails.  Why?

Simple.  The server on which the password change was made has never communicated it beyond the confines of Site A, and more importantly, this change has never been communicated to the Active Directory domain’s PDC Emulator.  Since the PDC Emulator is down, this change was never communicated to the recognized “final authority” in that domain for password authentication issues.  The Domain Controllers in Site A will be communicated this change rather quickly, but due to the timing of Intersite Replication, the bridgehead server for Site C won’t become aware of this change for some amount of time.

Now, when the Domain Controller in Site C is presented with the user’s new credentials, it compares the password (presented by the user) to the password previously known for that user (stored in its copy of the Directory).  The two passwords won’t match.  So the next step for the Domain Controller in Site C is to contact the domain’s PDC Emulator located in Site A for determination.  After some amount of waiting due to the lack of response from the PDC Emulator, the Domain Controller in Site C has no recourse but to deny the user’s authentication attempt.

Finding Your Operations Masters Role Holders

In a prior paper, I showed you how to identify the Active Directory Operations Masters through the available GUIs.  There is a much easier way.

Quick FSMO Role Holder Identification

Install the Support Tools for your OS (Windows 2000 and up).  This suite of tools includes a command-line utility called NETDOM.  Open a command prompt and execute the NETDOM command in accordance with the following syntax:

NETDOM QUERY /DOMAIN:domain FSMO

This will return the FSMO role holders for the indicated domain.  This will also indicate the Schema Master and Domain Naming Master role holders for the forest.  Viola – all information in one simple query!

You are now empowered with information.  You have identified the players, you know what they do, and you know what happens if they go down .. so .. where do you go from here?  Let’s talk about architecture, placement, of the Operations Masters role holders and Microsoft-recommended best practices.

Operations Masters Placement

Design by default, let’s review this.  First-up Domain Controller in an Active Directory Forest will hold all of the roles (including the Global Catalog).  If you know you are designing a forest which will have multiple Domains, you will see a stumbling-block fast.  The Global Catalog and the Infrastructure Master role should not exist on the same server unless your Active Directory environment will only be comprised of a single domain.

That said, bring-up a second Domain controller for the forest and transfer the PDC Emulator, Infrastructure Master, and RID Master roles to that new DC.  Leave the Schema Master, the Domain Naming Master, and the Global Catalog on the initial Domain Controller.

For redundancy, it would be a good idea to bring-up a third Domain Controller to serve as a secondary Global Catalog server for that site.  If this is done, the RID Master and the PDC Emulator roles could be moved to this server if desired.  Keep in mind, however, the PDC Emulator role holder will probably be the busiest of all role holders as many servers will query it and request processes to be performed.  Ensure the hardware platform is reasonable for the task.

Microsoft recommends having the RID Master and the PDC Emulator roles located on the same Domain Controller.  This is primarily because of two reasons:

  1. The RID Master is a relatively low-traffic, low-overhead
  2. Having the RID Master and the PDC Emulator on the same Domain Controller enhances the performance of the creation of objects at the request of NT 4 BDCs when working in a mixed-mode environment.

Any domains created within the forest should take a similar approach to the one shown above; however the Schema Master and Domain Naming Master roles will not be addressed on a domain-by-domain basis as they are Forest-wide roles.  Once addressed at that top-level, they are set. The placement of the Domain-specific role holders should still follow the pattern indicated above.  It is also recommended that those role holders be located at a site within the Domain which provides the best bandwidth and most reliable intersite connection.

One final suggestion, at remote sites it may be a good idea to setup two Domain Controllers for redundancy.  Aside from the inherent benefits, each should be configured as a Global Catalog server.  This is especially viable in Windows Server 2003 environments due to the enhancements for granularity in its replication of objects and attributes.  Windows Server 2003 will utilize less bandwidth during the Global Catalog synchronizations and yield better performance for forest-wide object look-ups initiated from users at the remote site.

How Do We Transfer Roles?

The Domain and Forest roles can be transferred via GUIs or via the command-line utility NTDSUTIL.  For the following activities, we are going to use only the command-line as it is simpler from the stand-point that all operations, transfer or seizure, for all roles can be performed from this one utility.  For these activities, we will assume a basic familiarity of both the Windows and the Command-line environments exist.

1)      Open a command prompt

2)      Type ntdsutil

 

3)      At the ntdsutil: prompt, type roles

4)      At the fsmo maintenance: prompt, type connections

5)      At the server connections: prompt, type connect to servername

Note:  The servername must be a Domain Controller within the domain in which you are working.  This will be the destination (or recipient) for the FSMO/Operations Master role to be transferred.  NetBIOS names usually suffice.  If the user you are currently logged in as does not have credentials recognized on the destination Domain Controller, may be prompted.  In most cases, Domain Admin credentials are appropriate.

Binding to dcb2k3 …

Connected to dcb2k3 using credentials of locally logged on user.

6)      At the server connections: prompt, type q

7)      At the fsmo maintenance: prompt, type your desired action

Action

Description
transfer domain naming master Transfers the Domain Naming Master role to the connected server
transfer infrastructure master Transfers the Infrastructure Master role to the connected server
transfer pdc Transfers the PDC Emulator role to the connected server
transfer rid master Transfers the RID Master role to the connected server
transfer schema master Transfers the Schema Master role to the connected server

After the transfer process has completed…

8)      At the fsmo maintenance: prompt, type q

9)      At the ntdsutil: prompt, type q

This will exit the NTDS Utility and return you to the command prompt

How Do I Seize a Role?

Okay .. Let’s say disaster has struck and you have lost a Domain Controller which was an Operations Master.  For whatever reason, you need to regain the functionality provided by that role holder immediately.  This is why we love NTDS Utility.  The process we will use is very similar to that of transferring an Operations Master role.

1)      Open a command prompt

2)      Type ntdsutil

3)      At the ntdsutil: prompt, type roles

4)      At the fsmo maintenance: prompt, type connections

5)      At the server connections: prompt, type connect to servername

Note:  The servername must be a Domain Controller within the domain in which you are working.  This will be the destination (or recipient) for the FSMO/Operations Master role to be transferred.  NetBIOS names usually suffice.  If the user you are currently logged in as does not have credentials recognized on the destination Domain Controller, may be prompted.  In most cases, Domain Admin credentials are appropriate.

Binding to dcb2k3 …

Connected to dcb2k3 using credentials of locally logged on user.

6)      At the server connections: prompt, type q

7)      At the fsmo maintenance: prompt, type your desired action

Action

Description
seize domain naming master Assigns the Domain Naming Master role to the connected server
seize infrastructure master Assigns the Infrastructure Master role to the connected server
seize pdc Assigns the PDC Emulator role to the connected server
seize rid master Assigns the RID Master role to the connected server
seize schema master Assigns the Schema Master role to the connected server

After the seize process has completed…

8)      At the fsmo maintenance: prompt, type q

9)      At the ntdsutil: prompt, type q

This will exit the NTDS Utility and return you to the command prompt

Seizing a role has more ramifications in an environment than a more graceful transfer does.  In fact, a transfer is a clean hand-off.  A seizing operation assumes that the state of the Operations Master role present on the DC to which the role has been assigned was intact and up-to-date. There can be inherent fall-out from this assumption.  Anytime a role is seized, be prepared to watch for fallout .. aberrant events in the System Event log.  Monitor this for a while and be prepared to deal.  Seizing a role is really a last effort, not to be undertaken lightly.  If the role holder can be brought back-up, OS drive array (system state) intact, within an acceptable amount of time it would be best to pursue that course of action.

Conclusion

Divide and distribute, redundancy, live to fight another day – those are the thoughts I would like to leave you with.  Of course, from an Active Directory perspective redundancy applies to the Global Catalog servers, not the Operations Master roles.  Design your enterprise Active Directory structure to mitigate risk.  Harden your servers and use well-connected sites as much as possible, especially between the primary data centers for each domain.  Distribute the Operations Master roles amongst the Domain Controllers in that location providing that location is the best based on the following criteria:

  • Bandwidth
  • Power
  • Cooling
  • Security
  • IT Support

Know your environment; know what is at risk with each server and Domain Controller.  Doing so will help you rest, even on the nights when you get the 3am pager alerts.

Bibliography

  1. “Understanding and Identifying the Operations Masters within Your Active Directory Environment”, Rick Gregson, Convergent Technologies, https://www.convergenttechonline.com/documents/understanding%20and%20identifying%20the%20operations%20masters%20within%20your%20active%20directory%20environment.htm
  2. “Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller”, Article #255504, Microsoft Support Knowledge Base
  3.  “FSMO placement and optimization on Active Directory domain controllers”, Article #223346, Microsoft Support Knowledge Base
  4. “Flexible Single Master Operation Transfer and Seizure Process”, Article #223787, Microsoft Support Knowledge Base
  5. “Initial synchronization requirements for Windows 2000 Server and Windows Server 2003 operations master role holders”, Article #305476, Microsoft Support Knowledge Base

 

Windows Server 2008 Five Attractive Benefits from Adopting Longhorn

/in /by

Introduction

Microsoft was scheduled to release its new Windows Server 2008 operating system, codenamed “Longhorn”, at the beginning of Q3 2007. I am bristling with anticipation for the next quarterly software maintenance release, which should be arriving in a few days, for Microsoft Business Partners. To satiate my curiosity, though, I downloaded the Windows Server 2008 Beta 3 Release and created a virtual machine so I could get a jump on familiarizing myself with this new edition of Windows. That journey will be presented later in a series of papers on this website.

As experience has proven, it is a good idea to wait a period of time before adopting a new operating system into your environment; however, by the same token, there is an impetus to move along with the flow and stay current. By doing so, you mitigate problems and risks associated with maintaining older software versions. Thinking back some years, Windows NT 4.0 Server was a good release in its day compared to the other Microsoft Windows Operating Systems. Though not always friendly, it did tend to be more stable than its peers. With the release of Windows 2000 the Microsoft community was introduced the X.500 standard by the implementation of Active Directory. Windows Server 2003 and Server 2003 R2 expanded the capabilities and functionality across the enterprise, with gains in performance, security, and efficiencies over its predecessor.

As I feel that most Technical Overviews of a product venture into the realm of “information saturation”, I have made a list of five “fast-gain” features of Windows Server 2008 which I feel will be most beneficial to medium and large-sized businesses from a perspective of security, management, performance, and reducing TCO (Total Cost of Ownership).

So what benefits await us moving forward into Windows Server 2008? Let’s take a look.

Windows Server Core Installation

This is a cool new installation option because it mitigates security vulnerabilities by shrinking the attack surface on a machine providing less opportunity for exploitation by hackers. Rather than building a domain controller and turning off whatever services your organization has deemed “risky”, why not just install a server core without all of the optional fluff? The core installation presently supports the following features for installation:

  • DHCP
  • DNS
  • File & Print Services
  • Active Directory Domain Service and Lightweight Directory Services
  • Server Virtualization

Another feature to this server build is that over its life-cycle it will require less updates and software maintenance meaning that it may advantageous for bandwidth deficient locations.

Read-Only Domain Controller (RODC)

At first glance, this was reminiscent of NT 4.0 BDCs and I was perplexed, but then the impetus started coming into focus. If a physical machine in a remote office is compromised, this build of a domain controller reduces further risk of security compromise as no changes can be made to the user accounts in Active Directory from that machine.

Terminal Services Gateway (TS Gateway)

Do you have applications at your Datacenter which you need to distribute to remote offices and/or laptop or home users and you don’t want to require the overhead of a VPN or third-party software? Microsoft Terminal Services, in conjunction with IIS 7.0, can now provide remote application delivery across the web. I think what I like best about this capability is the fact that Microsoft patches and security updates should be able to be applied without compromising the delivery systems.

Server Virtualization (WSv)

Windows Server 2008 can natively provide a virtual machine (VM) environment without the necessity of third-party software. This functionality allows one physical box to be divided-up logically into many individual server instances utilizing the same virtualized hardware platform. Rather than supporting and maintaining multiple physical servers, virtualization allows the consolidation of the IT footprint in an effort to reduce direct and indirect IT operating expenses. Server virtualization also leverages attached network infrastructure such as storage-area networks for a lower TCO. Supported guest operating systems are Microsoft Windows and Linux.

Network Access Protection (NAP)

Network Access Protection empowers Administrators to create policy-based client machine “health requirements” which could include stipulating OS patching requirements, software installation requirements, and required configuration settings. If a client machine is brought onto the network and it fails to meet the requirements, further action may be defined regarding how these rogue machines are to be addressed.

Understanding and Identifying the Operations Masters within Your Active Directory Environment

/in /by

Introducing the Operations Masters / FSMO (Flexible Single Master Operations) Roles

FLEXIBLE WHOS THAT DO WHAT?! That was my initial response when I first encountered these roles a few years back while preparing for an interview with Microsoft. Since then, I have been getting warmer and cozier with them, coming to understand their functions as well as their implications/impact upon an Active Directory environment. The Microsoft Windows 2000 Server and above architecture revolves around the concept of distributed environments and “multi-master” replication. Essentially, Microsoft did away with the single master architecture (PDCs and BDCs) of Windows NT 4.0 Server, right?

Well, mostly yes…

What it comes down to is this – There are some things better left with one single Domain Controller being responsible for making the changes in a given Active Directory forest or domain. In Windows 2000 environments, we refer to these responsible Domain Controllers as Flexible Single Master Operations (FSMO) role owners. In Windows 2003 Server environments, we refer to these Domain Controllers as Operations Masters. The terminology changed, but the essential roles didn’t.

There are five Operations Masters:

  • The Schema Master
  • The Domain Naming Master
  • The RID Master
  • The PDC Emulator
  • The Infrastructure Master

These roles exist because not everything in a well-constructed environment lends itself to a multi-master replication model. My favorite example for this is the governing of Schema changes. What if you had multiple servers capable of making changes to the Active Directory Schema at any given time? In a multi-master environment, generally speaking, the last change written wins. Effectively, if two people are editing the Schema and their efforts overlap, somebody’s changes will be lost. Let’s take that scenario a step further. What if multiple simultaneous changes cause corruption in the Schema or what if the Schema contents across the Domain Controllers gets out-of-synch? Envision strange replication errors at best and/or your Active Directory forest getting trashed at worst. Imagine long hours working to rebuild Domain Controllers and restoring System States from backups in an effort to rebuild your Active Directory environment. Personally, in my mind, it brings up visions of a villeage being brutally attacked by Genghis Kahn and his warriors. I can see the fires, destruction, and chaos reigning supreme. And usually in those stories, somebody’s head ends-up on a chopping block. Luckily, Microsoft foresaw the necessity of the establishing the five single master roles.

In this paper, we will review the Operation Masters / FSMO roles and become familiar with some of their characteristics from an Active Directory perspective. Understanding and locating these role owners now may help in assessing the performance of your network operations later as well as help by being a precursor step for evaluating the impact of a “server-down” situation.

Let’s begin.

The Schema Master

The Schema Master role owner is the only Domain Controller in an Active Directory forest which can process changes to the Schema. These changes are commonly referred to as extensions to the Active Directory Schema. These extensions could be either objects or properties being added to the Schema. Some examples of when a Schema would be extended include the introduction of Microsoft Exchange, the introduction of Microsoft Live Communications Server, or even an upgrade of an Active Directory domain from Windows 2000 to Windows 2003.

So where do the changes take place? Where is the Schema actually held? Well, when referring to the Schema we are refering to an Active Directory database partition known as the Schema Naming Context located at LDAP://cn=schema,cn=configuration,dc=. Changes are made to this database partition on the Schema Master and are then replicated out to all of the other Domain Controllers in the forest.

A few caveats to remember:

  • Forest role (1 per forest)
  • Default role owner is the first server promoted to Domain Controller within a Active Directory forest
  • To manipulate the Schema you must be a member of the Schema Admins group
  • Responsible for making changes to the Active Directory Schema
  • Maintains the Schema Naming Context   LDAP://cn=Schema,cn=configuration,dc=

The Domain Naming Master

The Domain Naming Master role owner is the only Domain Controller in a forest which can create or delete Active Directory domains within the forest. This role owner is also responsible for maintaining cross-references to domains in other external Directories.

The information this Domain Controller maintains is located in the Partitions\Configuration Naming Context, or LDAP://cn=partitions,cn=configuration,dc=. As with the Schema Master, changes are made to this database partition and are then replicated out to all of the other Domain Controllers forest-wide.

A few caveats to remember:

  • Forest role (1 per forest)
  • Default role owner is the first server promoted to Domain Controller within a Active Directory forest
  • A Domain Admin can manipulate this role if the Active Directory forest contains only a single domain
  • Only an Enterprise Admin can manipulate this role if the AD forest contains multiple domains
  • In Windows 2000 Native Mode, this role owner must also be a Global Catalog server. In Windows 2003 Functional Level, this role owner does not have to be a
  • Global Catalog server but it is recommended that one be present in the same site/subnet.
  • Maintains the Partitions\Configuration Naming Context    LDAP://cn=partitions,cn=configuration,dc=
  • Manages the addition or deletion of domains in the Active Directory forest as well as cross-references to domains in other external Directories

The RID (Relative ID) Master

The RID Master role owner is the only Domain Controller in an Active Directory domain responsible for assigning RID pools to the other Active Directory Domain Controllers within that domain. NT 4 BDCs in a mixed-mode domain are not assigned RID pools as they rely on the PDC Emulator for the creation of security principals. Security principals are objects such as users or groups which have permissions and/or rights assigned to them.

In a Windows 2000 or above domain, all Domain Controllers can create security principals. When a security principal is generated, the Domain Controller creating the object attaches a SID to it. This SID is comprised of a domain SID and a RID value (which ensures the SID’s uniqueness). During the logon process, credentials such as a SAM account name or a UPN (Universal Principal Name) are presented to the system. These credentials are resolved to their respective SID, which is used to uniquely identify that object. The SID is then evaluated for the purposes of authentication and resolving security permissions.

To ensure that each Domain Controller has a unique RID pool, the RID Master role owner, by default, allocates 500 RIDs for each Domain Controller in it’s domain. As new Domain Controllers are brought up in the domain, RID pool allocations are also made for those.

Starting with Windows 2000 Server Service Pack 4, Domain Controllers begin requesting a new RID pool when they reach a threshold value of 50% remaining RID values. Prior to SP4, the threshold value was 20%. This means that a SP4 or Windows 2003 Server Domain Controller using the default RID block size of 500 will start requesting a new pool when 250 RIDs (50%) remain. In contrast, a pre-SP4 Windows 2000 Server Domain Controller using the same RID block size will start requesting a new pool when only 100 RIDs (20%) remain.

The RID Master is also responsible for ensuring that when an Active Directory object is moved from one domain to another, the move is performed appropriately (that the object does not end-up existing in multiple domains simultaneously). To move an object via movetree.exe, initiate the move on the RID Master role owner in the Domain in which the object currently resides. After the move is complete, that RID Master will then delete that object from it’s Active Directory domain.

A few caveats to remember:

  • Domain role (1 per every domain contained in the Active Directory forest)
  • Default role owner is the first server promoted to Domain Controller within an Active Directory domain
  • To manipulate this role you must be a member of the Domain Admins group
  • Every security principal in a domain has a SID (Security Identifier), comprised in part by a RID
  • Object moves between domains are initiated at/performed by the originating domain’s RID Master

The PDC Emulator

The PDC Emulator role owner in an Active Directory domain is the Domain Controller with the final authority regarding password issues and is largely responsible for mitigating Kerberos authentication issues by providing an authoritative time-synch within a domain/forest. Any user authentication failure due to a password issue at a Domain Controller is passed-back to the PDC Emulator for a final determination before a password failure message is reported to the user. The PDC Emulator also functions as the Master Browser and processes the account lockout functions for it’s domain. There are some variations, however, in this role owner’s scope of responsibilities depending upon the functional level (or mode) of the Domain and the PDC Emulator’s location within the Active Directory forest.

Tip: In an enterprise, to assist a user with a password change and avoid the inconvenience of initiating Active Directory replication/s to synchronize changes, make the change on the Domain Controller which is the PDC Emulator for the user’s Active Directory domain.

The Domain Controller in an Active Directory forest which holds the PDC Emulator role is the authoritative time server for that forest. This is important and necessary because Kerberos uses time synchronization as one of it’s checks during the authentication process for security principals. By default, Kerberos authentication will fail if the clocks are more than 5 minutes apart.

Tip: It is strongly recommended that the PDC Emulator for the Active Directory forest be synchronized to an outside time source such as:

tock.usno.navy.mil
time.nist.gov
ntp2.usno.navy.mil

If the PDC Emulator role is transferred to another Domain Controller, then that Domain Controller should be pointed to an external time source to maintain the consistent, uniform time synch across the forest.

As mentioned before, the PDC Emulator role within an Active Directory domain also varies depending upon the functional level (or mode) of the domain it is in. In Mixed Mode, the PDC Emulator provides backward-compatibility, performing functions necessary to support NT 4.0 BDCs within the domain. These functions include processing account changes for the BDCs, the creation of security principals, and providing a centralized SAM for the BDCs to update themselves with. This Domain Controller also would be the referenced when establishing trust relationships with external NT 4.0 networks.

In a pure Windows 2000/2003 Server environment (aside from the possibility of Windows NT 4.0 Member Servers), all Domain Controllers are capable of creating security principals as well as processing account changes. Password changes, however, are treated preferentially. A password change can be processed by any Domain Controller within an Active Directory domain; however once that change is made, it is replicated immediately to the PDC Emulator. This action supports the PDC Emulator as being the final authority in password authentication.

The PDC Emulator role owner is the default location where Group Policy Objects are edited to reduce any risk of conflict.

A few caveats to remember about the PDC Emulator:

  • Domain role (1 per every domain contained in the Active Directory forest)
  • Default role owner is the first server promoted to Domain Controller within an Active Directory domain
  • To manipulate this role you must be a member of the Domain Admins group
  • Role varies somewhat depending upon the functional level or mode of the domain it is in
  • Final Authority for password authentication
  • Should be time synched across the forest; forest-level PDC should be synced to an external standard
  • Default Domain Controller on which Group Policy Objects are edited

The Infrastructure Master

The Infrastructure Master role owner is responsible for keeping track of all of the objects within it’s own domain as well as maintaining phantom objects found in cross-domain references. Let’s dissect this. “Keeping track of all objects in it’s own domain” – right on! Somebody has to know who’s on first, what’s on second, etc. No problem. “Maintaining phantom objects found in cross-domain references” – hmm, the whole phantom thing brings thoughts of Scooby-Doo and the Mystery Mobile to mind. Ruht-Roh! Let’s clarify this a bit.

Phantom objects are objects which do not exist in the Infrastructure Master’s domain, but they exist elsewhere and they are being referenced in this domain. A good example would be a person, whose user object exists in one domain, being included in a group which exists in your domain. That person’s user object is not present in your domain, but it’s essence is – thereby constituting a phantom object.

The essence analogy is my term for it. To be specific, the phantom object attributes maintained/tracked by the Infrastructure Master include the object’s GUID (Globally Unique Identifier), SID (if the object is a security principal), and the object’s DN (Distinguished Name). A phantom object reference is termed stale if the original object has been moved or renamed since the last update of the Infrastructure Master.

The Infrastructure Master within an Active Directory domain updates it’s phantom object references based on any changes found on it’s nearest Global Catalog Server. The Infrastructure Master writes any object updates it finds to it’s database and then replicates those changes out to the non-Global Catalog Domain Controllers within it’s domain.

Note: Global Catalogs contain all objects in an Active Directory forest; however they only contain a subset of the attributes for each object

Note: Global Catalog servers are updated regularly

Tip: Windows 2000 Global Catalog Servers rely on a full replication of the Global Catalog, which may prove to be a bandwidth burden depending upon how your remote sites are connected and how large your Global Catalog becomes. In contrast, Windows 2003 Servers hosting the Global Catalog only replicate changed objects and their attributes, yielding lesser bandwidth consumption and better performance.

In a single domain scenario, the Infrastructure Master role owner has nothing to do so it makes no difference on which Domain Controller this role exists. In a multiple domain Active Directory forest, the Infrastructure Master cannot sit on a Global Catalog server. Ideally, the Infrastructure Master should be sitting in a well-connected site which contains one or two Global Catalog servers (for redundancy), but the Infrastructure Master role owner itself should not be on a Global Catalog server.

Note: If the Infrastructure Master role is sitting on a Global Catalog server, it will never notice that changes have been written by the Global Catalog. Any changes that server has recorded will never be replicated out to the other non-Global Catalog Domain Controllers within it’s domain. Effectively, only the Global Catalog servers will be up-to-date.

This role owner maintains the Domain Naming Context partition of Active Directory. The LDAP location for this information is LDAP:// cn=domain,dc=. Changes are made to this database partition and then replicated out to all of the other Domain Controllers within that Active Directory domain.

A few caveats to remember:

  • Domain role (1 per every domain contained in the Active Directory forest)
  • Default role owner is the first server promoted to Domain Controller within an Active Directory domain
  • To manipulate this role you must be a member of the Domain Admins group
  • Maintains the Domain Naming Context partition of Active Directory     LDAP:// cn=domain,dc=
  • The Infrastructure Master role owner is responsible for keeping track of all of the objects within it’s own domain as well as maintaining phantom objects used in cross-domain references
  • In a single domain scenario, the Infrastructure Master role owner has nothing to do so it makes no difference on which Domain Controller this role exist
  • In an Active Directory forest with multiple domains, the Infrastructure Master role owner can not be a Global Catalog Server

How to Identify the Operations Master Role Owners within Your Environment

To identify the Domain Controllers holding the various Operations Master roles, there are various methods at our disposal; however, for the purpose of this paper, we will simply cover working through the various GUIs.

Identifying the Schema Master

Choose Start | Run
Type regsvr32 schmmgmt.dllClick OK



You will receive a success message

Click OK
Choose Start | Run

Type mmc /a

Click OK

(This opens the MMC utility in author mode)
Choose File | Add/Remove Snap-in  
Click Add…  
Choose Active Directory Schema

Click Add

Click Close
Click OK  
Maximize the Snap-in in the Console window  
Choose File | Save

Select the Windows\System32 folder

Give the console a name (ie Schema)

Click Save
In the console pane, expand the Active Directory Schema object.

Active Directory Schema [servername.<domain>]

The servername indicated is the Schema Master role owner

 

Identifying the Domain Naming Master

Open Active Directory Domains and Trusts

In the console pane, right click on Active Directory Domains and Trusts

Choose Operations Master…
This window identifies which Domain Controller is the Domain Naming Operations Master

Click Close

Identifying the RID Master

Open Active Directory Users and Computers

In the console pane, right click on Active Directory Users and Computers

Choose All Tasks | Operations Masters…

  
This window identifies which Domain Controller is the RID Operations Master

Click Close

Identifying the PDC Emulator

Open Active Directory Users and Computers

In the console pane, right click on Active Directory Users and Computers

Choose All Tasks | Operations Masters…
Click the PDC tab

This window identifies which Domain Controller is the PDC Emulator for the Domain

Click Close

 

Identifying the Infrastructure Master

Open Active Directory Users and Computers

In the console pane, right click on Active Directory Users and Computers

Choose All Tasks | Operations Masters…
Click the Infrastructure tab

This window identifies which Domain Controller is the Infrastructure Master

Click Close

Conclusion

SO WHAT DOES THIS MEAN TO ME? Simple. In either a Small Business Server environment or compact, single domain environment – it may not mean much. It would still be a good idea to at least identify the Operations Master role owners in your environment so that you can have an idea of the impact in the event of a “server-down” or “network-down” situation. Review the locations of the role holders. Do they make sense? What is your contingency in the event of an outage? To that end, I must say that NTDSUTIL is a terrific utility to keep accessible.

For Small Business Server owners, the identification is much simpler and your options are much narrower in scope. By design, all roles are held on the Small Business Server itself and cannot be transferred. Be diligent in performing backups and ensure that the System State as well as all necessary data is being backed-up appropriately.

Enterprise operations have the biggest gains (or losses) to be encountered in light of understanding the Operations Master roles, role placement, and contingency planning. Some roles can even be absent from an environment for a period of time before the effects become noticeable. The more we understand the roles and their interactions, the more “bullet-proof” we can design our Active Directory environment.

Bibliography

  1. Windows Server 2003: The Complete Reference, Kathy Ivens, ISBN: 0-07-219484-7
  2. Active Directory, Allen & Lowe-Norris, ISBN: 0-596-00466-4
  3. Exam Cram 2: Windows Server 2003 Active Directory Infrastructure, Will Willis & David Watts, ISBN: 0-7897-2950-4
  4. “‘Domain controller has failed to obtain a new identifier pool’ error event in Windows 2000 Server SP3 and earlier”, Article #316201, Microsoft Support Knowledge Base
  5. “Windows 2000 Active Directory FSMO Roles”, Article #197132, Microsoft Support Knowledge Base
  6. “How to View and Transfer FSMO Roles in the Graphical User Interface”, Article #255690, Microsoft Support Knowledge Base
  7. “How to Find Servers That Hold Flexible Single Master Operations Roles”, Article #234790, Microsoft Support Knowledge Base