raandree / NTFSSecurity

Managing permissions with PowerShell is only a bit easier than in VBS or the command line as there are no cmdlets for most day-to-day tasks like getting a permission report or adding permission to an item. PowerShell only offers Get-Acl and Set-Acl but everything in between getting and setting the ACL is missing. This module closes the gap.
MIT License
431 stars 61 forks source link

User Context #71

Open lorenzstorm1 opened 4 years ago

lorenzstorm1 commented 4 years ago

The Commands are always executed with the current user context permissions. Is it possible to specify another User for Accessing the Folder/Share/File?

mwtrigg commented 4 years ago

Create a PSDrive with alternate credentials, and run commands against that drive.

lorenzstorm1 commented 4 years ago

Works - had to make the PSDrive persist

lorenzstorm1 commented 3 years ago

Does not work with the NTFSSecurity Module: New-PSDrive -Name "W2" -PSProvider "FileSystem" -Root $Pfad -Credential $Cred $Share = "W2" get-psdrive Name Used (GB) Free (GB) Provider Root CurrentLocation


Alias Alias C 54,65 45,01 FileSystem C:\
D 0,45 99,55 FileSystem D:\ W2 FileSystem \path to share Get-NTFSAccess -Path W2: Get-NTFSAccess: Unable to find the specified file.

Other non NTFSSecurity Module cmdlets work e.g.: Get-ChildItem -Path W2:

raandree commented 3 years ago

Right, the commands are invoked in the context of the currently logged on user. @mwtrigg's idea would work if NTFSSecurity used the PowerShell providers. But one purpose of the module was to solve the Windows PowerShell 260 character path limitation, hence it uses AlphaFS which does not even know about PowerShell.

@lorenzstorm1, I know this answer comes a bit late. If you still have this issue, please try to use Invoke-Command.

lorenzstorm1 commented 3 years ago

Hi,

just tested with Invoke-Command > also not working

Invoke-Command -Computername $Server -Credential $Cred -ScriptBlock {Get-NTFSAccess -Path C:} > works Invoke-Command -Computername $Server -Credential $Cred -ScriptBlock {Get-NTFSAccess -Path \nas\share} > does not work

Sup3rlativ3 commented 3 years ago

I have a couple of questions for you that might help us get to the bottom of it for you.

lorenzstorm1 commented 3 years ago

What are you running this against? Is is a windows or Linux box, is it some sort of prebuilt NAS like Synology? EMC Isilon/Powerscale What version of NTFSSecurity are you using? the newest What client are you using? e.g. Windows 10 20H2, Windows 7? Server 2019

I want to run this Powershell Command through Jenkins Powershell Plugin which is always executed as SYSTEM User. So i somehow need to find a way to include a User with Permissions to the NAS in the Command. Hope that helps

Sup3rlativ3 commented 3 years ago

What's doing the authentication on the fileshares on your EMC, is it the domain controller or is it a local account?

Local account: If the user is local to the EMC, I could suggest putting the hostname of the EMC in place of the domain e.g. EMC01\User.name or you could try putting a period in instead like .\user.name

Domain account: If the shares are being hosted by a windows box the something like the below would work. Please note that this is obviously just a same and putting passwords in a script is a bad thing and shouldn't be done in prod.

$Server = "SERVER01.DOMAIN.INTERNAL"
$Username = "DOMAIN\USER.NAME"
$PlainPassword = "P@ssw0rd"
$SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force
$Credentials = New-Object System.Management.Automation.PSCredential -ArgumentList $UserName, $SecurePassword
Invoke-Command -ComputerName $Server -Credential $Credentials -ScriptBlock {Import-Module NTFSAccess; Get-NTFSAccess -Path \\$Using:Server\Share}

One other thing, is NTFSAccess installed for everyone on the remote server? If it's not available, you won't be able to use the cmdlet. I know it seems obvious but I've seen people skip over that detail.

jcardel commented 3 years ago

It sounds like you are trying to use a local account to connect to Isilon, that will not work without making a session first atleast. I have used this for Isilon permissions for many years now, you need to check the RBAC, and make sure that the account in your domain that you want to use is in the appropriate groups. Also some permissions cannot be manipulated unless you access the share you access with "root" permissions.

I suggest you make an extra share on the same path, that only this admin account can access, set it to "run as root", and you can do the "rest" now.

Also, maybe you want to create a session to Isilon with the credentials you want to use. I am using IsilonPOSH for this, you can find it on GitHub. It might be the solution you need.

I doubt it is anything with this module.

Med venlig hilsen / Best regards |--Johan Cardel --Storage admin |--Aarhus University

From: James Smith @.> Sent: 24. juli 2021 05:11 To: raandree/NTFSSecurity @.> Cc: Subscribed @.***> Subject: Re: [raandree/NTFSSecurity] User Context (#71)

What's doing the authentication on the fileshares on your EMC, is it the domain controller or is it a local account?

Local account: If the user is local to the EMC, I could suggest putting the hostname of the EMC in place of the domain e.g. EMC01\User.name or you could try putting a period in instead like .\user.name

Domain account: If the shares are being hosted by a windows box the something like the below would work. Please note that this is obviously just a same and putting passwords in a script is a bad thing and shouldn't be done in prod.

$Server = "SERVER01.DOMAIN.INTERNAL"

$Username = "DOMAIN\USER.NAME"

$PlainPassword = @.***"

$SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force

$Credentials = New-Object System.Management.Automation.PSCredential -ArgumentList $UserName, $SecurePassword

Invoke-Command -ComputerName $Server -Credential $Credentials -ScriptBlock {Import-Module NTFSAccess; Get-NTFSAccess -Path \$Using:Server\Sharefile://$Using:Server/Share}

One other thing, is NTFSAccess installed for everyone on the remote server? If it's not available, you won't be able to use the cmdlet. I know it seems obvious but I've seen people skip over that detail.

- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fraandree%2FNTFSSecurity%2Fissues%2F71%23issuecomment-885991691&data=04%7C01%7Cjc%40au.dk%7Cb05feb06063e4cc6e84d08d94e50a1e0%7C61fd1d36fecb47cab7d7d0df0370a198%7C1%7C0%7C637626930510381439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2B3O6kvN5R4U6ikP52PEBKfWAZHBfkX7hSv%2Fpcb8nj0s%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFICQW5T3347VOL5REEJLRLTZIVLLANCNFSM4SHK2ADQ&data=04%7C01%7Cjc%40au.dk%7Cb05feb06063e4cc6e84d08d94e50a1e0%7C61fd1d36fecb47cab7d7d0df0370a198%7C1%7C0%7C637626930510381439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KagASBr5y6mv4sJ2LQV58ATf0wmyn5nVyLuZKoSfyYA%3D&reserved=0.