Monday, 6 June 2016

Constrained Kerberos Delegation - Battling the hound of hades

Battling the what?... it’s interesting to note that the source of the name is from a Greek mythology creature named Cerberus. Often referred to as "hound of Hades" who guards the gates of the underworld, preventing the dead from leaving... Sounds more management to me not an authentication protocol but you’re not here for my ramblings so let get on with it.

Goal: We require NTLM authentication enabled for outlook anywhere clients. This will remove the dreaded outlook prompts. Our LAB environment consists of 2x Exchange 2010 SP3 servers using F5 GTM and LTM technologies to load balance all Exchange services to and from these servers. 

Internally clients connect to an internal virtual server which proxies the connections directly to the exchange servers which authenticates the user.  Internally outlook anywhere is working.

Externally users connect to an external virtual server. Cached NTLM credentials are used to complete pre authentication. If the authentication fails or local creds no do exist the user is prompted for authentication.
Once pre-authentication has completed successfully the F5 APM takes these user credentials and then requests or translates that into a Kerberos service ticket on the user’s behalf from Active Directory, and then present the service ticket to the Client Access server in order to access the user’s mailbox. This service ticket is only for the destination service required and, therefore, ‘constrained’. 

Issue:  Currently we see the APM completing pre-authentication and the Kerberos delegation appears to be completing correctly. Auto discover and Web services are working correctly via a Kerberos authentication backend. But Outlook anywhere is not.

The reply from exchange is *[:status][503 RPC Error: 6ba] 
RPC error 6ba. Based on MS-ERREF documents, means: RPC_S_SERVER_UNAVAILABLE. (RPC server is not available.)

This error happens after BIG-IP authenticates the user, and performs KCD to the CAS server. On the Exchange server we have enabled Kerberos debugging and we still see the following error:
Log Name:      System
Source:        Microsoft-Windows-Security-Kerberos
Date:          31/03/2016 3:15:56 PM
Event ID:      3
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
A Kerberos Error Message was received:
on logon session
 Client Time:
 Server Time: 5:15:55.0000 3/31/2016 Z
Extended Error: 0xc0000272 KLIN(0)
Client Realm:
 Client Name:
 Server Realm: XXXXX
Server Name: oaspn@DOMAIN.COM
Error Text:
 File: 9
Line: f09
Error Data is in record data.

Resolution: A couple of issues were found. 

1. FIREWALL RPC issues were stopping RPC traffic from being sent to the the exchange servers. 
2. Incorrect values in the f5 deployment guide. (eg. processmodel.identityType not processodel.identityType)
3. SPN account was not saving the namespace as a allow

I completed a packet capture on the DC and confirmed the ERR_BADOPTION Status: NO_MATCH

The most common scenario is a request for a delegated ticket (unconstrained or constrained delegation). You will typically see this on the middle-tier server trying to access a back-end server. There are several reasons for rejection:

1. The service account is not trusted for delegation

2. The service account is not trusted for delegation to the SPN requested

3. The user’s account is marked as sensitive

4. The request was for a constrained delegation ticket to itself (constrained delegation is designed to allow a middle tier service to request a ticket to a back end service on behalf on another user, not on behalf of itself).

Having a closer look at the APM Delegation account I thought the “No Match” error was related to the url not being listed in the “Services to which this account can present delgated credentuals” After some testing I could see that the setspn is meant to add the url into the msDS-AllowedToDelegateTo AD field on the APM Delegation account which wasn’t happening for what ever reason. So I manually added these in and it started working.

It would appear the order is important even when things are working well. The APM Delegation account must be set to “Trust this user for delegation to specified service only” before the setspn is completed otherwise the SPN url will not be added to msDS-AllowedToDelegateTo field. 

why the setspn isn't apply the namespace I'm unsure and using a number namespaces appears to hit certain limits. hacking the service account isn't ideal but it seems to work for now....