Tag Archives: VBS script

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)   1
1-1
1-3
2) Run the script:2Type the D:\Test\HR.txt and press OK
3)3
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:
4
  
Let’s click “Yes” and see how the permission setting in 1) correlate with this report:
SDreport
  
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:
  
1-4
  
e) DACL section:
   (“A discretionary access control list (DACL) identifies the trustees that are allowed or denied access to a securable object.”
http://msdn.microsoft.com/ru-ru/library/windows/desktop/aa374872%28v=vs.85%29.aspx)
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:
————————————————————————————————————-
Synchronize
Write ACL
Read security
Delete
Write attributes
Read attributes
Delete dir
Execute
Write extended attributes
Read extended attributes
Append
Write
Read
  
AccessMask for Trustee BUILTIN\Users:
————————————————————————————————————-
Synchronize
Read security
Read attributes
Execute
Read extended attributes
Read
————————————————————————————————————-
  
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:
DACL ACE FLAGS:
Permission have been inherited.
VALID_INHERIT_FLAGS
————————————————————————————————————-
  
f) SACL section:
(“A system access control list (SACL) enables administrators to log attempts to access a secured object.”
http://msdn.microsoft.com/ru-ru/library/windows/desktop/aa374872%28v=vs.85%29.aspx)
  
f-1) SACL TYPE:
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_FAILED_ACCESS,
AUDIT Mask of the object D:\Test\HR.txt for Trustee TestDom\Domain Users is:
  
Delete
  
– means we want to audit the failed DELETE attemts for estDom\Domain Users
  
f-3) SACL FLAGS for trustee: TESTDOM\Domain Users
  
AUDIT_SUCCESSFUL_ACCESS,
AUDIT Mask of the object D:\Test\HR.txt for Trustee TestDom\Domain Users is:
  
Execute
Read
  
– 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.
  
Attention!
  
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!
Advertisements