Global Catalogs and Infrastructure Role

There is often confusion when it comes to Global Catalogs (GCs) running on a server that is also has the FSMO role of Infrastructure Master.  I wanted to take some time to answer some of these questions, as well as make recommendations for how to configure your domain/forest.  (Below is just a brief overview of the topic.  I learned much of this from a session lead by Dean Wells – now an MS AD employee – at the 2008 Directory Experts Conference.)

First, it is important to explain what the role of the infrastructure master plays in an AD environment.  The technical definition of the infrastructure master is that it is responsible for cross domain updates and lookups.  What exactly does this mean?  Say you have a user named Herbie Finkelstein. Herbie is in Domain A, but needs access to a resource in Domain B (of the same forest).  So, you add Herbie to a Domain Local group in Domain B so that he can access this resource.  The infrastructure master (in Domain B) will then look at the GUID, SID and DN of Herbie’s account.  If it does not find Herbie’s account on this DC, it will update his account with the new information for this cross domain reference.  This will enable Herbie to now access the resource in Domain B.  (Note that the infrastructure role has nothing to do in a single forest/single domain environment.)

Now that we know a little more about what the infrastructure role does, how does a global catalog interact with this role?  If a server is a global catalog, it will already have Herbie’s account on it (partial attributes that are stored in the GC), so the infrastructure role will not do any updating of this account.  This becomes a problem if all of your DCs in a domain are not GCs.  If all of your DCs are a GC, they will have Herbie’s account on them and be able to reference his group membership.  The only difficulty comes if you have servers that are not GCs (other than your infrastructure role). 

So, what is the recommendation?  Here are the current recommendations for configuration:

  • Make all of your DCs GCs.  (This decision can be made on a domain by domain basis within a multiple child domain forest.)  You will see an error message in your event logs warning you about this that you can safely ignore.  This is the recommended configuration for the majority of situations.  You will find many references recommending against this, but newer materials
  • Do not have your infrastructure master be a GC.  This would be primarily used in a situation where you do not have all of your DCs as GCs.  This might be the case where you have GC caching turned on some of your DCs instead of full GCs.

References

An explanation of various FSMO roles in AD:

http://www.petri.co.il/understanding_fsmo_roles_in_ad.htm

Jorge (MS MVP for AD) and his recommendations:

http://blogs.dirteam.com/blogs/jorge/archive/2006/07/18/the-infrastructure-master-fsmo-and-the-gc-role.aspx

Phantoms, tombstones and the infrastructure master:

http://support.microsoft.com/kb/248047