Hi All,

I was hoping someone could help me out with a little problem I'm having.

I need to run the test-path cmdlet on a DFS Namespace UNC, but I also need to run it with alternate credentials.

Problem is, the test-path cmdlet doesn't support the -Credental parameter, so I'm trying to wrap it up in an Invoke-Command cmdlet.

For some reason, I keep getting an access denied error returned. I know for a FACT that the account I'm using for the alternate creds has permissions here because when I open a powershell prompt as that user, it works fine.

The invoke-command wrapper works too if I'm using a local path (C:\path\folder), but not with a DFS UNC.  Here's my code:

$targ = "filesystem::\\domain.com\FakePath\FakeFolder"
$username = "FakeUser"
$password = ConvertTo-SecureString "FakePassword" -AsPlainText -Force
$cred = new-object System.Management.Automation.PSCredential ($username, $password)
$tp = Invoke-Command -ComputerName "." -Credential $cred -ScriptBlock {test-path $args[0]} -ArgumentList $targ	
if ($tp -eq $false) {Write-host "Cannot find folder!"}
if ($tp -eq $true) {Write-host "Found folder!"}

Here's the error it's returning:

ERROR: Access is denied
ERROR:     + CategoryInfo          : PermissionDenied: (\\domain.com\fakepath\fakefolder:String) [Test-Path], UnauthorizedAccessException
ERROR:     + FullyQualifiedErrorId : ItemExistsUnauthorizedAccessError,Microsoft.PowerShell.Commands.TestPathCommand
ERROR:     + PSComputerName        : localhost

Any ideas?

Thanks,

Chris

• Edited by Topher2798 Friday, June 19, 2015 7:25 PM

Well... I guess I spoke too soon.  Now I'm getting this:

ERROR: New-PSDrive : Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous
ERROR: connections to the server or shared resource and try again
helpdesk.ps1 (1134): ERROR: At Line: 1134 char: 2
ERROR: +         New-PSDrive -Name X -PSProvider FileSystem -Root $targ -Credential $cred
ERROR: +         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ERROR:     + CategoryInfo          : InvalidOperation: (X:PSDriveInfo) [New-PSDrive], Win32Exception
ERROR:     + FullyQualifiedErrorId : CouldNotMapNetworkDrive,Microsoft.PowerShell.Commands.NewPSDriveCommand

And I've even tried clearing the drive first with this:

Remove-PSDrive X

How frustrating....

• Edited by Topher2798 Tuesday, June 23, 2015 9:56 PM

Actually, the test-path scenario is just a small piece of the puzzle. This script does a hell of a lot more than just validating folder paths. The full story is a bit more in depth....

Originally, what I was trying to achieve, is to perform a Get-ACL on a folder to see which groups are assigned permissions to it, so I could then connect to the group in Active Directory and pull the managedBy property. This information will be used by the help desk personnel to know who to contact for approval of group membership for access to the data.

Problem is, the help desk admin accounts don't have access to all of the folder paths in the environment, so I need to figure out a way (in the background) to get this information using alternate credentials. Since the Get-ACL command doesn't support the -Credential parameter, I tried wrapping it up in a scriptblock in the Invoke-Command cmdlet since that DOES support the -credential parameter. However, it was throwing errors.

The Test-Path is just a pre-check to determine if the folder path they specified even exists before trying to pull the ACL. However, the Test-Path cmdlet also doesn't support the -credential parameter, so I was trying to wrap it up in it's own Invoke-Command too. That's when I noticed that they both returned the exact same error (access denied).

The Test-Path scenario I explained in my original post seemed like the simplest and easiest way to summarize the problem at hand without having to write a long winded post trying to explain everything I was trying to achieve. I figured if we could sort out the Test-Path problem, I could use the same technique on the Get-ACL.

The script itself does a lot more than what I'm trying to add to it right now. It's has a tab enabled GUI interface with a bunch of tools that the help desk can use to perform various daily activities which saves them time and effort. (it also helps eliminate human error in some of their processes).

It's very important I get this latest addition working as this has been a real pain point in our environment for a long time now. It causes them to have to pass the support ticket over to a different group to pull this information and send it back to them so they can continue processing the request, slowing down the entire process. (cogs in the corporate machine)

In case you're interested, here's what the script looks like for the tab I'm currently working on. I have all of it working except for the folder permission piece in the lower right.

I have two weeks to get this working, and polish everything up to pass it off to them.  "Not Possible" is unacceptable.  I have to find a work around.

• Edited by Topher2798 11 hours 43 minutes ago

WMI Win32_Share can read the description of the share.  Place the managers in the description and you are how free.

All shares should be registered in AD in this setting and AD can have extra properties added to the object to display anything you need.  Yu can then just write a one time script to set these properties or the description. The script can be run as an admin and read all of the groups and store them in the "public" AD property.  You can rerun this script any time to update the properties.

Hmmm... thanks for the suggestion. I like this idea.  I'll look into the Win32_Share class.

Problem might be with us having multiple folders (with different "Owners") within the same share. So the problem goes a bit deeper than the share level.

Hmmm... thanks for the suggestion. I like this idea.  I'll look into the Win32_Share class.

Problem might be with us having multiple folders (with different "Owners") within the same share. So the problem goes a bit deeper than the share level.

You can still store the folder owners into AD on the share object.  Store them as an array of pairs folder=owner,owner,owner;folder2=owner,owner.

Now anyone can read the owners.

Actually, the test-path scenario is just a small piece of the puzzle. This script does a hell of a lot more than just validating folder paths. The full story is a bit more in depth....

Originally, what I was trying to achieve, is to perform a Get-ACL on a folder to see which groups are assigned permissions to it, so I could then connect to the group in Active Directory and pull the managedBy property. This information will be used by the help desk personnel to know who to contact for approval of group membership for access to the data.

Problem is, the help desk admin accounts don't have access to all of the folder paths in the environment, so I need to figure out a way (in the background) to get this information using alternate credentials. Since the Get-ACL command doesn't support the -Credential parameter, I tried wrapping it up in a scriptblock in the Invoke-Command cmdlet since that DOES support the -credential parameter. However, it was throwing errors.

The Test-Path is just a pre-check to determine if the folder path they specified even exists before trying to pull the ACL. However, the Test-Path cmdlet also doesn't support the -credential parameter, so I was trying to wrap it up in it's own Invoke-Command too. That's when I noticed that they both returned the exact same error (access denied).

The Test-Path scenario I explained in my original post seemed like the simplest and easiest way to summarize the problem at hand without having to write a long winded post trying to explain everything I was trying to achieve. I figured if we could sort out the Test-Path problem, I could use the same technique on the Get-ACL.

The script itself does a lot more than what I'm trying to add to it right now. It's has a tab enabled GUI interface with a bunch of tools that the help desk can use to perform various daily activities which saves them time and effort. (it also helps eliminate human error in some of their processes).

It's very important I get this latest addition working as this has been a real pain point in our environment for a long time now. It causes them to have to pass the support ticket over to a different group to pull this information and send it back to them so they can continue processing the request, slowing down the entire process. (cogs in the corporate machine)

In case you're interested, here's what the script looks like for the tab I'm currently working on. I have all of it working except for the folder permission piece in the lower right.

I have two weeks to get this working, and polish everything up to pass it off to them.  "Not Possible" is unacceptable.  I have to find a work around.

• Edited by Topher2798 Wednesday, June 24, 2015 7:25 PM

I really didn't want to have to modify properties on so many shares or objects in active directory.

I ended up just dropping the idea of using test-path and get-acl with invoke-command. Instead, I just mapped the UNC to a drive letter using new-psdrive and pulled the ACL from the drive letter (without using the -credential parameter).

In the end, I packaged the entire script into an executable. The packager has the ability to run the script as an alternate user, which is working well without any errors.

I'll still mark your reply as an answer since it's a valid solution to my problem. Even if I didn't end up going that direction.

Ha! I did it. I figured out a way to test-path and get-acl with alternate credentials without having to wrap up the entire script in an exe and run as a different user.  Here's the code snip-it showing how it was done. Note, this uses the DFS cmdlets included in Windows Server 2012.

$username = "domain\user"
$password = ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force
$cred = new-object System.Management.Automation.PSCredential ($username, $password)
$targ = "\\domain.com\namespaceroot\folder"
$ap = $targ.split("\")
$p2 = $ap[2]
$p3 = $ap[3]
$p4 = $ap[4]
$nsp = "\\$p2\$p3\$p4"
$dfs = Get-DfsnFolderTarget -Path $nsp
$nspc = $nsp.length
foreach ($itm in $dfs) { if ($itm.State -eq "Online") { $tpth = $itm.TargetPath } }
$tptharr = $tpth.split("\")
$t2 = $tptharr[2]
$t3 = $tptharr[3]
$t4 = $tptharr[4]
$tcon = [System.Net.Dns]::GetHostAddresses("$t2")
$tip = $tcon.IPAddressToString
$tpth = "\\$tip\$t3\$t4"
$sectarg = ($targ.substring($nspc))
$targ = "$tpth$sectarg"
if (Test-Path X:) { Remove-PSDrive X }
New-PSDrive -Name X -PSProvider FileSystem -Root "$targ" -Credential $cred
$targ = "X:\"
$tp = test-path $targ
if ($tp -eq $false) { [System.Windows.Forms.MessageBox]::Show("Folder not exist.")}
$acl = Get-Acl $targ
$acl

The code is ugly, and verbose, but it works!

• Marked as answer by Topher2798 12 hours 1 minutes ago

Ha! I did it. I figured out a way to test-path and get-acl with alternate credentials without having to wrap up the entire script in an exe and run as a different user.  Here's the code snip-it showing how it was done. Note, this uses the DFS cmdlets included in Windows Server 2012.

$username = "domain\user"
$password = ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force
$cred = new-object System.Management.Automation.PSCredential ($username, $password)
$targ = "\\domain.com\namespaceroot\folder"
$ap = $targ.split("\")
$p2 = $ap[2]
$p3 = $ap[3]
$p4 = $ap[4]
$nsp = "\\$p2\$p3\$p4"
$dfs = Get-DfsnFolderTarget -Path $nsp
$nspc = $nsp.length
foreach ($itm in $dfs) { if ($itm.State -eq "Online") { $tpth = $itm.TargetPath } }
$tptharr = $tpth.split("\")
$t2 = $tptharr[2]
$t3 = $tptharr[3]
$t4 = $tptharr[4]
$tcon = [System.Net.Dns]::GetHostAddresses("$t2")
$tip = $tcon.IPAddressToString
$tpth = "\\$tip\$t3\$t4"
$sectarg = ($targ.substring($nspc))
$targ = "$tpth$sectarg"
if (Test-Path X:) { Remove-PSDrive X }
New-PSDrive -Name X -PSProvider FileSystem -Root "$targ" -Credential $cred
$targ = "X:\"
$tp = test-path $targ
if ($tp -eq $false) { [System.Windows.Forms.MessageBox]::Show("Folder not exist.")}
$acl = Get-Acl $targ
$acl

The code is ugly, and verbose, but it works!

• Marked as answer by Topher2798 Thursday, August 06, 2015 7:10 PM