SOLVED

On premise Active directory and Azure Active directory synchronization

%3CLINGO-SUB%20id%3D%22lingo-sub-105854%22%20slang%3D%22en-US%22%3EOn%20premise%20Active%20directory%20and%20Azure%20Active%20directory%20synchronization%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-105854%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20are%20planning%20to%20sync%20our%20On%20premise%20AD%20to%20Azure%20AD%2C%20but%20there%20is%20a%20part%20where%20we%20have%20to%20create%20a%20new%20TXT%20or%20MX%20record%20with%20the%20domain%20registrar%2C%20the%20problem%20is%20our%20on%20premise%20domain%20name%20is%20already%20owned%20by%20the%20other%20company%20which%20is%20why%20we%20cannot%20create%20TXT%20or%20MX%20record.%3C%2FP%3E%3CP%3EIs%20ther%20any%20other%20way%20to%20sync%20our%20on%20premise%20AD%20to%20Azure%20AD%20without%20creating%20TXT%20and%20MX%20records%3F%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-105854%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAzure%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-106248%22%20slang%3D%22en-US%22%3ERe%3A%20On%20premise%20Active%20directory%20and%20Azure%20Active%20directory%20synchronization%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-106248%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Brian%2C%3C%2FP%3E%3CP%3EOne%20of%20the%20goals%20of%20establishing%20a%20sync%20between%20on-prem%20AD%20and%20Azure%20AD%20is%20to%20create%20a%20%3CSTRONG%3E'common%20identity'%3C%2FSTRONG%3E.%20In%20other%20words%20to%20have%20the%20same%20username%20(UPN)%20in%20both%20environments.%3C%2FP%3E%3CP%3EIt%20is%20not%20required%20to%20use%20custom%20domains%20nor%20to%20register%20your%20current%20on-premises%20domain%20as%20custom%20domain%2C%20but%20the%20most%20common%20practice%20is%20to%3A%3C%2FP%3E%3CUL%3E%3CLI%3Epick%20your%20primary%20e-mail%20(SMTP)%20domain%2C%3C%2FLI%3E%3CLI%3Eadd%20this%20one%20as%20your%20custom%20domain%20in%20Azure%20AD%2C%3C%2FLI%3E%3CLI%3Everify%20it%20with%20DNS%20TXT%20record%20(%3CEM%3Eif%20it%20is%20your%20e-mail%20domain%2C%20you%20should%20own%20it%2C%20right%3F%3C%2FEM%3E)%3C%2FLI%3E%3CLI%3Eand%20then%20you%20can%20add%20that%20domain%20as%20a%20new%20UPN%20suffix%20in%20your%20Windows%20Server%20AD%20and%20change%20your%20AD%20user%20accounts%20to%20use%20this%20UPN%20suffix.%3C%2FLI%3E%3C%2FUL%3E%3CP%3EIn%20this%20way%20your%20users%20will%20be%20using%20the%20same%20username%2C%20which%20is%20a%20first%20step%20to%20single%20sign-on.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-106193%22%20slang%3D%22en-US%22%3ERe%3A%20On%20premise%20Active%20directory%20and%20Azure%20Active%20directory%20synchronization%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-106193%22%20slang%3D%22en-US%22%3E%3CP%3EThanks%20Alex!!!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-105925%22%20slang%3D%22en-US%22%3ERe%3A%20On%20premise%20Active%20directory%20and%20Azure%20Active%20directory%20synchronization%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-105925%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Brian%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThere%20is%20no%20requirements%20that%20the%20shared%20and%20custom%20domain%20names%20must%20match.%20When%20you%20create%20an%20AAD%20instance%2C%20you're%20assigned%20a%20sheared%20domain%20(which%20is%20'*.onmicrosoft.com')%2C%20then%20you%20need%20to%20create%20a%20public%20DNS%20record%20(your%20public%20domain%20name)%20and%20verify%20it%20as%20documentation%20suggests%20(via%20TXT%20or%20MX%20record).%20Once%20it%20is%20done%2C%20you%20would%20have%20two%20domain%20names%20associated%20with%20your%20directory%20and%20you%20need%20to%20change%20it%20to%20'Primary'%20(the%20public%20one%20I%20mean).%20Then%20keep%20going%20with%20prerequisites%20to%20make%20AD%20Sync%20work.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EPlease%20follow%3A%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fwww.microsoftpressstore.com%2Farticles%2Farticle.aspx%3Fp%3D2315271%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fwww.microsoftpressstore.com%2Farticles%2Farticle.aspx%3Fp%3D2315271%3C%2FA%3E%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fconnect%2Factive-directory-aadconnect-prerequisites%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fconnect%2Factive-directory-aadconnect-prerequisites%3C%2FA%3E%20(Azure%20AD%20Connect%20prerequisites).%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
Deleted
Not applicable

We are planning to sync our On premise AD to Azure AD, but there is a part where we have to create a new TXT or MX record with the domain registrar, the problem is our on premise domain name is already owned by the other company which is why we cannot create TXT or MX record.

Is ther any other way to sync our on premise AD to Azure AD without creating TXT and MX records? 

3 Replies
Highlighted
Best Response
Solution

Hi Brian,

 

There is no requirements that the shared and custom domain names must match. When you create an AAD instance, you're assigned a sheared domain (which is '*.onmicrosoft.com'), then you need to create a public DNS record (your public domain name) and verify it as documentation suggests (via TXT or MX record). Once it is done, you would have two domain names associated with your directory and you need to change it to 'Primary' (the public one I mean). Then keep going with prerequisites to make AD Sync work.

 

Please follow:

https://www.microsoftpressstore.com/articles/article.aspx?p=2315271

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-prerequi... (Azure AD Connect prerequisites).

Highlighted
Highlighted

Hi Brian,

One of the goals of establishing a sync between on-prem AD and Azure AD is to create a 'common identity'. In other words to have the same username (UPN) in both environments.

It is not required to use custom domains nor to register your current on-premises domain as custom domain, but the most common practice is to:

  • pick your primary e-mail (SMTP) domain,
  • add this one as your custom domain in Azure AD,
  • verify it with DNS TXT record (if it is your e-mail domain, you should own it, right?)
  • and then you can add that domain as a new UPN suffix in your Windows Server AD and change your AD user accounts to use this UPN suffix.

In this way your users will be using the same username, which is a first step to single sign-on.