Powershell: Get-ACL doesn't support -Credential?

[PsychoData]

How come Get-ACL doesn't have -Credential support?

[mklement0]

Your question will probably get more attention if you explain _why_ Get-Acl should have that parameter.

Run Get-Acl from an _elevated_ session to avoid problems stemming from lack of permissions.

[PsychoData]

Here is my thing. My regular account doesn't have credentials to get into
even the root folder holding our home network drives.

If I had -credential I could prompt or pass my file system admin or domain
admin credential object to it and get in their content

On May 13, 2017 12:55 PM, "Michael Klement" [e-mail]
wrote:

Your question will probably get more attention if you explain why Get-Acl
should have that parameter.

Run Get-Acl from an elevated session to avoid problems stemming from lack
of permissions.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/3777#issuecomment-301260436,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADi_zDjkM74GWLH6tzdbQdtyNEPm1mW9ks5r5eCJgaJpZM4NZsWw
.

[mklement0]

To _generalize_ your requirement: you want an on-demand method for invoking a given command _with elevation_, similar to what sudo does in the Unix world.

That would indeed be helpful, and is already being discussed in #3232.

Unless this anticipated _generic_ mechanism still wouldn't meet your needs, I suggest you close this issue.

[PsychoData]

I don't see why you wouldn't want to have -Credential on it so you can call
it as another user?

Like how you can say 'Get-Aduser username -Credential $DAcred'

I also have fields hidden from my regular, daily driver user that are
visible from my admin account. Like employee number and Administrator
password are visible to my server admin account and above, but not that
lower account.

Same type of thing, just filesystem right now instead of AD.

On May 13, 2017 7:04 PM, "Michael Klement" [e-mail] wrote:

To generalize your requirement: you want an on-demand method for
invoking a given command with elevation, similar to what sudo does in
the Unix world.

That would indeed be helpful, and is already being discussed in #3232
https://github.com/PowerShell/PowerShell/issues/3232.

Unless this anticipated generic mechanism still wouldn't meet your
needs, I suggest you close this issue.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/PowerShell/issues/3777#issuecomment-301279991,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADi_zFRbxE6PzCGL0UpWJ6qdVToIcCHSks5r5jbegaJpZM4NZsWw
.

[mklement0]

I just realized that far more cmdlets than I was aware of in fact do have a -Credential parameter:

$VerbosePreference = 'Continue'
Get-Command -type cmdlet | ? { $c = $_; try { $_.Parameters.ContainsKey('Credential') } catch { write-verbose "Failed with: $c" } }

Still:

• It's not readily obvious to me which cmdlets were given this parameter vs. which were not.

• It seems to me that solving this problem at the level of _individual cmdlets_ is the wrong approach.

That said, I'll leave it to someone more knowledgeable to take it from here.

[rahulduggal18]

Can't use the Invoke-Command to elevate ?
Example, Invoke-Command -ComputerName . -ScriptBlock {get-acl} -Credential (Get-Credential)

[SotoDucani]

I'll agree and bump this a little. Unlike #2761 and #2975 (similar -Credential requests), there doesn't seem to be any restriction that prevents a -Credential parameter from being implemented. I only took a quick look through the .NET docs on ACL classes, so I very well could be wrong on that.

While Invoke-Command would work, it would force a weird usage in my opinion. Everything I've used so far supports -Credential, then all of a sudden for working with ACL's I'd have to shove the ~10 lines of logic into a scriptblock and either choose to invoke it against localhost or the remote computer that holds the file shares (since Invoke-Command requires a -ComputerName when -Credential is used). That's not a fantastic option since it additionally requires remoting to be available when Get-ACL only requires Share\NTFS permissions regardless of local vs remote file locations.

[charltonstanley]

I agree with others on this thread! To add my own input: A Credential parameter that accepts type [System.Management.Automation.PSCredential] would be extremely useful for the Get-ACL (and associated) cmdlets.

[mklement0]

I realize that I've conflated two things earlier:

• running in the context of a given user account
• running _with elevation_ (as admin, of necessity in a separate process, after confirming the UAC dialog)

If no actual elevation is required - just a different user's context - then I can see the value of adding this parameter to Get-Acl

[charltonstanley]

If no actual elevation is required - just a different user's context - then I can see the value of adding this parameter to Get-Acl

That is exactly it. I don't need a Credential parameter to elevate. However I do need it to leverage an account that has the required permissions necessary to read the ACL of the target path.

[iSazonov]

Users will expect that elevation works. It is bad UX.