User Context

[lorenzstorm1]

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]

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

[lorenzstorm1]

Works - had to make the PSDrive persist

[lorenzstorm1]

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]

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]

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]

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

• What are you running this against? Is is a windows or Linux box, is it some sort of prebuilt NAS like Synology?
• What version of NTFSSecurity are you using?
• What client are you using? e.g. Windows 10 20H2, Windows 7?

I know that both of those situations work as I created an RBAC module and used both methods. Also, just double checking that you used a double backslash and not just a single e.g. \nas not \nas?

[lorenzstorm1]

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]

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]

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\Share<file://$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 GitHub<https://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 unsubscribe<https://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>.