Exchange 2016 Edge Transport Server and IPv6

I’ve never paid too much attention to IPv6, except for turning it off completely in case of strange issues. And admit it, most of you do the same.

Security is getting more and more important, and as a messaging consultant you want your Exchange environment top notch. In the Dutch community NGN I was pointed to internet.nl where you can check your presence on the Internet. Lots of red crosses when it comes to messaging and IPv6, reason for me to start looking into that.

In this blogpost I will focus on the Exchange 2016 Edge Transport server (I have two for inbound and outbound email) and the Exchange 2016 Mailbox server, which is load balanced behind a Kemp LoadMaster LM3600.

Exchange 2016 Edge Transport server

Although a lot of Exchange admins disable IPv6 on their Exchange servers (through a registry key) in case of strange issues, it is not a recommended solution.

I have two Exchange 2016 Mailbox servers, one Exchange 2013 multi-role server and two Edge Transport servers (one Exchange 2013 and the other Exchange 2016) for inbound and outbound SMTP traffic. There are two MX records which point to these Edge Transport servers. Both have an external IPv4 address.

The first step of course is to add an IPv6 address to the network adapter of the Edge Transport servers, your provider should be able to supply you with a sufficient IP range.

image

This should not result in too much issues. If you want to ping your server on IPv6 make sure that the File and Printer Sharing (Echo request – ICMPv6-In) inbound rule is enabled in Windows Firewall.

The next step is to enable the Edge Transport server for IPv6 usage. The Mailbox server has everything setup by default, but the Edge Transport server is only configured for IPv4.

Open Exchange Management Shell and enter the following command:

Get-ReceiveConnector "*default*" | Select Bindings,RemoteIPRanges

And you’ll see that the Default Receive Connector is only bound to IPv4 and only accepts remote IPv4 connections:

image

You can bind IPv6 to the Default Receive Connector ([::]:25) and have it listen to all available remote IPv6 addresses (“,”::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) by using the following command in the Exchange Management Shell:

Get-ReceiveConnector "*default*" | Set-ReceiveConnector -Bindings "0.0.0.0:25","[::]:25" -RemoteIPRanges "0.0.0.0-255.255.255.255","::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff"

You can use the Get-ReceiveConnector “*default*” command again to check if the changes were carried out correctly.

image

When I send an email from my Gmail account to a mailbox on my Exchange 2016 environment and check the header information I can see that it’s actually using my IPv6 address:

image

When using a site like https://internet.nl I can see that my servers are configured correctly.

image

Summary

In contrast to the Exchange 2016 Mailbox server, which is fully configured for use with IPv6, the Exchange 2016 Edge Transport server is only configured for IPv4.

This is not a big problem though, after adding an external IPv6 address to your Exchange 2016 Edge Transport server you can bind the local IPv6 address (or range) to the Default Receive Connector. You can also add all remote IPv6 ranges to the Default Receive Connector. After adding the FQDN to public DNS using an AAAA record you’ll see email coming in on IPv6.

Single Sign-On and Azure AD Connect Pass-Through Authentication

In my previous blogpost I discussed Azure AD Connect Pass-Through Authentication (PTA), how it works and how it can be configured. In that blogpost I did not enable Single Sign-On (SSO) and that was also the first comment I got, within one or two days. Enabling SSO and how it works it this blogpost’s topic.

Authentication flow

I already explained the authentication flow when using PTA. When accessing a service in Office 365 you are redirected to Azure AD, you enter your credentials and the credentials are placed in the Azure Service Bus. The Azure AD Connect server retrieves these credentials from the Service Bus and presents them to the on-premises Domain Controller. The result is returned to the service bus and you’re granted access, or denied when something is wrong of course.

image

So, what happens if you enable SSO in the Azure AD Connect wizard? Enabling SSO is just a matter of checking the Enable single sign-on checkbox in the Azure AD Connect wizard:

image

Note. I skipped most of the configuration steps since this is identical to the configuration steps in the previous blogpost.

During the Azure AD Connect wizard you also must enter your on-premises administrator credentials, these are needed to configure your on-premises Active Directory to enable SSO with PTA.

To be fair, it’s not true SSO as with federation (through ADFS), but it is seamless Single-Sign On (sSSO). When enabling SSO in the Azure AD Connect wizard, users only need to enter their logon name when accessing services in Office 365, for example with Outlook Web App:

image

When you are on a domain joined workstation that has access to a Domain Controller, you only have to select the appropriate user account. The password is automatically returned to Azure AD and if all is well you are granted access to Outlook Web App.

If you don’t want to select or enter a logon name you can also use domain hints. In combination with Outlook Web App you would use a URL like https://outlook.office.com/owa/contoso.com. If you do so your current credentials (again, on a domain joined workstation that has access to a Domain Controller) are automatically passed through and you are granted access.

Seamless Single-Sign On under the hood

But how does this sSSO actually work under the hood.

When enabling SSO in the Azure AD Connect wizard you have to enter your on-premises domain administrator account. This is used to create an additional computer object in Active Directory called AZUREADSSOACC.

image

This computer account is used to create a shared Kerberos key between your on-premises Active Directory and Azure Active Directory, needed for creating the sSSO experience.

During logon in this scenario, the following 8 steps occur:

image

  1. The client accesses a service in the Microsoft cloud, for example OWA via https://outlook.office.com/owa.
  2. The request is redirected from Office 365 to Azure Active Directory.
  3. Access is denied, and a 401 error is returned to the client.
  4. The client accesses a local Domain Controller and requests a Kerberos token.
  5. A Kerberos session ticket is returned to the client.
  6. The session ticket is presented to Azure Active Directory. Since Azure Active Directory has a shared ticket with your on-premises Active Directory is can generate a Kerberos token for the client to use.
  7. The Kerberos token is returned to the client
  8. The Kerberos token is presented to Office 365 and access is granted. The user can now start using OWA.

As you can see this only works for domain joined clients that have access to a local Domain Controller. If they don’t have access to a local Domain Controller the regular PTA process as shown in the beginning of this blogpost (and previous blogpost) is followed.

Note. For the client to automatically pass the credentials, the Azure AD endpoints must be in the intranet zone

image

Tip. Use GPO to change this for all clients in your network.

If you use your browser and navigate to Exchange Online you will still be prompted to enter your username (or select a username when used previously) but you are not required to enter your password:

image

If you use a domain hint in your URL like https://outlook.office.com/owa/inframan.nl, then the account is automatically logged on. One small but strange note, this is supported by Microsoft Internet Explorer, but not by the Microsoft Edge browser (at least not at the moment of writing, early November 2017). This might change in the future though.

To get this working with Outlook 2016 (or fully patched Outlook 2013 that supports Modern Authentication) we need to enable OAuth on a tenant level. To achieve this, logon use Remote PowerShell in Exchange Online using the following commands:

$Cred= Get-Credential 'administrator@contoso.onmicrosoft.com'
$Session= New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/PowerShell-LiveID -Credential $Cred -Authentication Basic -AllowRedirection
Import-PSSession -Session $Session

And when logged in enter the following command:

Set-OrganizationConfig -OAuth2ClientProfileEnabled:$TRUE

image

Next time you start Outlook you will see that it will automatically logon to Exchange Online (whereas it didn’t when Oauth was not enabled).

Note. As outlined earlier in this post there’s a shared key between the computer account in your on-premises Active Directory and Azure Active Directory. It is strongly recommended to roll-over these keys every 30 days. For more information check the Microsoft FAQ on this: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-faq

Summary

You can use Pass-through authentication if you have a requirement to keep all user passwords on-premises (and thus not store them in the Microsoft cloud). When using Pass-through authentication you can also enable seamless Single-Sign On or sSSO. This way domain joined clients (that have access to a Domain Controller) can use Kerberos authentication to access services in the Microsoft cloud.

A number of issues to be aware of: not all clients do support PTA or sSSO as outlined in this article. For example, Internet Explorer does support it, but the Edge browser doesn’t. Outlook 2013/2016 do support it (modern authentication) but Outlook 2010 does not. Also, the Lync/Skype for business clients do not support this at all. I expect this to change in the (near) future, and when it does I will update this article.

More information

Azure Active Directory Seamless Single Sign-On: Frequently asked questions – https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-faq

Azure AD Connect Pass-Through Authentication

At Ignite 2017 it was announced that Pass Through Authentication (PTA) has reached General Availability (GA) so it is a fully supported scenario now.

But what is PTA? If Office 365 there are Cloud Identities, Synced Identities and Federated Identities. The first two are authenticated in Azure Active Directory, the last one is authenticated against on-premises Domain Controllers. For this to happen you need an ADFS infrastructure, consisting of multiple internal ADFS servers and multiple WAP (Windows Application Proxy) servers in the DMZ acting as ADFS proxies. Oh, and all servers need to be load balanced as well to provide redundancy and scalability.

PTA on the other hand is built on top of Azure AD Connect, and as such an interesting extension of the Synced Identities. PTA installs an agent on the Azure AD Connect server (AuthN agent) which accepts authentication requests from Azure AD and sends these to on-premises Domain Controllers. The advantage of authentication against on-premises Domain Controllers is that no passwords (or password hashes to be more precise) are stored in Azure Active Directory.

My first thought was how an authentication mechanism based on an asynchronous replication tool (Azure AD Connect synchronizes accounts every 30 minutes, and passwords within 2 minutes) ever be a reliable and safe solution. The last thing you want to happen is that you cannot authenticate to any service in the Microsoft cloud, because your Azure AD Connect server is busy doing other stuff (like automatically updating its engine for example ).

My second thought was how secure this could be. There’s no inbound connection to the Azure AD Connect server, there’s only an outbound connection on ports 80 (only used for SSL certificate revocation lists) and 443. And the communication itself should be secured as well, so…. But now that PTA is generally available more information becomes available, and things become clearer.

Authentication flow

For authentication to happen PTA uses a ‘service bus’ in Azure. The service bus is a standard Azure solution where application can store system messages in the service bus and where other applications can use these system messages. Using a service bus, you can create an asynchronous but reliable communication mechanism.

When logging to an Office 365 service the credentials are requested by Azure Active Directory, nothing new here. The credentials are encrypted and stored in the service bus. The AuthN agent on the Azure AD Connect server has a persistent connection to Azure AD and to the service bus, and retrieves the encrypted credentials from the service bus, decrypts them and presents them to the on-premises Domain Controller. The Domain Controller response (success, failure, password expired or user locked out) is returned to the AuthN agent and stored it on the service bus. Azure AD picks up this response and the user can continue working (or not of course, depending on the Domain Controller response).

image

Continue reading Azure AD Connect Pass-Through Authentication

TrendMicro Hosted Email Security: SPF DKIM and DMARC Part III

In the previous two blogpost I discussed how to configure SPF, DKIM and DMARC for outbound messages using the TrendMicro Hosted Email Security solution, including Office 365 centralized mail transport. In this blog I’ll discuss SPF, DKIM and DMARC for inbound messages (i.e. the verification part) using the TrendMicro solution.

Inbound protection

For inbound protection there’s not too much configuration to do, the only thing when using an online service is enabling the services.

In HEC Console select Inbound Protection and select Domain-based Authentication. Here you’ll find the options for SPF, DKIM and DMARC:

image

Select the Sender Policy Framework (SPF) option and in the SPF window check the enable SPF checkbox and when needed, check the Insert an X-header into email messages checkbox:

image

Continue reading TrendMicro Hosted Email Security: SPF DKIM and DMARC Part III

TrendMicro Hosted Email Security: SPF DKIM and DMARC Part II

In my previous blog I showed you how I implemented Trend Micro Hosted Email Security (HES) in my Exchange 2010 environment. Interesting case, it’s an Exchange 2010 hybrid environment with mailboxes in on-premises Exchange 2010 as well as mailboxes in Exchange Online. Centralized mail transport is used, so mail to and from Office 365 always routes via HES and the on-premises Exchange 2010 servers to Exchange Online. In this blog I will focus on implementing SPF, DKIM and DMARC in Trend Micro Hosted Email Security.

SPF

SPF in itself is covered in more detail in a previous blog post “SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part I” which can be found here: https://jaapwesselius.com/2016/08/19/senderid-spf-dkim-and-dmarc-in-exchange-2016-part-i/.

In this scenario, mail from the inframan.nl domain (including Office 365) is only routed via the Hosted Email Security environment so the SPF record is pretty simple:

v=spf1 include:spf.hes.trendmicro.com ~all

Set this TXT record in your public domain, start sending email and when checking the header information you’ll see your all good here:

image

DKIM

DKIM is a little more work to configure and takes a bit more time. DKIM is covered more in detail in part II of a previous series “SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part II” which can be found here: https://jaapwesselius.com/2016/08/22/senderid-spf-dkim-and-dmarc-in-exchange-2016-part-ii/

DKIM is about signing header information using a private key, and to decipher the signature you need a public key which is stored in public DNS, accessible for every mail server on the Internet. No need to worry about the configuration, HES will deliver all the details.

In the HES console select Outbound Protection and select DomainKeys Identified Mail (DKIM) Signing.

image

Continue reading TrendMicro Hosted Email Security: SPF DKIM and DMARC Part II

Microsoft UC Specialist