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:
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
Group that contains only accounts and other account groups from its own domain.
This group may be exported to a different domain.
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.
This flag is for the WinNT provider as the
ADS_GROUP_TYPE_DOMAIN_LOCAL_GROUP flag is for the LDAP provider.
Group that can contain accounts and account groups from any domains, but not domain local groups.
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.