Office 365 MailFlow Scenarios and Best Practices

Microsoft Office 365 gives you the flexibility to configure mail flow based on your requirements and uses scenario to delivered email to your organisation’s mailboxes. The simplest way to configure mail flow is to allow Microsoft EOP to handle spam filter and Maiflow of your organisation. However, you may have already invested your infrastructure handle mail flow. Microsoft also accepts this situation and allow you to use your own spam filter.

The below scenario and use cases will allow you to determine how you can configure MailFlow of your organisation.

Mailbox Location MailFlow Entry Point Scenario & Usecases Recommended MailFlow Configuration  and Example MX record
Office 365 Office 365 Use Microsoft EOP

Demote or migrate all mailboxes to office 365

Use Office 365 mailboxes

MX record Pointed to Office 365

MX: domain-com.mail.protection.outlook.com

SPF:  v=spf1 include:spf.protection.outlook.com -all

 

On-premises On-prem Prepare the on-prem to be cloud ready

Build and Sync AAD Connect

Built ADFS Farm

MX record Pointed to On-prem

MX1.domain.com

SPF: v=spf1 include: MX1.domain.com  include:spf.protection.outlook.com -all

Third-party cloud, for example, G-Suite Both third-party and office 365 Prepare to migrate to Office 365

Stage mailbox data

MailFlow co-existance

MX record pointed to third-party cloud

MX record Pointed to On-prem

in.hes.trendmicro.com

SPF: v=spf1 include:spf.protection.outlook.com include: in.hes.trendmicro.com include: ASPMX.L.GOOGLE.COM -all

Combination of On-premises and Office 365 On-premises Hybrid Environment

Stage mailbox migration

MailFlow co-existance

MX record Pointed to On-prem spam filter

MX record Pointed to On-prem

MX1.domain.com

SPF: v=spf1 include: MX1.domain.com  include:spf.protection.outlook.com -all

Combination of On-premises and Office 365 Third-party cloud spam filter Hybrid Environment

Stage mailbox migration

MailFlow co-existance

MX record Pointed to third-party cloud spam filter

MX record pointed to third-party cloud

MX record Pointed to On-prem

in.hes.trendmicro.com

SPF: v=spf1 include:spf.protection.outlook.com include: in.hes.trendmicro.com -all

MailFlow Configuration Prerequisites:

  1. Make sure that your email server (also called “on-premises mail server”) is set up and capable of sending and receiving mail to and from the Internet.
  2. Check that your on-premises email server has Transport Layer Security (TLS) enabled, with a valid public certification authority-signed (CA-signed) certificate.
  3. Make a note of the name or IP address of your external-facing email server. If you’re using Exchange, this will be the Fully Qualified Domain Name (FQDN) of your Edge Transport server or CAS that will receive an email from Office 365.
  4. Open port 25 on your firewall so that Office 365 can connect to your email servers.
  5. Make sure your firewall accepts connections from all Office 365 IP addresses. See Exchange Online Protection IP addresses for the published IP address range.
  6. Make a note of an email address for each domain in your organisation. You’ll need this later to test that your connector is working correctly.
  7. Make sure you add all datacenter IP addresses of Office 365 into your receive connector of on-premises Exchange server

Configure mail to flow from Office 365 to your email server and vice-versa. There are three steps for this:

  1. Configure your Office 365 environment.
  2. Set up a connector from Office 365 to your email server.
  3. Change your MX record to redirect your mail flow from the Internet to Office 365.

Note: For Exchange Hybrid Configuration wizard, connectors that deliver mail between Office 365 and Exchange Server will be set up already and listed here. You don’t need to set them up again, but you can edit them here if you need to.

  1. To create a connectorExchange in Office 365, click Admin, and then click to go to the Exchange admin center. Next, click mail flow click mail flow, and click connectors.
  2. To start the wizard, click the plus symbol +. On the first screen, choose the appropriate options when creating MailFlow from Office 365 to On-premises Server
  3. Click Next, and follow the instructions in the wizard.
  4. Repeat the step to create MailFlow between On-premises to Office 365.
  5. To redirect email flow to Office 365, change the MX (mail exchange) record for your domain to Microsoft EOP, i.e. domain-com.mail.protection.outlook.com

Relevant Articles:

Mailflow Co-existence between G-Suite and Office 365 during IMAP Migration

Office 365 Hybrid Deployment with Exchange 2016 Step by Step

Centralized MailFlow: NDR Remote Server returned ‘550 5.7.1 Unable to relay’

Migrate Office 365 Relying Party Trust to Different ADFS Farm

To migrate Office 365 Relying Party Trust from an existing ADFS Farm to new ADFS Farm, follow the step by step guide. Migrating Office 365 Relying Party Trust will incur a minor disruption to SSO environment.

Prerequisites:

  • Existing ADFS Farm with FQDN sts.domain.com
  • New ADFS Farm with FQDN sts1.domain.com
  • Existing Certificate CN=sts.domain.com or a wildcard certificate
  • New certificate with CN=sts1.domain.com
  • New public IP address for the public CNAME sts1.domain.com
  • A public CNAME record sts1.domain.com
  • An internal CNAME record sts1.domain.com

Note: keep the existing AAD Connect unless you have a requirement to build a new one.

Here are the steps:

Step1: Verify AAD Connect Configuration

  • Open AAD Connect, View Sign-in Option.
  • Check AAD Connect Wizard to make sure you did not configure “Federation with ADFS” Sign-in option. If you have done so then run AAD Connect Wizard again and replace the certificate and ADFS farm details to new ADFS server sts1.domain.com

Step2: Build ADFS and WAP Servers

Build a new ADFS farm side by side with an existing ADFS farm. It would be redundant effort to write another blog. Please follow my previous blog to deploy ADFS and WAP.

Building Multiple ADFS Farms in a Single Forest

Deploy Web Application Proxy Role in Windows Server 2012 R2 –Part I

Branding and Customizing the ADFS Sign-in Pages

Step3: Test SSO

Log on to the https://sts.domain.com/adfs/ls/idpinitiatedsignon.aspx using on-premises credentials to make sure you can single sign-on.

Step4: Gather list of existing federated domains from existing ADFS Farm

Log on to the existing primary ADFS Server, Open PowerShell as an Administrator, execute the following cmdlets.

$cred=Get-Credential

Connect-MsolService –Credential $cred

Get-MsolDomain

Record a list of Federated Domains.

Step5: Update Office 365 RP within the new ADFS Farm

Log on to the new primary ADFS Server, Open PowerShell as an Administrator, execute the following cmdlets.

$cred=Get-Credential

Connect-MsolService –Credential $cred

Update-MsolFederatedDomain –DomaiName “Domain.com” –SupportMultipleDomain –Confirm  Execute Update-MsolFederatedDomain Cmdlets if you have additional federated domains such as DomainB.com

GetMsolDomain

Open ADFS Management Console, Make sure Office 365 RP has been created with necessary tokens and permissions. If necessary, clone all incoming and outgoing claims and permission from previous ADFS farm to new ADFS Farm and apply to the newly created Office 365 RP.

Step6: Test SSOOnce you have completed the Step5, wait for Microsoft to update their backend Identity and Federation systems. In my previous implementation work, it took 30 minutes the change to take effect.  Sign on to portal.office.com; you will be redirected to https://sts1.domain.com to authenticate. Once you have sign-in successfully, you have completed the migration work.

Step7: New AAD Connect Server (Optional)Check step1 before running AAD Connect Wizard and reconfigure sign-in options. If you need to change sign-in options, please follow the guide to change Sign-in Option.

Relevant Articles:

Upgrading AD FS to Windows Server 2016 FBL

Deploy Web Application Proxy Role in Windows Server 2012 R2 –Part II

ADFS 4.0 Step by Step Guide: Federating with Splunk Cloud

To integrate On-Premises SSO with Splunk Cloud, you need the following items:

  • An administrative account in your ADFS
  • An administrative account in your Windows Active Directory
  • An administrative account for your Splunk Cloud instance or tenant.

Step1: Create Security Groups

  1. Sign into Domain Controller
  2. Open Active Directory Users and Computers
  3. Create two security groups named, SG-SplunkAdmin and SG-SplunkUsers

Step2: Download IdP (ADFS 2016) Metadata

  1. Log into the ADFS 2016 server or an admin PC.
  2. Open a browser and type metadata URL https://ADFSServer1.domain.com/federationmetadata/2007-06/federationmetadata.xml
  3. Download and save the metadata as IdP metadata.

Step3: Download Splunk Metadata

  1. Login to Splunk Cloud instance using administrator credentials.
  2. Download metadata from your instance of Splunk Cloud or This can be obtained by, once logged into a session as an admin role user, entering the URL https://yourinstance.splunkcloud.com/saml/spmetadata into your browser’s URL field.
  3. Download and save the metadata as SP metadata

Step4: Extract Splunk certificate from metadata

  1. Open Splunk metadata XML file in a notepad, Search “X509Certificate” in the metadata. Copy the everything starting from XML tags from ‘<ds:X509Certificate>‘ to ‘</ds:X509Certificate>‘.
  2. Open a new notepad and paste the content into the notepad. Place a row above the certificate with the text —–BEGIN CERTIFICATE—– and a row below the certificate with the text —–END CERTIFICATE—–
  3. Save the notepad as a .cer
  4. The file will look like this one but with more hexadecimal character

—–BEGIN CERTIFICATE—–

MIIEsjCCA5qgAwIBAgIQFofWiG3iMAaFIz2/Eb9llzANBgkqhkiG9w0BAQsFADCB

sjFuz4DliAc2UXu6Ya9tjSNbNKOVvKIxf/L157fo78S1JzLp955pxyvovrsMqufq

YBLqJop4

—–END CERTIFICATE—–

Step5: Create a Relying Party Trust

  1. Log into the ADFS 2016 server and open the management console.
  2. Right-click Service>Relying Party Trusts>Select Add Relying Party Trust from the top right corner of the window.
  3. Click Claims aware>Click Start
  4. Click Import Data about the relying party
  5. Browse the location where you saved Splunk metadata, select metadata, and Click Next
  6. Type the Display Name as SplunkRP, Click Next
  7. Ensure I do not want to configure multi-factor authentication […] is chosen, and click Next
  8. Permit all users to access this relying party.
  9. Click Next and clear the Open the Claims when this finishes check box.
  10. Close this page. The new relying party trust appears in the window.
  11. Right-click on the relying party trust and select Properties.
  12. On the properties, choose the Encryption tab, Remove the certificate encryption
  13. Choose the Signature tab and make sure the Splunk Certificate was imported
  14. Select to the Advanced tab and set the Secure hash algorithm to SHA-1.
  15. Click into the Identifiers tab. The default Relying party identifier for Splunk came in from the metadata file as ‘splunkEntityId’. Remove Default one. Add new entity ID splunk-yourinstance
  16. Under the Endpoints tab, make sure the Consumer Endpoints is https://yourinstance.splunkcloud.com/saml/acs  with a Post binding and index 0
  17. Under the Endpoints tab, make sure the make sure the Logout Endpoints is https://yourinstance.splunkcloud.com/saml/logout with a Post binding
  18. Click Apply, Click Ok.

Step6: Add Claim Rule for the Relying Party

  1. Log into the ADFS server and open the management console.
  2. Right-click on the Splunk relying party trust and select Edit Claim Rules.
  3. Click the Issuance Transform Rules tab.
  4. Click Add Rules. Add a Rule Type the Name as Rule1
  5. Ensure Send LDAP Attributes as Claims is selected, and click Next
  6. Select the below details

Claim Rule Name =  Rule1

Attribute Store = Active Directory

LDAP Attribute Outgoing Claim Type
Display-Name realName

 

Token-Groups – Unqualified Names Role
E-Mail-Addresses mail
  1. Click Finish. Click Apply
  2. Click Add Rules. Add a Rule Type the Name as  Rule2
  3. Ensure Transform an Incoming Claim is selected, and click Next
  4. Select the below details
Claim Rule Name Rule2

 

Incoming claim type UPN

 

Incoming NameID format Unspecified
Outgoing Claim Type Name ID
Outgoing name ID format Transient Identifier
  1. Click Finish. Click Apply

Step7: Import Splunk Certificate into ADFS Server

  1. Sign into ADFS Server, Open Command Prompt as an Administrator, type MMC.exe
  2. Click File, Click Add/Remove Snap-in
  3. Click Certificates, Click Computer Account
  4. Right Click on Trusted People>All Tasks>Import Certificate
  5. Browse the location of certificate and import
  6. Close MMC.
  7. Repeat these steps in all ADFS Servers in your farm.

Step8: Setup SigningCertificateRevocationCheck to None

Sign into primary ADFS, open PowerShell as an administrator, type the following and hit enter.

Set-ADFSRelyingPartyTrust -TargetName “SplunkRP” -SigningCertificateRevocationCheck None

Step9: Configure SplunkCloud in your instance

  1. On the Splunk instance as an Admin user, choose Settings->Access Controls->Authentication Method.  Choose SAML then click on the Configure Splunk to use SAML’ button.
    within the SAML Groups setup page in Splunk, click on the SAML Configuration button in the upper right corner.
  2. The SAML Configuration popup window will appear. Click on Select File to import the XML Metadata file (or copy and paste the contents into the Metadata Contents textbox) and click Apply.
  3. The following fields should be automatically populated by the metadata:
    Single Sign On (SSO) URL
    Single Log Out (SLO) URL
    idP’s Certificate file
    Sign AuthnRequest (checked)
    Sign SAML response (checked)
    Enter in the Entity ID as splunk-yourinstance as was used in ADFS RP Identifier property of the ADFS configuration.
  4. Scroll down to the ‘Advanced Settings‘ section.
    Enter in the Fully Qualified Domain Name (FQDN) of the Splunk Cloud instance – ‘https://yourinstance.splunkcloud.com
    Enter a ‘0‘ (zero) for the Redirect port – load balancer’s port.
    Set the Attribute Alias Role to ‘http://schemas.microsoft.com/ws/2008/06/identity/claims/role’
    It may also be necessary to set an Attribute Alias for ‘Real Name’ and ‘Mail’ – but not all implementations require these settings. Click Save to Save the configuration:
  5. The next step is set up the SAML groups. Within the Splunk ‘Settings->Access Controls->Authentication Method->SAML Settings‘ page, click the green “New Group” button
  6. Enter a group name that associates with ADFS Active Directory passed group names, some examples follow
Group Name (Type this name on New Group Properties ) Splunk Role (Select from Available Roles) Active Directory Security Group
SG-SplunkAdmin Admin SG-SplunkAdmin
SG-SplunkUsers User SG-SplunkUsers
  1. Click Save.

Step10: Testing SSO

  1. To test SSO, visit  https://yourinstance.splunkcloud.com/en-US/account/login?loginType=splunk  You will be redirected to ADFS STS Signing Page. Enter your on-premises email address and password as the credential.  You should be redirected back to Splunk Cloud.
  2. Also test logging out of Splunk, you should be re-directed to the Splunk SAML logout page.

 

ADFS 4.0 Step by Step Guide: Federating With Google Apps

To integrate On-Premises SSO with Google Apps, you need the following items:

Step1: Export ADFS Token Signing Certificate

  1. Log into the ADFS 2016 server and open the management console.
  2. Right-click Service>Certificate
  3. Right-click the certificate and select View Certificate.
  4. Select the Details tab.
  5. Click Copy to File. The Certificate Export Wizard opens.
  6. Select Next. Ensure the No, do not export the private key option is selected, and then click Next.
  7. Select DER encoded binary X.509 (.cer), and then click Next.
  8. Select where you want to save the file and give it a name. Click Next.
  9. Select Finish.

Step2: Download Google Certificate

  1. Login to Google Admin console with administrator permission to add new apps.
  2. Go to Apps > SAML Appsand click “+” at the right bottom of the page to add a new SAML IDP (“Enable SSO for SAML Application”).
  3. Select the “Setup my own custom app” at the bottom of the window. You will see the “Google IdP Information” page. Click Download button to retrieve google certificate.

Step3: Create a Relying Party Trust

  1. Log into the ADFS 2016 server and open the management console.
  2. Right-click Service>Relying Party Trusts>Select Add Relying Party Trust from the top right corner of the window.
  3. Click Claims aware>Click Start
  4. Click Enter Data about the relying party manually
  5. Give it a display name such as GoogleApps>Click Next>Click Next
  6. On the Configure URL Page, Check Enable support for the SAML 2.0 WebSSO protocol and type  https://www.google.com/a/domain.com/acs, Click Next
  7. On the Configure RP Identifier Page, type the identifiers: google.com/a/domain.com, Click Add
  8. Ensure I do not want to configure multi-factor authentication […] is chosen, and click Next
  9. Permit all users to access this relying party.
  10. Click Next and clear the Open the Claims when this finishes check box.
  11. Close this page. The new relying party trust appears in the window.
  12. Right-click on the relying party trust and select Properties.
  13. Select to the Advanced tab and set the Secure hash algorithm to SHA-256.
  14. Under the Endpoints tab, click Add SAML Logout with a Post binding and a URL of https://sts.domain.com/adfs/ls/?wa=wsignout1.0
  15. Select to signature tab, Click Add.. Import the google certificate, you have exported from Google admin console. Click Apply, Click Ok.

Step4: Add Claim Rule for the Relying Party

  1. Log into the ADFS server and open the management console.
  2. Right-click on the GoogleApps relying party trust and select Edit Claim Rules.
  3. Click the Issuance Transform Rules tab.
  4. Click Add Rules. Add a Rule Type the Name as GoogleApps Rule
  5. Ensure Send LDAP Attributes as Claims is selected, and click Next
  6. Select the below details
  • Claim Rule Name =  Send Email Address As NameID
  • Attribute Store = Active Directory
  • LDAP Attribute = E-mail-Addresses
  • Outgoing Claim Type = Name-ID
  1. Click Finish. Click Apply

Step5: Configure Google Apps in Admin Console

  1. Sign into the Google Apps Admin Console using your administrator account.
  2. Click Security. If you don’t see the link, it may be hidden under the More Controls menu at the bottom of the screen.
  3. On the Security page, click Setup single sign-on (SSO).
  4. Perform the following configuration changes:
  1. In Google Apps, for the Verification certificate, replace and upload the ADFS token signing certificate that you have downloaded from ADFS.
  2. Click Save Changes.

Step6: Testing SSO

To test SSO, visit http://mail.google.com/a/domain.com.  You will be redirected to ADFS STS Signing Page. Enter your on-premises email address and password as the credential.  You should be redirected back to Google Apps and arrive at your mailbox.

ADFS 4.0 Step by Step Guide: Federating with ServiceNow

Prerequisites:

Step1: Export Token Signing Certificate

  • Log into the ADFS 2016 server and open the management console.
  • Right-click Service>Certificate
  • Right-click the certificate and select View Certificate.
  • Select the Details tab.
  • Click Copy to File. The Certificate Export Wizard opens.
  • Select Next.Ensure the No, do not export the private key option is selected, and then click Next.
  • Select DER encoded binary X.509 (.cer), and then click Next.
  • Select where you want to save the file and give it a name. Click Next.
  • Select Finish. The instance requires that this certificate be in PEM format. You can convert this certificate using client tools or even online tools such as: SSL Shopper.
  • Use the DER/Binary certificate that you just created, and export it in Standard PEM format.
  • Right Click on the exported certificate>Edit with Notepad
  • Copy everything from Begin Certificate to End Certificate including —– and Paste in Service Now when needed.

—–BEGIN NEW CERTIFICATE REQUEST—–

/DY5HA/Cz5fElf4YTQak8PZMmCcndgPA==

—–END NEW CERTIFICATE REQUEST—–

Step2: Create a Relying Party Trust

  • Log into the ADFS 2016 server and open the management console.
  • Right-click Service>Relying Party Trusts>Select Add Relying Party Trust from the top right corner of the window.
  • Click Claims aware>Click Start
  • Click Enter Data about the relying party manually
  • Give it a display name such as ServiceNow>Click Next>Click Next>Click Next
  • Enter the instance site to which you connected as the Relying Party trust identifier. In this case use https://company.service-now.com and click Add.
  • Permit all users to access this relying party.
  • Click Next and clear the Open the Claims when this finishes check box.
  • Close this page. The new relying party trust appears in the window.
  • Right-click on the relying party trust and select Properties.
  • Browse to the Advanced tab and set the Secure hash algorithm to SHA-1.
  • Browse to the Endpoints tab and add a SAML Assertion Consumer with a Post binding and a URL of https://company.service-now.com/navpage.do
  • Under the Endpoints tab, click Add SAML Logout with a Post binding and a URL of https://sts.domain.com/adfs/ls/?wa=wsignout1.0

Step3: Add Claim Rule

  • Log into the ADFS server and open the management console.
  • Right-click on the ServiceNow relying party trust and select Edit Claim Rules.
  • Click the Issuance Transform Rules tab.
  • Select Add Rules. Add Custom Rule Type the Name as ServiceNow Rule, Copy and Paste the below rule.

Rule#1

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&#8221;, Issuer == “AD AUTHORITY”]

=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&#8221;, “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&#8221;, “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress&#8221;), query = “;userPrincipalName,sAMAccountName,mail;{0}”, param = c.Value);

Rule#2

c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress”%5D

=> issue(Type = “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&#8221;,

Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType,

Properties[“http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format”%5D

= “urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”);

Step4: Activate SSO in ServiceNow

  • Sign-on to your ServiceNow application as an administrator.
  • Activate the Integration – Multiple Provider Single Sign-On Installer plugin by following the next steps:
  • In the navigation pane on the left side, go to System Definition section and then click Plugins.
  • Search for Integration – Multiple Provider Single Sign-On Installer.
  • Select the plugin. Rigth click and select Activate/Upgrade.
  • Click the Activate
  • In the navigation pane on the left side, click Properties.
  • On the Multiple Provider SSO Properties dialog, perform the following steps:
  • As Enable multiple provider SSO, select Yes.
  • As Enable debug logging got the multiple provider SSO integration, select Yes.
  • In The field on the user table that… textbox, type user_name.
  • Click Save.

Step5: Import Certificate in ServiceNow

  • In the navigation pane on the left side, click x509 Certificates.
  • On the 509 Certificates dialog, click New.
  • On the 509 Certificates dialog>Click New.
  • In the Name textbox, type a name for your configuration (e.g.: 0).
  • Select Active.
  • As Format, select PEM.
  • As Type, select Trust Store Cert.
  • Open your Base64 encoded certificate in notepad, copy the content of it into your clipboard, and then paste it to the PEM Certificate
  • Click Update.

Step6: Configure IdP provider

  1. In the navigation pane on the left side, click Identity Providers.
  2. On the Identity Providers dialog, click New:
  3. On the Identity Providers dialog, click SAML2 Update1?:
  4. On the SAML2 Update1 Properties dialog, perform the following steps:
  • in the Name textbox, type a name for your configuration (e.g.: SAML 2.0).
  • In the User Field textbox, type email or user_name, depending on which field is used to uniquely identify users in your ServiceNow deployment.
  • copy the Identity Provider ID value http://sts.domain.com/adfs/ls, and then paste it into the Identity Provider URL textbox
  • copy the Authentication Request URL value http://sts.domain.com/adfs/ls, and then paste it into the Identity Provider’s AuthnRequest
  • copy the Single Sign-Out Service URL value https://domain.com/adfs/ls/?wa=wsignout1.0, and then paste it into the Identity Provider’s SingleLogoutRequest textbox.
  • In the ServiceNow Homepage textbox, type the URL https://company.service-now.com/navpage.do of your ServiceNow instance homepage
  • In the Entity ID / Issuer textbox, type the URL https://company.service-now.com/of your ServiceNow tenant.
  • In the Audience URL textbox, type the URL https://company.service-now.com/ of your ServiceNow tenant.
  • In the Protocol Binding for the IDP’s SingleLogoutRequest textbox, type urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect.
  • In the NameID Policy textbox, type urn:oasis:names:tc:SAML:1.1:nameid-format:emailaddress.
  • Deselect Create an AuthnContextClass (By deselecting this option, you have created SP-Initiated SSO)
  • In the AuthnContextClassRef Method, Since you are using on-premises ADFS or MFA for authentication then you should not configure this value.
  • In Clock Skew textbox, type 60.
  • As Single Sign On Script, select MultiSSO_SAML2_Update1.
  • As x509 Certificate, select the certificate you have created in the previous step.
  • Click Submit.

Testing Single Sign On:

IdP Initiated Signon Redirect:

To create a direct link so users do not need to select from a drop down list, browse to https://sts.domain.com/adfs/ls/idpinitiatedsignon.aspx?logintoRP=https://company.service-now.com

SP-Initiated Signon:

https://company.service-now.com/navpage.do

Office 365 Hybrid Deployment with Multiple Active Directory Forests

This article explains how you can deploy a hybrid Office 365 and Exchange on-premises environment with multiple Active Directory Forest. An organisation that utilizes an account forest and a resource forest to separate Active Directory accounts and Exchange servers in a single forest, aren’t considered as multiple AD Forest. Let’s say Company A (DomainA.com) bought Company B (DomainB.com). Company A has an Office 365 tenant with default domain domainA.onmicrosoft.com. Now Company A wishes to migrate Company B mailboxes into the Office 365 tenant but maintains the hybrid environment.

Here is the infrastructure you should consider.

AD Forest 1 AD Forest 2
On-prem Forest Corp.DomainA.com Corp.DomainB.com
Email Domain or Externally Routable NameSpace DomainA.com DomainB.com
Externally Routable Autodiscover CNAME Autodiscover.DomainA.com Autodiscover.DomainB.com
Default Domain in Office 365 Tenant domainA.onmicrosoft.com domainA.onmicrosoft.com
On-Prem Exchange Server Version Exchange 2013 SP1 or later Exchange 2013 SP1 or later
On-prem Certificate Issued by Public CA

CN= mail.DomainA.com

SAN=Autodiscover.DomainA.com

Issued by Public CA

CN= mail.DomainB.com

SAN=Autodiscover.DomainB.com

To configure a hybrid environment for a multi-forest organization, you’ll need to complete the basic steps below:

  1. Create Two-Way Trust Relationship between on-premises Corp.DomainA.com and On-premises Corp.DomainB.com if Trust relationship is not already established.
  2. Make sure you have correct public certificates for both Exchange Organisation.
  3. Build AAD Connect Server in Corp.DomainA.com Domain. AD Synchronisation occurs Corp.DomainA.com domain. you do not need to add another AAD Connect server in domainB.com domain. Run custom AAD Connect wizard and use domain filter and select both domains to sync to Azure AD.
  4. Build ADFS Farm in Corp.DomainA.com Domain. You use either AD FS or password sync to allow for a seamless user authentication experience for both domains.
  5. Add domain and verify both domains in Office 365 tenant. Setup both domain in Office tenant as an Internal Relay Domain
  6. Run Hybrid Configuration wizard in both Forest. Select both domains whilst running HCW.  For Centralized MailFlow Configuration of both domains, you must retain your existing MX record. Add EOP in your SPF record for the both domains. If you do not wish to configure Centralized MailFlow then point MX record to the EOP record of Exchange Online.

AAD Connect Recommendations:

  • Separate Topology – This topology might be the situation after a merger/acquisition or in an organization where each business unit operates independently. These forests are in the same organization in Azure AD and appear with a unified GAL.

In AAD Connect Wizard Select “Users are only once across all forests” and Mail Attribute.

  • Full Mesh- A full mesh topology allows users and resources to be located in any forest. Commonly, there are two-way trusts between the forests.

In AAD Connect Wizard Select “Users identities exist across multiple forests” and Mail Attribute.

Hybrid with Multiple Forest  Recomendations:

  • Having a single tenant in Azure AD for an organization
  • Having a single ADD connect server for an organisation
  • Having a unique Active Directory object for an organisation. Each unique object is synced into the Azure AD for once only.
  • Having a single on-prem namespace (UPN: domainA.com, domainB.com) to match the registered domain in Azure AD.
  • Having a single namespace associated with an user or an object
  • Having all email domains registered in a single tenant
  • Having a single AAD Connect and ADFS Farm in a same forest if “Federation with ADFS” is selected in AAD Connect custom installation Wizard

Relevant Article:

Office 365 Hybrid Deployment with Exchange 2016 Step by Step

Building Multiple ADFS Farms in a Single Forest

Let’s paint a picture, you have an unique requirement to build multiple ADFS farms. you have a fully functional hybrid environment with EXO. you do not want to modify AAD connect and existing ADFS servers. But you want several SaaS applications use different ADFS farm with MFA but their identity is managed by the same Active Directory forest used by existing ADFS farm.

Here is the existing infrastructure:

  • 1 single forest with multiple hybrid UPNs (domainA.com, domainB.com, domainC.com and many…)
  • 2x ADFS servers (sts1.domainA.com)
  • 2X WAP 2012 R2 cluster
  • 1x AAD Connect
  • 1X Office 365 Tenant with several federated domains (domainA.com, domainB.com, domainC.com and many….)
  • 1x public CNAME sts1.domainA.com

Above configuration is working perfectly.

Now you would like to build a separate ADFS 2016 farm with WAP 2016 cluster for SaaS applications. This ADFS 2016 farm will be dedicated to authenticate these SaaS applications. you would also like to turn on MFA on ADFS 2016. Add new public authentication endpoint such as sts2.domainA.com for ADFS 2016 farm.

End goal is that once user hit https://tenant.SaaSApp.com/ it will redirect them to sts2.domain.com and prompt for on-prem AD credentials and MFA if they are accessing from public network.

New ADFS 2016 infrastructure in the same forest and domain:

  • 2X ADFS 2016 Servers (sts2.domainA.com)
  • 2X WAP 2016 Servers
  • 1 X separate public IP for sts2.domainA.com
  • 1X public CNAME for sts2.domainA.com
  • 1X Private CNAME for sts2.domainA.com

Important Note: You have to prepare Active Directory schema to use ADFS 2016 functional level. No action/tasks necessary in existing ADFS 2012 R2 environment.

Guidelines and referrals to build new environment.

Upgrading AD FS to Windows Server 2016 FBL

ADFS 4.0 Step by Step Guide: Federating with Workday

Branding and Customizing the ADFS Sign-in Pages

Deploy Web Application Proxy Role in Windows Server 2012 R2 –Part I

Deploy Web Application Proxy Role in Windows Server 2012 R2 –Part II