Azure Active Directory vs. On-Premises Active Directory

Q: What's the difference between Azure Active Directory and Windows Server Active Directory?

A: The Active Directory capabilities that are part of Windows Server actually include several different roles, such as Active Directory Certificate Services (AD CS), Active Directory Lightweight Directory Services (AD LDS), Active Directory Federation Services (AD FS), and Active Directory Rights Management Services (AD RMS). However, most people think of Active Directory as the Active Directory Domain Services role, and this "Active Directory" is what most people mean when comparing AD with Azure Active Directory.

The reality is that Active Directory Domain Services (henceforth just Active Directory) in Windows Server is completely different from Azure Active Directory (Azure AD), and they actually have different focus areas. When you think about Active Directory you're talking about a true directory service that has a hierarchical structure (based on X.500) that uses DNS as its locator mechanism and can be interacted with via LDAP. In addition, Active Directory primarily uses Kerberos for authentication. Active Directory enables organizational units (OUs) and Group Policy Objects (GPOs) in addition to actually joining machines to the domain, and trusts are created between domains.

Azure AD, while having some aspects of a directory service, is really an identity solution and allows users and groups to be created but in a flat structure without OUs or GPOs. You can't join a machine to Azure AD. There's no Kerberos authentication, and you can't query it via LDAP. This is OK because the things Azure AD doesn't have make sense on-premises, where all types of communication are possible. However, Azure AD is focused around identity throughout the Internet, where the types of communication are typically limited to HTTP (port 80) and HTTPS (port 443) and are used by all types of devices—not just corporate assets. Authentication is performed through a number of protocols such as SAML, WS-Federation, and OAuth. It's possible to query Azure AD but instead of using LDAP you use a REST API called AD Graph API. These all work over HTTP and HTTPS.

When you think about using Azure AD, you'll use it for authentication for Internet-based services such as Office 365 and Azure, as well as much more, including Facebook and thousands of other services that are already federated with Azure AD (which mean they trust Azure AD without you having to do anything other than enable that application or service to be used by your users).

For the best seamless experience, you think about combining your on-premises Active Directory with Azure AD by setting up directory synchronization (including password sync) and federation. This allows users on their corporate assets to log on with their AD account and when they access Internet services, such as Office 365, authentication with Azure AD just happens seamlessly via the federation, allowing access to all the different services that Azure AD is federated with. This is actually a great benefit of federating your on-premises AD with Azure AD. It's possible for your organization to federate with all the different companies out on the Internet, but this is a lot of work to set up and maintain. However, if you just federate with Azure AD then you're now federated by proxy with all the organizations that Azure AD is federated with—which is pretty much all of the major services on the Internet today. Think of Azure AD as acting like a federation hub.