GuidesScripting NTFS permisions with ADSI (Part 1)

Scripting NTFS permisions with ADSI (Part 1)

ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.





by Marcin Policht

In his latest article, Marcin Policht illustrates how the Active Directory Services Interface (ADSI) can be used to manipulate permissions on the NTFS file system level.

Active Directory Services Interface is typically used for management of various account repositories, such as Windows NT SAM database, IIS

Metabase, or LDAP-based directories such as AD or NDS. However, the capabilities of ADSI go far beyond simple group and user account manipulation. For

example, ADSI can be used to manipulate permissions on the NTFS file system level.

In order to understand the mechanism that ADSI uses to accomplish this task, we need to take a closer look at the way the Windows operating system

secures its components. Information about security settings of an object (this applies to the NTFS file system, the Windows Registry, or Active Directory

objects) is stored in a structure called Security Descriptor.

Security Descriptor for an object contains some or all of the following information:

  •  Security identifier (SID) of a user who owns the object.
  •  Security identifier (SID) of a group which owns the object (typically this is the primary group of the object’s owner).
  •  Discretionary Access Control List (DACL), consisting of multiple Access Control Entries (ACE), which determine access rights assigned on the object.
  •  System Access Control List (SACL), determining how the system audits the object’s access. Its format is similar to DACL – each entry specifies the SID of a user or group and its associated auditing criteria.
  •  Control flags – affect additional aspects of the security descriptor (such as permission inheritance in case of DACL or success or failure audit in case of SACL)

An access control entry consists, in turn, of several subentries:

  •  A SID of a security principal (such as a group or a user) to which the entry applies.
  •  An access mask (represented by the sequence of bits) defining access permissions for the security principal (such as read, write, execute, take ownership, set permissions, etc.).
  •  Sequence of bits determining type of access permissions (allow or deny – in case of DACL entry).
  •  Sequence of bits determining the inheritance level for this particular entry (e.g. when applied to a folder, this flag would determine whether

    permissions apply to this folder only, or to subfolders and files as well).

The graphical representation of these settings can be viewed by launching Windows Explorer and checking the properties of a file or folder. After

selecting Security Tab, click on the Advanced button and you will see the list of Access Control Entries presented in a friendly fashion.

Dealing with ACEs, DACLs, and SACLs using scripting (or programming) is a fairly difficult task because the objects used to represent structures

described above are rather complex. Also, even small mistakes when changing permissions on file system, registry, or Active Directory objects can

have serious implications, so make sure you test your scripts appropriately.

Fortunately, Microsoft provides a number of samples documenting the way to manipulate permissions via scripting (programming methods are

extensively documented in the MSDN Library at msdn.microsoft.com). The Knowledge Base article Q279682 “How to Use ADsSecurity.dll to Add an Access Control

Entry to an NTFS Folder” outlines such a procedure. However, the sample code sets permissions on a folder level only, and the changes do not

propagate to any of its subfolders. The reason for this is the fact that the SetSecurityInfo API function (contained in ADsSecurity.dll, which is used

by the script) fails to propagate inheritable ACEs to any of the subfolders. Q266461 “How to Use ADSI to Set Automatic Inheritance of File/Folder

Permissions” describes a workaround for this.

In order to be able to manipulate Security Descriptors through scripting, you will need to start by obtaining AdsSecurity.dll, which is available

as part of ADSI Software Development Kit (available at http://download.microsoft.com/msdownload/adsi/2.5/sdk/x86/en/Sdk.zip). Alternatively, you

can use Platform SDK, which on one hand will give you the most recent information, but on the other hand, it will force you to go through a lengthy download process (the core SDK itself is 321.7 MB). You also have an option of ordering a CD; for details, refer to
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/.

Once you get the copy of ADsSecurity.dll, copy it to your %Windir%System32 directory and register by running

REGSVR32.EXE ADsSecurity.DLL from the command prompt.

In order to fully understand the structure of a Security Descriptor (and ultimately to be able to write scripts that change it), you will need to

become familiar with a number of constants used in setting ACE masks (affecting permissions), ACE flags (affecting inheritance), and ACE types

(determining whether ACE mask is used for allowing or denying access).

The format of access masks and the listing of constants are available at msdn.microsoft.com but since you are risking an information overload by

accessing it, here is an abbreviated version:

The following are relevant constants that can be used to analyze the
granular permissions assigned to files and folders by setting appropriate

access masks:

  •  ‘*** bit indicating permission to read data from file or list
    contents of directory

    ‘*** corresponds to List Folder / Read Data permissions in Windows UI

    const FILE_READ_DATA = &h1 ‘bit number 0

    const FILE_LIST_DIRECTORY = &h1 ‘bit number 0
  •  ‘*** bit indicating permission to write data to file or
    create file in directory

    ‘*** corresponds to Create Files / Write Data permissions in Windows UI

    const FILE_WRITE_DATA = &h2 ‘bit number 1

    const FILE_ADD_FILE = &h2 ‘bit number 1
  •  ‘*** bit indicating permission to append data to file or to
    create subdirectory

    ‘*** corresponds to Create Folders / Append Data permissions in Windows
    UI

    const FILE_APPEND_DATA = &h4 ‘bit number 2

    const FILE_ADD_SUBDIRECTORY = &h4 ‘bit number 2
  •  ‘*** bit indicating permission to read extended attributes

    ‘*** corresponds to Read Extended Attributes permissions in Windows UI

    const FILE_READ_EA = &h8 ‘bit number 3
  •  ‘*** bit indicating permission to write extended attributes

    ‘*** corresponds to Write Extended Attributes permissions in Windows UI

    const FILE_WRITE_EA = &h10 ‘bit number 4
  •  ‘*** bit indicating permission to execute file or traverse
    directory

    ‘*** corresponds to Traverse Folder / Execute File permissions in
    Windows UI

    const FILE_EXECUTE = &h20 ‘bit number 5

    const FILE_TRAVERSE = &h20 ‘bit number 5
  •  ‘*** bit indicating permission to delete directory and all
    files it contains

    ‘*** corresponds to Delete Subfolders and Files permissions in Windows
    UI

    const FILE_DELETE_CHILD = &h40 ‘bit number 6
  •  ‘*** bit indicating permission to read file or folder
    attributes

    ‘*** corresponds to Read Attributes permissions in Windows UI

    const FILE_READ_ATTRIBUTES = &h80 ‘bit number 7
  •  ‘*** bit indicating permission to change file or folder
    attributes

    ‘*** corresponds to Write Attributes permissions in Windows UI

    const FILE_WRITE_ATTRIBUTES = &h100 ‘bit number 8
  •  ‘*** bit indicating permission to delete file or folder

    ‘*** corresponds to Delete permissions in Windows UI

    const DELETE = &h10000 ‘bit number 16
  •  ‘*** bit indicating permission to read security descriptor

    ‘*** corresponds to Read Permissions permissions in Windows UI

    const READ_CONTROL = &h20000 ‘bit number 17
  •  ‘*** bit indicating permission to change discretionary ACL

    ‘*** corresponds to Change Permissions permissions in Windows UI

    const WRITE_DAC = &h40000 ‘bit number 18
  •  ‘*** bit indicating permission to assign owner

    ‘*** corresponds to Take Ownership permissions in Windows UI

    const WRITE_OWNER = &h80000 ‘bit number 19
  •  ‘*** bit indicating permission to perform synchronize
    operation, used sometimes during file access

    ‘*** this permission is automaticaly granted with read and write access
    and revoked when read or write access is denied.

    ‘*** it is not displayed in the list of permissions in Windows UI

    const SYNCHRONIZE = &h100000 ‘bit number 20

Handling these individual permissions is typically not needed, since they tend to be assigned on a less granular level, at least when dealing with

file system permissions (controlling access to Active Directory objects is much more complex). Therefore, it might be more efficient (and easier)

to consider simply four types of basic access rights:

  •  Full Control
  •  Change
  •  Read
  •  No Access

Here’s how these types of access rights translate into a combination of access mask bits. Each needs to be considered in combination with the value

of the ACE type:

  •  NTFS Full Control file permissions consist of the following access masks (111110000000111111111 in binary or 2032127 in decimal)

    Ace Type:

    ACCESS_ALLOWED

    ACE Mask:

    FILE_READ_DATA

    FILE_WRITE_DATA

    FILE_APPEND_DATA

    FILE_READ_EA

    FILE_WRITE_EA

    FILE_EXECUTE

    FILE_DELETE_CHILD

    FILE_READ_ATTRIBUTES

    FILE_WRITE_ATTRIBUTES

    DELETE

    READ_CONTROL

    WRITE_DAC

    WRITE_OWNER

    SYNCHRONIZE

  •  NTFS Change file permissions consist of the following access masks (100110000000110111111 in binary or 1245631 in decimal)

    Ace Type:

    ACCESS_ALLOWED

    ACE Mask:

    FILE_READ_DATA

    FILE_WRITE_DATA

    FILE_APPEND_DATA

    FILE_READ_EA

    FILE_WRITE_EA

    FILE_EXECUTE

    FILE_READ_ATTRIBUTES

    FILE_WRITE_ATTRIBUTES

    DELETE

    READ_CONTROL

    SYNCHRONIZE

  •  NTFS Read file permissions consist of the following access masks (100100000000010101001 in binary or 1179817 in decimal)

    ACE Type:

    ACCESS_ALLOWED

    ACE Mask:

    FILE_READ_DATA

    FILE_READ_EA

    FILE_EXECUTE

    FILE_READ_ATTRIBUTES

    READ_CONTROL

    SYNCHRONIZE

  •  The following listing illustrates access masks for NTFS deny read file permissions (000100000000010101001 in binary or 131241 in decimal)

    ACE Type:

    ACCESS_DENIED

    ACE Mask:

    FILE_READ_DATA

    FILE_READ_EA

    FILE_EXECUTE

    FILE_READ_ATTRIBUTES

    READ_CONTROL

    Note that since this listing refers to ACCESS_DENIED Ace type, the SYNCHRONIZE permission is missing (comparing with the previous set of entries).

In my next article, I’ll provide a script which will allow you to display the content of DACL (ACE entries) for arbitrarily chosen files or folders.

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends & analysis

Latest Posts

Related Stories