RSS All Posts

RSS PowerShell Posts

Tags

2142 Active Directory Administrativia Announcements Battlefield Blogging Cricket Deployment Deployment4 Get-PSUGUK Group Policy HowTo Linux MDT MDT 2010 Microsoft Deployment Toolkit MSDN Music Permissions Personal PowerGui Power Lines PowerShell PowerShell Groups PowerShell Support PowerShell Tools PowerShell V2 Presentations PSUGAU Quick Tips Scripting SDDL Security Tech Talk Ubuntu User Groups Virtualisation VMware Infrastructure Client WAIK Weekly Poll Windows 7 Windows Automation Installation Kit Windows Server 2003 Windows Server 2008 XML

Archives

Meta


« | Main | »

Setting Filesystem permissions using SDDL format

By Adam Bell | January 23, 2007

When it comes to setting the permission on the filesystem there has already been some interesting conversation between Tony (MSHforFun blog) and Marc (MOW):
http://mshforfun.blogspot.com/2005/12/play-with-acl-in-msh.html

This is fine if you want to add your ACE into an existing DACL. But what if you want to completely overwrite the DACL and “roll-your-own”? I posed this question on the MS Powershell newsgroup recently, and the reply was spot on (cheers Rob!). Basically you need to specify the DACL in SDDL format.

After about half a days googling for information on SDDL I found a few URL’s that provide some good information on the subject. I have posted the links on the Further Reading page (I’m having a few link issues here *sighs*. Spot the n00b!)
OK, so let’s try it out:

:replace-acl function


function replace-acl
{
Param (
  $sObject,
  $sSDDL
  )
  $acl = Get-Acl $sObject
  $acl.SetSecurityDescriptorSddlForm($sSDDL)
  
  Set-Acl -aclObject $acl $sObject
}
replace-acl "d:\" "O:BAG:BAD:AI(A;OICI;0x1301bf;;;AU)(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)"

Basically we’re passing the function the folder we want to apply the permissions to, and then our complete DACL in SDDL format.
The first portion of the SDDL sets the Owner as Builtin-Administrators (O:BA), the POSIX compliant group to the same (G:BA) and the 3 ACE’s with the inherit flag on, and : Builtin-Administrators FullControl, System FullControl, and AuthenticatedUsers with a hex flag set, which equates to Modify.

The DACL will cascade down the directory tree to any child folders, which is great. However if any of these children have manual ACE’s added, or if inheritence has been turned of (by the inherit from parent flag being unticked) then the permissions will either merge in the case of the former, or not be applied at all in the case of the latter.

This can be rectified with a simple get-children function:

:flush-acl function


function flush-acl
{
Param (
  $sObject
  )
 
  $col = Get-ChildItem $sObject -Recurse
  foreach ($item in $col)
  {
  
    replace-acl $item.FullName "O:BAG:BAD:"
    
  }
}
flush-acl "d:\"

I’ve found that by rewriting the DACL on each child folder, with just the Owner and Group information has the effect of dropping the existing manual ACE entries, and the bonus of turning the inheritence back on again. By applying the flush function and then replacing the DACL at the required level is a very effective way of repermissioning a directory tree, knowing that there’s no hidden surprises further down the tree!

Topics: PowerShell | 2 Comments »

2 Responses to “Setting Filesystem permissions using SDDL format”

  1. /\/\o\/\/ Says:
    January 24th, 2007 at 01:02

    Hi Adam,

    nice post !

    glad we got you started

    Did you find this post also ?

    http://mow001.blogspot.com/2006/05/powershell-import-and-export.html

    the post goes about share sercurity but in the importscript I use this way also to create the directories.
    As could be a bit hard to find on my old blog, the google search at the bottom mostly works best

    Greetings /\/\o\/\/

  2. AdamBell Says:
    January 24th, 2007 at 11:31

    Cheers MOW. I will have a look at the link you posted. I’m always interested in delving deeper into PS,and I find your blog very useful for that.

    With the release of PS I can see the boundaries between scripter and coder starting to blur as scripters have more reach now. Maybe that’s just my perception/limitation but I can already see that I’m starting to understand the basics of .NET classes and I can only imagine that this will grow through more use.

    I believe this will be compounded by the position MS have taken with PS and Exchange 2007. I hear that Quest are already following suit by providing access to their product suite via PS!

    Time will tell ;)

    Cheers

    Adam

Comments