1

So far, I know to do the following:

  1. Determine the service logon account - (Get-WmiObject -Query "SELECT StartName FROM win32_service where name = 'mssqlserver'").StartName
  2. Get accounts that have read access to the folder - accesschk -q -d $env:TEMP

But this leads me nowhere:

PS C:\> (Get-WmiObject -Query "SELECT StartName FROM win32_service where name = 'mssqlserver'").StartName
LocalSystem
PS C:\> accesschk -q -d $env:TEMP
c:\Users\MKHARI~1\AppData\Local\Temp
  RW NT AUTHORITY\SYSTEM
  RW BUILTIN\Administrators
  RW DAYFORCE\mkharitonov
PS C:\> accesschk LocalSystem -q -d $env:TEMP

Accesschk v5.2 - Reports effective permissions for securable objects
Copyright (C) 2006-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

  Error looking up account: LocalSystem:
  The operation completed successfully.
PS C:\> accesschk "DAYFORCE\mkharitonov" -q -d $env:TEMP
RW c:\Users\MKHARI~1\AppData\Local\Temp
PS C:\>

The AccessChk does not seem to recognize LocalSystem. Also, if I run it with an account belonging to the BUILTIN\Administrators, it does not seem to acknowledge the access.

Does it mean AccessChk is not suitable for this or am I using it wrong? Is there a way to do it at all without actually trying to access the folder under the account in question?

When PowerShell is running not as administrator:

PS C:\> $service = Get-WmiObject -EnableAllPrivileges Win32_Service | Where-Object {$_.Name -eq "MSSQLSERVER"}
PS C:\> '{0:x}' -f $service.GetSecurityDescriptor().ReturnValue
80070522
PS C:\>

Which corresponds to A required privilege is not held by the client. The command works OK when the PowerShell is running as administrator. Ideally, I would like a solution that does not require elevation.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
mark
  • 59,016
  • 79
  • 296
  • 580
  • Can you check with this (as localsystem uses the token of nt authority\System) : accesschk.exe system -q -d $env:temp – ClumsyPuffin Dec 18 '16 at 10:44
  • That looks good, it outputs **RW c:\Users\MKHARI~1\AppData\Local\Temp**. However, `(Get-WmiObject -Query "SELECT StartName FROM win32_service where name = 'mssqlserver'").StartName` returns **LocalSystem**, not **System**. If this is a special case - I can map LocalSystem to System in my script. But I am worried that there are maybe more cases when WMI returns something that needs to be mapped to something else before calling accesschk.exe. Any ideas? – mark Dec 18 '16 at 16:19
  • I have updated the solution as answer,Can you check – ClumsyPuffin Dec 18 '16 at 17:57

2 Answers2

2

localsystem uses the token of nt authority\System, so this command line will work (you will need to map the localsystem to system in code):

accesschk.exe system -q -d $env:temp

I have created a snippet to fetch the proper name and pass it to accesschk (tested in PowerShell v5 and requires elevated access):

$service = Get-WmiObject -EnableAllPrivileges Win32_Service | Where-Object {$_.Name -eq "wlidsvc"}
 $desc = (($service.GetSecurityDescriptor()).Descriptor).owner
 $desc.Domain + "\"+$desc.name | %{.\accesschk.exe $_ -q -d $env:temp}

$desc.Domain + "\"+$desc.name will return NT AUTHORITY\SYSTEM instead of localsystem

PS: The script can be optimized

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
ClumsyPuffin
  • 3,909
  • 1
  • 17
  • 17
  • Please, see **EDIT 1** – mark Dec 18 '16 at 18:15
  • Please, include the accesschk.exe command line in the answer with the need to map LocalSystem to system. This is good enough for me to mark it as answer. If you have a way to get the canonical user name without elevation - that would be an extra bonus for me. – mark Dec 18 '16 at 18:16
  • @mark I have added the accesschk commandline as you suggested – ClumsyPuffin Dec 18 '16 at 18:22
0
$account = 'whatever you like'
$acl = Get-Acl 'folder'
$acl.access | where { $_.IdentityReference -like "*$account*"}).FileSystemRights

I am not sure this will work with PowerShell v.2, but it will work for PowerShell v.3 and later.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
4c74356b41
  • 69,186
  • 6
  • 100
  • 141
  • How does it help me exactly? In my example the ACL returns three subjects - `NT AUTHORITY\SYSTEM`, `BUILTIN\Administrators` and `DAYFORCE\mkharitonov`. None of them matches `LocalSystem` and yet the latter does have access, being a local administrator. – mark Dec 17 '16 at 18:44
  • `NT AUTHORITY\SYSTEM` is `LocalSystem` – 4c74356b41 Dec 17 '16 at 18:47
  • https://msdn.microsoft.com/en-us/library/windows/desktop/ms684190(v=vs.85).aspx @mark – 4c74356b41 Dec 17 '16 at 18:56
  • `BUILTIN\Administrators` is a group. So any account in this group has access. But the simple string matching will not reveal it. – mark Dec 17 '16 at 19:21
  • what does that supposed to mean – 4c74356b41 Dec 17 '16 at 19:45
  • `$_.IdentityReference -like "*$account*"` is a string matching, isn't it? – mark Dec 18 '16 at 03:00