Do you know how powerful Azure Active Directory (AAD) is? Do you know it’s not just an Azure or an Office 365 thing? I find that when I talk to people about Azure or when someone else is talking about it, topics like Azure Site Recovery (ASR), VMs in the cloud, or Azure Backup are in the conversation. But very few people talk about AAD, what I think is Microsoft’s killer hybrid service.
Connecting Azure AD
I heard a phrase around Ignite 2015 that I hadn’t before: Legacy AD (LAD); apparently that’s what Microsoft now call the AD that you have been running on servers since Windows Server 2000 (W2000). This is because Microsoft is investing in Azure AD, and expecting you to connect your LAD to AAD. This will make, at the lowest level, your users and their passwords available in the cloud:
- Federation: Using ADFS, you can connect AAD with LAD. AAD doesn’t store user accounts in this design. Instead details are continued to be stored in LAD, and AAD reaches out to LAD to authenticate or authorise users whenever there is a request – no connection = no sign-in. This is a single sign-on solution.
- Synchronisation: This is a solution that Microsoft has had many tools for, but now Azure AD Connect (AADConnect) does. Usernames and passwords are synchronised beween LAD and AAD, stored in both locations. The solution is more tolerant of failure than federation but not as scalable. This is known as shared sign-on.
Note that I’ve talked about users so far. We can now register devices in AAD (e.g. Windows 10) and via write-back, send these details back to LAD.
You Might Have Already Connected
You might not know this, but AAD is what provides user services for Office 365 (and other MSFT SaaS products). If you’ve deployed Office 365 with DirSync (or another sync tool) or ADFS then you have already accomplished the above. With a few mouse clicks in the O365 admin portal, you can make your domain appear an the Azure management portal.
AAD – Single Security Database for Microsoft SaaS
Microsoft uses AAD for all of their business cloud services:
- Office 365
- Azure
- Intune
- CRM
- Azure Rights Management Services
- And more
This makes it really easy for a business to enable a user to avail of new services once you have configured AAD: you configure the domain, and then you can bring O365 or any of the other Microsoft online business services to those users in seconds.
Single Sign-On With Third-Party SaaS
Microsoft isn’t stupid; they know that you use third-party cloud services, such as SalesForce. And you know what? Microsoft wants to make that easier for you by enabling single sign-on. So not only can users use their single username/password combination to sign into their PC and access their servers, but now the same credentials can work with Microsoft cloud services and third-party services. This brings “shadow IT” under the control of IT. You can use the free Cloud App Discovery to scan a network, find what online services are being used by the business, and reign these services under control using AAD.
There is an upsell here. Microsoft sells AAD Premium (included in the EMS Suite) to enable SSO with more than 10 cloud services. This upgrade also brings in things like self-service password reset.
The Future is Now
Because AAS is a cloud service, it can be developed and improved at cloud pace which is weeks, not years. Feedback and innovation are driving rapid change. You can register devices, including Windows 10 PCs, with AAD. That’s pretty cool:
- Mobile workers can register with AAD
- It makes BYOD and remote working easier
- Cloud-centric SME’s might not need an on-premises DC anymore
Replacing GPO
If LAD is how we control policy on user devices, and we’re replacing LAD with AAD, how do we configure machines? The answer is Microsoft Intune. Intune can configure policy on managed devices. We’re told (I haven’t verified this for myself yet) that:
- A customer have configured AAD
- The customer has licensed for Intune with that domain
- A user registers their device in the AAD domain
- That device is automatically enrolled for management by Intune – and getting policy from Intune
How I’ve Done It
At work, we deployed the following solution to get AAD configured:
- We have 2 on-premises DCs, required for our Hyper-V cluster
- There is an Azure subscription and an O365 E3 subscription
- We deployed 2 Basic A-series VMs in an availability set in Azure on a VNET
- There is a site-to-site VPN connection between the on-prem network and the VNET
- The Azure VMs are joined to the domain and promoted to be DCs
- AADConnect is installed on one of the in-Azure VMs to connect with AAD (O365)
- Configure the domain in Azure AD via the O365 Admin Portal
And from there, we’ve opened up all of the power of Azure AD … albeit requiring additional licensing for the Premium edition 
Why create the VM’s in Azure? (vs running AADConnect on an on-premise DC or vs setting up ADFS)
Was it just to get around having to setup ADFS or was it more for resiliency (having a DC in the cloud in case your DC’s go down).
Do you recommend AADConnect over ADFS in general or was picking AADConnect done for this specific scenario?
Thanks!
Great question – It’s a long-term play. We want to implement Azure Site Recovery for DR. If you have more than 1 DC then the correct solution for the DC’s is not to replicate the DC VMs but to use AD replication. So … I have that done now. Next we need to sort out some on-prem stuff, and then we can deploy ASR for the other LOB/data VMs. If we do a failover, the machines will authenticate in the ASR site.
Why are we running the Sync in the cloud? It means that if we fail over, then nothing changes there. There’s not much more gain. If we were using ADFS, then I would absolutely put it in the cloud because it rules out our on-prem Internet connection as a point of failure for remote workers.
Thanks! Makes sense, especially when you consider how cheap a VM in Azure really is (at least one that would only be running the DC role!)
“…especially when you consider how cheap a VM in Azure really is (at least one that would only be running the DC role!)”
Aidan stated in his other post that he went for a basic A1 for one of his Azure located domain controllers and a basic A2 for the other domain controller that ran the AADConnect role since it needed a bit more ram. The Azure Pricing Calc’s saying running those two VM’s will currently cost you £1210 for the year (ignoring the 11% Azure price increase next month).
I wouldn’t say that really is that cheap, considering you could run those on your probably already existing virtualised private cloud for practically no additional cost?
But yes, the benefit is that your DR failover will be seamless should you ever actually need it.
You’re thinking way too small. There’s a cost to running anything on-premises: power, disk, management software, etc. That’s all included in the cost of the VMs in Azure. Plus having these DCs in the cloud ensures that the domain runs without the on-premises network is operational. You mentioned DR; that’s one scenario. What if you’re using ADFS and have branch offices/mobile workers? Do you want your ENTIRE business offline because O365/etc cannot authenticate users? You can avoid that by running DCs & ADFS in the cloud, and limit the damage caused by the network outage. And I did say that DCs in the cloud were a start. I can then deploy other VMs in Azure and authenticate them reliably and efficiently against “local” DCs. Think BIGGER.
I think the main stumbling block with the AAD management is going to be the Windows InTune license costs which are very high.
€4.60 per user per month, with up to 5 devices for that user, including the cost of AV. Or buy it as a part of the EMS bundle that includes Azure AD Premium, Azure RMS Premium, and soon, Advanced Threat Analytics.