Security Descriptor Reader

  Working with the highly sensitive information may require you to document ntfs permissions (including audit settings) a person has on a file or a folder. Creating a list of permissions once for a definite period of time may help track changes to a file or folder access mask and, in case of deliberate or undeliberate modifications, take appropriate actions. For this purpose I wrote the vbs script SecurityDescriptorReader.vbs (SecurityDescriptorReader – please copy/paste the content of the SecurityDescriptorReader.doc into SecurityDescriptorReader.VBS before use) that can read file security descriptor, including auditing settings and would like to offer it to you in this article.
    Let’s say we need to have a list of the ntfs permissions and the audit settings set on D:\Test\HR.txt.  All  we need to get a txt-file report (SDreport) with the ntfs permissions and the audit settings for that file is to run the script and supply a file/folder name. Now I will demonstrate the whole procedure in a step-by-step manner:
1) First let’s set the following set of permissions and the auditing mask:
(Administrators -Full Control, Users – Read and Execute)
2) Run the script:2
3) Type the D:\Test\HR.txt and press OK3
The warning message appears informing you the report will be saved in the C:\VBSreports folder (it will be created in case it does not already exist)
4) The report is created:
Let’s click “Yes” and see how the permission setting in 1) correlate with this report:
a) “Owner of the D:\Test\HR.txt is TestDom\User1″ – the owner of the file
b) “Object DACL is PRESENT” – ntfs permissions are present
c) “Object Audit is TURNED ON” – the audit has been set (SACL is present)
d) “SACL can be inherited” – means the “Include inheritable auditing entries from this object’s parent” option on the Auditing tab is checked:
e) DACL section:
   (“A discretionary access control list (DACL) identifies the trustees that are allowed or denied access to a securable object.”
In step 1 we set permissions for the two accounts: BUILTIN\Administrators and BUILTIN\Users. Here are the corresponding access masks:
AccessMask for Trustee BUILTIN\Administrators:
Write ACL
Read security
Write attributes
Read attributes
Delete dir
Write extended attributes
Read extended attributes
AccessMask for Trustee BUILTIN\Users:
Read security
Read attributes
Read extended attributes
DACL Ace Type shows which type of access the current access mask describes: Allowed or Denied (in our case both BUILTIN\Administrators and BUILTIN\Users have
ACCESS_ALLOWED_ACE_TYPE DACL Ace Type. If we denied, for instance, Execute permission for BUILTIN\Users we would have an extra DACL Ace Type set to ACCESS_DENIED_ACE_TYPE with the AccessMask set to Execute.
If we had any inheritable permissions set on the D:\Test\HR.txt we would also see the following DACL flag:
Permission have been inherited.
f) SACL section:
(“A system access control list (SACL) enables administrators to log attempts to access a secured object.”
Audit for trustee TestDom\Domain Users is TURNED ON – the account we added on the Audit tab
f-2) SACL FLAGS for trustee: TESTDOM\Domain Users
AUDIT Mask of the object D:\Test\HR.txt for Trustee TestDom\Domain Users is:
– means we want to audit the failed DELETE attemts for estDom\Domain Users
f-3) SACL FLAGS for trustee: TESTDOM\Domain Users
AUDIT Mask of the object D:\Test\HR.txt for Trustee TestDom\Domain Users is:
– means we want to audit successful Execute and Read access for TestDom\Domain Users also.
So after running this script for the D:\Test\HR.txt file we have a secuity descriptor report in C:\VBSreports\SDreport.txt. If we continue running the script for other files the corresponding reports will be appended to the C:\VBSreports\SDreport.txt file. Scheduling the script, for instance, on a monthly basis will allow you to track whether any of ntfs permissions on your most important files changed or not.
For unknown reasons running the script for a LOCAL file on Windows Server 2008R2/Windows7 will ALWAYS result in  SACL TYPE: TURNED OFF, even when the auditing is enabled! It won’t occur if the file supplied to the script is located on a mapped drive, so you can run the script on Win2008R2/Win7 and supply the file name in the form X:\[folder]\file, where X: is a mapped drive. It’s rather interesting that the folder to wich the drive (for example, X) is mapped can be located on Windows Server2008R2/Windows7 and in this case SACL information will be read correctly!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: