Links and Backlinks in Active Directory for Exchange

In Active Directory (AD) there is the concept of objects, attributes and links between objects.

AD Objects

AD objects (or more correctly Object Classes) include users, groups, computers, service connection points, OUs, etc.  They are the type of things about which we want to store information.  An instance of an AD object class is an AD object, however that in itself isn’t very useful since we have no way to describe the object, nor distinguish one object from another.

Attributes

Attributes describe an object, and within the AD schema there are attribute classes which declare what this attribute’s relationship is with object classes, and also what type of information this attribute stores.  This is how we can store things like first name, last name, display name, etc for users.

Linked Attributes

Linked attributes describe relationships between objects, For example groups have members, mailboxes have delegates, mailboxes are automapped for full access users.  These examples are all called forward links, as they are the main direction that we describe the relationship in.  What if you want the reverse though, what if you want to see which groups a user is a mermber of?  Luckily AD generally declares linked attributes as pairs, and this reverse link is called a back link.  Again within the AD schema attribute classes declare what type of information this attribute stores (which will always be some derivative of a distinguished name, and in the case of a forward link it can be single valued or multi valued)   For Linked attributes there is a special attribute in the schema called linkID.  For forward links this attribute always have an even value, for back links it is always odd and always the next number.

For example one of these link pairs is publicDelegates and publicDelegatesBL.  As you can see below they have the linkID 14 and 15 respectively.  These link IDs used to be controlled by Microsoft and if you wanted to add a linked attribute then you would request a link ID from Microsoft to be allocated to you.  However starting with Windows Server 2003, the link ids can be auto-generated by placing the value 1.2.840.113556.1.2.50 into the linkid of the forward link and place the attribute id of the forward link into the link id of the back link.  When these extensions are applied to AD then it will assign you linkids that will definitely not already be in use.  The attributeid is an Object ID (OID) and are managed by ISO National Registration Authority, who will assign a unique OID root to anyone who asks for one.

publicDelegates and BL

These linked attributes are stored in a special way in AD.  AD has a number of tables in its DIT database file, one of which is a data table to store all the attribute values and another is a link table.  This link table stores the source object, the target object and the linkid to signify the relationship.  Note that AD only stores the forward link.  The two objects can be thought to use the Distinguished Name as the attribute used to identify which object is referred to, since that is easy to understand, however in reality each Domain Controller (DC) takes the distinguished names (DN) and calculates a distinguished name tag (DNT) (which is more like a row number to another table that actually stores the object)  When replicating changes to these linked attributes the DC translates the DNT back to a DN and then sends that to the DC that was asking for the changes to be sent.  This DC again calculates DNTs from the DNs and updates its link table.

Now it makes sense AD stores the forward links so that groups have members, mailboxes have delegates and mailboxes are automapped for full access users, but what if you need to find out the reverse?  i.e. find all groups that this user is a member of, or find all mailboxes that a user is a delegate for, or find all mailboxes that a user should automap?

Luckily AD helps us out here by maintaining the backlinks.  These are not actually stored in AD but are a by product of having the link table as well as the fact that a backlink’s linkid is always the next consecutive number after the forward link.  So this means that without any trouble AD can retrieve the reverse relationship.  e.g. the query give me all mailboxes that a user is a delegate for is translated to look in the link table for the linkid for publicDelegates where the target object is this specific user.  Lo and behold AD knows the answer.

Now when searching we can either use an LDAP tool, including AD Users and Computers, to write a custom ldap query/filter such as (&(publicDelegatesBL=CN=Conrad Murray,OU=Test Users,DC=neroblancolab,DC=co,DC=uk)) or we can use Exchange Powershell such as get-mailbox -filter “GrantSendOnBehalfTo -eq ‘CN=Conrad Murray,OU=Test Users,DC=neroblancolab,DC=co,DC=uk)'”

Both of the above will produce the same results (assuming all the relationships are between mailboxes)

Now in some cases Exchange Powershell doesn’t expose an attribute via a filter and so AD filters need to be used.  An example of that is automapping.  To work out which mailboxes a user should automap you can look at the AD attribute msExchDelegateListLinkBL which will list the Distinguished Name of all mailboxes that ought to be automapped by this user.

How do you know which attributes are Backlinks and what values they have?  The easy part first, backlinks are always multi-valued attributes containing distinguished names.  The second part is slightly harder in that they do almost all end with BL but seeing them in AD Users and Computers isn’t automatic.  You need to make sure that a) you’ve enabled Advanced Features in the View menu, and then in the Attribute Editor you need to click on Filter and ensure Backlinks is ticked.

There are loads of these links and backlinks, but some of the more common ones include

• altRecipient/altRecipientBL
• dLMemRejectPerms/dLMemRejectPermsBL
• dLMemSubmitPerms/dLMemSubmitPermsBL
• msExchArchiveDatabaseLink/msExchArchiveDatabaseLinkBL
• msExchDelegateListLink/msExchDelegateListBL
• publicDelegates/publicDelegatesBL
• member/memberOf
• manager/directReports
• owner/ownerBL

If you want a complete list of all linked attributes in your AD then you can always run an ldap query against the Schema partition with the filter (&(objectclass=attributeSchema)(linkid=*)) and you will pull all of them out.  Sort them by link id and you will know the forward and backward links and how they relate to each other.

If you are interested in more details about links and backlinks then check out this blog.  It was written a few years ago but the concepts are still very much alive and kicking.  Fun with Linked Attributes

Now in practice I was recently asked to provide a list of all people who were delegates.  I thought about it for a bit to see how you might do it in Exchange Powershell, but in the end I went back to LDAP and literally wrote a filter containing ‘(&(publicDelegatesBL=*))’ and within a few minutes (for >250,000 users) it gave me the list of around 40,000 delegates!  Versus trying to do that in Exchange Powershell, which would have needed to go through all GrantSendOnBehalfTo add them all to a single array and then select the unique ones, and would have taken hours!

There you have it.  Linked attributes are used quite a bit in Exchange, and often to get queries that run in a reasonable length of time it is quicker to revert to AD queries than Exchange Powershell.