Azure AD Connect was recently released by Microsoft to help federating on-premises environments with Office 365. I have tested it and created my own lab (now working fine). I have identified exactly 10 steps to build such environment. I’m not going to dive in the details on how to complete these 10 steps because it’d be way too long and I’d loose most of the readers after a few steps only. Here the idea is to share the AD Connect experience and potential problems you might encounter with the solutions you could try.
Step 1 – Join your Azure Tenant with Office 365 if necessary
If you already have a separate Azure Tenant, you must join it to your Office 365 tenant. Quite easy to do as you only need to add an external user that exists in your 365 directory to your Azure directory. Azure will then join both systems and you’ll be able to select the Office 365 AD as the default AD of the subscription.
Step 2 – Add a domain you own to your Office 365 AAD
The goal of this step is to join a domain known on the Internet to Office 365. You can now do that directly from the AAD in Azure. 365 will ask you to add some records to prove that you’re well the owner of the domain. If you don’t host the domain (as for me), you can ask your provider to add the required records via a support ticket. Usually they accept doing such things.
Step 3 – Create a virtual network in Azure
Since you’ll have to install three VMs that must talk to each other, you should first add a virtual network in Azure.
Step 4 – Create three virtual machines in Azure
To create the federation, you’ll need two machines. One that hosts the actual federation service and one that plays the role of the ADFS proxy. The latter should be in DMZ. So must not join it to the domain (next step). The third machine is optional but the idea is to add a client machine to the domain that you create in step 5 so that you can play with ADFS & Azure settings about dual factor authentication etc…by accessing applications/365 via domain joined machines and external devices.
Step 5 – Promote one machine as a Domain Controller
In one of the machine, add the Domain Controller windows role. Once done, choose the Create new forest option and specify your domain : i.e silver-it.com.
Reboot the machine.
Step 6 – Create a certificate
You’ll have to create a certificate. For a lab, a self-signed certificate is OK. Of course, you’ll be prompted by the browser when signing in. Only a few commands are required:
makecert.exe -n "CN=365Lab Root CA,O=SilverIT, OU=Development,L=Wallkill,S=NY,C=US" -pe -ss Root -sr LocalMachine -sky exchange -m 120 -a sha1 -len 2048 -r
makecert.exe -n "CN=*.silver-it.com" -pe -ss My -sr LocalMachine -sky exchange -m 120 -in "365Lab Root CA" -is Root -ir LocalMachine -a sha1 -eku 188.8.131.52.184.108.40.206.1
You should then export the .pfx and choose a password for later use.
Step 7 – Enable Remote PowerShell in both VMs
Follow the instructions given here https://technet.microsoft.com/en-us/magazine/ff700227.aspx to enable remote PowerShell. The tip here is that you must also enable it for the local machine (where AD Connect wizard is running).
Step 8 – Add the required DNS Records
You’ll need to make sure to create a DNS record (Forward lookup zone – A record) that points to the proxy server. During the installation process (next step), the wizard will prompt you for a prefix in order to build the federation services URL. For instance adfslab…, so make sure to add another A Record for that guy.
Step 9 – Install and run AD Connect on the Domain Controller and perform the synchronization
Follow the instructions given by the wizard; You’ll have to pick the certificate created in step 6.
During the installation with the wizard, you can opt to perform an automatic synchronization once the setup completes but that didn’t work out for me. So, you can run it manually using the DirectorySyncClientCmd command that you should find in C:\Program Files\Microsoft Azure AD Sync\Bin.
Make your ADFS sign-in page reachable
As said previously, during the setup, AD Connect will prompt you to choose a prefix for the login page (i.e adfslab.silver-it.com. While you already had to add a DNS record for that guy to make it known internally, this page must also be publically available since this is where Office 365 will redirect users when logging in. So, three possibilities here:
- You only login using domain joined machines and that page will be available thanks the DNS record created previously but you can forget about mobile devices
- Since it’s a lab, you can edit the host files for laptops (not tablets & phones) you’d like to use and add an entry that points to the public IP of the proxy machine. That way, you’d be able to login using non domain joined desktops/laptops. Of course, this is only an option for a lab nor for a production environment
- The best option is to ask your domain hoster to add a A Record in the forward lookup zones to make this subdomain publicly known on Internet. After all, the proxy is in DMZ…
On top of that, you must add the support of HTTPS in the list of endpoints of the Azure VM.
In theory, the above 10 steps should be enough to get a federated on-premises environment with Office 365 but…in my experience, the wizard crashed for some weird reasons at the very last step :)…From there on, I’ve uninstalled AD Connect and rebooted the machine completely and reinstalled a few times but no luck.. I noticed that when reinstalling, it didn’t go through all the steps as for the first time which means that the uninstallation didn’t clean everything up. By the way, I also noticed that the technical account provisoned in Azure AD by the tool to perform the sync wasn’t removed either. I even had to create a new one and tell Sync Manager to use it to perform the sync because I had “invalid username/password issues”.
So, the additional tasks I had to do were:
- Enable the Web Application Proxy / AD FS proxy role
- Add two entries to the host file or the proxy server to make the federation server known. Remember that the proxy isn’t part of the domain. Just use the internal IP (if you installed all the VMs in the same network, that shouldn’t be an issue). One entry is for the host itself and another entry is for the ADFS login page.