In recent several projects, our team have dealing with Programming by Active Directory Service Interface more and more frequently than ever, I feel obligated to present the AD Programming to you, just for your reference, or maybe a little helpful. And the basic Active Directory manipulate code had already in using, which I will not interpret here, I find an interesting stuff happened when I was fixing an issue of a utility for export certain users of certain permission. Here I want to illustrate how the Active Directory Service encapsulating the authorization to every each objects which hold in Active Directory, and how we manipulating the security access could rules in a special programming way.
Actually, the whole passage was an email which sends to Towngas IT Business Solution leader for reference.
Hi, Jason
I got your email, and I know what exactly happened there, I knew this issue going to happen.
Now, let me decipher this issue step by step, and I need you and your AD admin see this.
The answer of this problem is I couldn’t export those person who have the certain permission (here is write/read members) by which inherited the superior, parent or base (something like that) authorize permission, but only the permission granted by AD admin manually.
In the first place I would like to interpret how the AD object organized in ADSI, here especially the Group object in AD: In AD, all the detail of a group object exists as binary, but with architecture as well, So, in a programming way, we exact those binary and reform it to a .NET available object, and this was just ADSI COM provided for us, and we manipulate AD in this way all the time. And the AD Group objects I illustrated like below:
This Group Object has a particular Security object except those common attributes. And in this Unique Object(each AD group Object got its own security object), it include an ActiveDirectoryAccessRule collection, which include detail security rules, and each ActiveDirectoryAccessRule consist of ‘Ojbect Type’,’IdentityReference’, and other attributes used to describe certain Rules. Each ActiveDirectoryAccessRule may like this:
The two special attributes I want to emphasize here: Object Type and Identity Reference.
ObjectType is a Guid Object, and Active Directory somehow using this GUID to perform security control and other authentication stuff.
IdentityReference is a String, actual it is a LongonName, which belong to one of the AD objects (Every AD object have a longon Name, right?)
So, we have clear mind right now: the AD using this way to control an AD object permission.
Let’s take it further step interpretation:
In our case, we want to export entire group member with Read/Write members, this is an ActiveDirectoryAccessRule, right?
Actually, I find this rule Ojbect Type is:’ bf9679c0-0de6-11d0-a285-00aa003049e2’, and the Reference is somewhat logonName ‘VSTS\Slevin’(just for example). And by study, the Read/Write Members Object type is a constant value in AD all over the world, no matter where and when, this value never change as long as the AD service is come from the Microsoft. What I pursuit is trying to compare all the ActiveDirectoryAccessRule’s Object Type to filter this constant GUID (bf9679c0-0de6-11d0-a285-00aa003049e2), and get the IdentityReverence relative to the special Read/Write members Object Type.
And by the IdentityReferenct via LogonName, we could retrieve the user’s information easily.
OK, now let’s get on our problem. The thing goes like this:
1, I create one group named ‘APJ- InheritancePermission’ and another group named ‘APJ- ManullyGrantPermission’
Now I using my program to exact the ActiveDirectoryAccessRule for two of them
The front part is GUID which is Object Type, and the end of each line is the IdentityReference. You may curiosity about what is ‘S-1-5-32-548’ and ‘S-1-5-32-560’, acutally this is a special key for derived permission identity.becasue these two group was not in the root of AD, it derived permission from ‘IT Workstations Admin’ OU.
2, I add someone (Chia Gary C.G.) for security control for the two groups.
And both group grants Read/Write permission to ‘Chia Gary C.G.’ Now let’s see what happened to the access rules of the two group?
Here is the result:
Well, we can see clearly we grant Read/Write Permission to ‘Chia Gary C.G.’ , but why the Object Type for the user still ‘00000000-0000-0000-0000-000000000000’ ?
It is supposed to be ‘bf9679c0-0de6-11d0-a285-00aa003049e2’, right? Let's put it aside and do the next step.
We open the Advanced Security Settings for APJ- ManullyGrantPermission Group:
And Edit the Permission Entries for ‘Chia Gary C.G.’ Open the properties tab, the read member and write member item are perfectly ticked, why the AD Access Rule left Object Type empty(‘00000000-0000-0000-0000-000000000000’)? The answer is: this access rule are derived from the Group level, but here, if we tick out the Read members and write members entries, and tick the two entries back. And now the Access Rule turns to:
Then, we can see there are too many access rules there for ‘Chia Gary C.G.’ Here we go, we have ‘bf9679c0-0de6-11d0-a285-00aa003049e2’ Object Type Now!
Here is why I can’t export some group member appeared to have Read/Write Members, but actually this permission is grant from Group level ,not the Access Rule level. I only could export the access rule level permission.
By reading through this passage, the Group Object inner fabric is only an example for presenting a conceptual model which all the AD object could been have, and the essential information I want spread here is the Security Access Rule, how it contained in an ADSI COM object, what genesis of it come from, how does Active Directory controlled every single object which kept in it. When we start to design our own security object, dose this schema could provide us any fresh idea to make our own model more secure or more easily to control?
Subscribe