SOLVED

Resource-based Kerberos constrained delegation is not working

Copper Contributor

Hi all,

 

I have attempted for a week to implement a second hop in powershell remoting by following this article.

Making the second hop in PowerShell Remoting - PowerShell | Microsoft Docs

 

I appears that this is a very easy configuration, however, i was unable to get it working. 

 

The second hop to the last server always fallbacks to NTLM, anonymous user instead of the computer object kerberos ticket.

 

What is going on?

 

Kevin

1 Reply
best response confirmed by kevinpekwk (Copper Contributor)
Solution

I was dumb. Wasted an entire week.

I was trying for Windows admin center SSO.

For any of you out there, Resource-based Kerberos constrained delegation is indeed as straight forward as it gets.

The KDC automatically enables it and it is intrinsic.

To troubleshoot, I have turned on everything in auditpol. Though apparently, you only need to monitor the logons and logoffs.

The NT Authority\Anonymous User using NTLM was logged in the security events which means that the delegation had failed.

I dug through with wireshark, Kerberos logging, all to no avail.

As a last resort, i created a brand new domain user account. Added it into the administrators group on both the frontend and the backend machine and voila.

A little probing identifies the root cause. I had checked this account is sensitive and cannot be delegated.

Thus, the hair-pulling mystery is solved.

1 best response

Accepted Solutions
best response confirmed by kevinpekwk (Copper Contributor)
Solution

I was dumb. Wasted an entire week.

I was trying for Windows admin center SSO.

For any of you out there, Resource-based Kerberos constrained delegation is indeed as straight forward as it gets.

The KDC automatically enables it and it is intrinsic.

To troubleshoot, I have turned on everything in auditpol. Though apparently, you only need to monitor the logons and logoffs.

The NT Authority\Anonymous User using NTLM was logged in the security events which means that the delegation had failed.

I dug through with wireshark, Kerberos logging, all to no avail.

As a last resort, i created a brand new domain user account. Added it into the administrators group on both the frontend and the backend machine and voila.

A little probing identifies the root cause. I had checked this account is sensitive and cannot be delegated.

Thus, the hair-pulling mystery is solved.

View solution in original post