How to test the ability to connect a remote computer(with alternate credentials)

PowerShell Help
1

Hello Guys,

I am a powershell newbie, learning on v3. I can use the test-connection cmdlet to check if the remote machine is online, but how can I check if I am able to connect to the remote machine successfully [with alternate credentials]? I could simply use the test-path to \server\c$ , but test-path does not allow us to use credentials with UNC path in -path.

Whats the best alternate way to achieve this?

(note - powershell remoting is NOT enabled here)

2

Hey there GJ, Test-Connection does actually have the -Credential parameter in v3. Are you not getting a prompt?

CORRECTION Test-Path also has a -Credential parameter in v3. But I see the problem. I’ll put my thinking cap on if no one else catches it. :slight_smile:

You could run PowerShell itself under the required alternative credentials to bypass the issue.

3

Try New-PSDrive; it’s the equivalent of “net use” in that it maps a drive to the remote system, and allows you to specify alternate credentials.

4

Hey there Dave,

I thought about New-PSDrive, but where I got stuck was removing it from the alternate user’s profile (in case they want to clear it out after their verification was done). But I ran into a problem where Remove-PSDrive didn’t have a -Credential option. It seems like it’s still persisting in the alternate profile though.

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 connections to the server or shared resource and try again
At line:1 char:1
+ New-PSDrive -Name TestDrive -PSProvider FileSystem -Root "\\server01\c$" -Crede ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: [TestDrive:PSDriveInfo] [New-PSDrive], Win32Exception
    + FullyQualifiedErrorId : CouldNotMapNetworkDrive,Microsoft.PowerShell.Commands.NewPSDriveCommand

However, if I log in or run PowerShell alternate user instance, I don’t see the PSDrive I created. Is there a good way to clean it up after your testing is complete?

5

Thanks for the response Dave & Will.

@Will - Test-connection cmdlet can be used only for ping tests. The credential parameter in that is used when you want to ping a remote target machine from a different source machine.

@Dave - Thanks for your suggestion. I have managed to use New-PSDrive and build the script. But I don’t know if there is a more efficient way to test this. Any suggestions would be appreciated.

$servers = Get-Content D:\posh\servers.txt
$cred = Get-Credential
foreach ($server in $servers) {
    if(Test-Connection $server -Count 1 -ErrorAction SilentlyContinue) {
        if(New-PSDrive -Name testshare -PSProvider FileSystem -Root "\\$server\c$" -Credential $cred -ErrorAction SilentlyContinue) {   # I don't know if there is a more efficient way to test this.
            $status = 'online and able to connect'
            Remove-PSDrive testshare
        }
        else {
            $status = 'online but unable to connect'
        }
    }
    else {
        $status = 'offline/not in DNS'
    }
    Write-Host $server - $status
}
6

[blockquote]but how can I check if I am able to connect to the remote machine successfully [with alternate credentials]?[/blockquote]

To circle back to the original question, you’d have to further answer: “Connect via what means?”

Doing this with New-PSDrive tests that you can connect via SMB. It doesn’t tell you anything about WMI, WinRM, or any other protocol. If your goal was to test SMB, then you can either map a drive, or attempt to access (not “test,” but actually read) a known file via UNC, and then trap any errors. SMB doesn’t provide a more “proactive” means of testing, because any such means would actually be a security problem - it’d give a potential intruder a way to more quickly test credentials to see if they worked or not.

7

Don, My idea is to use these steps like a preliminary check before I attempt to run some other commands on the remote machines.

Here is the ugly pseudo style code which could possibly explain better,

$hosts = get-content hosts.txt #this host.txt is a mixture if hosts with some are in domain, some are in workgroup, some could be offline, some could even be non windows OS.
$cred = get-credentials #my domain credential

foreach ($host in $hosts){
  if $host ping success {
    if connection to $host is successful with user $cred { #basically this is to check if the user has access/admin rights on the remote host - this is what my original query is 
      $host >>goodhosts.txt
    } else {
      $host >>online_but_no_rights_on_remotehost.txt
    }
  } else {
    $host >>offline_hosts.txt
    }
}

$goodhosts = get-content (goodhosts.txt) #this list will now only left with the hosts I can do something
foreach ($goodhost in $goodhosts){
  # run other commands - which accepts credential parameter
  eg1 - gwmi $goodhost -cred $cred
  eg2 - get-winevent $goodhost -cred $cred
  eg3 - get-process $goodhost -cred $cred
  etc.
}
8

Yup. That’s a noble goal, but the underlying technology doesn’t have a “test connectivity” function. So it’s going to have to be just out-and-out attempting to access something, and trapping the error. What’s more, you’re going to actually have to try and read or write a file, because simply mapping to the share won’t confirm that file operations will work. There’s just no “ping” function like this in the SMB APIs. So mapping a drive is a good first go - but it won’t necessarily confirm that you can do anything.

But that won’t confirm that Get-WmiObject will work, or Get-WinEvent, or Get-Process (which uses the Remote Registry Service). Each of those APIs might deny you, even if one of the others worked.

Now, look, if your assumption is, “I’m actually just wanting to test if I have local Administrator privileges, because if I do, I can do all of those things.” That’s something you can test directly. Exactly how depends a bit on how you think you’ll become a member of that local group on each machine, but it’s probably easier to test that one assumption that to individually test every single possible API that allows you to connect.

Of course, the alternative is to ditch all that crap and just use Remoting. One check (and there’s a Test- cmdlet for it!) and you’re in or not, period.

9

Thanks for the explanation Don.

Yes, I am already in process enabling the psremoting in my environment which is under review.