If you would like to read the other parts in this article series please go to:
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 1)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 2)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 3)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 4)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 5)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 6)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 7)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 9)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 10)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 11)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 12)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 13)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 14)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 15)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 16)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 17)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 18)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 19)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 20)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 22)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 23)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 24)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 25)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 26)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 27)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 28)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 29)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 30)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 31)
Introduction
In part 20 of this article series revolving around what the Windows Azure service is all about as well as how you deploy an Exchange hybrid deployment in Windows Azure, we created the publishing rule required for publishing the AD FS servers in the Active Directory forest to the Internet followed by verifying access from the Internet worked as required. We also added our domain to the Azure Active Directory tenant and configured it for Exchange Online use.
Let’s get going…
Adding Domain to Azure Active Directory tenant
So previously in this article series, we have verified that clients and devices can access and authenticate against our federation service from the Internet. Since the primary reason for the federation service is to provide single sign-on access to Office 365 workloads, the next step is to federate our Active Directory domain with the Azure Active Directory tenant, which Office 365 uses as the identity platform.
To do so, we need to connect to the AAD tenant and run a PowerShell command, but before we do so, we have to add our domain to the AAD tenant. To do so let us logon to the Office 365 Portal and click “Domains” in the navigation pane (Figure 1).
Figure 1: Domains page in the Office 365 Portal
Click “Let’s get started”.
Figure 2: Adding domain to the Active Directory tenant using the Office 365 Portal
On this page, we need to specify the domain to be added. In our case “azurelab.dk”. When you have done so, click “Next”.
Figure 3: Specifying domain to be added to the tenant
We are now presented with a TXT record that needs to be added to the domain zone at our external DNS provider. If you use a DNS provider that does not allow you to create a TXT record, you also have the option of using an invalid MX record.
Figure 4: TXT record information
Adding the TXT record to your DNS provider should be a straightforward task. Just remember to add it with a TTL value of 3600 or lower in order for it to replicate quicker.
Figure 5: Creating TXT record in external DNS
Now go back to the Office 365 Portal Domain section and click “Okay, I’ve added the record”. If verification succeeds, you are taken to the page shown in Figure 6. Click “Next”.
Figure 6: Domain verified with success
Now we have the option to update the existing cloud users. However, we will select to skip this step for now.
Figure 7: Option to update existing cloud users
In step 2, we also have the option to create new cloud users, but since we will use Directory Synchronization to synchronize our Active Directory domain users to the Azure Active Directory tenant, we will skip this step as well.
Figure 8: Option to create cloud users
We have reached step 3, where the “Add a new domain in Office 365” wizard will determine which DNS records are needed.
Click “Next”.
Figure 9: Required DNS records will be determined
We will select “No, I don’t have a website at www.azurelab.dk” as we do not have one and click “Next”.
Figure 10: Do you have a website or not?
We now have the option to change the name servers we use. We do not want to do so at this point.
Figure 11: Option to change the nameservers we use for the domain
We need to tell which service we wish to use. This only Exchange Online is in scope for this article, tick “Outlook for email, calendar, and contacts”.
Figure 12: Selecting which services to use
We are now presented with the DNS records we need to create.
Figure 13: DNS records required for Exchange Online (non-hybrid scenario)
Since we are dealing with an Exchange hybrid scenario none of these needs to be created yet, so you can ignore them for now and finish the wizard.
Figure 14: Finishing the domain wizard
Unlike the old Office 365 Portal, the domain status will no longer state “incomplete” despite that we have not created the DNS records required for non-hybrid scenarios. This is just one out of many improvements and fixes to the portal.
Figure 15: Domain added with success
Federating our Domain with Azure Active Directory
With our domain added to the Azure Active Directory tenant (Office 365), we can now federate the domain as required. To do so, let us logon to the first AD FS server we deployed in our Active Directory domain. Prior to connecting to the Azure Active Directory tenant using PowerShell, we need to download and install the Microsoft Online Services Sign-In Assistant for IT Professionals RTW followed by the Windows Azure Active Directory Module for Windows PowerShell, which provides the PowerShell commands required for connecting to and managing our Azure Active Directory tenant using PowerShell.
Figure 16: Installing the Sign-in Assistant
Figure 17: Installing the Azure Active Directory module for PowerShell
Now let us connect to the tenant. We do this by launching PowerShell using the new shortcut on the Desktop or by opening Windows PowerShell and typing “Import-Module MSOnline” followed by typing “Connect-MsolService”. Then specify the credentials of a Global Administrator in Office 365.
Figure 18: Connecting to the Azure Active Directory tenant using PowerShell
Let us list the tenant domains with the current setting by typing “Get-MsolDomain | fl”. Here we can see that the custom domain we added currently is set as a managed domain as shown in Figure 19.
Figure 19: Custom domain listed as a managed domain
In order to federate the domain we must convert it to (yes you guessed right) a federated domain. We do this be running the following command:
Convert-MsolDomainToFederated –DomainName “azurelab.dk” -SupportMultipleDomain
Figure 20: Converting our domain to a federated domain
The “SupportMultipleDomain” parameter is not required but makes it easier to add additional federated domains later on if that becomes a neat in the future.
As you can see in Figure 21 our custom domain has now been changed to a federated domain.
Figure 21: Custom domain converted to a federated domain
Let us open the AD FS management console (Server Manager > Tools) and select “Relying Party Trusts”. Here we can see that the Office 365 identity platform has been added as a relying party trust.
Figure 22: New relying party trust created
To see the details of the relying party trust, simply double-tab the trust in the right pane and examine the setting under each tab.
Verifying Authentication Redirection works as expected
We can now move on and verify that authentication redirection works as expected. To do so, let us open a browser on an external client and enter “portal.office.com”. This will redirect us to the login.microsoftonline.com page where we can specify the credentials for a federated user. Since we have not yet configured directory synchronization, we will just use a fictive test user ([email protected]).
Figure 23: Microsoft Online Services sign-in page
When switching to the password field, a redirection to the AD FS sing-in page should occur as shown in Figure 24.
Figure 24: Redirection to the AD FS based federation service
We are now presented with the AD FS sign-on page but since we haven’t set up directory synchronization, we cannot authenticate against our “on-premises” Active Directory yet.
Figure 25: AD FS sign-in page
This concludes part 21 of this multi-part article in which I provide you with an explanation of what Windows Azure is and how you configure an Exchange 2013 hybrid lab environment in Windows Azure.
If you would like to read the other parts in this article series please go to:
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 1)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 2)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 3)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 4)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 5)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 6)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 7)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 9)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 10)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 11)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 12)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 13)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 14)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 15)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 16)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 17)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 18)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 19)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 20)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 22)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 23)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 24)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 25)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 26)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 27)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 28)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 29)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 30)
- Deploying an Exchange 2013 Hybrid Lab Environment in Windows Azure (Part 31)