In Active Directory there is something called linked attributes. They exist in pairs, consisting of a forward-link and a back-link. The linked attribute pair member, of Group objects, and memberOf, of User or Groups is an example. In this particular case member is the forward-link and memberOf is the back-link. Back-links are always calculated automatically by the system whenever an attribute that is a forward-link is modified. If you change the member attribute of a group and add another object, the groups DN is automatically added to the memberOf attribute of the object you added.

I wanted to find out a little more about how this worked so I created a couple of scripts to do some testing. Specifically I wanted to see if I could write directly to a back-link attribute.

The first script tried to do that. It connected to an object in the directory and tried to write the DN of a group into the memberOf attribute. That failed with the error:

Code: 80072035
Error: The server is unwilling to process the request.

The next script connected to a group and added a user to it. As expected, that worked. I examined the user I added to the group in ADSI Edit and the back-link memberOf had been correctly computed. From that I can draw the conclusion that the computing of back-links is implemented in the DSA itself and not in the Admin tools (I was using a script, not ADUC, remember).

Next, I tried to edit the memberOf attribute of the user I had just added to the group directly in ADSI Edit. That provided the last piece of the puzzle and a conclusive answer to my question. Because that failed with the following error:

Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM).

So that was it. You cannot write to the back-link of a linked attribute pair. The back link is always automatically calculated and added by the system.

Also, the calculation and updating of a back-link attribute does not qualify as a change of the object. When I added a user to a group, only the group’s whenChanged attribute was updated. The user’s remained unchanged. That means that it is always the group object that is modified when you add a user to it. This seems obvious, but consider that you can also do this from the user’s properties on the Member Of tab. What you are actually doing is editing the group object, not the user.

Ain’t Active Directory fun!