Microsoft Identity and Access Management Solutions

Identity and access management is a core foundational piece for security and compliance. Everything today starts with identity. Users have identities to access resources such as applications, and they can do that from anywhere on the planet. Applications themselves have identities to define their permission scopes. Computer objects have identities and can be used as a factor to make access decisions. Understanding identity concepts and capabilities is a requirement for properly achieving security and compliance in your organization.

Skills in this chapter:

• Define the basic identity services and identity types of Azure AD

• Describe the authentication capabilities of Azure AD

• Describe access management capabilities of Azure AD

• Describe the identity protection and governance capabilities of Azure AD

Skill 2-1: Define the basic identity services and identity types of Azure AD

This objective deals with the fundamental concepts of Azure Active Directory. In this section, you’ll learn what Azure Active Directory is and its key enterprise features. You’ll also learn about internal and external identities, and you’ll also learn about hybrid identity and the different ways to authenticate to Azure Active Directory. This skill provides the building blocks of Azure Active Directory.

Describe what Azure Active Directory is

Azure Active Directory is Microsoft’s cloud-based Identity-as-a-Service (IDaaS) offering. It is an Identity and Access Management (IAM) product with 200,000 customers (corporations/business entities), 425 million monthly active users, and 30 billion authentications processed each day! Many of the IAM features are covered throughout this chapter, but let’s take a high-level view of some of the key features to help give you an idea of what makes up Azure Active Directory.

Applications

Azure Active Directory is the Identity Provider (IDP) for Microsoft applications such as Office365 and Azure. It also leverages modern protocols such as WS-Federation, SAML, OAuth, and OpenID Connect to integrate with non-Microsoft applications. The Azure AD Application Gallery has thousands of pre-integrated applications to make authentication to these apps easy to set up. Also, the Application Gallery uses the SCIM (System for Cross-domain Identity Management) protocol for provisioning users to and de-provisioning users from these applications. If the application is not in the gallery, you can still integrate it with Azure Active Directory yourself, or you can request that it be added to the gallery.

Application proxy

Application proxy is used to provide remote access to on-premises web applications. This allows any conditional access policies to apply when accessing these on-premises applications without making any changes to the application itself. This is an excellent way to leverage your cloud-based identity security to protect your existing on-premises applications. All connectivity is outbound to Azure AD. These applications will appear to the user as any other application. There is no difference to the user if the application is on-premises or in the cloud. They access it the same way.

Authentication

Skill 2-2 is focused on the authentication aspects of Azure Active Directory, such as password hash sync (PHS), pass-through authentication (PTA), federation, self-service password reset (SSPR), multifactor authentication (MFA), Windows Hello for Business, and Azure AD Password Protection.

Access management

Skill 2-3 is focused on the access management aspects of Azure Active Directory, specifically the conditional access feature. At a high level, you can define which users or groups must meet a specific criterion such as completing MFA or having a specific device or platform type before they can access a resource, such as a specific application or the applications in your tenant. There are also many different Azure Active Directory roles that can be assigned to administrators to follow the principle of least privilege while also granting the necessary access to perform the tasks they need to perform.

Devices

Intune is the primary device management platform for cloud-based devices, but there are device objects in Azure Active Directory that are Azure AD–registered, hybrid Azure AD–joined, or Azure AD–joined. We’ll cover hybrid Azure AD–joined devices in more detail in the next section, but these devices can be used as a control in conditional access that must be met before accessing the resource. Just be aware that devices do exist in Azure AD, but the traditional management you think of with group policy Objects (GPOs) is performed from Intune. However, there is a tight relationship between Azure Active Directory and Intune.

Domain services

Azure Active Directory Domain Services enables you to join your Azure virtual machines to a traditional Active Directory domain. This is completely separate from your on-premises Active Directory domain, but it is populated from your Azure Active Directory tenant. You can think of this more as a resource forest for legacy protocols like NTLM, Kerberos, and LDAP for applications that have been lifted and shifted into Azure.

External identities

Azure Active Directory enables easy collaboration with other companies using Azure AD Business-to-Business (B2B) that are sharing resources like documents or accessing applications. You would use Azure AD Business-to-Consumer (B2C) if you are creating customer-facing apps that are fully featured Customer Identity and Access Management (CIAM) solutions. Azure Active Directory B2C is a totally separate Azure Active directory. Both Azure AD B2B and Azure AD B2C support conditional access.

Governance

Skill 2-4 is focused on the governance aspects of Azure Active Directory. These features include Access Reviews and Entitlement Management. The primary focus of governance is to determine which users should have access to which resources. The governance process also needs to be auditable to verify that it is working.

Reporting

Various log sources are available, including directory changes in audit logs to sign-in logs for both interactive and non-interactive events. Azure AD also includes logs for applications and managed-service identities, which are a specific type of application identity. These can all be accessed in the Azure Active Directory portal or exported to Log Analytics, Azure Sentinel, or any other SIEM.

Licensing

Azure Active Directory has three levels of licensing:

• Azure AD Free Azure AD Free provides user and group management, as well as directory sync. This is included when you sign up for Office 365 or Microsoft 365 resources.

• Azure Active Directory Premium 1 This level is where most of the features discussed in this chapter are included. This includes conditional access, self-service password reset with writeback, dynamic groups, and much more.

• Azure Active Directory Premium 2 This level includes governance capabilities, such as access reviews, entitlement management, and privilege identity management. It also includes identity protection advanced security features.

Describe what hybrid identity is

Very few customers are starting with a completely greenfield environment (a from-scratch and totally new environment) with only Azure Active Directory accounts accessing only cloud resources. Most customers are in a hybrid-identity state with their Azure AD tenant(s) connected to an on-premises AD. This is where user accounts need to exist in both the on-premises Active Directory and in Azure Active Directory. The user might access a local file server and then access their email in Office365. They need to be able to do this with one seamless account. Hybrid identity makes this possible. If you want to leverage your existing Active Directory environment and take advantage of Azure Active Directory, you’ll need to use a hybrid identity.

There are two distinct components to a hybrid identity setup:

• Syncing of the users and their attributes from Active Directory to Azure Active Directory.

• Authenticating to Azure Active Directory using credentials from on-premises Active Directory. This can be accomplished via PHS, PTA, or federation.

Azure Active Directory Connect

Azure Active Directory Connect is the primary tool used to create users, groups, and other objects in Azure Active Directory. The information is sourced from your on-premises Active Directory, which is the usual scenario for most customers who are using a hybrid identity. Changes in your on-premises directory to those objects are automatically synced to Azure Active Directory. The source of authority (SOA) for these objects is the on-premises Active Directory. This means the sync is a one-way sync from Active Directory to Azure Active Directory.

Azure AD Connect has a very robust setup wizard to help you with this process. You use the express setup, which will choose the default options for you, or you can do a custom installation to get extremely granular with your choices. You can select which objects will be synced to Azure Active Directory (and which attributes of those objects, if needed).

Another part of the setup wizard helps you pick which authentication method your users will use to authenticate to Azure Active Directory, as shown in Figure 2.1.

Azure AD Connect is a key piece of hybrid infrastructure and must be protected the same way you would protect a domain controller in Active Directory. If an attacker were to get access to an Azure AD Connect server, this would be the security equivalent of getting access to a domain controller.

Password hash synchronization

The current credentials in on-premises Active Directory are synced to Azure AD through Azure AD Connect. The on-premises password itself is never sent to Azure Active Directory but the password hash. The hashes stored in Azure Active Directory are completely different than the hashes in on-premises Active Directory. Active Directory password hashes are MD4, and Azure Active Directory password hashes are SHA256. The user authenticates to Azure Active Directory by entering the same password they use on-premises. For the detailed cryptographic specifics on how this process works, see the More Info item below.

You can also select password hash sync as an optional feature in Azure AD Connect if you are using PTA or federation as your primary authentication method, as seen in Figure 2.2. This gives you two benefits:

• Azure Active Directory can alert you when the username and password are discovered online. There will be a leaked credential alert for that user.

• If something catastrophic happens to the on-premises Active Directory, an admin can flip the authentication method to password hash sync. This would allow users to still access cloud resources when the full disaster recovery plan is being executed.

Password hash synchronization should be used as the default authentication choice unless there are specific requirements not to do so.

Pass-through authentication

With pass-through authentication, the user’s password is validated against the on-premises Active Directory using PTA agents. When a user goes to authentication to Azure AD, the username and password are encrypted and put into a queue. The on-premises PTA agent reaches outbound to Azure AD, picks up the request, decrypts the username and password, and then validates it against Active Directory. It then returns to Azure AD if the authentication was successful. This allows for on-premises policies such as sign-in-hour restrictions to be evaluated during authentication to cloud services. The password hash doesn’t need to be present in Azure Active Directory in any form for PTA authentication to work. However, PHS can be enabled as an optional feature.

The first PTA agent is usually installed on the Azure AD Connect server. It’s recommended that you have a minimum of three PTA agents for redundancy. You can see the total number of PTA agents installed at the Azure AD Connect page in the Azure AD Portal shown in Figure 2-3.

To see the specific IPs of the PTA agents, click Pass-Through Authentication, as shown in Figure 2-4. The maximum number of PTA agents per tenant is 40. The servers running PTA agents should also be treated and protected the same as you would protect a domain controller.

PTA should be used as an authentication choice if password hash sync cannot be used or if sign-in hour restrictions are required. Also, PTA is useful for a company that is trying to move away from federated authentication but doesn’t want to move to password hash sync yet.

Federation

This allows users to authenticate to Azure AD resources using credentials provided by another identity provider (IDP). In the Azure AD Connect set up, when you choose the Federation With AD FS option, Active Directory Federation Services is installed and configured. Also, a Web Application Proxy (WAP) server is installed to facilitate communication between the on-premises AD FS deployment and the Internet. The WAP should be located in the DMZ. The AD FS server should never be exposed to the Internet directly. Federation is the most complicated identity authentication configuration. There are few reasons why federated authentication to Azure AD would be needed, and doing so should be the last choice when evaluating PHS, PTA, and federation.

At the time of this writing, Smart Card authentication is not supported in Azure AD. If that is a core requirement, then you will need to use federation. If a custom MFA provider is needed that is not available in Azure AD, you will need to use federation for authentication.

Finally, AD FS servers should be protected and treated the same way as domain controllers. If an attacker were able to get access to the AD FS server, they could sign claims impersonating any user in the directory.

Describe Azure AD identities (users, devices, groups, and service principals/applications)

Azure AD identities are made up of four main categories of identities: users, devices, groups, and applications. All of these will be present in your Azure AD tenant.

Users

User identities are typically connected to a person. These are the identities that you traditionally think of when users authenticate to a resource. When someone starts working at a company, they are given a user identity that is used to identify the user across various applications and services, such as O365 or external SaaS applications. User identities can be added to groups or distribution lists, and they can hold administrative roles. Authorization decisions are made against user identities. User identities can be members of your organization or outside of your organization, as will be discussed later in this skill.

As covered in the “Describe what hybrid identity is” section, user identities are most typically synced from on-premises Active Directory via Azure AD Connect. The attributes of the user, such as name, department, and office phone, can all be synced in Azure AD Connect.

User identities can also be created in Azure AD directly. An on-premises Active Directory is not needed. Population of additional user data, such as department, is still needed. This is usually provided by some other system as part of user onboarding. Both user identity types can be seen in Figure 2-5.

When the term identity is used, its most likely referring to a user identity.

Devices

Devices also have an identity in Azure AD. There are three types of device identities in Azure AD, but we’re including an on-premises device identity, so there is a complete picture for all device states that you will encounter.

• Domain–joined computer First, we have a traditional domain-joined computer. This is usually a corporate-owned device that is joined to the on-premises Active Directory. The on-premises Active Directory account is used to sign-in. This is probably the device identity type you are the most familiar with and has been used since Active Directory first arrived in Windows 2000.

• Hybrid Azure AD–joined device Next, there is the hybrid Azure AD–joined device, which is where the device is domain-joined to Active Directory but also has an identity in Azure AD. Typically, this identity is created through the Azure AD Connect sync process when syncing computer accounts to Azure AD. The account that is used to log in to the device is still an on-premises Active Directory account. However, because this device has an identity in Azure AD, this can be used as part of the conditional access controls. It also gives users a better user experience by reducing prompts for Azure AD–backed applications.

• Azure AD–joined Azure AD–joined devices are directly joined to Azure AD. Instead of being domain-joined to on-premises Active Directory, it’s joined directly to Azure AD. Intune is used to apply policy and manage the Azure AD–joined device. With an Azure AD–joined device, the Azure AD account is used to log in. A device cannot be domain joined to both Active Directory and Azure Active Directory at the same time.

• Azure AD–registered Typically, this is a personal device, such as a mobile phone or a personally owned computer. This is mostly used for BYOD scenarios where some corporate resources are needed, but a device is not provided. Intune is used to provide some light management capabilities. A local account, perhaps a Microsoft account, is used to log in, not a corporate Active Directory or Azure Active Directory Account. Azure AD–joined, hybrid Azure AD–joined, and Azure AD–registered can all be seen in the Devices section of the Azure AD portal as shown in Figure 2-6.

Groups

Groups are a collection of users or devices. They are used to specify an action or apply a policy on many of these objects at once instead of doing it individually. For example, if we want to grant everyone in the sales department access to a sales application, we can assign the sales group instead of assigning each member individually. We can also apply licenses to the group, and all members will receive the license assignment. This allows the admin to take actions at a greater scale.

There are several types of groups that you can use in Azure AD:

• You can sync your on-premises groups from Active Directory to use as a security group.

• You can also create an Azure AD security group where the membership is assigned directly to the group.

• The group can also be made to be of a dynamic membership based on attributes on the user or the device.

The different group types and membership types are shown in Figure 2-7.

Using the previous sales team example, a dynamic group could be made where when the department equals Sales, which means they are automatically in the group (see Figure 2-8). These dynamic groups are constantly reevaluating and adding and removing members. The automation that can be built around dynamic groups is tremendous.

Microsoft 365 groups—sometimes referred to as unified groups—is a newer group type and represents the future direction for resource permissions in Microsoft 365, such as Teams, SharePoint, and Exchange Online. One group can be used to ensure consistent access with minor administrative effort across the Microsoft 365 suite of applications.

Applications

Nobody logs into anything for the fun of it. Users log in to do something important to them, such as send an email, check their paystub, or access a line-of-business application. Applications are the day-to-day drivers for users, and there are lots of applications in Azure AD.

As described earlier, Azure AD supports open standards such as SAML, OAuth, and OpenID Connect. Any applications that support these protocols can be integrated into Azure AD. Azure AD also has an Application Gallery where Microsoft has worked with these different application providers to make the setup as easy as possible. The Application Gallery can be seen in Figure 2-9. Azure AD also can work with your on-premises web applications using Azure AD Application Proxy, as described earlier.

Line-of-business applications can also be updated to use Azure AD authentication. Because Azure AD supports open standards, any language that has a library for SAML, OAuth, or OpenID Connect can integrate with Azure Active Directory. Microsoft also has the MSAL library to simplify the authentication process for many common languages, such as .NET, ASP.NET, Node.js, Java, Python, iOS, macOS, Android, and Xamarin.

Application identities can be seen in the Enterprise Apps section of the Azure AD portal, as shown in Figure 2-10. These are called service principals. These define the access policy and permissions for the application insofar as what it can do in the tenant. There is a lot of developer detail beyond the scope of this exam, but here is a real-world example: When applying a conditional access policy, such as requiring users to complete MFA before accessing an application, you apply conditional access policy to a service principal. These are automatically added to the tenant when you integrate an application from the Application Gallery, consent to an application, or add an app proxy application.

A second type of service principal is called a managed identity. This is typically for developers, but it can really be used by anyone managing Azure resources that access Azure Active Directory authentication. The idea is that there no credential management needs to be done for the application. Without managed identities, a developer would need to rotate either a shared secret (a password for an application) or a certificate at regular intervals. These credentials need to be protected as well. With a managed identity, the service handles the storage and rotation.

The final type of application identity is the application object created by application registration. This configures the application to use Azure AD identities for authentication (in your tenant or by other people’s Azure AD tenants if you choose to allow that) and results in an application object being created in Azure AD. Things like the application uniform resource identifier (URI) and permissions of the application are defined in this object. Every application object (created through the Azure portal or by using the Microsoft Graph APIs or the Azure AD PS Module) also creates a corresponding service principal object that inherits certain properties from that application object. This is located in a tenant, but it would not be in your tenant unless it were an application your company was developing (see Figure 2-11).

Putting it all together with a few examples should clarify what administrators see in the portal. Contoso is using Office 365. There will be a service principal for Office 365 Exchange online, Office 365 SharePoint online, and so on in their Enterprise Apps. There will not be an application registration for those applications. The application registration would be in the Microsoft tenant, not in the Contoso tenant. The only thing Contoso would see is the service principal in Enterprise Applications. This applies to any application added from the gallery or that is manually added. Contoso is moving its line-of-business application to leverage Azure AD authentication. In this scenario, there would be an object for this line-of-business application in the Application Registrations section and a service principal object in the Enterprise Applications section.

Describe the different external identity types (guest users)

Most companies’ business models require them to work with external identities. This can be in the shape of business partners, distributors, suppliers, or vendors. Previously in this type of scenario, an external Active Directory forest would be used, and the business partner would be given a separate account in that forest. This presented a couple of challenges. First, because these identities were not the business partners’ main corporate identities, they would frequently forget their passwords, which would increase help desk calls. Second, when this business partner would leave their company, they would still have an account in the external Active Directory forest unless a separate notification process had been set up (which is rare). The business partner would still be able to log in and access resources, even if they shouldn’t be able to. Azure AD business-to-business (B2B) solves both issues.

Azure AD B2B focuses on enabling collaboration between companies. For example, let’s consider an airline that designs and sources parts from many different companies. These business partners frequently need to work on a document or access other resources hosted by the airline. Azure AD B2B facilitates this collaboration and solves the two problems above by inviting their corporate identity into your tenant as a guest user, as shown in Figure 2-12. The only thing needed for this to work is the corporate entity’s email. Access to resources in your tenant would be controlled just like it would for other users, including the ability to apply conditional access policies to these guest accounts. All authentication for the guest user takes place in their home directory. The airline would invite its supplier into their tenant to work on a document. Before the supplier company user could access the document, they would authenticate in their home tenant. If the authentication is successful and passed the Conditional Access requirements, the supplier would have access to whatever was granted to them in the airline company’s tenant, which in this case, is the document.

This solves the first password problem because the supplier is using their current corporate credentials, not an additional account they must remember when they use it. Any password resets would need to take place in their home directory for their main corporate account, just like they would do today if they forgot their password. It also solves the second problem because if the partner left their company, their corporate account would be terminated. They would not be able to successfully authenticate and access any of your organization’s resources.

External identities can also be customers who are purchasing products or services. Traditionally, the customers would need to create an account on the website to complete the order. This can be frustrating for the customer because they now must create an account on each site from which they want to buy goods or services. This is the traditional Customer Identity and Access Management (CIAM) scenario, where Azure AD Business-to-Consumer (B2C) comes into play to help with this problem.

Azure AD B2C focuses on your business customers. In our airline example, this would be the person buying a flight from the airline. This person would use a B2C account to complete their purchase. Azure AD B2C is a separate directory from your corporate Azure AD directory and can scale to millions of users. Azure AD B2C branding is fully customizable per application or organization. Typically, this type of customization and flexibility will require a developer who understands web technologies such as HTML, CSS, and JavaScript.

Another aspect of Azure AD B2C is that it can support other consumer identities, such as a Microsoft Account (MSA), a Google account, or Facebook. This way, when buying a ticket from the airline, the user wouldn’t need to create a new account. Instead, the user could use one of their other accounts to authenticate. It’s really up to the business to decide which accounts they want their customers to use.