Microsoft Azure

How to Create and Validate a Microsoft Azure Active Directory Domain

I’m by no means an expert on Azure Active Directory (AAD), but I thought I would share the little I know because I am aware that confusion about AAD is causing issue with the deployment of other components of Azure IaaS. AAD was something that I ignored until recently, but more and more, AAD is becoming central to Microsoft’s hybrid cloud IaaS solutions:

  • RemoteApp uses AAD for user authentication
  • Possible single sign-on integration with other Microsoft cloud services such as Office 365
  • Windows 10 devices can register with AAD
  • You can enable single-sign on with over 2700 third party cloud services, including Salesforce, Amazon, and Google!

In this post, I’m going to show you how to set up the pre-requisite for linking AAD with your legacy on-premises Active Directory domain: creating and validating your domain in Azure.

The Default Directory

When you set up your Azure subscription, a default directory will be created. This is where your Azure subscription will create and use accounts by default. The default directory will pull its default domain name from your subscription. For example, if my subscription was “joeelway” then my default domain would be joeelway.onmicrosoft.com, and if I created a user called User1 then that user’s UPN (logon name) would be [email protected]
Let’s assume that I create an on-premises domain called joeelway.com.  There are two issues that could possibly arise:

  • Confusion: User1 is used to signing in as [email protected] They’d be confused if I told them that sometimes they would be called [email protected]
  • Out-of-sync domains: If I try to federate or sync the legacy on-premises AD with AAD then they are out of sync; the domain names are different.

Note: In a lab scenario I have solved the out-of-sync domain issue by adding the AAD domain suffix (joeelway.onmicrosoft.com) as an additional suffix in my on-premises AD. Then I change the UPNs of the users from @joeelway.com to @joeelway.on.microsoft.com. This is not a good production solution because it still causes confusion. However, this method can be tweaked (using joeelway.com) when the company has used a domain that cannot be verified, e.g. joeelway.internal, for their on-premises AD.

Sponsored Content

What is “Inside Microsoft Teams”?

“Inside Microsoft Teams” is a webcast series, now in Season 4 for IT pros hosted by Microsoft Product Manager, Stephen Rose. Stephen & his guests comprised of customers, partners, and real-world experts share best practices of planning, deploying, adopting, managing, and securing Teams. You can watch any episode at your convenience, find resources, blogs, reviews of accessories certified for Teams, bonus clips, and information regarding upcoming live broadcasts. Our next episode, “Polaris Inc., and Microsoft Teams- Reinventing how we work and play” will be airing on Oct. 28th from 10-11am PST.

What I want to do here is set up my AAD to use my on-prem AD domain of joeelway.com.

Create the Domain

Log into the Azure management portal, browse to Active Directory, click on your Default Directory, and navigate to Domains. Click Add A Custom Domain.

Add the name of your domain here. This must be a DNS domain name that you own and can create records for on the Internet – you will need to do this to validate the domain. Note the “I plan to … single sign-on …” checkbox. If you plan to use ADFS to link your domains then check this box. Note that directory synchronization is not single-sign on, it is shared sign-on; do not check this box if you are using a sync tool instead of ADFS.

Click Add and then navigate to the next page where you will be provided with details for validating your domain.

Create and Validate a Microsoft Azure Active Directory Domain
Add a new domain to your Azure AD directory [Image Credit: Aidan Finn]

Verify the Domain

You are told to create a TXT record in your domain (joeelway.com) on the Internet DNS servers. This will allow Microsoft to verify that you own the domain in question and that you are entitled to use this domain on the Internet – the hybrid solutions that AAD powers are usable on the Net and you wouldn’t want someone else signing into Salesforce with your domain name, would you?

Azure AD requires you to prove that you own a DNS domain using a verification process [Image credit: Aidan Finn]
Azure AD requires you to prove that you own a DNS domain using a verification process [Image credit: Aidan Finn]
Log into your domain registrar’s control panel, create a TXT record and enter the information required.

Note that with my registrar, I didn’t have to enter the @ symbol anywhere – I just created a TXT record, and set the data value to equal the destination value from the Microsoft instructions.

Prove ownership of your DNS domain to Azure AD using a TXT record [Image Credit: Aidan Finn]
Prove ownership of your DNS domain to Azure AD using a TXT record [Image Credit: Aidan Finn]
Wait a few moments, then return to Azure and click the Verify button.

A successful Azure AD domain verification [Image Credit: Aidan Finn]
A successful Azure AD domain verification [Image Credit: Aidan Finn]
And now you have a verified domain that you can sync users into:

The newly created and verified domain in Azure Active Directory [Image credit: Aidan Finn]
The newly created and verified domain in Azure Active Directory [Image credit: Aidan Finn]

Related Topics:

BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register
Comments (0)

Leave a Reply

Aidan Finn, Microsoft Most Valuable Professional (MVP), has been working in IT since 1996. He has worked as a consultant and administrator for the likes of Innofactor Norway, Amdahl DMR, Fujitsu, Barclays and Hypo Real Estate Bank International where he dealt with large and complex IT infrastructures and MicroWarehouse Ltd. where he worked with Microsoft partners in the small/medium business space.
External Sharing and Guest User Access in Microsoft 365 and Teams

This eBook will dive into policy considerations you need to make when creating and managing guest user access to your Teams network, as well as the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

You will learn:

  • Who should be allowed to be invited as a guest?
  • What type of guests should be able to access files in SharePoint and OneDrive?
  • How should guests be offboarded?
  • How should you determine who has access to sensitive information in your environment?

Sponsored by: