Thanks a million Rohn for building that module. Saves so much time and effort. I’m trying out the Get-SecurityDescriptor functionality on Powershell 2.0 and so far so good – but ! ( there’s always one 😉 ) some SIDs aren’t recognized by the function. I’m trying it out remotely on a SQL server and the SQLServer..$… account SIDs aren’t translated. You can do a quick check with part of a script I presently use just to get the trustee list and compare with your function.
gwmi win32_share -cn $sqlserver -filter “type=0” |select -exp name | %{gwmi -class win32_logicalsharesecuritysetting -computername $sqlserver -filter “name=’$_'”} |
%{$shareName = $_.name ; $_.getsecuritydescriptor().descriptor.DACL }| %{$_.trustee.name}
It might simply be a parameter that I’m not using or a filtering out of specific local accounts.
Let me know.
thanks
Serge
Name translations for local accounts on remote systems do not currently work. I am working on this, though. The latest version has functions that will do SID->Account and Account->SID translations against remote computers. The account to SID works really well because you can put the account in the COMPUTERNAME\USERNAME form, and it works without having to change any other module internals. I’ve got some ideas that should fix what you’re describing, too (I’m guessing that it just shows the SID, correct)?
I appreciate you using the module, and also letting me know that this issue is affecting you. Hopefully within the next few days I’ll have the next version posted, and hopefully I will have added the SID->Account translation for remote systems. I can tell you that the features that have already been implemented (I’m still testing) are pretty cool.
I realy do appreciate the process flow you’ve used in having taken the object types as a key element in parsing through the hex conversion and various other similar ‘handles’. It’s something I’ve never done (yet) and once you decipher it, it’s a satisfying ‘ha ha moment’. Yes just the “Account unknown SID” is shown. Thanks for the workaround and will surely check the updates.
Get-EffectiveAccess isn’t really meant to show where access comes from. Its main purpose is to show what the true access is for a given user, after all group memberships and allow/deny ACEs have been taken into account.
I think you might be looking for the functionality provided by the Get-AccessControlEntry function. It already has -Inherited and -NotInherited switch parameters, along with other parameters that allow filtering (you can filter on pretty much any ACE component).
If you’ve already looked at the Get-AccessControlEntry and it’s not doing what you need, can you briefly describe what functionality you’re looking for.
Thanks for using the module and providing feedback!
Hello Rohn. I’m looking for sample code from your PS Summit 2016 presentation on PS Modules using Metaprogramming. Please let me know if it is available anywhere. Thank you!
Hello, Rohn
I found a PS script you wrote for SMB Insecurely Configured Service (Ensure the ‘Everyone’ group does not have ChangeConf, WDac, or WOwn permissions). Here is a copy of that script
# First, you need the security descriptor. One way to get this is to use
# the sc.exe command with the ‘sdshow’ option:
$Sddl = sc.exe sdshow $ServiceName | where { $_ }
try { # Next, create a common security descriptor object with that SDDL:
$SD = New-Object System.Security.AccessControl.CommonSecurityDescriptor(
$false, # Not a container
$false, # Not a DS Object
$Sddl
)
}
catch {
Write-Warning (“Error creating security descriptor for {0}: {1}” -f $ServiceName, $_.Exception.Message)
return
}
# At this point, you’d want to call sc.exe sdset (MAKE SURE YOU RUN THIS AS AN ELEVATED ADMINISTRATOR, SO THAT ANY SACL THAT’S PRESENT WON’T BE OVERWRITTEN)
}
} | Format-List
It run with no errors, but how can I tell it it worked, any information would be appreciated
You should be able to just call sc.exe with the sdshow option and make sure that the SDDL representation has been updated.
That script is pretty old, though, and I’d recommend using the PowerShellAccessControl module [https://gallery.technet.microsoft.com/scriptcenter/PowerShellAccessControl-d3be7b83] instead. It lets you do something like this to confirm the security descriptor:
Rohn's Blog 
Thanks a million Rohn for building that module. Saves so much time and effort. I’m trying out the Get-SecurityDescriptor functionality on Powershell 2.0 and so far so good – but ! ( there’s always one 😉 ) some SIDs aren’t recognized by the function. I’m trying it out remotely on a SQL server and the SQLServer..$… account SIDs aren’t translated. You can do a quick check with part of a script I presently use just to get the trustee list and compare with your function.
gwmi win32_share -cn $sqlserver -filter “type=0” |select -exp name | %{gwmi -class win32_logicalsharesecuritysetting -computername $sqlserver -filter “name=’$_'”} |
%{$shareName = $_.name ; $_.getsecuritydescriptor().descriptor.DACL }| %{$_.trustee.name}
It might simply be a parameter that I’m not using or a filtering out of specific local accounts.
Let me know.
thanks
Serge
Name translations for local accounts on remote systems do not currently work. I am working on this, though. The latest version has functions that will do SID->Account and Account->SID translations against remote computers. The account to SID works really well because you can put the account in the COMPUTERNAME\USERNAME form, and it works without having to change any other module internals. I’ve got some ideas that should fix what you’re describing, too (I’m guessing that it just shows the SID, correct)?
I appreciate you using the module, and also letting me know that this issue is affecting you. Hopefully within the next few days I’ll have the next version posted, and hopefully I will have added the SID->Account translation for remote systems. I can tell you that the features that have already been implemented (I’m still testing) are pretty cool.
I realy do appreciate the process flow you’ve used in having taken the object types as a key element in parsing through the hex conversion and various other similar ‘handles’. It’s something I’ve never done (yet) and once you decipher it, it’s a satisfying ‘ha ha moment’. Yes just the “Account unknown SID” is shown. Thanks for the workaround and will surely check the updates.
Dear Rohn,
What a fantastic tool you have created… Great for ntfs auditing!
I only have one request… would it be possible to add another noteproperty: “inherited” to the get-effectiveaccess cmd-let?
Kind regards,
Geert
And to make it even more useable, a “-noinherited permissions” filter would make it the absolute best thing…
Get-EffectiveAccess isn’t really meant to show where access comes from. Its main purpose is to show what the true access is for a given user, after all group memberships and allow/deny ACEs have been taken into account.
I think you might be looking for the functionality provided by the Get-AccessControlEntry function. It already has -Inherited and -NotInherited switch parameters, along with other parameters that allow filtering (you can filter on pretty much any ACE component).
If you’ve already looked at the Get-AccessControlEntry and it’s not doing what you need, can you briefly describe what functionality you’re looking for.
Thanks for using the module and providing feedback!
Hello Rohn. I’m looking for sample code from your PS Summit 2016 presentation on PS Modules using Metaprogramming. Please let me know if it is available anywhere. Thank you!
It’s available on my GitHub page here:
https://github.com/rohnedwards/Summit2016Demos
Hello, Rohn
I found a PS script you wrote for SMB Insecurely Configured Service (Ensure the ‘Everyone’ group does not have ChangeConf, WDac, or WOwn permissions). Here is a copy of that script
$EveryoneSid = ([System.Security.Principal.NTAccount] “Everyone”).Translate([System.Security.Principal.SecurityIdentifier])
$RightsToCheck = 0xc0002 # ChangeConfig, ChangePermissions, ChangeOwner
Get-Service | ForEach-Object {
$ServiceName = $_.Name
# First, you need the security descriptor. One way to get this is to use
# the sc.exe command with the ‘sdshow’ option:
$Sddl = sc.exe sdshow $ServiceName | where { $_ }
try { # Next, create a common security descriptor object with that SDDL:
$SD = New-Object System.Security.AccessControl.CommonSecurityDescriptor(
$false, # Not a container
$false, # Not a DS Object
$Sddl
)
}
catch {
Write-Warning (“Error creating security descriptor for {0}: {1}” -f $ServiceName, $_.Exception.Message)
return
}
if ($SD.DiscretionaryAcl | where { $_.AceQualifier -eq [System.Security.AccessControl.AceQualifier]::AccessAllowed -and $_.SecurityIdentifier -eq $EveryoneSid -and $_.AccessMask -band $RightsToCheck }) {
$null = $SD.DiscretionaryAcl.RemoveAccess(
“Allow”, # ACE type
$EveryoneSid,
$RightsToCheck,
“ContainerInherit, ObjectInherit”, # InheritanceFlags
“None” #PropagationFlags
)
[PSCustomObject] @{
Service = $ServiceName
OriginalSddl = $Sddl
UpdatedSddl = $SD.GetSddlForm(“All”)
}
# At this point, you’d want to call sc.exe sdset (MAKE SURE YOU RUN THIS AS AN ELEVATED ADMINISTRATOR, SO THAT ANY SACL THAT’S PRESENT WON’T BE OVERWRITTEN)
}
} | Format-List
It run with no errors, but how can I tell it it worked, any information would be appreciated
Wayne
Wayne,
You should be able to just call sc.exe with the sdshow option and make sure that the SDDL representation has been updated.
That script is pretty old, though, and I’d recommend using the PowerShellAccessControl module [https://gallery.technet.microsoft.com/scriptcenter/PowerShellAccessControl-d3be7b83] instead. It lets you do something like this to confirm the security descriptor:
PS> Get-Service ServiceNameHere | Get-PacAccessControlEntry
It also has helper commands for adding (Add-PacAccessControlEntry) and removing (Remove-PacAccessControlEntry).
There are two versions: 3.0, which is a script module that you can open up and read the code directly from the module, and version 4.0, which is a compiled module whose source is here: https://github.com/rohnedwards/PowerShellAccessControl/tree/v4.0_devel
Rohn,
Thank you so much for responding, I will try your suggestion and let you know the results