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.
I am currently reading John Craddock and Salley Storey’s book Active Directory Forestry. It is a very good read, and I can recommend it highly.
Anyway, I discovered something interesting. The book mentions some attributes of the RID Set object of Domain Controllers, specifically the rIDNextRID attribute of that object. rIDNextRID holds the value of the RID that will be given to the next object created on that domain controller. On my DC that value was 1130. Just for fun I created a new user and checked the value of rIDNextRID, only to discover that it had jumped two values insted of one, to 1132. This was a lone DC and no other objects had been created at the same time, so that was not the reason. I checked the SID of the newly created user and discovered that it had a RID of 1131. So which object had the 1130 RID?
I searched the forest for that SID and the search returned 0 objects. But then I asked LDP to return deleted objects as well, and then I got a match. The object with RID 1130 had been deleted at nearly exactly the same time that my test user had been created. The deleted object also had been named exactly the same as my test user. What had happened?
The answer was that when I created my test user I specified a password that did not meet the password requirements of my domain. You complete the create user wizard completely before you get that error from the directory service. So what happened was that the user had been created in the directory, but had been immediatley deleted by the system when it was found that the password did not meet the policy.
In the user interface I could simply click the back button and reenter a new password. That however triggered the creation of a new user, identical to the first one, but now with a compliant password.
I found this to be an interesting quirk and a nice insight into how the administative tools work.
Group sAMAccountType groupType systemFlags isCriticalSystemObject
——————————————————————————
Built-in 536870912 -2147483643 -1946157056 Yes
DL 536870912 -2147483644 <Not Set> <Not Set>The groups in the Builtin container may look like ordinary Domain Local groups, but they are not. In Windows Server 2003 Active Directory they are listed as Builtin Local.
These groups cannot be used on other machines in a domain when the domain is in native mode (as can other Domain Local groups in native mode).
The builtin groups are only valid on Domain Controllers.
<— From ADSI SDK : Start ————————————————————————>
The groupType attribute in Active Directory contains the group type definition:
ADS_GROUP_TYPE_GLOBAL_GROUP
ADS_GROUP_TYPE_DOMAIN_LOCAL_GROUP
ADS_GROUP_TYPE_UNIVERSAL_GROUP
ADS_GROUP_TYPE_SECURITY_ENABLED
The first three flags specify the group scope.
The ADS_GROUP_TYPE_SECURITY_ENABLED flag indicates the type of the group. If this flag is set, the group is a security group. If this flag is not set, the group is a distribution group.ADS_GROUP_TYPE_GLOBAL_GROUP = 0x00000002
ADS_GROUP_TYPE_DOMAIN_LOCAL_GROUP = 0x00000004
ADS_GROUP_TYPE_LOCAL_GROUP = 0x00000004
ADS_GROUP_TYPE_UNIVERSAL_GROUP = 0x00000008
ADS_GROUP_TYPE_SECURITY_ENABLED = 0x80000000
ADS_GROUP_TYPE_GLOBAL_GROUP
Group that contains only accounts and other account groups from its own domain.
This group may be exported to a different domain.
ADS_GROUP_TYPE_DOMAIN_LOCAL_GROUP
Group that can contain accounts and universal groups from any domains. It may not be included in either access-control lists of resources in other domains or groups other than global groups in the same domain.
ADS_GROUP_TYPE_LOCAL_GROUP
This flag is for the WinNT provider as the
ADS_GROUP_TYPE_DOMAIN_LOCAL_GROUP flag is for the LDAP provider.
ADS_GROUP_TYPE_UNIVERSAL_GROUP
Group that can contain accounts and account groups from any domains, but not domain local groups.
ADS_GROUP_TYPE_SECURITY_ENABLED
Group that is security enabled. This group can be used to apply an access-control list on an ADSI object or a file system.
<— From ADSI SDK : End ————————————————————————–>
In reality there exists a fifth group type:
ADS_GROUP_TYPE_BUILTIN_LOCAL_GROUP = 0x00000001
These groups can only be security enabled, and when they do, they have a groupType attribute with the value -2147483643.
