Problems With ACL Permission Inheritance (follow up)

Problems With ACL Permission Inheritance (follow up)

Post by ericmlegau » Wed, 03 Mar 2004 07:31:52


I have solved my previous problem. However, when setting generic
rights for a user (e.g. ADS_RIGHT_GENERIC_ALL or
ADS_RIGHT_GENERIC_READ), the specific rights for that user are only
visible in the Access Control Settings dialog (through the Advanced
button). All of the checkboxes are empty for that user in the
Permissions listbox on the Security tab.

For example, if I gave JoeB Full Control on FolderA, the Allow
checkbox for Full Control (and all others) are unchecked; clicking
Advanced shows the Permission Entries list in the Permissions tab, and
JoeB is listed as "Full Control" in the "Permission" column, and the
"Apply to" column says "Special".

Does this have anything to do with setting "objAce.AceFlags =
ADS_ACEFLAG_INHERIT_ONLY_ACE"? Or am I missing something else?

Or, since the permissions are effectively applied, is it a big deal
that the check boxes aren't being set and I should live with it
because it works? :-)

Eric Legault
 
 
 

Problems With ACL Permission Inheritance (follow up)

Post by maxv » Sun, 07 Mar 2004 03:19:05

This is a classic problem of trying to use the wrong Access Mask and Access
Flags for the wrong ACL type. The IADsSecurityDescriptor and its
associated interfaces were created for Active Directory objects. The
constants in the ADS* enumeration types used by the security interfaces are
for Active Directory objects.

The really cool thing is that these interfaces are scriptable and they may
things humanly readible and they can be easily adapted to other security
descriptors. It is very important to realize that their many different
types of security descriptors, each with their own specific sets of Access
Masks and Ace Flags. Below is a short list of the SDs I am aware of (
their may be more)

NTFS Files
File Shares
Registry Keys
Active Directory Objects
Exchange Objects

Each with their own ACLUI that allow you to create the appropriate ACEs for
that SD. If the ACL UI ( Access Control list UI) does not check the boxes
for a specific checkboxes for an ACE, the UI does not recognize the ACE as
one for that item. True, the ACE will work in most cases, however, in the
log term it can have some unintended consequenses. I had a customer that
was using the ADS* enumeration types to add ACEs to NTFS files. The ACEs
appeared to apply the appropriate permissions. Over time, these NTFS
Volume became corrupted and they had to reset the ACLs on the files. We
changed thier code to add aces for files that the ACLUI for NTFS files
recognized, and they have not had any additional NTFS volume corruption.
We could not direclty tie the old way of making aces to the probem, but
changing their code made the problem go away.

If you are using the ADSI to add ACEs to an ACL, make sure that you ace is
marked appropriatly in the ACLUI of the target object. In you case, the
NTFS ACLUI should recognize the ACE you are adding programmatically.

For a list of NTFS file Acess masks and Ace Flags, take a look at the
WinNT.H header file.

Generally, when I want to add an ACE programmatically for a specific set of
permissions, I add the test ACE through the ACLUI for the object, then I
dump the ACL and locate the ACE the UI created. I then use the information
from that dumped ACE to as a template to write my code for the ACE I want
to add.

Hope this helps...

Sincerely,
Max Vaughn [MS]
Microsoft Developer Support


Disclaimer: This posting is provided "AS IS" with no warranties, and
confers no rights. You assume all risk for your use.