The other day, someone asked me what attributes in Active Directory are a part of the set of attributes that is replicated in the Global Catalog, also known as the Partial Attribute Set (PAS). To answer this question, let’s take a step back first. Let’s first look at the concept of partitions or naming contexts (NC) in Active Directory. A NC is a segment of the directory that contains information used for a common purpose and sometimes has a unique replication. There are 3 default Naming Contexts in Active Directory:
· The Schema NC holds the definition of the objects and attributes used to describe objects in the directory
· The Configuration NC holds data about the configuration of the Active Directory forest, such as the site topology
· The Domain NC contains information about a domain in the forest. This includes the objects in the domain, such as users, computers, etc. Each DC has a copy of the Domain NC for the domain that it belongs to.
There are also other NCs in Active Directory that you can use for application data. These are commonly called “application partitions” and they can be used for AD-integrated applications to store data in. The most common use of an app partition is AD-integrated DNS. DNS records are stored in an app partition and you can therefore specify its scope of replication, meaning that you can choose which Domain Controllers get a copy of the partition. Up until Windows Server 2003, application partitions didn’t exist and all of the data that AD held was in one of the three NCs that I defined above. DNS records, for example, were kept in the Domain NC, and that sometimes caused problems if you were in the situation where you wanted both a root and child domain to have a copy of an AD-Integrated zone. Since the DNS data was in the domain partition, only one of the domains could hold the DNS unless you went outside of AD replication and used zone transfers. Putting DNS records in an app partition solved this problem. For now, however, I’m going to put aside app partitions and just discuss the NCs that I mentioned earlier.
Why We Need the GC
Of the three NCs that I outlined above, only two of them get replicated to every Domain Controller in the forest – the Schema and Configuration NCs. This makes sense, as every domain in the forest uses the same schema and configuration data (i.e. site topology). The Domain NC, however, is only replicated among Domain Controllers within that domain. So what happens if a user or process in one domain in a forest needs to search for data in another domain in the forest? Since the Domain NCs are only kept on the DCs that own the domain, the search would have to take place on a DC in the other domain. This can become problematic if you want to search for data across the entire forest because you have to search in every domain.
The Global Catalog (GC) solves this problem by providing some information about the objects in every domain to all of the other domains. To understand how this works, let’s take a quick look at how the schema works. The database file that AD stores its data in is called NTDS.DIT. This database is a Jet database, which is a technology that Microsoft has owned for many years. Wrapped around this database is an engine for reading and writing data to and from the database. This engine is called the ESE (Extensible Storage Engine). The job of the ESE is to perform operations on the database so the application doesn’t have to open the database file directly and read and write data to it itself. The ESE enforces standard semantics on the data – things like ensuring that the data being written to the database doesn’t break the rules of the database. The ESE also puts some logic into the database allows for the transactional data model used in AD. This is the same data model used in Exchange server – the ESE enforces this. The ESE keeps transaction logs and ensures that the atomicity of the data is kept. For example, it ensures that either the entire operation is written to the database or none of it is written to the database. This guards the database against things like data corruption.
There are several tables inside of the NTDS.DIT database file. In Windows Server 2008 R2, there are 12. Some older versions of AD have fewer tables. The primary table that the data is held in is the table called “datatable”. Inside this table there is a row for every object in AD. Each column in the “datatable” table represents an attribute of the object. The schema is what defines each of these columns. A quick look at a Windows Server 2008 DC that I had running in a lab showed that there were 2,190 columns in my “datatable” table. Each object in AD is a row in this “datatable” table. Not every row has data in all of the columns. The Directory System Agent (the DSA) ensures that these columns aren’t filled in for a row that shouldn’t use it. For example, if you create an attribute called “ShoeSize” and only specify that “User” objects can use that attribute, then the DSA will ensure that the “ShoeSize” column can only contain data for rows that contain “user” objects. The interface used for accessing AD data (ADSI) ensures that every operation goes through the DSA, so people can’t break the rules.
How Attributes Are Defined
Each of these attributes (columns) in the directory has a list of properties that define how the attribute behaves – for example, the kind of data stored in the attribute or whether it’s indexed or not. The ata about each of these attributes is stored in the Schema NC. Each attribute has an object in the Schema NC called an attributeSchema object. One of the properties on the attributeSchema objects is the “isMemberOfPartialAttributeSet” property. This boolean (true or false) property defines whether or not the attribute is replicated as part of the Global Catalog. So if you want Domain Controllers for every other domain in the forest to have a copy of this attribute, you just set the isMemberOfPartialAttributeSet property to TRUE. The easy way to do this is through the Schema MMC snap-in. Before you can use it, you have to register it – run the following command from a command prompt:
Then open the Schema MMC and browse to an attribute object. Open the properties on the object and you’ll see the “Replicate this attribute to the Global Catalog” setting. If you check this box, the isMemberOfPartialAttributeSet object gets set as TRUE and this attribute is replicated to all DCs in every domain of the forest.
Listing All of the Attributes in the PAS
So let’s go back to the question at hand – how can we find out which attributes are in the PAS? Since we now know that this is actually defined by an attribute on the attributeSchema object, we can just do a search in the Schema NC for every object that has this value set to TRUE. One way to do this is to open up ADSIEdit.msc and do a custom query in the schema partition:
isMemberOfPartialAttributeSet=TRUE
Here’s the output from running this query on one of my WS08 R2 Domain Controllers:
Happy Schema-Editing!