Kerberos Question

Technically speaking, APM Kerberos SSO (server side) employs Kerberos Protocol Transition (KPT - S4U2Self) and Kerberos Constrained Delegation (KCD - S4U2Proxy). APM uses an account in the realm as a delegation anchor. A Kerberos AS_REQ is generated for this delegation account to get a TGT. The first TGS_REQ is the S4U2Self to get a delegated TGT for the user, and the second TGS_REQ is the S4U2Proxy KCD request for a ticket to the target service.

The SPN of the target pool member can be derived in one of three primary ways:

1. By default APM Kerberos SSO will perform a reverse DNS lookup into the realm with the chosen pool member's IP address. The returned name is then crafted into a SPN value (assuming the local system "owns" the web service)

    

2. A "SPN pattern" can be applied to the APM Kerberos SSO profile to circumvent the above lookup for a statically defined string value (ex. HTTP/target-service.domain.com@DOMAIN.COM)

    

3. You can use a wildcard in the SPN pattern field to either derive the hostname from the incoming host name - %h, or from a local Hosts entry based on the pool member IP address - %s (ex. HTTP/%s@DOMAIN.COM)

    

Ah, good questions.

So first of all, you need at least TWO accounts in the domain/realm - the "delegator" (that which you delegate from) and the "delegatee" (that which is delegated to). The first is nothing more than a user account given a servicePrincipalName (SPN) attribute, and the second is the target, the web server. Any form of Kerberos delegation implies that one service is delegating to another service on behalf of another party (usually the user). For instance, simple forwarding delegation allows a user to authenticate to a Kerberos-based SQL server behind a Kerberos-based SharePoint server without having direct access to or even knowledge of the SQL server. The user authenticates to SharePoint and then gives SharePoint the authority to request Kerberos tickets to other services (with constrained limits). In this case the user requests two TGTS - the TGT it uses to request a ticket for services directly (the SharePoint server), and a forwarding TGT - the TGT it gives to SharePoint to allow it to request tickets on the user's behalf. In the case of APM, as a full proxy it is always the case that the client cannot send a forwarding TGT through APM, so you need another kind of Kerberos delegation called service for user to self (S4U2Self) or also called Kerberos Protocol Transition. This allows the service providing the delegation to not only delegate to other services, but also authenticate and fetch an original TGT on behalf of the real user (who cannot otherwise perform this function). As it turns out, the RFCs mandate that KPT always involves KCD (constrained delegation), and for good reason, so that's why APM does KPT and KCD (S4U2Self and S4U2Proxy). And since APM isn't technically a member of the domain, it needs this delegation account as its "anchor".

On the second question regarding the "Use any authentication method" option, that is Microsoft-speak for Kerberos Protocol Transition. It's always befuddled me why they didn't just say that or at least mention it in the help, but that's what it is and what you need for the delegation account to be able to perform KPT and KCD.

Kerberos Protocol Transition is essentially a form of impersonation. You're providing a mechanism (a Kerberos protocol extension) that allows one service to request and use a user's ticket granting ticket (TGT) on that user's behalf. KPT is generally used when a client cannot communicate with a KDC directly, and the relevant references, RFC4120 and MS-SFU, don't explicitly define how that client should actually authenticate. So to that end, there's an inherent security risk if proper client side authentication isn't performed correctly.

As far as enabling the "Use Any Authentication Protocol" setting, that enables the Kerberos Protocol Transition extension to work for the designated delegation account. It is required for that function and is required for APM Kerberos SSO to work.

Again, the important thing here is that you perform appropriate client side authentication. Can you elaborate on what your security team is questioning?