Now up until the other day I had no idea what CredSSP was and the exception that was raised by the LCM was rather new to me:
After spending ages trying to learn what the CredSSP protocol is and why someone would use it (see https://4sysops.com/archives/using-credssp-for-second-hop-powershell-remoting/ and https://technet.microsoft.com/en-us/library/hh849872.aspx ) I decided to check for a DSC resource to enable it...and there is one, xCredSSP. Happy days!
Then came the joy and agony of seeing DSC in action. Joy because the resource is so simple to configure:
xCredSSP Client
{
Ensure = 'Present';
Role = 'Client';
}
OrxCredSSP Server
{
Ensure = 'Present';
Role = 'Server';
}
Seems simple enough, and it just works (the resource that is) but the resource that needed it still failed with the same error. I tried setting my node as the client and then as the server and then as both (by specifying both configurations above) and still nada, nothing, zip - the exception was the same.Then finally (after getting on my knees) it dawned on me that I was right to specify the node as client and server was the right thing to do because of the loop back nature of the Invoke-Command (notice the . after -ComputerName in the example above) but what was missing was the delegation rights that the xCredSSP resource needed to apply. So I added the following:
xCredSSP Client
{
Ensure = 'Present';
Role = 'Client';
DelegateComputers = 'myvm.mydomain.com';
}
Well, that did it. By telling the security provider that implements CredSSP what servers were allowed to be delegated to, it just worked. It is worth noting that the DelegateComputers property supports an array of computer names or even the *.mydomain.com wildcard.
No comments:
Post a Comment