Global catalog and User Logon

A domain controller can locate only the objects in its domain. Locating an object in a different domain would require access to a global catalog server.
A global catalog server is a domain controller that, in addition to its full, writable domain directory partition replica, also stores a partial, read-only replica of all other domain directory partitions in the forest.
The attributes that are replicated to the global catalog are identified in the schema as the partial attribute set (PAS) and are defined by default by Microsoft.
In addition to its activities as a domain controller, the global catalog server supports the following special activities in the forest:
User logon: Domain controllers must contact a global catalog server to retrieve any SIDs of universal groups that the user is a member of.


(1) Client logs on to the domain, which prompts
(2) a DNS query for the closest domain controllers.
(3) Client contacts the returned domain controller DCx for authentication.
(4) DCx queries DNS to find the closest global catalog server and then
(5) contacts the returned global catalog server DCy to retrieve the universal groups for the user
The global catalog stores the membership (the member attribute) of only universal groups.

Additionally, if the user specifies a logon name in the form of a UPN (which has the format sAMAccountName@DNSDomainName), the domain controller contacts a global catalog server to retrieve the domain of the user:


Universal and global group caching and updates: In sites where Universal Group Membership Caching is enabled, domain controllers cache group memberships and keep the cache updated by contacting a global catalog server.
Caching group membership reduces WAN traffic, which helps in sites where updating the cached group membership of security principals generates less traffic than replicating the global catalog to the site.

How Domain Controllers Are Located (DCLocator)


This article describes how Windows client locates a domain controller. On the client, the NetLogon service verifies logon requests, and it registers, authenticates, and locates domain controllers by using the DsGetDcName API call (known as the domain controller locator function).

The following sequence describes how the Locator finds a domain controller during the logon process:

      1. Client does a DNS query to get a list of DC of the current domain in the form: _LDAP._TCP.dc._msdcs.domainname. (all domain controllers register this SRV record).
      2. Client receives a list of DC IP addresses from DNS (they are ordered following priority & weight).
      3. The client begins querying the DCs in turn to find out which DC is available. It sends a datagram LDAP UDP search which contains the IP address of the client (IP address ONLY without the subnet).
      4. The DC looks up the client IP address in its subnet-to-site mapping table and returns:
        • the subnet object that most closely matches the client IP address
        • The name of the site in which the current domain controller is located
        • A flag that indicates if the current DC is in the site closest to the client.
      5. The client decides whether to try to find a better domain controller. The decision is made as follows:
        • If the returned DC is in the closest site (the returned bit is set), the client uses that DC.
        • If the client has already tried to find a DC in the site in which the DC claims the client is located, the client uses that DC.
        • If the DC is not in the closest site, the client updates its site information and sends a site specific DNS query (_LDAP._TCP.sitename._sites.domainname) to find a new DC in the site. If the second query is successful, the client uses the new DC. If the second query fails, the client uses the original DC.

Automatic Site Coverage
There is not necessarily a domain controller in every site. If a site contains no DCs, then DCs in the sites closest to that site (calculated by site-link costs) will register site-specific records for that site as well, to help clients find a DC as close as possible.

This process known as automatic site coverage ensures that every site has a domain controller, even if a site does not contain a domain controller for that domain.

By default, each domain controller checks all sites in the forest and then checks the replication cost matrix. A domain controller advertises itself (registers a site-related SRV record in DNS) in any site that does not have a domain controller and for which its site has the lowest-cost connections.

Clients with No Apparent Site
Sometimes the client pings a domain controller and the client IP address cannot be found in the subnet-to-site mapping table. In this case, the domain controller returns a NULL site name, and the client uses the returned domain controller.

How to determine the fsmo role holder (fsmoRoleOwner attribute)

This article describes how to find the servers that hold the Flexible Single Master Operation (FSMO) roles in a forest.

Active Directory defines five FSMO roles:

Per-forest roles, one per forest:

  • Schema master
  • Domain naming master

Per-domain roles, one per domain:

  • RID master
  • PDC master
  • Infrastructure master


To determine the master for a partition, query the fSMORoleOwner attribute on the corresponding object under the naming context root in question:

Schema Master:

Domain Naming Master:

PDC Role Owner:

Infrastructure Master:
LDAP://cn=Infrastructure, dc=concorp,dc=contoso,dc=com

RID Master:
LDAP://cn=RID Manager$,cn=System, dc=concorp,dc=contoso,dc=com

You can use tools such as ldifde to perform queries to get FSMO role holders:

ldifde -f Infrafsmo.ldf -d "CN=Infrastructure,DC=concorp,DC=contoso,DC=com" -l fSMORoleOwner

This query returns the infrastructure master role owner for the DC=concorp,DC=contoso,DC=com partition to the Infrafsmo.ldf file.

The information in the attribute is stored as a DN, representing the NTDS Settings object of the DC that is the role owner. Example:

CN=NTDS Settings,CN=DC1,CN=Servers,CN=SITE1,CN=Sites,CN=Configuration,DC=contoso,DC=com

The following c# code returns the PDC role owner:

static void Main(string[] args)
  DirectoryEntry DomDn = new DirectoryEntry("LDAP://dc=concorp,dc=contoso,dc=com");
  DirectoryEntry PDCfsmo = new DirectoryEntry("LDAP://" + DomDn.Properties["fsmoRoleOwner"].Value.ToString());

  Console.WriteLine (PDCfsmo.Parent.Properties["dnsHostName"].Value.ToString());


Same as previoulsy, the following VBscript code returns the PDC role owner:

Set objDomDn = GetObject("LDAP://dc=concorp,dc=contoso,dc=com")
strfsmoRoleOwner = objDomDn.Get("fsmoRoleOwner")

Set objPDCfsmo = GetObject("LDAP://" &  strfsmoRoleOwner)
Set objPDCfsmoParent = GetObject(objPDCfsmo.Parent)
Wscript.Echo  objPDCfsmoParent.Get("dnsHostName")

Flexible Single Master Operation (FSMO)

To prevent conflicting updates in Windows, Active Directory performs updates to certain objects in a single-master fashion. In a single-master model, only one DC in the entire directory is allowed to process updates, it is referred to as a Flexible Single Master Operation (FSMO) role. Currently in Windows there are five FSMO roles:

Schema master: responsible for performing updates to the directory schema (that is, the schema naming context or LDAP://cn=schema,cn=configuration,dc=<domain>).

Domain naming master: responsible for making changes to the forest-wide domain name space of the directory (that is, the Partitions\Configuration naming context or LDAP://CN=Partitions, CN=Configuration, DC=<domain>).

RID master: each DC is assigned a pool of RIDs from the global RID pool by the domain controller that holds the RID master role. The RID master (also known as the RID pool manager, RID manager, or RID operations master) is responsible for issuing a unique RID pool to each domain controller in its domain.

Each security principals (Users, computers, and groups) is assigned a unique alphanumeric string called a SID. The SID includes a domain prefix identifier that uniquely identifies the domain and a relative identifier (RID) that uniquely identifies the security principal within the domain.

PDC emulator: it is also responsible for time synchronizing within a domain. It is also the password master for a domain. Any password change is replicated to the PDC emulator as soon as is practical.

Infrastructure master: When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to security principals), and the DN of the object being referenced. The infrastructure FSMO role holder is the DC responsible for updating an object’s SID and distinguished name in a cross-domain object reference. There is one Infrastructure FSMO role per domain and application NC in a directory.

Active Directory naming contexts (directory partitions)

Active Directory is the central repository in which all objects in an enterprise and their respective attributes are stored. It is a hierarchical, multi-master enabled database, capable of storing millions of objects. Those objects areorganized as a treeand stored into sections, called naming contexts or directory partition.

Each directory partition contains a hierarchy (subtree) of directory objects. At minimum, each domain controller stores three NCs in its local copy of the Active Directory database.
Active Directory naming contexts

Configuration NC contains objects about sites, services, and directory partitions. Every domain controller in the forest has a replica of the same configuration partition.

Configuration NC

Schema NC contains the Schema container, which stores class and attribute definitions for the forest. Every domain controller in the forest has a replica of the same schema partition

Domain NC : The domain partition contains the directory objects, such as users and computers, associated with the local domain. Each domain controller stores a full replica of the domain partition for its local domain, but does not store replicas of the domain partitions for other domains