Foreign Security Principals and Well-Known SIDS, a.k.a. the curly red arrow problem

So I was at a customer today, and for some reason or another we ended up looking at the members of the group called "Pre-Windows 2000 Compatible Access". Members of this group basically have read-only rights in all of Active Directory. The member set depends on the forest history, but since Windows 2003 the only default member is Authenticated Users.

I noticed that Authenticated Users had a curly red arrow on it, which means that it is a Foreign Security Principal (FSP). This suddenly struck me as strange. Why would the Pre-Windows 2000 Compatible Access group have Authenticated Users from another forest? The customer noticed me looking and inquired what was going on :) So, I promised to find out.

A Foreign Security Principal is needed when you have a group that has members of another, trusted forest. The FSP is a small placeholder object that holds only one bit of information: the SID of the foreign group. Using this SID, Windows can resolve its friendly name using the trust relation when this is needed by tools like Active Directory Users and Computers. To view FSPs, open ADU&C, enable advanced mode, and look for a container called ForeignSecurityPrincipals at the root of the domain. In advanced mode you can view and inspect the FSPs. Whenever a foreign group is first added to an AD group, AD will create the required FSP object. No manual action is ever needed here.

When you add a member to a group, you are really using the attribute "member". Let's look at the member attribute in a bit more detail. The Active Directory schema defines what member should look like: it is a linked multivalued attribute, and the data must be of type Object(DS-DN). Let me quote you what this means:

String that contains a distinguished name (DN). For attributes with this syntax, Active Directory handles attribute values as references to the object identified by the DN and automatically updates the value if the object is moved or renamed.

So the content of member must be a distinguished name (DN), and not only that: Active Directory promises to keep the DN valid if its target moves. So if you move a users that is member of a group, the DN of the user changes, but the value of the DN in the member attribute is updated automatically. The key point: the member attribute must contain a DN that points to a valid, existing object.

Now we get to the core of the problem. You need to add Authenticated Users to a group. But Authenticated Users is not a normal group. It's not a group at all. You can't find it as an object anywhere in the domain. It is one of the well-known SIDs as explained in this well-known article: https://support.microsoft.com/en-us/kb/243330. And that is the issue: the member attribute requires an existing, real object, not some phantom reference. The solution: abuse the Foreign Security Principal mechanism.

The following screenshot is from my lab where I added a number of well-known SIDs to a group:

When you add a well-known SID as a member to a group, Active Directory will at that point create an FSP object to match this group. This satisfies the condition that an object must exist in order to have a valid DN reference. Once the FSP exists, you should not remove it for that same reason: if you remove an FSP object the valid DN condition is no longer satisfied, and AD will remove the DN from all the groups that it is member of. You should only remove an FSP when you are sure it is no longer in use.

Verifying usage of an FSP is not difficult. Open ADU&C in advanced mode, open the properties of the FSP you want to check on, select the Attribute Editor, set its filter to include backlinks, and read the memberOf attribute. The example below shows that the FSP for Authenticated Users should not be removed:

Coming back to the original question: is it normal to have FSP references for well-known SIDs? Yes it is, and these references are completely unrelated to any trust relations that may or may not exist.