Hi,
I was looking into this stuff, and I found there were:
one to one session, with the Enter-PSSession
and
one to many, with the Invoke-command.
But what about a commande like (and others like it)
Get-wmiObject -Class win32_bios -ComputerName DC1
Where does that fit in to all of this?
Is it a 3. category by it self?
Or it isn’t remoting at all?
Is it also secure? Does it also use http? Is it also encrypted? etc. etc.
Could you call it implicit remoting?
And one more question. What about the commandLet Get-ADcomputer -computername xyz. Is that also some kind of remoting, or is it only working because you have RSAT installed, so that in-fact all the remoting is done between the RSAT components and the DC?
Get-WMIObject doesn’t use PowerShell Remoting for it’s calls. Like any other remote WMI query or command, it’s using RPC. Get-CIMInstance, however, does use PowerShell Remoting.
And Get-CimInstance doesn’t use PowerShell Remoting. It uses the same underlying protocol, WinRM, but it isn’t reliant on PowerShell per se. It’s a CIMSession, not a PSSession.
So remoting i PS isn’t consistent in using http. Some cmdLet’s use http, others use LDAP and others RPC. I was told that in PS remoting was done over http with one secure port, and therefore it was much easier to get through firewalls and stuff. But it looks like that might not be the case after all, or? (or am I missing something)?
If you’re having problems getting all these different ports opened in your firewall by your admin. Would it be an accetabel solution to use the Get-ADcomputer, Get-WmiObject, Get-CIMInstance and others the like, inside an invoke-command so that the actual RPC call or ldap call are made only at the remote computer itself, and thereby bypassing the firewall (except for the http which would be open in the FW of course)?
No, PowerShell Remoting is a specific technology and it absolutely uses HTTP. Specifically, it uses WS-MAN, the Microsoft implementation of which is called WinRM.
However, that isn’t the only technology by which a cmdlet might connect to a remote machine. Read “Secrets of PowerShell Remoting,” but, briefly, other cmdlets might use other protocols. When talking to AD, for example, it makes sense to use LDAP, because that’s what AD has always used and will continue to use. Get-WmiObject is deprecated - it uses an outdated protocol called RPC. But just because those are happening inside PowerShell does not make them “PowerShell Remoting.” They aren’t.
And yes, it’s entirely acceptable to use Invoke-Command as you suggest. Whether or not that bypasses a firewall very much depends on the technology. With Get-WmiObject, a call to the local computer uses COM, not DCOM, and so RPC doesn’t become involved. With AD, LDAP always goes “out and back in,” meaning the firewall would still potentially be a problem.
These are all different technologies originating in different times. There’s no one, easy answer that covers everything.
Oh, I ment (and forgot to specify it) if my local computer was on one side of the FW and the remote on the other side. This was the scenario I was referring to and I guess the Invoke-command would mean I would go through the FW via HTTP and hit the remote computer from where the LDAP call to the DC would be made. Afterwards the resulting obj’s would be returned back to my local machine via HTTP, “bypassing” the Ldap port in the FW (both directions) but using the port for HTTP.
Regarding all the different technologies in PS, I can totally understand that, I’m just trying to make sense of it all in my head.
And so that would start engaging some double-hop authentication problems.
Remoting delegates your credential from you to Machine A; it isn’t, by default, allowed to send it further. So most calls would fail without additional setup. Again, “Secrets of PowerShell Remoting” :).
As the remote machine in my scenario actually would be one of the DC’s as that’s where the Active Directory modul would reside, I think it would work (no double-hop authentication problem)
