Security Identifiers (SIDs) and NT Account name

Adam Bell — Mon, 26 Mar 2007 19:17:42 +0000

I have a couple of functions that are quite useful when dealing with Active Directory permissions.

Translate SID to NT Account:
:get-NTaccount.ps1



#----------------------------------------------------------------------------------------------------------

function get-NTaccount

#----------------------------------------------------------------------------------------------------------

{

Param (

  $SID

  )

  $id = New-Object System.Security.Principal.SecurityIdentifier($sid)

  $account = $id.Translate( [System.Security.Principal.NTAccount] )

  return $account

}

 

#----------------------------------------------------------------------------------------------------------

get-NTaccount "S-1-5-21-812403740-544655063-2921696178-1958"

In this function we take a SID in string format, and cast it as a SecurityIdentifier and then use the .Net method to translate this into the NT Account name.

Translate NT Account to SID:
:get-SID.ps1



#----------------------------------------------------------------------------------------------------------

function get-sid

#----------------------------------------------------------------------------------------------------------

{

Param (

  $DSIdentity

  )

  $ID = new-object System.Security.Principal.NTAccount($DSIdentity)

  return $ID.Translate( [System.Security.Principal.SecurityIdentifier] ).toString()

}

 

#----------------------------------------------------------------------------------------------------------

get-sid "bella"

This is basically the same premise as above, only we are working the other way around. If you provide a name without a domain prefix or UPN, the method presumes the current domain.

So with our Test OU, you can output the SDDL format of the Security Descriptor to a text file to examine the permissions.
:noclick



$root = [adsi]""

$test = [adsi]("LDAP://ou=test ou,"+$root.distinguishedName)

$test.psbase.get_objectsecurity().GetSecurityDescriptorSddlForm("All") > DS-SDDL.txt

When you start playing around with Security Discriptors, and examining various permissions structures, it quickly becomes very useful to be able to translate SID’s back and forth to confirm things are working as expected.

Setting Filesystem permissions using SDDL format

Adam Bell — Tue, 23 Jan 2007 22:20:00 +0000

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!

Lead, Follow, or Move » Permissions

Security Identifiers (SIDs) and NT Account name

Setting Filesystem permissions using SDDL format