Consider the case of a client (let's call it Client) doing a remote Powershell session to a server (ServerA). In this Active Directory environment, the client has full administrative permissions over ServerA. To create the session, the client opens a Powershell console and types:

$ps = New-PSSession -ComputerName ServerA
Enter-PSSession $ps

From this point, the client wants to be able to open a different remote Powershell session to another server (ServerB). Again, he's having administrative permissions over this server as well. If he goes ahead and uses the cmdlet below:

$newPS = New-PSSession -ComputerName ServerB

...this won't work by default due to the Kerberos double hop issue.

A way to make this work is enable delegation for the Client AD account (by adding a dummy SPN and also making sure the Account is sensitive and cannot be delegated isn't enabled), and turn on unconstrained delegation for the ServerA computer account in Active Directory. After this is done, as soon as the 1st remote PS session is entered, issuing a 'klist' will reveal a Kerberos TGT for Client, with the 'forwarded' flag set. The 2nd remote PS session can be made without any issues now to ServerB.

However, in order to make this more secure, as to not have ServerA being able to act on behalf of Client to any target machine, but only against ServerB, constrained delegation can be used. So the ServerA's Delegation tab in AD is changed as to contain only the http/ServerB.fqdn (since we're using Powershell remoting). The problem is that trying to initiate the 2nd connection fails just as in the original case (logon session does not exist). Checking things further, I've noticed that after the 1st session is entered, issuing a 'klist' only reveals an http/ServerB.fqdn Kerberos ticket, and no longer any Kerberos TGTs. However reading the documentation surrounding constrained delegation (namely the S4U2Proxy component) here, it doesn't look as the TGT should be present there.

The question is why cannot constrained delegation be used here or more likely, what is it I'm doing wrong ?

Note that CredSSP is a mechanism that I wouldn't want to use here. Also, even though this entry contains a lot of Active Directory information, I thought it would be relevant for the Powershell community to post here as opposed to the Active Directory section. If this should be moved, please let me know.

Why not create a custom delegated remote session on Server A?

 Create a service account that has admin rights to both machines, and use that for the session RunAs account, and then you can have one more hop from Server A to Server B from that session on Server A.

mjolinor, I'm not sure I follow. The Client account already has administrative rights on both servers, so this could be used as the service account. But I'm not sure how to create a custom delegated remote session on ServerA ?

Here's the start a series of articles that may help:

http://blogs.msdn.com/b/taylorb/archive/2012/03/26/remote-administration-with-powershell-3-0-sessions-part-1.aspx

It's a very good solution - I've just tested it against 2 Windows Server 2012 R2 boxes from a Win 8 client and the 2nd session could be created without any issue.

The only drawback is that for my environment I'm dealing with multiple boxes running only Powershell v2 and also that the script that's been in the works will have to be re-factored. Not that these 2 can't be solved...

If there won't be any other reply concerning a Powershell V2 solution to this issue, I'll have to admit that your answer is closest to what I'm after, mjolinor.