If you have seen some of my posts, specifically the posts for step-by-step guiding Remote Desktop Services installation, configuration and modification, you might have noticed that I use a very basic lab setup. Simply running the Hyper-V role on my laptop and building needed VMs there.
It’s time for a more “professional” lab environment.
I decided to go for an Azure lab. I have multiple reasons for choosing Azure. It gives me the chance to learn something new, possibilities to do this with colleagues, and it’s Microsoft’s cloud, since my goal is to ultimately create a full blown hybrid cloud environment with my private datacenter, currently in the meter cupboard because space was available for a Hyper-V host, and my internet cable connection is in there as well.
Disclaimer for those who want to build based on these “Building an Azure lab” guides:
I’m not claiming these are best practices, or that these are “the way to go”. I’m simply providing step-by-step guides set up by me, and my colleagues on occasion, to document how we did things to achieve the goals that were set. These guides get the job done, for me.
That said, let’s get started.
I started with an MSDN Subscription Azure benefit, which, fortunately, is provided by my employer. These guides work for any subscription, even trial subscriptions.
I activated the MSDN Azure subscription and logged on to https://manage.windowsazure.com using my personal live-id which is linked to said MSDN account.
The first thing I see is that an Azure AD is provided for me, named “Default Directory”.
Goal for this guide is to sync my on-premises Active Directory to this Azure AD and provide a federated logon experience when logging in on any Azure services that leverages Azure AD.
Passwords will be maintained in both directories.
Pre-requisites for this guide:
Working Active Directory on-premises.
UPN suffix that matches your external domain name (it-worxx.nl in my case).
A service account for Azure AD sync (this is a normal Domain User, no extra rights required).
Working Active Directory Federated Services on-premises (optional).
If you need to build the ADFS infrastructure I suggest following this guide for ADFS: http://www.schmarr.com/Blog/Post/12/Installing-Windows-2012-R2-Server-ADFS-Service-
And this one for ADFS proxy: http://www.schmarr.com/Blog/Post/13/Installing-Reverse-Proxy-on-Windows-Server-2012-R2-(Web-Application-Proxy)
Note: this is only to be able to use federation when accessing published services based on your Azure AD, it’s not a showstopper if you don’t have or want this.
While we’re in the Directory context let’s create a new admin account. Not all services based on Azure AD can be accessed using a personal live-id, so I want an account that has full rights to everything in my subscription, that can always be used. I’ll call this account the backdoor admin account from now on.
Enter the Display Name, select a role (Global Admin means full administrator for everything that you see in the portal) and supply an alternate email address, outside of your subscription context (your context being .onmicrosoft.com), and click next:
Note: make sure the alternate email address is some address you have access to. Temporary passwords will be mailed to this address should you need them.
Notice the only admin account there is just your live-id?
Type the backdoor admin email address (this is the mail address inside your subscription context, the username of which you needed to take note earlier. In my case that is firstname.lastname@example.org):
Put a check in your subscription to allow access and click the Finish button.
This effectively makes the backdoor admin a co-administrator for the subscription, allowing access to the Azure Portal. Without this setting the backdoor admin would not be able to see the subscription in the Azure Portal.
The new user is required to change the temporary password upon first log in, so let’s do that right away.
Remember that temporary password for the backdoor admin on the clipboard?
Log off the current user, and sign back into portal using the backdoor admin account (make sure to use the full username in your subscription context. Again, for me that is email@example.com) to change the password on first sign in.
We’re going to install some tools for connectivity to Azure AD. I chose to do this on my domain controller, but you’re free to choose any domain member server you like.
Log in to the machine using an account that is an administrator on that machine and an administrator for ADFS (if you’re going for federation).
For educational and informational purposes read this article about Azure AD Powershell: https://msdn.microsoft.com/en-us/library/azure/jj151815.aspx
The download and install the two packages mentioned in that article:
Those who choose to go forward without federation can skip the next step. I’ll tell you when to pick up the guide.
Open the Windows Azure Active Directory Module for Windows Powershell, which now should be in your start menu.
Issue the following command:
$msolcred = get-credential
This will prompt you for credentials. Enter your backdoor admin credentials.
Then issue the following command:
connect-msolservice -credential $msolcred
This effectively creates a connection to the Azure AD.
Issue the following command to register the federation in your on-premises ADFS and to tell Azure AD we did so:
Set-MsolAdfscontext -Computer <internal fqdn to your (primary) adfs server>
Ofcourse insert your own FQDN into that command before issuing it.
Issue the following command to add a new domain name to your Azure AD:
New-MsolFederatedDomain -DomainName <external domain name>
Note that this external domain name must match that UPN suffix I mentioned in the pre-requisites.
More info on this command can be found here: https://msdn.microsoft.com/en-us/library/azure/dn194105.aspx
Output for the command:
Notice that adding the domain requires you to prove it is your domain by adding a TXT record to the domain’s DNS. In my case I had to add a TXT record with a value of MS=ms62608000 as seen above. Use your own value for this and refer to your DNS provider for instructions.
And of course you can also check this statement in the Azure Portal in the Directory node, in your Default Directory (or whatever you renamed it to) on the Domains tab:
This will also tell you it is now verified.
At first I just tried to add the domain from this very same menu in the Azure Portal. I could get everything to work but couldn’t get this status to show up as Verified as it does now. I refer to my disclaimer, since this is probably my lack of knowledge at play.
For those who skipped the federation part, now’s the time to pick up again.
We’ll be setting up Directory Synchronization between the on-premises Active Directory and Azure Active Directory next.
Download and install Azure AD Connect. I also did this on my domain controller, but you’re free to choose any domain member server you like.
Download link I used for Azure AD Connect: https://www.microsoft.com/en-us/download/details.aspx?id=47594
Have a look at the Directory Integration tab in Directory menu in the Azure Portal for your Default Directory:
Notice that Directory Sync is still disabled and if you click the 2 below it will show the next steps to take. Installing and running the Azure AD Connect tools.
I have a SQL Server on-premises so I use that for the Synchronization database. If you don’t have one the wizard will install and use SQL Express on the current machine.
Also enter the account details that will be used to run the Sync tasks. This is the account I mentioned in the pre-requisites.
If you scroll down you find another option to configure. Custom sync groups. I’ll not be using those, so click the Install button.
Enter your backdoor admin credentials to access the subscription (luckily we already added the co-administrator role for the subscription). This will fail if you use your live-id. Click the Next button:
Enter credentials for an account to access your on-premises Active Directory. I used the same service account as the one that is used for the Sync tasks. If your Active Directory consists of multiple domains check the question marks for extra help and do some research yourself. My Active Directory consists of a single domain. Click the Add Directory button when everything is entered:
You have the option to add additional domains and forests. We’ll skip that and click the Next button:
This interface is used for differentiating users between forests and domains. Azure AD is a single domain as well, so all objects from all your on-premises forests and domains are synced into one domain. Since we have only the one domain I leave everything default here and click the Next button:
Because I have a multi-purpose Active Directory and don’t want anything synced to Azure AD right away I created a Security Group in Active Directory, named it ITW Azure Enabled, and added some users to it. I used this group in this step to scope the Azure AD synchronization. If you want federation to work make sure that the UPN for those users that need to be synced are set to the UPN suffix that was configured earlier. Best practice tip: make UPNs for users reflect their default email addresses. Make your own choices here and click the Next button:
Refresh the Azure Management Portal (assuming it is still on the Directory Integration tab):
Directory Sync is now Activated and step 3 tells you to verify the initial sync using the Azure Portal, so let’s do that as well.
Instead of clicking Continue, I pressed the Tab key:
I can now choose between a “Live ID”, which is considered a Personal account, or for the Federated way; a Work or school account.
I chose the Work or school account option.
And we’re there. My domain’s ADFS Proxy is presenting me with the interface I know, since I’m using it to access my own applications already, such as Exchange OWA and such.
Notice that fancy Bing background that changes daily to reflect Bing.com’s background in my ADFS pages? I’ll explain how to do that in a later post.
Bonus content unlocked (without extra effort I might add):
Since all Azure’s services share the Azure AD we have been working with in this post, we can now also do federated sign in to Office 365 services.
I assigned the Global Administrator role to firstname.lastname@example.org in the Azure Portal and used that account when opening https://portal.office.com/admin/default.aspx:
Several things to notice here.
I’m signed on to the Office Portal with the same account as I’m signed in to the Azure Portal (it won’t even ask for credentials if it’s still the same browser session!).
You can see the same account source as was shown in the Azure Portal.
And you can see all accounts are visible. Even the backdoor admin and the administrative account that is still my personal live-id which I used to create the Azure subscription.
Now if only I had some Office 365 licenses…
Until next time, where we’ll join the on-premises network to a virtual network in Azure using Site-2-Site VPN, effectively creating a hybrid cloud environment.