Cannot Verify A DNS Domain In Azure Because You Used .LOCAL or .INTERNAL

[Image credit: Microsoft]

A lot of companies have used a non-public domain name for their Active Directory. This meant that they didn’t have to buy an public domain name (but they probably did eventually for email), they had company politics issues, or they wanted to separate public from private (making resolution of external services easier). But this causes a problem when you are trying to federate or sync with Azure Active Directory, and I’ll explain a way to solve that issue here.

The Issue

When we connect a legacy Windows Server AD (LAD) to AAD we need to have both domain names matching. So if the company has an AD called joeelway.internal then they cannot sync or federate that domain to an Azure AD called joeelway.com (the public DNS domain for the company) or joeelwayazure.onmicrosoft.com (a default domain name for an Azure subscription). This is because is we have a user, Barbara, then her UPNs would mismatch:

  • barbara@joeelway.internal VS barbara@joeelway.com OR
  • barbara@joeelway.internal VS barbara@joeelwayazure.onmicrosoft.com

Solution

Method one is extreme and disruptive:

  • Rename the domain and deal with any consequences (eek!)
  • Configure internal DNS to resolve names of company-owned external services
  • Re-educate people about their UPNs if they’ve been using UPN to log in

I think we can agree that method 1 is too disruptive. There is a softer approach that you can use:

  • Configure an additional DNS suffix for your domain
  • Change the UPN of users to use the new DNS suffix
  • Re-educate people about their UPNs if they’ve been using UPN to log in

Adding a suffix is easy:

  1. Launch AD Domains and Trusts
  2. Right-click on Active Directory Domains And Trusts (not the domain name) and select Properties
  3. Enter the desired domain name in Alternative UPS Suffixes and click Add

image

Next you’ll change the UPN of the users. You can do this in AD Users and Computers (very slowly) or Google some PowerShell to do it near instantly at scale.

image #

Users will now have a single UPN for LAD (Azure, Office 365, etc), AAD, (hopefully) their email, and any third party SaaS if you federate your AAD.

A Demo Lab

I bought joeelway.com for my demo lab so I can show the real world solution in classes. If you’re just experimenting, learning, or doing a quick demo, then you can use the Azure default domain name. The default domain name is based on the name of your Azure subscription, for example joeelwayazure.onmicrosoft.com. Use this domain name as the additional suffix in your LAD, and set the UPNs to use this, e.g. barbara@joeelway.onmicrosoft.com; use this UPN for logging into cloud services.

Technorati Tags: ,,
Please follow and like us:

Leave a comment

Your email address will not be published.

*