Forum Discussion
NimbostratusKerberos multi-hop supported in APM
We currently have a virtual server set up with APM and we are using it to extract UPN from client certificate and pass along a Kerberos ticket to the back-end server for authentication. This part is working fine, but the application team now wants to pass along these credentials to a second server via the first.
When we test internally (bypass APM and go directly to back-end server which then sends to second server), multi-hop actually works and we can see the impersonation level of the ticket set to "Delegation." When we test through APM it fails and the impersonation level set to "Impersonate." From what I read, impersonation level needs to be "Delegation" for multi-hop.
Is multi-hop supported in APM? It looks like APM sets impersonation level to "Impersonate" and I don't see any options to change this.
3 Replies
- Kevin_Stewart
Employee
The trick for multi-hop constrained delegation (what APM does) is to enable constrained delegation at every hop. So in your case you have an account in AD that is allowed (and constrained) to delegate to a specific service (presumably a web server). The account that owns that service must then be given (constrained) delegation rights to the downstream service.
- Kevin_Stewart
Correct.
The APM SSO service account must be able to delegate to the first service (the web server). The first service must then be able to delegate to the second service (the database).
- Kai_Wilke
MVP
Hi John,
You can mix a classic Kerberos Delegation (as defined in RFC1510) on the first hop and then use Kerberos Constrained Delegation on the second hop, to delegate the user credentials to a third hop.
But you can not mix Kerberos Contrained Delegation on the first hop with classic Kerberos Delegation on the second hop. It will simply fail, since the second hop does not get a forwardable TGT from the first hop to perform a classic Kerberos Delegation to the the third hop.
Since the F5 performs a Kerberos Constrained Delegation with Protocol Transition on the first hop, you have to make sure that every subsequent hop uses the same mode. As long each hop uses this mode, you can delegate the credentials to as many chained hops as you like. There is no limitation...
Note: If you experience any authentication problems between two hops in your chain, then just check the applications and the Kerberos settings of the involved hops, since Protocol Transition completely detaches the incomming and outgoing authentication on each individual hop without having any relationship to previous hops...
Cheers, Kai
