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
Computer: EXC1.corp.domain.com
Description:
A
Kerberos Error Message was received:
on
logon session
Client
Time:
Server
Time: 5:15:55.0000 3/31/2016 Z
Error
Code: 0xd KDC_ERR_BADOPTION
Extended
Error: 0xc0000272 KLIN(0)
Client
Realm:
Client
Name:
Server
Realm: XXXXX
Server
Name: oaspn@DOMAIN.COM
Target
Name: oaspn@DOMAIN.COM@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....
No comments:
Post a Comment