The Azure Bakery series: Azure Active Directory

When you sign up for a Microsoft cloud service, such as Azure, the tenant, an Azure Active Directory instance is created. The Azure Active Directory tenant represents your organization. It’s the first layer of our Azure cake.

Every Azure environment is built on top of an Azure Active Directory (Azure AD) tenant. Azure AD is Microsoft’s cloud-based identity and access management service.

What is needed when engineering and deploying your solution? There’s a lot to it. Today, we’ll look at Azure AD from a fundamental perspective by looking at identity and security basics.

Identity

We need an identity to access and manage your Azure environment; this is essential for authentication and authorization. Authentication verifies who you are, whereas authorization determines what you can and cannot do.

Ensure the identity has the needed permissions for fulfilling only the role it’s supposed to do and not more. This way, the damage is limited if the identity falls into the wrong hands. This approach is called role-based access control (RBAC) and follows the principle of least privilege. There are three identity types:

• User accounts: They enable users and administrators to log in and work with Azure. When authenticating, the user needs to enter a username and password—preferably followed by a second form of authentication called multi-factor authentication.
• Service principals: They allow applications and automation tools to access and work with resources within Azure. Authentication is handled by combining the application identifier and a secret key or certificate.
• Managed identities: They provide an identity for resources. For example, the identities can access other resources, like the secret keys inside an Azure Key Vault. You don’t need to manage credentials; Azure manages these.

There are two managed identity types: system-assigned and user-assigned. A system-assigned managed identity is created as part of a resource, for example, a virtual machine. A user-assigned managed identity is created as a stand-alone resource and is usually associated with multiple resources. For instance, workloads that run on various resources share a single identity.

Hybrid identity

When there are on-premises and cloud identities, it’s recommended to integrate them. The integration enables you to manage user identities from one location, on-premises. And allows the users to use a common identity for accessing on-premises and cloud resources.

Synchronization between the directories is accomplished by using Azure AD Connect. The software is installed on an on-premises server, which connects to Active Directory (on-premises) and synchronizes with Azure Active Directory (cloud).

Security

Azure AD has many different capabilities and offerings to enhance your security posture—machine learning, Conditional Access policies, and self-service, to name a few.

Treat identity as the primary security perimeter by centralizing security controls around the user and service identities.

Multi-factor authentication: This service adds a second form of authentication to the users’ sign-in process. The user is prompted for an additional form of identification, such as approving the sign-in or providing a code, finger, or face scan. Handling these requests is often done through a second device like your phone.

You’ll leave an insecure attack vector when only using a password to authenticate. Is it the user signing in or someone else who obtained the credentials? Adding another factor will increase security because this isn’t as easily obtained or duplicated as a password..

Basic multi-factor authentication (MFA) features are free to Azure AD administrators. If you want to create reports, receive fraud alerts, add IPs to the allowlist, or use a custom greeting and caller ID, you need Azure AD Premium P1 or P2 licenses.

Conditional Access policies: The policies are evaluated when a user wants to access a resource. With Conditional Access, you can bring signals together to make decisions, like blocking or granting access and using if-then-like statements to keep your organization secure and optimize the user experience.

When using Conditional Access policies, you’ll need Azure AD Premium P1 or P2 licenses.

Privileged Identity Management: This service enables you to manage and monitor access to Azure AD and Azure resources. Minimizing the number of users and giving just-in-time access reduces an attacker’s chance of acquiring privileged permissions. Privileged Identity Management (PIM) provides time and approval-based role activation.

For example, when users need privileged permissions, like managing the configuration for security-related services, they can activate the security administrator’s role. Justification must be given during the activation process, and the manager must approve the request. The user is added to the role for a specified time when approved. This way, you’re in control of the privileged permissions in your organization.

You need Azure AD Premium P2 licenses when you want to use PIM.

Emergency access accounts: These are essential because they prevent you from locking yourself out of your Azure tenant, either by accident or failure of a service you depend on for handling the sign-in. You can mitigate this by creating at least two emergency access accounts.

Create the emergency access accounts directly in Azure AD to make them cloud-only. And use the *.onmicrosoft.com domain; this way, the accounts are not synchronized or federated.

The emergency access accounts should not be associated or connected with any individual user, device, phone, or hardware token. Use a smartcard or password for the credentials and keep them secure and known to the individuals who are authorized to use them.

When using passwords, randomly generate a password at least sixteen characters long. And that the password doesn’t expire. Separate the password into two or three parts, write it down on separate pieces of paper, and store them in different secure locations.

The emergency access accounts should have a permanent Global Administrator role assignment for when the PIM service is down or having issues.

The authentication mechanism used for each emergency access account should differ. For example, set up the first emergency access account to use Azure AD MFA and exclude the account from any Conditional Access policies. And the second account is to use Conditional Access with a third-party MFA provider. This way, if one of the services is unavailable, you can still use one of the accounts.

Use Log Analytics to monitor the emergency access accounts’ sign-in and audit log activity. By triggering notifications, you’ll get notified when a sign-in occurs. Monitoring makes sure that the accounts are only used for emergencies or testing.

Up next

Thank you so much for taking the time to read this post. I’d love to hear what you think, and I hope to see you next week when we’re going through the next layer of our cake management groups. Bye for now!