I would like to share interesting experience with Kerberos
and ASA accounts during the Exchange 2013 migrations. We are in the process of
migrating from Exchange 2010 to Exchange 2013.Basically we have 3 regions APAC,
EMEA and US. These three regions we have Exchange gateway servers to accept the
external connections and send/receive emails from external.
Our migration plan is like migrate each site one by one and
pick each server from each site. So this issues started once we completed the
migrations of a APAC region and EMEA
migration phase, just after we rollout Kerberos authentication and
ASA account in APAC site.
Let me explain our environment. Outlook uses SCP records in
the AD to discover Autodicover endpoint, but skype and all uses SRV record configured
with as eg: Autodiscover.abc.com as host for the autodiscover service. As a result
client talk to the autodiscover.abc.com which resolved to mail.abc.com which in turn by resolved to respective LBs
(APAC.abc.com) , EMEA (EMEA.abc.com) and US (us.abc.com).
As we already migrated APAC and EMEA to Ex2013 and in APAC
we have flipped the SPN record to Exchange 2013 ASA (newly created for Exchange
2013 ). As a result us.abc.com is sitting on different ASA (Existing one for
Exchange 2010) than autodiscover.abc.com This breaks Kerberos authentication as
encryption can’t be passed from one ASA (Exchange 2010) to another (Exchange
2013).
This was causing lot of issues, like skype people
unable to see the presence information etc. and they are getting authentication
message.
Unfortunately we discovered that there is absolutely no way to
have two Exchange versions active behind a load balancer without causing
authentication prompts, user access issues and a variety of other impacts to
connected systems . These topics have caused a lot of noise.
Some
background:
How
skype client gets to calendar info:
1.
userA@EMEA.abc.com looks
up for presence of userB@EMEA.abc.com
2.
Skype client looks for srv record to retrieve endpoint for EMEA.abc.com
3.
it finds record _autodiscover._tcp.emea.abc.com which points to
autodiscover.abc.com
4.
autodiscover.abc.com resolves to EMEA.abc.com
5.
EMEA.abc.com resolves to VIP
6.
client connects to Exchange, authenticates via Kerberos and retrieves necessary
info
What's
happening now:
1.
userA@emea.abc.com looks up for presence
of userB@emea.abc.com
2.
Skype client looks for srv record to retrieve endpoint for emea.abc.com
3.
it finds record _autodiscover._tcp.emea.abc.com which points to
autodiscover.abc.com
4.
autodiscover.abc.com resolves to emea.abc.com
5.
Emea.abc.com resolves to VIP
6.
LB routes the session to one of the Exchange servers:
o If the session is routed to any of the
Exchange 2013, Client looks for Autodiscover.abc.com and fails since
Autodiscover.abc.com which is assigned to Exchange 2010 ASA
o
If the
session is routed to the l Exchange 2010 server which still has the
Autodiscover.abc.com entry, its succeeded
Some information on Kerberso,
NTLM, SPN, ASA etc.
When Exchange 2010 SP1 launched their main focus was on to getting in to
the feature that made it possible for MAPI clients (usually internal
Outlook clients) to connect to a load balanced CAS array to be able to authenticate
with Exchange using Kerberos authentication. Previous versions of Exchange server supported Kerberos
authentication since the MAPI clients connected to the mailbox server FQDN and
not FQSN pointing at a load balance in front of a CAS array. With Exchange 2010 RTM, there was no way for MAPI clients to
authenticate using Kerberos authentication
ASA- (Alternate Service Account
): It
is using for configuring Kerberos on CAS server.
An SPN is a
unique identifier for a service on a network that uses Kerberos authentication.
It consists of a service class, a host name, and a port. On a network that uses
Kerberos authentication, an SPN for the server must be registered under either
a built-in computer account (such as NetworkService or LocalSystem) or user account.
SPNs are registered for built-in accounts automatically. However, when you run
a service under a domain user account, you must manually register the SPN for
the account you want to use
Difference in NTLM
and Kerberos authentication:
As the number of the connection increase, there is potential
for a bottleneck in terms of handling NTLM authentication.
Whereas Kerberos authentication is efficient and faster, as
when NTLM must connect to a domain controller to authenticate client. With
Kerberos authentication protocol on other hand, the server is not required to
go to a domain controller. The sever can authenticate the client by examining
the credential provided by the client. Clients can obtain the credentials for a
particular server once and then reuse those credentials throughout a network
logon session
References:-
http://blogs.technet.com/b/exchange/archive/2015/02/20/exchange-2013-and-exchange-2010-coexistence-with-kerberos-authentication.aspx
No comments:
Post a Comment