As Microsoft continue to develop the functionality in Office 365 and Azure AD, the cloud becomes a more and more attractive proposition for organisations that previously would not have been able to move data away from their on-premises servers. And whereas Exchange Online has previously been the first entry point for organisations, the ever-improving security offerings within Azure AD can now offer a better initial introduction to the cloud, in some instances without the need to migrate any data at all.
In this series of blogs I’m going to look at the end-to-end process of taking an organisation from not publishing any Exchange on-premises services to the internet, to publishing Autodiscover, Outlook and OWA/Outlook on the Web externally, secured with Azure AD Conditional Access, Hybrid Modern Authentication and the Azure Application Proxy.
The easiest way to secure Exchange 2016 on-premises with Azure AD is to use Hybrid Modern Authentication (HMA), but this does not currently support OWA or ECP, so an additional solution will have to be implemented to ensure that all services are published securely. My preference is to implement Azure Application Proxy, but to use this, we must first configure OWA and ECP on-premises to be authenticated with Kerberos. This will form Part 1.
In Part 2 and Part 3 we will look at configuring Hybrid Modern Authentication, and then the Azure Application Proxy.
If you want to know more about how kerberos works with Microsoft Exchange, and the differences between what you already know about kerberos I strongly recommend you read this follow up post from my colleague Tristan Watkins: https://tristanwatkins.com/forget-kerberos-before-configuring-exchange-server-for-kerberos/
In my scenario I have two Exchange 2016 servers load balanced using DNS Round Robin.
Configure Alternate Service Account Credential
First, I need to configure an Alternate Service Account credential to support Kerberos Authentication. I have relied heavily on the Microsoft guide here (https://docs.microsoft.com/en-us/exchange/architecture/client-access/kerberos-auth-for-load-balanced-client-access) for this process.
The first step is to create an ASA service account. In this situation it is recommended to use a computer account for this service account rather than a user. A computer account doesn’t allow interactive logon and may have simpler security policies than a user account. To create the new computer account I run the following commands in Active Directory PowerShell:
New-ADComputer -Name EXCH2016ASA -AccountPassword (Read-Host 'Enter password' -AsSecureString) -Description 'Alternate Service Account credentials for Exchange' -Enabled:$True -SamAccountName EXCH2016ASA
You then need to enable AES 256 encryption for the account by running the following command:
Set-ADComputer EXCH2016ASA -add @{"msDS-SupportedEncryptionTypes"="28"}
Once this account has been created I need to deploy the account to my Exchange servers. As I mentioned before, I’ve got two servers in my deployment so I need to deploy the account to a single CAS server first, and then replicate to the other using the following two commands. These should be run from Exchange PowerShell running from the <Exchange 2016 installation directory>\V15\Scripts directory.
.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer EXCH01.MP365LAB.local -GenerateNewPasswordFor MP365LAB\EXCH2016ASA$ .\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer EXCH02.MP365LAB.local -CopyFrom EXCH01.MP365LAB.local
You can confirm that the ASA has been deployed by running the following command
Get-ClientAccessServer EXCH02 -IncludeAlternateServiceAccountCredentialStatus | Format-List Name, AlternateServiceAccountConfiguration
Which should return something similar to the following:
Name : EXCH02 AlternateServiceAccountConfiguration : Latest: 14/09/2018 10:19:22 AM, MP365LAB\EXCH2016ASA$ Previous: <Not set> ...
Finally you need to associate the Service Principal Name to the new ASA by running the following command from Command Prompt:
setspn -S http/mail.mp365lab.co.uk MP365LAB\EXCH2016ASA$
Configure Kerberos in OWA Virtual Directory
Now that your ASA has been configured, the prerequisites for getting Kerberos working with OWA have been completed, and you can now update the virtual directory configuration. You need to switch your OWA and ECP virtual directory settings to use WindowsIntegratedAuthentication rather than Forms-Based for all CAS servers. The easiest way to do this is update the settings in ECP to the following:
This will update the InternalAuthenticationMethods, but may not update the ExternalAuthenticationMethods for the directory. To ensure I have set all the authentication methods correctly I run the following commands:
Set-OWAVirtualDirectory EXCH01\OWA (Default Web Site) -BasicAuthentication:$false -DigestAuthentication:$false -WindowsAuthentication:$true -ExternalAuthenticationMethods Negotiate Set-ECPVirtualDirectory EXCH01\ECP (Default Web Site) -BasicAuthentication:$false -DigestAuthentication:$false -WindowsAuthentication:$true -ExternalAuthenticationMethods Negotiate
Once you have completed all of the above steps, you need to ensure that your client machines include the SPN as an intranet address by going to Internet Properties > Security > Local Intranet and add the URL (in this case https://mail.mp365lab.co.uk, see below). In a production environment this would of course be done via Group Policy.
Kerberos should now run successfully for your users. You can validate this by signing into OWA from a machine inside the domain. You should receive single sign-on (you won’t have to enter a username or password to open OWA) and if you run klist from a Command Prompt you should see an entry similar to the following with the server name of your SPN:
#1> Client: mparker_adm @ MP365LAB.local Server: HTTP/mail.mp365lab.co.uk @ MP365LAB.LOCAL KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canoni calize Start Time: 9/15/2018 9:19:51 (local) End Time: 9/15/2018 19:15:36 (local) Renew Time: 9/22/2018 9:15:36 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0 Kdc Called: DC01.MP365LAB.local
So now we have Kerberos working within the network, we can move on to beginning to secure Exchange with Azure AD functionality, starting with Hybrid Modern Authentication in Part 2 and then adding Azure App Proxy in Part 3.
If you have any questions or comments please either use the comments section below, Tweet me @MikeParker365 or via email blog@mikeparker365.co.uk.
