Azure Active Directory
One of the most important pieces of the Azure cloud platform (and most underrated) is the Azure Active Directory (AD) service. Azure AD is a world class authentication and authorization system that underpins the entire Azure, Microsoft 365, and Dynamics 365 ecosystem, even including personal services like outlook.com and XBOX Live. As an identity provider, the primary functions of Azure AD are authentication and authorization. This means Azure AD needs to verify who you are and decide what you have access to.
App Registration/Service Principals
The most familiar form of identity is a user account that represents a person. For example, you might log in to your Outlook web app using your email address and password. That user account belongs to or represents you and the way you prove who you are is by providing a piece of information that only you should know, your password. The system authenticates you (verifies who you are) using the password you provided and then authorizes you to access your mailbox and any other resources you have permissions to access. This may sound simple, but the scale, security, and feature set of Azure AD make it a truly impressive service.
The second type of identity is a device identity. This type of identity represents a physical piece of hardware like a PC, laptop, tablet, or mobile phone. The devices are registered or joined to Azure AD so that Azure AD can identify when a request is coming from that device. A common use for device accounts is Conditional Access Policies. As an example, if a user is trying to access their M365 email from a company owned device that is joined to Azure AD, they might not be prompted for an MFA code whereas if they attempt to access their M365 email from a personal device the system could prompt them for an MFA code that is sent via SMS message or the Authenticator app.
The third type of account gets a little more abstract, a Service Principal. A service principal is also referred to as an app registration and takes the place of a service account from the traditional on-premise Active Directory. This type of identity represents an application that needs to access certain resources. For example, let’s say you have a web application that needs to access some data in SharePoint. You can create an app registration in Azure AD for the application and grant the application permissions to access the SharePoint API to read the data in SharePoint. The application can authenticate using either a secret (similar to a password), or for a more secure method, a security certificate. Possessing the certificate or secret proves that the application is in fact who it claims to be (the app that is registered in Azure AD). Once the application proves who it is, it is then allowed to access the SharePoint data.
Here is where you can configure the locations that a registered app can authenticate from, what secrets and certificates it will use for authentication, and what APIs it has access to.
The final type of identity helps to overcome the complexity associated with app registrations or service principals. This type of identity is called a Managed Identity. The managed identity represents a resource that is running on the Azure platform and allows you to grant permissions to this resource directly while allowing the Azure platform to handle all the authentication. As an example, you can enable a managed identity for a virtual machine running on Azure and then directly grant that virtual machine permissions to read data from an Azure Storage Account. Azure AD recognizes the virtual server because it is already running on the Azure platform and authenticates it. There is no need to manage a secret or certificate. This would function the same way for a web application running on an Azure App Service. Managed Identity makes it simple to click a few buttons to grant applications and infrastructure resources access to other data and services on Azure in a secure manner.
Managed identities are hidden in enterprise applications:
This is where you turn on a managed identity:
Granting Permissions
This photo shows where you would grant permissions for an app service to access a storage account:
The main job of Azure Active Directory is to authenticate who a user or other resource is and then grant that resource access to other data or services. It asks, “who are you?” and “can you prove it?” Then, once the user or service is authenticated, it is allowed to access the resources that the administrator has allowed. While this can come across as a mundane behind the scenes service, it is foundational to the security and functionality of the entire Microsoft ecosystem. The more you understand the different types of identities and how Azure AD authenticates them, the more flexibility you will have in controlling access to your resources.
Final Word
Azure AD is a world-class authentication and authorization that braces the entire Azure, Microsoft, and Dynamics 365 environment. The scalability, security, and feature set of this valuable suite of tools make it a truly impressive service.
Do you want to integrate Microsoft Azure into your organization? Dynamic Consultants Group provides full-service Azure solutions for businesses like yours, helping modernize and re-architect your existing applications for cloud-enabled integration and scalable capabilities. Schedule a call here!
