Freigeben über

Using ADConnect with multiple clouds

  • Artikel

(dieser Artikel ist auch auf deutsch verfügbar)

I was curious how you can connect an on-premise domain to multiple clouds, especially to Azure and Azure Germany. So I tried it, and here is the result...

Why?

Maybe a few words at the beginning on why you might want to do this... The Microsoft Cloud Germany comes with a separate Azure Active Directory, which means that uses that exist in the Azure AAD are completely unknown to the AAD of Azure Germany, and vice versa. So any authentication of those (global) users to services in Azure Germany is not possible, and - again - vice versa. Maybe there is a way to have users in both AADs? That was exactly the starting point for this blogpost.

Logical view

To make that very clear from the beginning: Users cannot have the same username in Azure and Azure Germany. Why? Well, user names in AAD always consist of the username itself and a domain name, and the domain name is different: For Azure this is "onmicrosoft.com" and for Azure Germany it is "onmicrosoft.de". So the user "ralf@demobag.onmicrosoft.com" is definitely not in the AAD of Azure Germany...

But how about additional domains? Can I add "demobag.de" to Azure? Yes you can, but those domains can only be added to one tenant at the same time, so if you add the domain to Azure, the user "ralf@demobag.de" can login to Azure, but when you try to add the same domain also to your Azure Germany tenant it will fail. Or the other way round, when you add this domain to Azure Germany, you cannot add it at the same time to the global Azure. "ralf@demobag.de" would then be able to login to Azure Germany but not to Azure. (Just to make it clear here: the ".de" ending for additional domains can be used in both AADs, same is for any other top level domain.)

Technical view

From a technical perspective of course you can have the sync tool "ADConnect" running on more than one server in your domain. And you can use a filter to define which accounts should be synchronized, for example based on OrganizationsUnits OU. Problem here is that you cannot sync the same user with the same login name to different environments, as stated above. There might be even more than one way to solve this (rename users etc), the one that I tried is to use different UPN suffixes in the local domain.

UPN suffixes? Remember? Quite easy: By default the so called UserPrincipalName (UPN) of an (onpremise) AD user aligns to the DNS name of the domain (roughly speaking). So if the AD domain is called "DEMOBAG" and the DNS name is "demobag.de", then the login name of a user looks like "DEMOBAG\ralf" or - as UPN - "ralf@demobag.de". You can add UPN suffixes (the part after the "@") in your local domain, so users within the same domain can have different login name schemas. It would be possible for example to have some users with a login " @germany.demobag.de" and other users with " @global.demobag.de", but all users are part of the "DEMOBAG" domain. And that's what I did. For a better overview here is a picture:

[caption id="attachment_465" align="alignnone" width="445"]Setup of the on-premise domain Setup of the on-premise domain[/caption]

As you can see I gave all the users in "OU=germany" the UPN suffix " @germany.demobag.de", and did the same for the users in "OU=global" with " @global.demobag.de". The UPN suffix is assigned per user and does not depend on the OU, this was just easier to handle and easier to define a filter on this (see later).

How does this help me?

By using the UPN suffix we have something that looks like a subdomain (but is still one AD domain). With this trick we can add the two "subdomains" germany.demobag.de and global.demobag.de to different Azure tenants, for example the germany.demobag.de to the subscription in Azure Germany and global.demobag.de to a different subscription in Azure global. And when we set up a synchronization between local AD and Azure AD (or better: two synchronizations - one for each Azure environment) users from our local domain with a login name like "foo@germany.demobag.de" can use the same name to login to Azure Germany (and even the same password if you chose to sync those, too). And of course other users of our local domain with a name like "bar@global.demobag.de" can also use the same name to login to Azure global. But keep in mind that we still have this restriction that a user can only exist in one of the two AAD directories, and that the login does not work for the 'other' environment, so "foo@germany.demobag.de" cannot login to Azure and "bar@global.demobag.de" cannot login to Azure Germany.

Just do it

Now for the details. I do this here with the domain demobag.de (which is mine and I can manage the DNS server, which is important for later...).

Step 1: Subscriptions

We need two subscriptions, one in Azure and one in Azure Germany. For this example I created "demobag.onmicrosoft.com" on the page https://account.windowsazure.com/organization, and the second tenant "demobag.onmicrosoft.de" on https://account.windowsazure.de/organization (please note that both links have only a different ending .com vs. .de!).

Step 2: The DNS thing

For the DNS management we need the two DNS subdomains "germany" and "global", and our always helpful and friendly DNS master can do this hopefully (I'm skipping this step since there are so many different tools to do this and I'm sure your DNS admin knows what and how to do). Just to make clear: We are only creating DNS subdomains, no AD domain, we will continue to use only "DEMOBAG" or "demobag.de".

Step 3: Add DNS domains to AAD

I did this before in another blogpost, here is the short form: Login to Azure, add the domain "global.demobag.de", and Azure will give us a test DNS record that we have to add to our DNS server (and again your friendly DNS master knows how to do this, it's easy). The idea is that when you can administer the DNS server of a domain, that domain most likely belongs to you. After you entered the test record in your DNS server, initiate the verification in Azure. When Azure finds the expected test record it takes it as a proof that the domain is yours. Do the same with Azure Germany by adding "germany.demobag.de", edit the DNS server and let Azure Germany verify it. Now you are ready for ADConnect...

Step 4: ADConnect - finally

I also did the setup for ADConnect before in this article so I will skip this here - it's easy anyways. Be aware that you need two servers in your domain (and please for security reasons don't use the domain controller): One for ADConnect to Azure, and one for ADConnect to Azure Germany. It's the same software, but a different configuration. ADConnect picks the right environment based on the login name (onmicrosoft.de or onmicrosoft.com). Make sure that you define a correct filter: The two syncs have to be mutually exclusive, for our example we sync the "OU=global" to Azure and "OU=germany" to Azure Germany. Since users can only be in one of the OUs, this makes sure that also the users will by sync'ed only to one AAD.

Step 5: Test

After a successfull synchronisation all users of the OU "germany" with a UPN suffix "germany.demobag.de" can login to Azure Germany, for example at the Azure Germany Management Portal by using their normal domain user, like "foo@germany.demobag.de". Same is true for users of the OU "global" with the UPN suffix "global.demobag.de". They can login at the global Azure Management Portal with their normal usernames, like "bar@global.demobag.de". I'm sure you noticed that these are different portals...

Step 6: Documentation

Nobody does this anyways, it is here just for completeness :-) and an overview picture that hopefully says more than a thousand words...

Demo-Szenario

Summary

Using different UPN suffixes enables us to (kind of) simulate subdomains, and to sync a single AD domain into different Azure ADs by using multiple ADConnect instances. Separation of users is done by using filters, for example based on OU.

If you want to test it, you can do this completely in Azure (no matter in which one :-)). Just deploy 3 VMs: A domain controller, 2 member servers, that's it and that's exactly how I did it...

Bye.

Comments

  • Anonymous
    January 26, 2017
    Very well thought out! I like this architecture. Thank you for posting.
  • Anonymous
    January 29, 2017
    Well Explained Post. Will definitely try this one out in my demo env.
  • Anonymous
    February 09, 2017
    Really great article - as the others are as well - thanks. The only thing missing for me is: "what if one person needs to go to both sides - Global and Germany (and maybe also more than one tenant on both sides)"Sounds weird, but this is exactly what we are trying to achieve right now. This is for a valid reason, which explaining here would exhaust any reader ;)
    • Anonymous
      February 13, 2017
      See article at the beginning: To make that very clear from the beginning: Users cannot have the same username in Azure and Azure Germany. So when the user has two accounts, one can be sync'ed to global and one to Germany.