Goatee PFE

Blog of Microsoft Premier Field Engineer Ashley McGlone featuring PowerShell scripts for Active Directory.

PowerShell: SID Walker, Texas Ranger (Part 1)

PowerShell: SID Walker, Texas Ranger (Part 1)

  • Comments 6
  • Likes

SID Walker

First things first:

  1. If Chuck Norris wrote a PowerShell script it would be a one-liner, because Chuck Norris can do anything in one strike.
  2. Chuck Norris does not have SID history, because there is only one Chuck Norris.
  3. Chuck Norris' ACL only has one ACE: Chuck Norris – Full Control.

Do you remember SIDWALK?  This resource kit utility was written back in the NT 4.0 days to assist with domain migrations.  It used a mapping file to rewrite old SIDs with new SIDs across ACLs in a number of areas:  files shares, printer shares, registry paths, NTFS permissions, etc.  That utility is a teenager now (born 1998).  It's time we rewrite this and bring it up to date… in PowerShell.

Sidwalk V1.0
Copyright (C) 1998 Microsoft Corporation
Usage: Sidwalk <profile file> [<profile file> ..] [/t /f [<path>] /r /s /p /g /l <file>]

In part one of this series we will learn how to parse SIDs out of SDDL that we receive from Get-ACL.  This handy cmdlet works with many of these permissions.  Once we get the SIDs parsed out of SDDL, a future post will walk us through swapping them out and updating them.

Why SID Walker?  Why PowerShell?

One of my favorite Active Directory topics is SID history and its impact on token size.  In my former post I discussed creating a SID mapping file by querying SID history data from AD.  Eventually I plan to release a PowerShell module for remediating token size issues due to SID history.  This series on SID translation will be the centerpiece of that module.

Whether you are doing a domain migration, cleaning up SID history, or doing a search-and-replace for a group migration project this script will become your BFF.

Terms of Security

Most of us already know these terms, but let me define a few of these up front for anyone who is not familiar with them:

  • ACLAccess Control List – This is the list of permissions on a resource (file, folder, registry key, etc.).  ACLs contain ACEs.
  • ACEAccess Control Entry – This is an individual permission entry on an ACL.  An example would be TEXAS\cnorris Allow FullControl.
  • SDDLSecurity Descriptor Definition Language – This is a short-hand string that represents the entire ACL in a single, encoded string.  See MSDN for the specifics.
  • SIDSecurity Identifier – This is the unique security GUID that is assign to all security principles in a domain (users, computers, groups).  SIDs live in ACEs to represent the users who get the access.


Editing ACLs with VBScript was a royal pain, but now we have the Get-ACL and Set-ACL cmdlets in PowerShell.  Setting and getting permissions on the file system, registry, and even AD organizational units has become a one-liner.  Look at the sample output for Get-ACL below:

PS C:\Users\ashley> Get-ACL | gm

TypeName: System.Security.AccessControl.DirectorySecurity

Name            MemberType      Definition
----            ----------      ----------
Access          CodeProperty    System.Security.AccessControl.Auth...
Sddl            CodeProperty    System.String Sddl{get=GetSddl;}
AccessToString  ScriptProperty  System.Object AccessToString {get=...

<<output trimmed>>


PS C:\Users\ashley> Get-ACL | fl *

PSPath                  : Microsoft.PowerShell.Core\FileSystem::C:\Users\ashley
PSParentPath            : Microsoft.PowerShell.Core\FileSystem::C:\Users
PSChildName             : ashley
PSDrive                 : C
PSProvider              : Microsoft.PowerShell.Core\FileSystem
AccessToString          : NT AUTHORITY\SYSTEM Allow  FullControl
                          BUILTIN\Administrators Allow  FullControl
                          NADOMAIN\ashley Allow  FullControl
AuditToString           :
Path                    : Microsoft.PowerShell.Core\FileSystem::C:\Users\ashley
Owner                   : NT AUTHORITY\SYSTEM
Group                   : NT AUTHORITY\SYSTEM
Access                  : {System.Security.AccessControl.FileSystemAccessRule, System.Security.AccessControl.FileSystemAccessRule, System.Security.AccessControl.FileSystemAccessRule}
Sddl                    : O:SYG:SYD:P(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;FA;;;S-1-5-21-468525095-708123637-3513119021-43309)
AccessRightType         : System.Security.AccessControl.FileSystemRights
AccessRuleType          : System.Security.AccessControl.FileSystemAccessRule
AuditRuleType           : System.Security.AccessControl.FileSystemAuditRule
AreAccessRulesProtected : True
AreAuditRulesProtected  : False
AreAccessRulesCanonical : True
AreAuditRulesCanonical  : True


PS C:\Users\ashley> (Get-ACL).Access | fl *

FileSystemRights  : FullControl
AccessControlType : Allow
IdentityReference : NT AUTHORITY\SYSTEM
IsInherited       : False
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

FileSystemRights  : FullControl
AccessControlType : Allow
IdentityReference : BUILTIN\Administrators
IsInherited       : False
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

FileSystemRights  : FullControl
AccessControlType : Allow
IdentityReference : NORTHAMERICA\asmcglon
IsInherited       : False
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

Get-ACL gives us the same ACL in three different properties:

  1. AccessToString – This is a simplified representation to get a summary of the ACEs.
  2. Access – This is an array of access rule objects with rich properties.  Enumerating these is the easiest way to script and report against ACLs.
  3. SDDL – This is the only place where you can see the actual SIDs behind the ACEs.  For our purposes of SID translation we'll have to use this property.

You can pass any file, registry, or OU path to Get-ACL.  Without the path it defaults to the local context.  See "Get-Help Get-ACL -Full" for more information.


Although it looks cryptic, a few minutes of study on MSDN will help you crack the code and break down what is happening in the SDDL string.  Notice the string in the example below (note that the SID has been changed to protect the innocent):


Look what happens when we break it down by the parentheses:

  1. O:SYG:SYD:P
  2. (A;OICI;FA;;;SY)
  3. (A;OICI;FA;;;BA)
  4. (A;OICI;FA;;;S-1-5-21-468525095-708123637-3513119021-43309)

The first piece contains owner and primary group information.  We're going to skip this for now; SIDs can live here, but we are targeting ACEs specifically.  The next three pieces delimited in parentheses correspond to each of the three ACEs in the ACL.  Note that the last one contains a SID, because it references a non-default account in the ACE.

Now let's break down that last ACE.  Observe that ACEs are delimited with semicolons:

  1. A;
  2. OICI;
  3. FA;
  4. ;
  5. ;
  6. S-1-5-21-468525095-708123637-3513119021-43309

The "A" means "allow".  "OI" and "CI" reference "ObjectInherit" and "ContainerInherit" as observed in the full output of the Access property listed above.  These denote that permissions set at this level will be inherited downward.  If this value contained "ID", then we would know that the values where inherited from above and not explicitly defined at this level.  You can read about the other specific SDDL coding on MSDN.

The last element of the ACE array contains the SID, and that is our target for this script.  The user or group SID will always live in the 5th array index of each ACE.  If there is no SID here, then you'll find an alpha code representing a well-known group.

Finding SIDs in ACLs

To summarize our breakdown of SDDL above you can find the ACL SIDs using the process below:

  1. Get the ACL
  2. Get the SDDL string of the ACL
  3. Split the SDDL on parentheses to get the ACEs
  4. Split the ACEs on semicolons
  5. Reference the last index of the ACE array to find the SID

While this may seem like a lot of effort that is exactly what PowerShell does best.  We'll wrap this process into a function to reuse and call for each ACL that we want to parse.

Why all of this trouble?  Why not use the robust Access property array?  Remember that we are translating SIDs, and this is the only place where we can find them.  Both the regular account SID and the SID history will appear the same in the DOMAIN\username representation of the Access property ACE objects.  This is an important distinction.

The Code

The script attached to this blog gives you a basic function to parse SDDL as described above.  As an educational script it includes much verbose output and comments.  Study the output to learn more about how ACLs, ACEs, and SDDL work in different security contexts (file system vs. registry vs. AD).  Customize it for your own needs.  Note that we ignore any ACEs that are inherited, because we only want to target ACEs with explicit permissions for translation.

Coming Up Next

The next post in this series will adapt this function into a larger script that mimics SIDWALK by translating SIDs on file resources.  We'll learn how to unleash your inner Chuck Norris round house kick on SID history.

 Ashley McGlone, Microsoft PFE
 August, 2011
 Parse-SDDL function.
 0 ;1 ;2 ;3 ;4 ;5
 0 ;ID ;2 ;3 ;4 ;SID
 Split the SDDL on the characer: (
 Process indexes 1 to end
 Split on character ;
 If index 1 contains "ID" then ignore because inherited
 If index 5 contains a SID then process it
function Parse-SDDL {            
    param ([Parameter(valueFromPipelineByPropertyName=$true)]$SDDL)            
    $SDDLSplit = $SDDL.Split("(")            
    "`n---SDDL Split:"            
    "`n---SDDL SID Parsing:"            
    # Skip index 0 where owner and/or primary group are stored            
    For ($i=1;$i -lt $SDDLSplit.Length;$i++) {            
        $ACLSplit = $SDDLSplit[$i].Split(";")            
        If ($ACLSplit[1].Contains("ID")) {            
        } Else {            
            $ACLEntrySID = $null            
            # Remove the trailing ")"            
            $ACLEntry = $ACLSplit[5].TrimEnd(")")            
            # Parse out the SID using a handy RegEx            
            $ACLEntrySIDMatches = [regex]::Matches($ACLEntry,"(S(-\d+){2,8})")            
            $ACLEntrySIDMatches | ForEach-Object {$ACLEntrySID = $_.value}            
            If ($ACLEntrySID) {            
            } Else {            
                "Not inherited - No SID"            
    #return $null            
# Experiment with these different path values to see what the ACL objects do            
$path = "C:\users\username\"          #Not inherited            
$path = "C:\users\username\desktop\"  #Inherited            
$path = "HKCU:\"                      #Not Inherited            
$path = "HKCU:\Software"              #Inherited            
$path = "HKLM:\"                      #Not Inherited            
$ACL = Get-ACL $path            
"`n---Access To String:"            
"`n---Access entry details:"            
$ACL.Access | fl *            
# Call with named parameter binding            
$ACL | Parse-SDDL            
# Call with parameter string            
#Parse-SDDL $ACL.SDDL            
# ><>
Attachment: Parse SDDL for SIDs.p-s-1.txt

Can you help me?  Yes!

If you would like to have me or another Microsoft PFE visit your company and assist with the ideas presented in this blog post, then contact your Microsoft Premier Technical Account Manager (TAM) for booking information.

For more information about becoming a Microsoft Premier customer email PremSale@microsoft.com.  Tell them GoateePFE sent you.

Sharing Links
  • Good post Ashley!

  • Hi Ashley,

    as I am looking into "converting" a very large file space from old domain to new (with SID translating) and the file space has many (tens of thousands) of files/folders which exceed max_path (260 chars) the get-acl command of powershell does fail on those. Did you ever encounter this problem and if yes, what was your solution? (Shorten the folder and file names is no option).

    The following approach seems to me quite unreliable: gallery.technet.microsoft.com/.../Get-folder-permissions-for-6a636999

    With kind regards,


  • Hi Michael,

    Thanks for the question.  Unfortunately I don’t have a good answer.  To my knowledge there are no tools for ACL translation that can handle the 'path too long' scenario (SUBINACL, XCALCS, ADMT, etc.).  I haven’t tested them all, but I believe they have the same limitation.  I have discussed this limitation in my post here:


    The latest version of the SID history module will at least log the path where the error occurred so that you know where you need to fix manually.

    If someone else has a solution please reply with more information.




  • Quite late I know, but a newly released module "File System Security PowerShell Module 3.0"
    here: https://gallery.technet.microsoft.com/1abd77a5-9c0b-4a2b-acef-90dbb2b84e85
    might help some.

    From the readme:
    This version leverages the AlphaFS (http://alphafs.codeplex.com) to work around the MAX_PATH limitation of 260 characters
    This requires new *-Item commands to be able to discover items with a log path
    GetChildItem2 (dir2)
    Get-Item2 (gi2)
    Remove-Item2 (del2, rm2)

    Though you'd probably have to mangle your module to utilise the long file path access options.
    It might help someone like Michael

    And point #3 is wrong. It should say:
    Chuck Norris' ACL only has one ACE: Chuck Norris

    Excellent scripts.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment