So, it’s important to distinguish Azure AD from on-premises AD. There are few similarities between the two. They are both Identity Providers (IdP). However, they used different protocols, structures, and so on. So, let’s look at some of the differences.
Both Azure AD and AD contain identities such as users, groups, and devices. And each identity has attributes that contain information and characteristics about that identity. So, that is a similarity.
On-premises Active Directory is hierarchical. In other words, you have a domain then under the domain you have containers, OUs, and sub-containers, and sub-OUs. Azure Active Directory is a flat structure where everything falls directly underneath the Azure AD “Domain”.
Accessing attributes and data
However, how that information is accessed is very different between the two. For both, you can of course use PowerShell to pull information. Also, both have GUIs that can be utilized. Azure AD has the Azure Portal and AD has the Microsoft Management Consoles. In Azure AD you also have the option to use the Azure Command Line Interface (CLI), as well. The protocols that are used to access that information are of course different. The most common protocol for on-premises AD is LDAP. Most applications and tools leverage LDAP to some degree to pull information. Azure AD the primary way to access as well as change information is Graph API.
Active Directory leverages Kerberos and NTLM to for authentication.
Whereas Azure Active Directory uses Oauth 2.0 and Open ID Connect. However, you will see SAML used quite a bit, especially for Single Sign On (SSO)
Configuration of Devices
In Active Directory, Group policy is used to configure computers. Many of the settings in Group Policy center around configuring security settings
In Azure Active Directory, Intune is used to manage the configuration of computers and devices.
Users, Groups, and Devices
On-premises Active Directory contains user accounts. However, Azure AD has many types of user accounts. For most organizations the majority of the users are sourced from Active Directory. In other words, users are synced from Active Directory. These are called synced accounts. Keep in mind that on-premise Active Directory is authoritative for these accounts including for the password
Additionally, users can be created natively in the cloud. These are named cloud users. These users do not exist in the on-premises Active Directory.
Finally, there are also guest users. Azure AD has a feature named B2B. B2B allows users from other Azure AD tenants to be given access to applications in your tenant. So, for example lets imagine a user is from the Contoso organization and his UPN is email@example.com. Continusing this example there is another organization named Fabrikam and hosts the Fabrikam.com domain. Fabrikam can invite john to the Fabrikam tenant as a guest account. Then when accessing an application hosted by Fabrikam, John would log in to the Contoso tenant and that authentication would be trusted by Fabrikam, and John could access the application. I will go into much more detail in an upcoming posting.
Below are the group types available in Azure AD. One nice feature that Azure AD possess is dynamic groups. With dynamic groups the group is built dynamically based on one or multiple attributes of the user or device.
- Synced Groups: Groups synced from on-premises Active Directory
- Assigned Group: A cloud group whose membership is assigned.
- Dynamic Group: A cloud group whose membership is determined by an attribute query.
- M365 Group: A group used in M365 for collaboration, especially with Office 365 applications
- M365 Dynamic Group: An M365 group whose membership is dynamically assigned by an attribute query.
Devices can be added to Azure Active Directory. There are 3 device states that Azure AD supports: Hybrid Azure AD Joined, Azure AD Joined, and Azure AD registered. I will just cover the basic here and save the details for an upcoming posting.
Hybrid Azure AD Joined: This is Windows computer that is joined to both on-premises Active Directory and Azure Active Directory. An Active Directory user or Azure AD user can login to these types of machines.
Azure AD Joined: This is a Windows computer that is joined to Azure Active Directory. Azure AD Users can sign into these devices. Keep in mind an Azure AD User can be a user synced from on-premises Active Directory.
Azure AD Registered: Is a device, usually a phone or tablet that is joined to Azure Active Directory. A local user account is able to login to this device. For example, with an iPhone you effectively login to the phone with your iCloud account and not an Azure AD account.
In on-premises Active Directory you delegate access to users, groups, and devices by OU. Azure AD is a flat structure, so there are no OUs to delegate access. In Azure AD you delegate access through Administrative Units. In order to accomplish this, you must first create the Administrative Unit. Then you add Users, Devices, or Groups to that AU. Finally, there is a set of roles that have certain rights and permissions over the objects contained in that AU. So, you add the users you would like to delegate access to, to one of those roles.
This concludes Part 1. In Part 2, I will discuss Authentication methods. Keep in mind that this posting was an overview, and I will go into a more detailed explanation once I cover the most common aspects of Azure AD at a high level.