Managing identities is a vital part of cyber-security in general and especially in the cloud. Organizations may want to manage identities, authentication and authorization by themselves, also when users are accessing cloud resources and workloads. They can do this without any problems by using Azure AD Sync to synchronize Active Directory Objects to Azure AD, and therefore keep the source of authority of these objects in the organization. On the other hand, organizations may use ADFS to federate identities. By doing this, authentication and authorization decisions are made also in the organization.
IT professionals normally try to build such labs in order to understand and see how everything works. These days I managed to build such a lab in Microsoft Azure. I used a MSDN subscription where you get a monthly credit of 115 EUR, if I’m not wrong. I think it may be helpful to briefly share how I build this lab.
First, we needed 1 Domain Controller, 1 Azure AD Sync server, 1 ADFS, 1 Web Application Proxy and, of course, 1 client.
First of all we need to create a cloud service where our virtual machines would run. We simply can’t create virtual machines without any available cloud service. You may find HERE a step-by-step guidance on how to do this.
Secondly, we would need a virtual network. Again, it is not a big deal to create it, you just have to follow this step-by-step documentation. It is important here to define the exact subnet that we’ll be using, since our VMs will get IPs based on the subnet configuration.
Then we can start to create the VMs. As mentioned above, for this standard lab we would need 4 Windows Server 2012 R2 servers and 1 Windows 8.1 client.
We can start building our lab as soon as our virtual machines are up and running. As a first thing to do is set a static IP for the VMs that will be used as Domain Controller/DNS server, and ADFS. Next, we install the DNS server role on the machine that will be also promoted to domain controller. After the role is installed, set 127.0.0.1 in the machine IP configuration for the DNS server. A restart of the VM will be necessary.
Next step would be to install Active Directory Domain Services and run the configuration wizard afterwards. A restart is again required and starting now we would be able to login to the server with domain credentials. Afterwards we can join all machines to the domain, except the WAP. Also in the IP configuration of each machine set the IP address of your DNS server as primary DNS address.
Next step would be to download Azure AD Sync on the machine where we would like to configure it. The latest build fixed some very important issue and as far as I can see this build is already available in the download centre. When the download completes, you can install and configure the sync service (before you do this, please make sure that directory synchronization is activated in your Office 365 tenant). Now we can run a first synchronization to Office 365.
Now that synchronization is also working we would have to configure the ADFS server. Here there is another aspect that we have to take into consideration: certificates. For my lab I installed Active Directory Certificate Services on the ADFS server and configured a local certification authority. We can then issue a certificate with the FQDN of your secure token service as a subject and import it to the local certificate store of the server. We would also have to export it, including the private key, and import it later on the WAP.
IMPORTANT NOTE! Please don’t do this in a production environment! It is important to understand that for a production environment we would need a certificate issued by a trusted certification authority.
When the certificate is ready to use, we can install ADFS server role and run the ADFS configuration wizard afterwards. For a step-by-step guidance on how to set up ADFS with Office 365 you may use THIS documentation. After everything is done, SSO to Office 365 should work perfectly from the Windows 8.1 client that you created as VM.
Last step would be to configure the Web Application Proxy. In Windows Server 2012 R2 we would have to install the Remote Access Server Role and choose Web Application Proxy as a service role. To find out more about this, please refer to this step-by-step documentation. After the installation, we are prompted to run the configuration wizard. Here we would have to specify the certificate we imported and a domain admin credential set and we should be good to go. Also we would have to make sure that the WAP server (which is not domain joined) is able to communicate with the ADFS server. To do this we may need to configure an additional endpoint and a specific ACL.
However, with this step, we’re still not ready to go. If we want to login form outside our cloud service, we would have to create an additional endpoint on the WAP server for HTTPs traffic.
And we have also to make sure that external traffic is redirected properly to the WAP server. To do this, most documentations advise to create an A record in the public DNS zone of the federated domain, pointing to the WAP server. In Azure we may be able to direct traffic to the public IP of the cloud service. However, if you shut down your machines in order to minimize costs, the public IP of the cloud service would be different each time you power on your VMs. So to avoid this, I decided to create a CNAME record pointing to mycrloudservice.cloudapp.net, instead of an A record pointing to the public IP of the cloud service. This works perfectly for me.
Now your Office 365 identity lab should be up and running. Hope this is helpful for you :). As always, feedback is really appreciated.
Latest posts by Dan Patrascu-Baba (see all)
- #Build 2017 – some exciting things - 10/05/2017
- Testing Azure AD per app MFA and conditional access based on network location - 29/07/2016
- Curriculum Vitae Builder, a great Office add-in - 28/07/2016