The fundamentals of Azure identity management
By Curtis Love as written on docs.microsoft.com
Managing identity is just as important in the public cloud as it is on premises. To help with this, Azure supports several different cloud identity technologies. They include these:
You can run Windows Server Active Directory (commonly called just AD) in the cloud using virtual machines created with Azure Virtual machines. This approach makes sense when you’re using Azure to extend your on-premises datacenter into the cloud.
You can use Azure Active Directory to give your users single sign-on to Software as a Service (SaaS) applications. Microsoft’s Office 365 uses this technology, for example, and applications running on Azure or other cloud platforms can also use it.
Applications running in the cloud or on-premises can use Azure Active Directory Access Control to let users log in using identities from Facebook, Google, Microsoft, and other identity providers.
Running Windows Server AD in Azure virtual machines is much like running it on-premises. Figure 1 shows a typical example of how this looks.
Figure 1: Windows Server Active Directory can run in Azure virtual machines connected to an organization’s on-premises datacenter using Azure Virtual Network.
In the example shown here, Windows Server AD is running in VMs created using Azure Virtual Machines, the platform’s IaaS technology. These VMs and a few others are grouped into a virtual network connected to an on-premises datacenter using Azure Virtual Network. The virtual network carves out a group of cloud virtual machines that interact with the on-premises network via a virtual private network (VPN) connection. Doing this lets these Azure virtual machines look like just another subnet to the on-premises datacenter. As the figure shows, two of those VMs are running Windows Server AD domain controllers. The other virtual machines in the virtual network might be running applications, such as SharePoint, or being used in some other way, such as for development and testing. The on-premises datacenter is also running two Windows Server AD domain controllers.+
There are several options for connecting the domain controllers in the cloud with those running on premises:+
Make all of them part of a single Active Directory domain.
Create separate AD domains on-premises and in the cloud that are part of the same forest.
Create separate AD forests in the cloud and on-premises, then connect the forests using cross-forest trusts or Windows Server Active Directory Federation Services (AD FS), which can also run in virtual machines on Azure.
Whatever choice is made, an administrator should make sure that authentication requests from on-premises users go to cloud domain controllers only when necessary, since the link to the cloud is likely to be slower than on-premises networks. Another factor to consider in connecting cloud and on-premises domain controllers is the traffic generated by replication. Domain controllers in the cloud are typically in their own AD site, which allows an administrator to schedule how often replication is done. Azure charges for traffic sent out of an Azure datacenter, although not for bytes sent in, which might affect the administrator’s replication choices. It’s also worth pointing out that while Azure does provide its own Domain Name System (DNS) support, this service is missing features required by Active Directory (such as support for Dynamic DNS and SRV records). Because of this, running Windows Server AD on Azure requires setting up your own DNS servers in the cloud.+
Running Windows Server AD in Azure VMs can make sense in several different situations. Here are some examples:+
If you’re using Azure Virtual Machines as an extension of your own datacenter, you might run applications in the cloud that need local domain controllers to handle things such as Windows Integrated Authentication requests or LDAP queries. SharePoint, for example, interacts frequently with Active Directory, and so while it’s possible to run a SharePoint farm on Azure using an on-premises directory, setting up domain controllers in the cloud will significantly improve performance. (It’s important to realize that this isn’t necessarily required, however; plenty of applications can run successfully in the cloud using only on-premises domain controllers.)
Suppose a faraway branch office lacks the resources to run its own domain controllers. Today, its users must authenticate to domain controllers on the other side of the world – logins are slow. Running Active Directory on Azure in a closer Microsoft datacenter can speed this up without requiring more servers in the branch office.
An organization that uses Azure for disaster recovery might maintain a small set of active VMs in the cloud, including a domain controller. It can then be prepared to expand this site as needed to take over for failures elsewhere.
There are also other possibilities. For example, you’re not required to connect Windows Server AD in the cloud to an on-premises datacenter. If you wanted to run a SharePoint farm that served a particular set of users, for instance, all of whom would log in solely with cloud-based identities, you might create a standalone forest on Azure. How you use this technology depends on what your goals are. (For more detailed guidance on using Windows Server AD with Azure, see here.)
As SaaS applications become more and more common, they raise an obvious question: What kind of directory service should these cloud-based applications use? Microsoft’s answer to that question is Azure Active Directory.+
There are two main options for using this directory service in the cloud:+
Individuals and organizations that use only SaaS applications can rely on Azure Active Directory as their sole directory service.
Organizations that run Windows Server Active Directory can connect their on-premises directory to Azure Active Directory, then use it to give their users single sign-on to SaaS applications.