Kerberos delegation on 11.5.3

APM can absolutely do this, but it isn't a simple delegate service as you're describing. APM is an authentication proxy, and as such uses separate processes for both client side and server side Kerberos. The client would pass a non-delegated ticket to the client side of APM, and APM would perform Kerberos Protocol Transition and Constrained Delegation to the server on the server side. This is essence allows you to do one side without the other. So to clarify, APM cannot consume and delegate forwarded Kerberos tickets as you're describing.

For APM Kerberos to work, you need a client side APM Kerberos configurtion:

https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-aaa-auth-config-11-2-0/4.html?sr=47873427

which once successful produces a set of session variables, in particular session.logon.last.username (ex. bob.user@domain.com) in UPN format. Then you apply an APM Kerberos SSO profile to the access policy:

https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-sso-config-11-2-0.pdf?sr=47873443

This requires as input the username and the domain, which can be extracted from the UPN in the client side Kerberos transaction using a variable assignment agent in the visual policy:

session.sso.token.last.username = return [lindex [split [mcget {session.logon.last.username}] "@"] 0]

session.logon.last.domain = return [lindex [split [mcget {session.logon.last.username}] "@"] 1]

The simplest configuration, with client side and server side Kerberos would look something like:

start -> 401 Auth -> Kerberos Auth -> Variable assign -> Allow

where the 401 and Kerberos Auth agents would handle client side Kerberos, the variable assignment would split the UPN into separate username and domain session variables, and the SSO would be applied to policy itself and be triggered at the Allow block.