Forum Discussion
APM SSO - Kerberos double hop delegation issue
We are also experiencing the same scenario with Hitachi HCP Anywhere. Waiting to hear a response from F5 on the issue.
- Antonio_Macia_RAug 11, 2016
Nimbostratus
After opening a case with F5 we confirmed that they deny by default the double delegation. The RFC leaves this behaviour as optional, implementation dependant. F5 decided to not allow the double delegation and there is no way to change this except filling a "Request For Enhancement"
Find below the official response:
This is not a bug. There is no RFC stating that a GSSAPI client must delegate if OK-AS-DELEGATE flag is set in a Service ticket. There are GSSAPI implementations that do not honor the OK-AS-DELEGATE flag.
OK-AS-DELEGATE is a Microsoft extension added to RFC4120 that allows the administrator of a Kerberos realm to communicate with a particular service that is trusted for delegation. It can be set on AD with the TD userAccountControl bits.
This Kerberos flag is just an indication or recommendation by KDC to the GSSAPI client that it can request delegation for that service.
From RFC4120 (5.3 Tickets -> flags): ok-as-delegate: This flag indicates that the server (not the client) specified in the ticket has been determined by policy of the realm to be a suitable recipient of delegation. A client can use the presence of this flag to help it decide whether to delegate credentials (either grant a proxy or a forwarded TGT) to this server. The client is free to ignore the value of this flag.
GSS-API leaves the determination of whether delegation is desired to the client application turning on "deleg_req_flag" (GSS_C_DELEG_FLAG)
From RFC2743 (1.2.9: Delegation): The GSS-API allows delegation to be controlled by the initiating application via a Boolean parameter to GSS_Init_sec_context(), the routine that establishes a security context.
However, the simple delegation control provided by GSS-API should always be able to over-ride other mechanism-specific delegation controls; if the application instructs GSS_Init_sec_context() that delegation is not desired, then the implementation must not permit delegation to occur.
RFC5896 adds a new input flag "deleg_policy_req_flag" (GSS_C_DELEG_POLICY_FLAG) to request delegation to the given target only when approved by central policy.
If the initiator sets the deleg_policy_req_flag (and not deleg_req_flag), the Kerberos GSS-API mechanism MUST only delegate if OK-AS-DELEGATE is set [RFC4120] in the service ticket. Other policy checks MAY be applied. If the initiator sets deleg_req_flag (and not deleg_policy_req_flag), the behavior will be as defined by [RFC2743]. If the initiator set both the deleg_req_flag and deleg_policy_req_flag, delegation will be attempted unconditionally.
A Request For Enhancement (RFE) could possibly be requested, if you are interested in this, I can follow up with the RFE template to be filled.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com