While working on an ACL coding issue I realized that there was some info that I had intended to put into chapter 26 of Active Directory Third Edition that I seem to have spaced on and forgot to add (that or I spaced when looking for it). It involves special options for reading/writing the Security Descriptor (SD).
The SD is a special attribute in that it is handled specially. 🙂 It is handled specially because there are several pieces of info in the SD and different folks should be able to deal with the different pieces of it. It isn’t broken up into separate attributes because the mechanisms for working with it across all securable objects (files, mutexes, processes, etc) all use the same format and it is one blob (binary large object – block of binary values) for all of them.
First a quick look at a security descriptor
A security descriptor is made up of several main pieces of info and some other stuff. The main pieces are
Owner – The owner of the object. This is the security principal that has the ability to modify the access rights to the object no matter what permissions are in place.
DACL – This is the Discretionary Access Control List. It is a list of Access Control Entries (ACEs) describing the types of access granted to the object and who has those access rights. For instance, joe is allowed to see the secret info in this object. Dean is not allowed to see the secret info in this object.
SACL – This is the System Access Control List. It is a list of ACEs that describe the auditing configured for a given object. For instance, log a message when joe actually goes and looks at the secret info or when Dean tries to see the secret info.
So now you have all of this info for this one attribute and there are special non-LDAP rules on what can be done with it and who can do what. For instance, if I am a normal user with take ownership rights on the object, I can write myself to the owner portion of the SD but not someone else. If an I am a full admin, I can write what I want (mostly) and see all of the attribute. If I am a normal user with write permissions access over the object I can write the DACL but not the SACL and in actuality I can’t even SEE the SACL, etc etc etc.
So because of this you need special controls around the attribute. Specifically you need the ability to tell it what pieces of it you want to return or to update. The methods used to handle this depend on whether you are using ADSI or a real programming API… Haha. Just kidding.
With the LDAP API you need to set up an LDAP Control to submit with the query/update request. The specific control is the LDAP_SERVER_SD_FLAGS_OID control. It takes a bitflag indicating which pieces of the SD you want to work with. You can specify any combination of Owner, Group, DACL, and SACL. This is actually relatively simply to do, for more info and a c code example check out
With ADSI it is fairly similar, you need to play with the IADsObjectOptions interface and set the ADS_OPTION_SECURITY_MASK with the value of the portions of the SD you need to work with. You can see the specifics here
and
