Enabling Kerberos Authentication in a Exchange Server 2016 Environment

Create alternate service account

All Exchange servers running Client Access services that share the same namespaces and URLs need to use the same alternate service account credentials. In general, it's sufficient to have a single account for a forest for each version of Exchange. alternate service account credential or ASA credential.

Create a service account using dsa.msc

Now we have to assign a password to all servers part of the namespace. we can use the built-in script for this purpose. This script will create a system generated password, assign that password to all array member servers and also it will update that generated password to the AD.

To verify this activity

From eventvwr

Using powershell

Identify the Service Principal Names that should be associated with the ASA

After you create the alternate service account, you must determine the Exchange service principal names (SPNs) that will be associated with the ASA credentials. The list of Exchange SPNs may vary with your configuration, but should include at least the following. In my lab i am going to associate the ASA with all SPNs.


• http Use this SPN for Exchange Web Services, Offline Address Book downloads, and the Autodiscover service.

• exchangeMDB Use this SPN for RPC Client Access.

• exchangeRFR Use this SPN for the Address Book service.

• exchangeAB Use this SPN for the Address Book service.

Associating SPNs with ASA

The following command provides an example of how to set the SPNs on the shared ASA credential. The setspn command with this syntax must be run once for every target SPN that you identify.

Enabling kerberos authentication for outlook clietns

Since i am using MAPI over HTTP for outlook connections, i am assigning kerberos only on the MAPI virtual directory. I you are using RPC over HTTP, you have to assign this to outlook anywhere VD.

Get-MapiVirtualDirectory -Server CAS-1 | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm, Negotiate

Validating Exchange client kerberos authentication

After you've successfully configured Kerberos and deployed the RollAlternateServiceAccountPasswordl.ps1 script, verify that clients can authenticate successfully.

Validating from outlook

goto outlook connection status and make sure the authentication method is "Negotiate".

Validating from CAS logs

goto C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Mapi and open the latest log and check for the word "Negotiate".

We can also check the OAB logs for the same.

Exchange 2016 CAS load balancing using single namespace - Lab simulation

When you first install Exchange Server 2016 it is pre-configured with default URLs for the various HTTPS services such as OWA, ActiveSync, EWS, and others.

The default URLs contain the fully qualified domain name of the server. So for example if your server name is “ex2016srv1.lyncit.net” then the default URL for OWA will be “https://ex2016srv1.lyncit.net/owa“.

Problem with this approach is

1. Users cant remember the server FQDN
2. We cant load balance
3. Internal domain will not valid for external recprds like domain.local

The recommended practice is to change the URLs configured on your Exchange 2016 servers to aliases or generic host names such as “mail.domain.com” after you first install the server.

My lab setup

DC1.LYNCIT.NET - Domain controller
EX2016SRV1.LYNCIT.NET - Exchange 2016 server1
EX2016SRV2.LYNCIT.NET - Exchange 2016 server2
EX2016SRV3.LYNCIT.NET - Exchange 2016 server3

As i mentioned earlier all my URLs for the various services are configured with local server FQDN.

If you take EX2016SRV1,

OWA internal URL configured as - https://ex2016srv1.lyncit.net/owa
Outlook anywhere - ex2016srv1.lyncit.net
ECP - https://ex2016srv1.lyncit.net/ecp
OAB - https://ex2016srv1.lyncit.net/oab
EWS - https://ex2016srv1.lyncit.net/EWS/Exchange.asmx
MAPI - https://ex2016srv1.luncit.net/mapi
ActiveSync - https://ex2016srv1.lyncit.net/Microsoft-Server-ActiveSync
AutoDiscover - https://ex2016srv1.lyncit.net/Autodiscover/Autodiscover.xml

We can see the above information by using ther respective Get command.

For OWA its "Get-OWAVirtualDirectory".

In this article we are going to implement load balancing using single namespace method.

I planned to use "mail.lyncit.net" as a namespace for the services.

Create DNS record

First we have to create a DNS A record for "mail.lyncit.net" for each server IP. Its nothing but a DNS roundrobin method.

Assign namespace to virtual directories

We have to assign the namespace to all HTTPS services virtual directories using the respective "Set" command.

To set internal URL using powershell

Get-OwaVirtualDirectory -Server ex2016srv1.lyncit.net | Set-OwaVirtualDirectory -ExternalUrl $null -InternalUrl https://mail.lyncit.net/owa
Get-OabVirtualDirectory -Server ex2016srv1.lyncit.net | Set-OabVirtualDirectory -ExternalUrl $null -InternalUrl https://mail.lyncit.net/oab
Get-EcpVirtualDirectory -Server ex2016srv1.lyncit.net | Set-EcpVirtualDirectory -ExternalUrl $null -InternalUrl https://mail.lyncit.net/ecp
Get-mapiVirtualDirectory -Server ex2016srv1.lyncit.net | Set-mapiVirtualDirectory -ExternalUrl $null -InternalUrl https://mail.lyncit.net/mapi
Get-ActiveSyncVirtualDirectory -Server ex2016srv1.lyncit.net | Set-ActiveSyncVirtualDirectory -ExternalUrl $null -InternalUrl https://mail.lyncit.net/Microsoft-Server-ActiveSync
Get-WebServicesVirtualDirectory -Server ex2016srv1.lyncit.net | Set-WebServicesVirtualDirectory -ExternalUrl $null -InternalUrl https://mail.lyncit.net/EWS/Exchange.asmx

we have to do the above for all servers.

Create certificate

Since i have internal CA i am going to use self signed certificate option to assign the request to internal CA immediately and sign the certificate.

Click finish. It will sent the request to internal CA and if you have everything setup correctly, you will get a signed certificate and you can assign that to IIS.

We have to assign this certificate to IIS. we can also use this cert for SMTP, POP and IMAP.

Restart IIS on all three servers.

Verify the outlook connectivity

Before the change

 After the change

Test outlook connection switch over

1. Ping mail.lyncit.net and check to which server IP its resolving
2. Down that server
3. Outlook will disconnect

4. I waited for some time but my local machine cache was not flushed. So i did ipconfig /flushdns and it look the other CAS IP. Now my outlook is connected.

What happened to CAS array in Exchange Server 2013

What happened to CAS array in Exchange Server 2013?

How CAS load balancing in Exchange Server 2013?

How CAS high availability works in Exchange Server 2013?

How outlook clients connects to Exchange Server 2013?

I personally had all these questions in my mind and got it cleared after gone through some good articles. So thought of share that will you all.

What is CAS array?

Introduced with Exchange 2010, CAS arrays provided a method to group a set of CAS servers together in such a way that they could be addressed as a single entity (and had a single IP address and FQDN). Individual servers could join and leave the array over time and the array would keep functioning as long as a single server was active. Its not a load balance mechanism.

CAS role in Exchange Server 2013

The Exchange 2013 version of the CAS is a much simpler beast as it is purely an authentication (are you authorized to connect to Exchange?) and proxy/redirect (where do you need to go to find your mailbox?) server. No processing is performed of mailbox data by the CAS; all it does is to send on client requests to connect to the mailbox server that hosts the currently active copy of their mailboxes via HTTPS (no MAPI RPCs).

How outlook connects to 2013 CAS

The RPC Client Access namespace, which was introduced in Exchange 2010 to handle the concept of RpcClientAccessServer described above is no more and Exchange no longer uses FQDNs of CAS servers or arrays to locate user mailboxes. Instead, CAS uses the unique GUID assigned to the mailbox. When an incoming client connection must be processed, CAS looks up Active Directory to find details of the mailbox via its GUID (including the database that hosts the mailbox) and Active Manager will tell CAS what mailbox server currently hosts the active copy of the database.

There are many reasons why Microsoft has taken this route for Exchange 2013, but perhaps the most basic is to uncouple the functionality of CAS from mailbox servers so that both can function independently of each other in terms of geographic location (a CAS in one datacenter can service requests going to a mailbox server in another) and software versions (you won’t have to update CAS and mailbox servers with the same software in future).

CAS high availability in 2013

As mentioned earlier outlook clients will access their mailboxes using MAPI over HTTP/HTTPS method.

When we look the outlook anywhere configuration of each CAS server, the InterHostname property was configured with its host name by default. So when the outlook connects with that CAS and if that is offline, outlook will take time to switch the connection to other available CAS server through AutoDiscover.

To overcome this we can configure single namespace instead of unique server FQDN. we also need to make sure that the DNS record created for that name space and points to the CAS servers. In this way we can use DNS round robin for load balancing till we get HLB.

without HLB the outlook takes around 20 secs to time out and then re-establish connectivity to the other IP address that the name space resolves to.

MAPI over HTTP

What is mapi over http

Messaging Application Programming Interface (MAPI) over HTTP is a new transport protocol implemented in Microsoft Exchange Server 2013 Service Pack 1 (SP1). MAPI over HTTP improves the reliability and stability of the Outlook and Exchange connections by moving the transport layer to the industry-standard HTTP model. This allows a higher level of visibility of transport errors and enhanced recoverability. Additional functionality includes support for an explicit pause-and-resume function. This enables supported clients to change networks or resume from hibernation while maintaining the same server context.

Implementing MAPI over HTTP does not mean that it is the only protocol that can be used for Outlook to access Exchange. Outlook clients that are not MAPI over HTTP capable can still use Outlook Anywhere (RPC over HTTP) to access Exchange through a MAPI-enabled Client Access server.

Benefits of MAPI over HTTP

• Enables future innovation in authentication by using an HTTP based protocol.
• Provides faster reconnection times after a communications break because only TCP connections—not RPC connections—need to be rebuilt. Examples of a communication break include:
• Device hibernation
• Changing from a wired network to a wireless or cellular network
• Offers a session context that is not dependent on the connection. The server maintains the session context for a configurable period of time—even if the user changes networks.

Prerequisites

1. Upgrade Outlook clients to Outlook 2013 SP1 or Outlook 2010 SP2 and updates KB2956191 and KB2965295 (April 14, 2015).
2. Upgrade Client Access and Mailbox servers to Exchange 2013 SP1

Note : All Client Access servers must be upgraded to Exchange 2013 SP1 before enabling MAPI over HTTP. Otherwise, Outlook can fail to connect to mailboxes.
Failure to upgrade the all the Mailbox servers in a Database Availability Group (DAG) can result in email delays and a client requirement to restart Outlook in case of a database failover.

3.       On all Exchange 2013 servers, you need to install Microsoft .NET Framework 4.5.2

4.     On all Exchange 2013 SP1 Client Access servers, add the COMPLUS_DisableRetStructPinning Windows environment variable by performing the following steps.

a.     In a Command prompt window, run systempropertiesadvanced and click Environment Variables.

b.     In the System variables section, click New and enter the following information.

o    Variable name   COMPLUS_DisableRetStructPinning

o    Variable value   1

c.     When you are finished, click OK.

How to configure MAPI over HTTP

1.       Virtual directory configuration   Bydefault, Exchange 2013 SP1 creates a virtual directory for MAPI over HTTP. You use the Set-MapiVirtualDirectory cmdlet to configure the virtual directory. You must configure an internal URL, an external URL, or both

Set-MapiVirtualDirectory -Identity "Contoso\mapi (Default Web Site)" -InternalUrlhttps://Contoso.com/mapi -IISAuthenticationMethodsNegotiate

2.     Certificate configuration   The digital certificate used by your Exchange environment must include the same InternalURL and ExternalURL values that are defined on the MAPI virtual directory. Make sure the Exchange certificate is trusted on the Outlook client workstation and that there are no certificate errors, especially when you access the URLs configured on the MAPI virtual directory.

3. Update server rules   Verify that your load balancers, reverse proxies, and firewalls are configured to allow access to the MAPI over HTTP virtual directory.
4. Enable MAPI over HTTP in your Exchange Organization

        Set-OrganizationConfig -MapiHttpEnabled $true

Test MAPI over HTTP connections

You can test the end-to-end MAPI over HTTP connection by using the Test-OutlookConnectivity cmdlet.

Test-OutlookConnectivity -RunFromServerId ContosoMail -ProbeIdentity OutlookMapiHttpSelfTestProbe

Logs for MAPI over HTTP activity are at the following locations:

• %ExchangeInstallPath%Logging\MAPI Address Book Service\
• %ExchangeInstallPath%Logging\MAPI Client Access\
• %ExchangeInstallPath%Logging\HttpProxy\Mapi\

Note: This will applicable to Exchange server 2016.