AD DS: Identifying Attributes That Are Members of the Partial Attribute Set in Active Directory

This is the second post that I’m bringing over from my previous TechNet blog.  Even though it references a Windows Server 2008 forest, the techniques are the same, so I have had to do very little editing.  Everything shown below works equally well in both Windows Server 2008/R2 and Windows Server 2012/R2.  Again, I hope you find it useful information!

In my earlier post, I showed how to add an attribute to the Partial Attribute Set (PAS) in Active Directory.  But how can you tell which attributes are already part of the Partial Attribute Set in the first place?  You can certainly check each one manually, but that will take forever.  Is there any other way that's more convenient?

In fact, let me show two ways to do it that will make life a great deal easier.

USING LDP

The LDP utility is a graphical LDAP tool for use with Active Directory that allows us to perform very granular searches against Active Directory.  It was first made available in the Windows 2000 Support Tools, but is included with Windows 2008/2012 and is available if you have Active Directory Domain Services installed as a role on your server.

To use LDP to list the attributes in our Schema that belong to the Partial Attribute Set, we want to take the following steps:

• Open the LDP utility by going to Start and entering LDP in the initial search window.  By default, it will look like this (not much, right?):

• Connect to a Domain Controller by selecting Connection and choosing Connect...
  • In the Server field, type the fully qualified domain name of the Domain Controller we are connecting to.
  • In the Port field, enter 389 (since we are doing an LDAP query, not a Global Catalog query)

At this point, the information we have entered looks like the following:

Once we select OK, we will see the RootDSE information on the right-hand screen.  This information contains the top-level information about AD DS for our local domain controller and can be useful in understanding the basics of our directory structure.  The screenshot below shows my lab DC after I’ve connected.  On the right-hand side is the RootDSE information:

At this point, we've connected, but we still need to authenticate to Active Directory.  To do this, we'll do an LDAP Bind.

• Select Connection again in the menu bar and this time choose Bind...
• Choose how we want to bind to Active Directory.  The screenshot below shows the choices I made for my example:

Note that in my case, I’ve chosen to bind with the credentials I’ve used to log on.  It is also possible to bind with other credentials, perform a simple bind, etc.  Another thing that is recommended is that after binding, all further traffic is encrypted (the default).  Though this is not strictly required, it is the more secure option so we’ll leave it checked and select ‘OK’.

Once we have successfully bound to the directory, we will see information similar to this on the right-hand pane:

If any other type of message is returned, we likely have not used the right credentials and will need to get that resolved before proceeding.

At this point, we have connected to our DC and have successfully completed an LDAP bind to authenticate against the directory.  Now it's time to do what we came for.

To use LDP to find out which attributes belong to the Partial Attribute Set, take the following steps:

• Go to Browse in the menu bar and select Search (Ctrl+S)
• In the resulting Search window, enter the top of the search tree (where our search will begin) in the Base DN field.  This will take the form of: CN=Schema,CN=Configuration,DC=<domain component>,DC=com
• We will also enter our query into the Filter field as follows: (&(objectClass=attributeSchema)(isMemberOfPartialAttributeSet=TRUE))
• In the Scope, we want to select Subtree.In Attributes we will select whichever attributes we wish to be displayed (for example, if we want only the name of the attribute displayed in your list, enter 'name').

The resulting window is what we come up with after entering this information:

• If we want to increase the default page size, you can select Options and enter 9999 in the Page size field of the resulting Search options window.

• Select Run to execute your query.

When your query runs, every object that is part of the Partial Attribute Set (which has its attribute of isMemberOfPartialAttributeSet set to TRUE) will be displayed as shown by the sample of my output below:

USING LDIFDE

For those that prefer to work from the command line or within PowerShell (yes, we can run LDIFDE from the PowerShell console), we can also use the LDIFDE tool to query Active Directory for this information (personally, I like LDP but I admit that getting around in it can be a bit challenging at time).  When using LDIFDE, the actual content of the query is largely the same as outlined above, though we'll need to know how to get LDIFDE to give us the output we desire.  And if we’re dealing with a lot of information that we need to work with over time, LDIFDE is the preferred method of gathering this information.

To query Active Directory via LDIFDE, open a command prompt or PowerShell console (we'll once again need to make sure we’re using elevated credentials) and type the following:

LDIFDE -s <fully qualified server name> -d <Base DN> -r <search criteria> -l <list of attributes to export> -f <file name where the query will be written>

On my server, the command looks as follows:

A couple of comments about running LDIFDE:

• -s is not a required parameter if we are querying the local computer.  It is always an option, but is typically used if we are querying remote instances of Active Directory
• -d is the distinguishedName that I am searching.  In this case, I am searching the entire Schema container (and note that while cn=Schema makes it appear that it is a child of the Configuration container, it is actually a separate partition and does not replicate as a component of the Configuration partition)
• -r provides us the search criteria for the information we’re seeking.  In my example, I have specified only objects of the ‘attributeSchema’ class (yes, there is an object type that specifies attributes…a little confusing, maybe, but necessary).  I have also specified which particular attribute of the attributeSchema objects I am interested in.  In this case, I want only those where the attribute ‘isMemberOfPartialAttributeSet’ is equal to TRUE
• -l lists the attributes I want returned.  So in my present example, if I find an object of the attributeSchema class with the attribute ‘isMemberOfPartialAttributeSet’ equal to TRUE, I want to list its CN value
• -f specifies the file where my output will be stored

As can be see from the screenshot above, running this command returned 196 entries.  Below is a screenshot of a sample of those entries as found in the pas.txt file created by LDIFDE:

Note that this information contains the distinguishedName of the attribute even though I did not specifically ask for it.  The output also takes the form of an LDF file, which is used to update and modify Active Directory objects.  The ‘changetype’ entries for each of the returned objects specifies what LDIFDE would do if I attempted to import this file.  It would attempt to add these objects into Active Directory (since they are already present in AD DS, the operation would fail, but the export assumes I might want to use this file to do an import later, so it sets this value for me).

Summary

Either way that we choose to determine which attributes are members of the Partial Attribute Set, we'll find that both LDP and LDIFDE have numerous uses in our day-to-day work as an Active Directory Administrator.  This is just one example of how much value these tools can provide.  Even if we don’t ever want to look up or modify the Partial Attribute Set, every AD DS administrator would be very wise to know both of these tools if we're to optimize our efforts in supporting our Active Directory infrastructures.