Chapter 5. Manage identities

Microsoft has long been a leader in the identity space. This leadership goes back to the introduction of Active Directory (AD) with Windows 2000 before the cloud even existed. Microsoft moved into cloud identity with the introduction of Azure Active Directory (Azure AD), which is now used by over five million companies around the world. The adoption of Office 365 led to this extended use of Azure AD. These two technologies, however, have very different purposes, with AD primarily used on-premises and Azure AD primarily used for the cloud.

Microsoft has poured resources into making AD and Azure AD work together. The concept is to extend the identity that lives on-premises to the cloud by synchronizing the identities. This ability is provided by a technology named Azure AD Connect. Microsoft has also invested in extending those identities to enable scenarios such as single sign-on by using Active Directory Federation Services (ADFS), which is deployed in many large enterprises.

Microsoft has continued pushing forward by developing options for developers to leverage Azure AD for their applications. Microsoft provides the ability for developers to extend a company’s Azure AD to users outside of the organization. The first option is known as Azure AD B2C (Business to Consumer). This allows consumers to sign into applications by using their social media accounts, such as a Facebook ID. A complementary technology, known as Azure AD B2B (Business to Business), extends Azure AD to business partners.

As the cloud becomes more popular and Azure AD adoption continues to pick up, there are some legacy applications that require you to use the traditional AD, even in the cloud. For this, Microsoft has developed a service called Azure AD Domain Services. This allows for traditional Kerberos and LDAP functionality in the cloud without deploying Domain controllers into an Azure virtual network.

This area of the AZ-103 exam is focused on the management of identities by using Azure Active Directory, as well as implementing and managing hybrid identities.

Skills covered in this chapter:

Skill 5.1: Manage Azure Active Directory (AD)

Azure Active Directory (Azure AD) has several features beyond user and group management, such as the ability to add one or more custom domains to an Azure AD tenant. Azure AD also provides, user experience controls such as self-service password reset (SSPR) and the ability to perform ongoing access reviews to ensure compliance with policies through Azure AD access reviews. There are also controls to manage the potential risk associated with user logins through Azure AD Identity Protection, the management of devices with AD Join, and the management of data stored on these devices with Enterprise State Roaming.

Add custom domains

Creating an Azure AD requires an initial domain name in the form of domainname.onmicrosoft.com. This name cannot be changed or deleted, but it is possible to add a registered Internet domain name to your Azure AD. Companies typically have domain names they use to do business and users who sign in by using their AD Domain name. Adding custom domain names to Azure AD allows you to assign user names familiar to users. This means they can log in by using their email address, like [email protected], instead of [email protected].

The process to add a customer domain is simple:

  • Add the custom domain name to your directory.

  • Add a DNS entry for the domain name at the domain name registrar.

  • Verify the custom domain name in Azure AD.

To add a custom domain by using the Azure portal, open the Azure AD that you wish to add a custom domain to. Next, select Custom Domain Names followed by +Add Custom Domain, then enter a domain name, such as contoso.com. Upon completion, you can see a screen resembling the screen shown in Figure 5-1 with instructions on adding a DNS record to your authoritative NS server that Azure will use to verify you are the owner of the domain.

A screen shot of the Azure Portal showing the domain verification screen.

Figure 5-1 Add a custom domain to Azure AD

After the records are added with your registrar, click Verify, and the domain is added to the list of domains that can be used with this Azure AD.

Note Add and Verify your Custom Domain

You should add your custom domain and verify it prior to synchronizing the directory to an on-premises Active Directory. This allows your users to log in to Azure AD by using their on-premises credentials.

Note that you can verify your custom domains with either a TXT or MX record. It is also important to remember that you can take some time for DNS records to propagate after making any updates with your registrar.

After you have verified the domain, you may want to set it as the primary domain. In Azure AD, the onmicrosoft.com domain is the primary default. By setting the primary domain to a custom domain you can ensure new users are created in the desired domain namespace. When you set the primary domain, existing users are not affected, and their user names may still need to be updated.

To set the primary domain, select the custom domain that you want to be the primary followed by the make primary command and confirm your change.

Configure Azure AD Identity Protection, Azure AD Join, and Enterprise State Roaming

Azure AD Identity Protection, Azure AD Join, and Enterprise State Roaming are features of Azure Active Directory that allow you to manage both user and device identity while protected the data that those identities access.

Azure AD Identity Protection

Azure Active Directory Identity Protection is a feature of the Azure AD Premium P2 edition that enables you to:

  • Detect potential vulnerabilities affecting your organization’s identities

  • Configure automated responses to detected suspicious actions that are related to your organization’s identities

  • Investigate suspicious incidents and take appropriate action to resolve them

Enabling Azure AD Identity Protection requires a global administrator to onboard the service. After the service has been on-boarded into an Azure AD tenant, if can be managed by users with the global administrator and security administrator roles in Azure AD. Users with the security reader role will be able to access the service but cannot make configuration changes.

To enable Azure AD Identity Protection, browse to the Azure portal as a global administrator and search for Azure AD Identity Protection in the Azure Marketplace. After selecting the service, you can create it as shown in Figure 5-2.

Enabling Azure AD Identity Protection

Figure 5-2 Enabling Azure AD Identity Protection

The configuration of Azure AD Identity Protection is performed by browsing to the service in the Azure portal. Through the portal you can configure the MFA registration policy, sign-in risk policy, and user risk policy for the Azure AD tenant.

The multi-factor authentication registration policy allows you to apply organization-wide policy to all users or select individuals and groups within your Azure AD tenant. To configure this policy, browse to Azure AD Identity Protection in the Azure portal and select MFA registration to open the Policy Settings blade. From this blade you can select the users that are included and or/excluded from the policy as shown in Figure 5-3.

A screen shot of the Azure Portal showing the MFA registration policy creation experience for selecting included and/or excluded users and groups.

Figure 5-3 Select users and groups for MFA registration policy

After selecting your users and/or groups you can then set the type of access you want to enforce as shown in Figure 5-4.

A screen shot of the Azure Portal showing the MFA registration policy creation experience for selecting the controls to be enforced within the policy.

Figure 5-4 Select controls to be enforced for the MFA registration policy

Finally, you can set the state of your policy to On or Off as shown in Figure 5-5.

A screen shot of the Azure Portal showing the MFA registration policy creation experience for setting the state of the policy to On or Off.

Figure 5-5 Select the state of the MFA registration policy

Configuring the sign-in risk policy is done through the Sign-In Risk policy blade of Azure AD Identity Protection. When configuring the policy, you will first select the users and/or groups the policy applies to.

Next, you will select the sign-in risk level for the policy as shown in Figure 5-6.

A screen shot of the Azure Portal showing the sign-in risk policy creation experience for assigning a risk level to the policy.

Figure 5-6 Select the sign-in risk level for the sign-in risk policy

Select the controls to be enforced and then the enforcement state can be set to On or Off.

Configuring the user risk policy is performed in the User risk policy blade of Azure AD Identity Protection. When configuring the policy, you will first select the users and/or groups the policy applies to.

Next, you will select the user risk level that will be associated with the policy as shown in Figure 5-7.

A screen shot of the Azure Portal showing the user risk policy creation experience for assigning a risk level to the policy.

Figure 5-7 Select the user risk level for the user risk policy

Select the controls to be enforced and then the enforcement state can be set to On or Off.

Azure AD Join

Azure Active Directory includes the ability to manage device identity which enables single sign-on to devices and the applications and services managed through Azure Active Directory that are accessed from that device. Managed devices include both enterprise and bring-your-own-device (BYOD) scenarios. This allows users to work from any device, including personal devices, all while protecting corporate intellectual property with the necessary regulatory and compliance controls.

Azure AD Join allows you to control these devices, the applications installed and access from them, and how those applications interact with your corporate data.

When associating devices with Azure AD, you have two options: registering a device or joining a device. Registration of devices would be appropriate for personal devices while joining devices is useful for corporate-owned devices.

In either case, associating a device with Azure AD allows you to manage a device’s identity. Note that this identity can be managed independently of a user’s identity. This provides a great degree of flexibility as devices can be enabled or disabled without affecting a user account. Azure AD Join is an extension of device registration which changes the local state of the device. When a device is Azure AD Joined, users can sign in to the device using an organizational account instead of a personal account.

Registration of devices in Azure AD can be combined with a mobile device management solution such as Microsoft Intune as well. This allows for additional attributes from the device to be tracked in Azure AD (e.g. device OS version, device state including whether the device is rooted or jailbroken, etc.). Those attributes can then be used to build and enforce conditional access policies which can further secure corporate data.

Device registration is configured in Azure AD under Devices and then Device Settings. From this screen, you can set the configuration for an entire Azure AD tenant as seen in Figure 5-8.

A screen shot of the Device Settings screen in Azure Active Directory.

Figure 5-8 Configure device registration settings

From this screen, you can configure the following settings:

  • Users may join devices to Azure AD This setting allows you to select the users and groups that can join devices to Azure AD. This setting only applies to Azure AD Join on Windows 10 devices. The default value is All and can be changed to Selected or None.

  • Additional local administrators on Azure AD joined devices With Azure AD Premium, you can choose which users are granted local administrator rights to the device. Global Administrators and the device owner are granted local administrator rights by default. The default value is None and can be changed to Selected. If the value is Selected, any users added here are also added to the Device Administrators role in Azure AD.

  • Users may register their devices with Azure AD Allow users to register their devices with Azure AD (Workplace Join). Enrollment with Microsoft Intune or Mobile Device Management for Office 365 requires Device Registration. If you have configured either of these services, ALL will be selected, and the button associated with the setting will be disabled.

  • Require Multi-Factor Auth to join devices Multi-factor authentication is recommended when adding devices to Azure AD. When set to Yes, users that are adding devices from the internet must first use a second method of authentication. Prior to enabling this setting, you must ensure that multi-factor authentication is configured for the users that are able to register devices and that those users have gone through MFA setup. This setting is only applicable to Azure AD Join on Windows 10 and BYO device registration for Windows 10, iOS and Android.

  • Maximum number of devices per user This setting designates the maximum number of devices that an individual user can have in Azure AD. If the quota is reached, the user will not be able to add a device until one of their existing devices is removed. Valid values for this setting are 5, 10, 20, 50, 100, and Unlimited.

  • Users may sync settings and app data across devices With Azure AD Premium you can select a subset of your users through the Selected value and enable the Enterprise State Roaming feature for them the feature can be enabled or for All users or None.

After the directory has been configured, you can begin registering devices. For Azure AD Join, there are several requirements for devices, including Windows versions. The requirements for Windows versions are driven by the type of Azure AD Join – hybrid or non-hybrid. Non-hybrid Azure AD Join is applicable to devices that are not joined to an on-premises Active Directory while hybrid Azure AD Join is applicable to devices that are joined to an on-premises directory. For hybrid Azure AD Join, an IT administration must perform the join to Azure AD.

For non-hybrid Azure AD Join, Windows 10 Professional and Windows 10 Enterprise devices can be joined to a directory. For hybrid Azure AD Join scenarios, you can join current Windows devices such as Windows 10 and Windows Server 2016. There is support for a hybrid join with down-level devices as well including Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

Enterprise State Roaming

Enterprise State Roaming is available for Windows 10 devices and allows users to synchronize user settings and application data through Azure AD. While this feature is like the consumer settings sync that has been in Windows since Windows 8, it does offer several benefits when considering protecting corporate data on client devices, including separation of consumer and corporate data, encryption of roaming data, and better management with the ability to monitor which devices are synchronizing data and turn off synchronization per-device when needed. For a device to use Enterprise State Roaming, the device must be Azure AD Joined. Once joined, both hybrid and non-hybrid joined devices can leverage the feature.

When Enterprise State Roaming is enabled, Azure Rights Management (Azure RMS) is used to encrypt the data before it leaves the device and all data is encrypted in transit and at rest. This differs once again from consumer sync in that a data is encrypted where in consumer sync only sensitive information such as credentials is encrypted. The license used for Azure RMS is a limited use license which is used just for encryption and decryption of data. Microsoft customers can purchase a full Azure RMS license to gain access to additional functionality such as document protection and bring-your-own-key (BYOK) support

Enterprise State Roaming data is stored in an Azure region that most closely aligns with the country or region value set in Azure Active Directory. This value is set at the time the directory is created and cannot be changed later. There are three geographies that are used to partition roaming data – North America, Europe, the Middle East and Africa (EMEA), and Asia-Pacific (APAC). Microsoft may store the roaming data in one or more Azure regions within a geography.

Roaming data includes Windows settings and application data. Windows settings such as the theme, browser settings for both Internet Explorer and Microsoft Edge, passwords, language settings and other common Windows settings are synchronized while application data includes data from Universal Windows apps which write their data to a roaming folder in the user profile. The synchronization of application data is dependent on the application developer to leverage the roaming feature of Windows 10.

Enterprise State Roaming is enabled through the Azure AD admin center and the Azure Portal. To enable Enterprise State Roaming, select Azure Active Directory, then Devices, and Enterprise State Roaming (see Figure 5-9). The user enabling the service can select which users can sync settings and data, with the ability to select all users or a subset of users in the directory.

A screen shot of the Enterprise State Roaming configuration screen in Azure AD.

Figure 5-9 Configure Enterprise State Roaming

Configure self-service password reset

Self-service password reset (SSPR) allows users to reset their password in Azure AD, including the ability to optionally write the password back to an on-premises environment when properly licensed and configured by using password writeback and Azure AD Connect. SSPR allows users to change their password, reset their password when they cannot sign in, and unlock their account all without the intervention of an IT administrator.

Each scenario above address either cloud-only or hybrid users; licensing varies as well. Table 5-1 details each scenario, the type of user it applies to, and any required licenses.

Table 5-1 Self-service password reset license requirements

Scenario User Type License Requirements
Password Change Cloud-only user. Included in all editions of Azure AD
Password Reset Cloud-only user Azure AD Basic, Azure AD Premium P1, Azure AD Premium P2
Password Change/Unlock/Reset Hybrid user Azure AD Premium P1, Azure AD Premium P2

SSPR can be enabled through the Azure Portal by browsing to your Azure AD tenant and then selecting Password reset. When enabling SSPR (see Figure 5-10), you can scope the functionality to a group, so you can roll out the feature in waves as users are onboarded into the service. As a part of configuration, you will also select the authentication methods for SSPR: email, mobile phone, office phone, and/or security questions. Finally, you will configure registration options, whether registration is required to use SSPR and the number of days for reconfirmation.

A screen shot of Password Reset, Authentication methods screen in the Azure portal.

Figure 5-10 Configure SSPR Authentication methods

Implement conditional access policies

Security is a concern for every organization using the cloud. As service providers take on more responsibilities for physical network security controls, organizations using Azure AD still maintain full control over their users and how those users interact with the services that use Azure AD for authentication and authorization. Focusing on who can access your organization’s resources, along with how the resources are accessed, allows you to maintain a cloud-first, mobile-first security posture.

With Azure AD conditional access policies, you can implement automated access control decisions for allowing access to your cloud applications after a user has authenticated that are based on conditions. Conditions are evaluated in real-time, based on signals from the users’ login included device, location, and the application they are accessing. This information is evaluated against Microsoft’s data set of global logins to Azure AD and your organizational policies. Optionally, session risk can also be evaluated, and effective security controls applied to the authentication attempt. This can include MFA challenges, of even denying access based on the input signals and conditions. Only after passing through the rules associated with conditional access can a user access their application. Cloud applications, such as Office 365, and even on-premises applications can be protected by Azure AD conditional access.

A conditional access policy is a definition of an access scenario using the pattern: when this happens, then do this. When this happens is the entry point, or trigger, for a conditional access policy. This is where the conditions that will be evaluated are defined. Then do this refers to the response of a policy. This is where the access controls of the policy are applied to the request. Conditional access does not grant authorization to a cloud application or override user rights within an application once they have accessed it. That still occurs through user assignments to an application registration in Azure AD. Conditional access allows you to define the conditions under which that access should be granted.

To create a conditional access policy, at a minimum you need to configure the assignments for users/groups and cloud apps (when this happens). You must also supply at least one access control (then do this). The assignment conditions for users/groups and cloud apps are mandatory. If needed, you can define additional conditions beyond the mandatory set such as associating a sign-in risk, mandating a device platform, or defining the locations associated with a policy.

When creating conditional access polices, you will also have access to both include and exclude rules. There are policies that will lock you out of your Azure AD tenant if not properly configured. You should carefully evaluate policies that affect complete sets such as all users, all groups, or all cloud apps and apply exclusions accordingly. It is a best practice to test policies with non-production or test users first to evaluate their impact before assigning them to your standard users.

Using conditional access requires an Azure AD Premium P1 or P2 (or equivalent EM + S) license.

When you create a new policy, there are no users, groups, apps, or access controls selected. A policy must include these items before it can be finalized. As stated, these are mandatory items. If no users or groups are assigned to a policy, the policy will never be triggered and if you do not select any access controls there is nothing for the policy to do.

Conditional access policies are managed through the Azure portal. They items can be found by browsing to your Azure AD tenant and selecting Conditional access policies. From here, you can create and manage existing policies. An example of the +New Policy Blade is shown in Figure 5-11 with users and groups, cloud apps, and access controls highlighted.

A screen shot of the New conditional access policy blade with Assignments and Access controls called out in a red box.

Figure 5-11 Configure conditional access policy

When selecting cloud apps, you can apply the policy to all cloud apps in the Azure AD tenant or only selected apps (see Figure 5-12). You cannot select an app that is not registered in the directory.

A screen shot of the New conditional access policy blade with the Cloud apps configuration open to select Cloud apps.

Figure 5-12 Configure conditional access policy Cloud apps

Available conditions include:

  • Sign-in risk The likelihood that the sign-in is coming from someone other than the user. The risk level can be high, medium or low. This feature requires an Azure AD Premium 2 license.

  • Device platforms The platform the user is signing in from. Available platforms include Android, iOS, Windows Phone, Windows, and macOS.

  • Locations The location (determined using IP address range) the user is signing in from.

  • Client apps (preview) The software the user is using to access the cloud app. Valid selections include Browser and Mobile apps and desktop clients.

  • Device state (preview) Whether the device the user is signing in from is Hybrid Azure AD Joined or marked as compliant. Compliant devices are devices that are Intune compliant and will be excluded from the evaluation of the policy.

When configuring access controls, you can block access or grant access with additional requirements such as requiring multi-factor authentication or requiring an approved client application from Microsoft.

Approved client apps can be used to control access from Android and iOS devices when using the device platform condition. The setting applies to the following apps:

  • Microsoft Azure Information Protection

  • Microsoft Edge

  • Microsoft Excel

  • Microsoft Flow

  • Microsoft Intune Managed Browser

  • Microsoft Invoicing

  • Microsoft Kaizala

  • Microsoft Launcher

  • Microsoft OneDrive

  • Microsoft OneNote

  • Microsoft Outlook

  • Microsoft Planner

  • Microsoft PowerApps

  • Microsoft Power BI

  • Microsoft PowerPoint

  • Microsoft SharePoint

  • Microsoft Skype for Business

  • Microsoft StaffHub

  • Microsoft Stream

  • Microsoft Teams

  • Microsoft To-Do

  • Microsoft Visio

  • Microsoft Word

  • Microsoft Yammer

Policies can be enabled and disabled as needed and Microsoft also supplies a What if tool which can be used to evaluate which policies will apply to one or more users or groups under certain conditions. The What if tool (see Figure 5-13) can only evaluate enabled conditions against enabled policies.

A screen shot of the What if tool for conditional access in the Azure portal.

Figure 5-13 Conditional access What if tool

Manage multiple directories

Each Azure AD tenant (or directory) is managed as an independent resource. There is no parent-child relation between directories, although users from one directory can be invited to another directory through Azure AD B2B features.

As each tenant is an independent resource, directories can be created and deleted as needed. This also means that each directory can have independent administers and role assignments. Deleting an existing directory can affect resources outside of the directory. For example, when deleting a directory where external users are present, those users will no longer be able to access any applications or resources that have been shared with them as you will need to remove both the users and the association to the underlying resources (for example, a resource group in Azure).

Finally, each directory can be synchronized independently as well. This means if you have two domains on-premises that need to be synchronized to two different Azure AD tenants, you have the flexibility you need when implementing hybrid identity in Azure AD.

Managing directories may include deleting directories or even an entire Azure AD tenant. When deleting a tenant, global administrator rights are required. When a directory is deleted, all the resources or objects within that directory are deleted as well.

There are several prerequisites that must be satisfied prior to directory deletion, specifically:

  • There can be no existing users or groups except for the single global admin.

  • There can be no enterprise application registrations in the directory.

  • There are no MFA providers linked to the directory.

  • There are no subscriptions for Azure, Office 365, or other Microsoft SaaS services associated with the directory.

Perform an access review

Azure AD access reviews allow organizations to better manage privileged role assignments, group memberships for Azure AD security and Office 365 groups, and access to cloud apps registered in Azure AD.

Access reviews can be used to recertify access for not just your employees, but also external users who have been invited into an Azure AD tenant. When combined with Azure AD Privileged Identity Management, role assignments for administrative users who are assigned Azure AD roles or Azure subscription roles can also be recertified.

Azure AD access reviews require an Azure AD Premium P2 or EM + S E5 license. Access reviews can be created by browsing to the Azure portal and accessing the Access reviews service. You must onboard to the service before performing any configuration through the Onboard blade and clicking Onboard Now (see Figure 5-14 for a screen shot).

A screen shot of the Azure Portal showing the Onboard blade for the Access reviews service.

Figure 5-14 Onboard to Azure AD Access Reviews

From the Access reviews blade you can proceed to select or create a program and create controls.

To create a program, you will need to supply a name and a description. Programs allow you to group controls and the access reviews (see Figure 5-15) associated with a control together. This allows to you scope reviews to initiatives within your organization and offers easier reporting based on program. You can create new programs as needed, however a program cannot be deleted if it has any controls associated with it.

To create a control, you will need to supply:

  • Review name

  • Optional description

  • Start date

  • Frequency: One time, Weekly, Monthly, Quarterly, or Annually

  • Duration

  • End: Never, End by, or Occurrences. When selecting Occurrences, you will enter the number of occurrences for the review.

  • Users that the access review applies to

  • Program the control applies to

  • Reviews that will perform the reviews.

A screen shot of the Azure Portal showing a portion of the screen to create a new access review.

Figure 5-15 Creating an access review

When creating a review and selecting the users to review, you will also select a scope for the review. Valid scopes include Guest users only and Everyone. You will also define the type of users to review, either users assigned to an application or members of a group.

There are advanced controls available within an access review which allow the creator to configure whether or not the results of the review should be applied automatically, what should happen if a reviewer does not respond, and whether or not a justification is required when an approver allows continued to access to a group or application.

A screen shot of the Azure Portal showing a portion of the screen to create a new access review where Upon completion and Advanced settings are defined.

Figure 5-16 Creating an access review Upon completion and Advanced settings

After a review has been created, reviewers will action the review through the Azure portal or through the Access panel. Reviews for Azure AD roles and Azure resource roles are performed in the Azure portal, as these reviews are created through Privileged Identity Management (PIM), whereas all other reviews occur in the Access panel.

To see the pending access reviews, click the Review Access link in the email or Sign in on the Azure AD access panel as shown in Figure 5-17.

A screen shot of an email in Outlook Online sent to a reviewer to perform an access review.

Figure 5-17 Example Access review email

From there, you can perform the review for yourself (or for others) depending on the control configuration of the access review. Within an individual access review, you will see names of the users who the review is applicable to. It is possible to see only your name in the list of users if the review applies to your own access. For each user in the list, you will approve or deny the access of the user. You may be asked to supply additional data based on how the review was configured. For instance, the review may require that a reason is supplied for approval.

When a user’s access is removed as a part of a review, their access isn’t removed immediately. It can be removed automatically when the review is completed or when an admin stops the views. This means that approvers can return to an in-progress review and update their response if needed.

Skill 5.2: Manage Azure AD Objects

In an Azure AD tenant there are users, groups, and devices that are controlled through the features of Azure AD discussed in this chapter. In this section we will focus on managing users and groups throughout their lifecycle, how to manage device settings, and how to perform bulk updates to users using automation tooling such as PowerShell.

Create users and groups

Recall that there are two types of users in Azure AD – cloud-only users and users synchronized from an on-premises directory. How you create a user varies based on where that user is sourced from with cloud-only users created and managed exclusively in Azure AD while synchronized identities are created and managed in the source system. For example, to update an attribute for a user created in an on-premises Active Directory and synchronized to Azure AD, that attribute must be updated on-premises first and then synchronized to Azure AD through Azure AD Connect. In the case of cloud-only users, attributes can be updated directly in Azure AD.

You can create cloud-only users through the Azure Portal, Azure PowerShell, and the Azure CLI. You can also interact with users through the Graph API as well if you are developing solutions that interact with Azure AD. When creating new users, you must have Global administrator or user administrator rights within the directory.

To create cloud-only users from the Azure Portal, browse to your Azure AD tenant as a user with rights to create users and select the Users blade followed by +New User. An example of this blade is shown in Figure 5-18. Note that you can also add guest users to your directory through the Azure portal as well.

A screen shot of the Azure portal showing the New User Creation blade. The current selected sub-blade is the Profile blade, showing the First Name, Last Name, Job Title, and Department Fields.

Figure 5-18 New user blade in the Azure portal

Creating cloud-only groups is a similar experience and can be performed from the Azure Portal, Azure PowerShell, the Azure CLI, and the Graph API. To create a group in Azure portal, browse to your Azure AD tenant and select the Groups blade followed by +New Group. An example of the New Group blade is shown in Figure 5-19.

A screen shot of the Azure portal showing the New Group Creation blade. On this screen, Group Type, Group Name, Group Description, and Membership Type can be defined.

Figure 5-19 New Group blade in the Azure portal

When creating a new group, there are several factors that dictate the type of group that is created and how that group behaves in Azure AD and associated workloads such as Office 365.

You will first select the type of group you are creating. This is a required field. There are currently two values you can select from: Security and Office 365. A Security group is used to manage members’ access to shared resources such as resources in Azure and items in Office 365. An Office 365 group if a part of the wider Office 365 service where membership to Office 365 resources such as a shared Outlook inbox and a SharePoint site are managed. Note that even if you are creating groups in an Azure AD tenant that is not associated with an Office 365 subscription you will still see the option to create an Office 365 group.

The group name is also a required field. While group description is not required, it is recommended that you always include a description to make it easier to find and identify the purpose of a group later.

Membership type allows you to select from one of three values:

  • Assigned This value allows you to select one or more users and add them to the group. Adding and removing users is performed manually.

  • Dynamic user This value allows you to use dynamic group rules to automatically add and remove members.

  • Dynamic device This value allows you use dynamic group rules to automatically add and remove devices.

For both dynamic user and dynamic device-based groups, the rules associated with the group are evaluated on an ongoing basis. If a user or device has an attribute that matches the rule, that user or device is added to the group. If an attribute changes and the user or device no longer matches the criteria for group membership, the entity will be removed. Membership processing is not immediate. If an error occurs while processing a membership rule, an error is surfaced on the group page in the Azure portal. You can always view the current processing status from the group page.

It is important to note that you can create a dynamic group for users or devices, but not both at the same time. You also cannot use user attributes in device-based rule. It is possible to change the membership type of a group after it has been created, which provides an opportunity to transition from a static (or assigned) membership model to a dynamic membership model or vice-versa.

When creating dynamic groups, rules can be edited in the simple rule format, where you will build the query and conditions through select lists or they can be built in the advanced editor where you can build complex rules with conditional logic. In the example shown in Figure 5-20, a dynamic user group is being created which will automatically update its membership based on the department attribute and its value in Azure AD.

A screen shot of the Azure portal showing the creation of dynamic membership rules for a dynamic user security group.

Figure 5-20 Dynamic membership rules

Dynamic groups require an Azure AD Premium P1 (or equivalent EM + S) license.

Manage user and group properties

As users and groups are used, they may need updates to their attributes (or properties). This may be simple updates such as changing a users’ Job title or adding and removing members from an existing group.

Cloud-only users and groups can be updated using the same management tools that are available for creation: Azure Portal, Azure PowerShell, Azure CLI, and the Graph API. Figure 5-21 shows an example of the user update screens from the Azure portal that can be accessed by browsing to your Azure AD tenant, selecting Users, then a User, and clicking Edit.

A screen shot of the Azure portal showing the Edit user blade. This screen shows the various attributes that can be updated for a cloud-only user.

Figure 5-21 Edit User blade in the Azure portal

Groups can be managed through the Azure Portal by browsing to your Azure AD tenant, selecting Groups, a group, and then Properties, Members, or Owners, depending on the type of update you want to make. When editing a group, you will not be able to change the group type (change a Security group to an Office 365 group) but you will be able to update the Group Name, Group Description, and in some cases the Membership Type as shown in Figure 5-22.

A screen shot of the Azure portal showing the Edit Group Properties blade where the Group Name, Group Description, and Membership Type can be updated.

Figure 5-22 Edit group properties blade in the Azure portal

Manage device settings

Registered and joined devices in Azure AD can be managed in two areas in the Azure Portal. The first is by browsing to your Azure AD tenant in the Azure portal and selecting Devices followed by All Devices. The second is through the Devices blade for an individual user. With either option you will be able to search for devices using the device name as a filter, view a detailed overview of any registered and joined devices, and perform common device management tasks.

To enable and disable devices you must be a global administrator. Disabling a device prevents a device from accessing Azure AD resources. Note that this does not prevent the user from accessing resources in general, only from accessing resources from that disabled device. Figure 5-23 shows the disable menu.

A screen shot of the Azure portal showing the Disable device menu highlighted. This menu can be accessed from the All devices blade from Devices in Azure AD.

Figure 5-23 Disable device menu from the All Devices blade in the Azure portal

Deleting devices is similar to enabling or disable a device. Again, the user performing the update must be a global administrator. Deleting a device prevents a device from accessing your Azure AD resources and removes all details that are attached to the device ( BitLocker keys for Windows devices). Deleting a device represents a non-recoverable activity and is not recommended unless it is required.

Perform bulk user updates

The Azure portal can be helpful for one-time operations but is not suited for making programmatic updates to users in bulk. Tools like PowerShell can be quicker at making bulk updates and are better suited for the task. Example tasks include creating and updating users and groups in batches, bulk updates to user properties, and bulk removes.

When approaching user updates with PowerShell, you need to be mindful of the module you use and the versions of those modules. There are multiple modules available that can be used to update users, including the Azure Active Directory v1 (or MSOL cmdlets) and the Azure Active Directory v2 (or AzureAD cmdlets). The Azure Active Directory v2 cmdlets are also referred to as the Azure Active Directory PowerShell Module Version for Graph.

These cmdlets can be used for Azure AD administrative tasks such as user management, domain management, and for configuring single sign-on. To begin using the module, you will first need to install the module from the PowerShell Gallery (or PSGallery) using the Install-Module command.

The AzureAD module is available through the PowerShell Gallery.

# Install the module
Install-Module AzureAD

After the module has been installed, you can import the module to a PowerShell session using Import-Module.

# Import the module
Import-Module AzureAD

Using a user with rights to manage users you can use the Connect-AzureAD cmdlet to establish a connection with your Azure AD tenant.

# Store a credential (username/password)
$AzureAdCred = Get-Credential

# Connect to public cloud
Connect-AzureAD -Credential $AzureAdCred

The following PowerShell script demonstrates how users could be created in bulk by using a CSV file.

# Simple CVS
# DisplayName,UPN,MailNickname,GivenName,Surname,UsageLocation,Password

$users = Import-CSV .users.csv
foreach ($user in $users) {
   # Define password profile
   $PasswordProfile = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
   $PasswordProfile.Password = $user.Password
   
   # Create new user
   New-AzureADUser `
     -DisplayName $user.DisplayName `
     -GivenName $user.GivenName `
     -SurName $user.Surname `
     -UserPrincipalName $user.UPN `
     -MailNickname $user.MailNickname `
     -UsageLocation $user.UsageLocation `
     -PasswordProfile $PasswordProfile `
     -AccountEnabled $true
}

In this next example, you will see how to create Security groups in bulk using a CSV too.

# Simple CVS
# DisplayName,Description

$groups = Import-CSV .groups.csv
foreach ($group in $groups) {
   New-AzureADGroup `
     -Description $group.Description `
     -DisplayName $group.DisplayName `
     -MailNickName $group.MailNickName
     -MailEnabled $false `
     -SecurityEnabled $true
}

Skill 5.3: Implement and manage hybrid identities

Integrating an on-premises AD with Azure AD is the lifeblood for hybrid cloud deployments. This section focuses on how to accomplish this by using Azure AD Connect and then leveraging that setup to provide more complex scenarios, such as password synchronization and writeback.

Install and configure Azure AD Connect

Azure AD Connect, or AAD Connect is Microsoft’s tool for integrating on-premises directories with Azure AD and is the cornerstone of hybrid identity in the Microsoft cloud. Being able to use your on-premises identities with Azure AD means you have a common identity for access all your resources, regardless of whether they are in the cloud or on-premises. AAD Connect is the current iteration of Microsoft’s identity synchronization tooling for Azure AD and the replace for DirSync and AAD Sync.

Preparing for Directory Synchronization

Prior to installing AAD Connect, there are several prerequisites across Active Directory and Azure AD that you must be aware of in addition to the requirements of the AAD Connect software itself.

Within Azure AD, you will want to ensure that the user name suffix for your on-premises users has been added and verified as a custom domain in Azure AD. For example, if your user’s logon to their devices with a user name ending in @contoso.com, you will want to have contoso.com added as a custom domain in Azure AD. This allows your users to synchronize from on-premises and keep the same user name. If you do not verify the domain prior to synchronization, users will be created in Azure AD in the onmicrosoft.com namespace. Next, you will need to verify the number of objects that you intend to synchronize to Azure AD. When you verify your first domain, the object limit will be increased from 50k to 300k objects. If you need more than 500k objects you will need a license beyond the free tier of Azure AD.

After you have added a custom domain and verified you are within the synchronization limits for your Azure AD tenant, it is recommended that you fix any potential errors in your on-premises directory with IdFix. IdFix is a Microsoft provided tool which will identify errors in your onpremises directory and help you fix them. IdFix detects a number of errors and in some cases can automatically fix them as well. Common errors include the detection of illegal characters such as a leading and trailing spaces in mail addresses and illegal characters in user principal names.

It also detects duplicate entries, formatting errors, length errors, and null value errors. Note that these attributes may work in your on-premises directory today, but should be fixed before you perform any synchronization activities as they will not be compatible with Azure AD.

IdFix can be used to perform the updates for any errors it finds, however you may wish to perform those updates in another manner (e.g. through a custom PowerShell script) where you can exercise more control. You can run IdFix as many times as needed as you assess your environment and its readiness for synchronization to Azure AD.

For your on-premises directory itself, you must be at both a forest functional level and AD schema version of Windows Server 2003 or later. This requirement only applies to the schema version, and not your domain controllers themselves which can run any version of Windows Server. There are some optional features of Azure AD such as password write which require Windows Server 2008 R2 or later for your domain controllers.

Finally, there are the requirements for AAD Connect itself. AAD Connect must be installed on Windows Server Standard or higher and requires a server with a GUI, which means it is not supported for installation on Windows Server Core. AAD Connect can be installed on a domain controller, however this is not required nor is it recommended. AAD Connect must be installed on a domain member.

Inbound projections, or identities, from your on-premises directory are stored in a Microsoft SQL Server database. A default installation of AAD Connect using the Express settings will install SQL Server 2012 Express LocalDB which has a 10GB size limit and will limit the number of objects that you can manage (approximately 100k objects). There are also potentially availability and recovery concerns in larger environments when using SQL Express. It is possible to use a separate SQL Server instance (shared or dedicated) for your identity database and storage. When using an external SQL Server, SQL Server 2008 or later is required. While the SQL Server can be shared with other workloads, it is only supported to have a SQL instance associated with one synchronization engine at a time. This means you cannot use the same SQL instance for hosting databases for both AAD Connect and FIM/MIM.

To install AAD Connect, you will also need access to several accounts. A local administrator account is required to install AAD Connect along with the credentials for a Global administrator in the Azure AD tenant which you will be establishing a synchronization relationship with. When AAD Connect is installed with defaults, a Connector Account is also created in the onpremises directory which is used to read and write information to and from Active Directory. To create this account as a part of AAD Connect installation, the credentials for an Enterprise Administrator are required. Optionally, the Connector Account can be pre-created by an administrator prior to the installation of AAD Connect which would negate the need for Enterprise Administrator credentials during installation.

You should also be aware of DNS resolution requirements. AAD Connect requires both intranet and internet DNS resolution and must be able to resolve both your on-premises Active Directory and the public Azure AD endpoints.

Note Azure AD Connect Prerequisites

The full and current list of prerequisites for Azure AD Connect can be found at:
https://docs.microsoft.com/azure/active-directory/hybrid/how-to-connect-install-prerequisites.

Installing AAD Connect

The AAD Connect installer is linked through the Azure Active Directory service in the Azure Portal and can be downloaded directly from the Microsoft Download Center at https://go.microsoft.com/fwlink/?LinkId=615771. The download (see Figure 5-24) is a single MSI. To install AAD Connect, download the installer to the target server and run the executable.

A screen shot of the Azure portal showing link to download Azure AD Connect from the Azure Active Directory service.

Figure 5-24 Download Azure AD Connect link in the Azure portal

There are two phases to the installation of AAD Connect: the installation of the agents and the associated tooling such as PowerShell on older versions of Windows Server and the required versions of the .NET Framework which is then followed by the configuration of synchronization between your on-premises domain and Azure AD (see Figure 5-25).

A screen shot of Microsoft Azure AD Connect installer executing on a server.

Figure 5-25 Microsoft Azure AD Connect Setup

To begin the installation, execute the installer on the target server. Recall that you will need the credentials for a Global administrator in your target Azure AD and optionally the credentials for an Enterprise Administrator account if you have not already created the Connector Account.

After agreeing to the terms and conditions, you will select a custom or express installation. Selecting Use Express Settings will configure synchronization for all identities in the local formation, configure password hash synchronization (see Figure 5-26), enable auto-upgrade of AAD Connect, and initiate synchronization as soon as the installer completes. Choosing a custom installation offers the opportunity to specific a custom installation location, use an existing SQL instance, specific existing service accounts, and specify custom sync groups.

A screen shot of Microsoft Azure AD Connect installer showing the screen to select custom or express settings.

Figure 5-26 Microsoft Azure AD Connect Setup Express Settings

With the installation of required components complete, you will proceed to the second phase of the installation–the configuration of synchronization.

You will first select how users will sign-in to Azure AD (see Figure 5-27). Valid options are:

  • Password Hash Synchronization This option allows users to sign in to Azure AD using the same user name and password that they use on-premises. This is also known as a simple or same sign-on model.

  • Pass-Through Authentication This option enables Azure AD to authenticate users using your on-premises identity infrastructure.

  • Federation With AD FS This option allows users to sign-in with AD FS as a federated identity provider. With this option, after users in federated domains have been resolved through home realm discovery in Azure AD they will be redirected to the target identity provider.

  • Federation with PingFederate This option allows users to sign-in with PingFederate. With this option, after users in federated domains have been resolved through home realm discovery in Azure AD they will be redirected to the target identity provider.

  • Do Not Configure This option allows you to perform federated authentication with a federated identity provider which is not AD FS or PingFederate but is in the Azure AD Identity Provider Compatibility Docs located at https://www.microsoft.com/download/details.aspx?id=56843.

You can optionally enable single sign-on for domain-joined desktops without the use of AD FS (see Figure 5-27).

A screen shot of Microsoft Azure AD Connect configuration wizard showing the User sign-in settings.

Figure 5-27 Microsoft Azure AD Connect Configuration User sign-in

Next, you will enter the credentials for a Global administrator in your target Azure AD (see Figure 5-28). This is required to enable synchronization and establish the relationship between your on-premises directory and Azure AD. You will not be able to proceed beyond this screen without the required credentials.

A screen shot of Microsoft Azure AD Connect configuration wizard showing the Connect to Azure AD settings.

Figure 5-28 Microsoft Azure AD Connect Configuration Connect to Azure AD

You can now connect to your local Active Directory forest(s) and select one or more domains for synchronization (see Figure 5-29). This is the phase of the configuration where the Connector Account is created or where you will select an existing Active Directory account. When creating a new account, the credentials for an Enterprise Administrator are required.

A screen shot of Microsoft Azure AD Connect configuration wizard showing the configuration of the AD forest account.

Figure 5-29 Microsoft Azure AD Connect Configuration AD forest account

The after adding your domain(s), the configuration wizard (see Figure 5-30) will enumerate the verified domains in your target Azure AD tenant and allow you to select the attribute that you will use from your on-premises directory to project to Azure AD as the user principal name (or sign-in name). By default, this will be a straight translation from your on-premises userPrincipalName to userPrincipalName. In cases where your on-premises userPrincipalName is not internet routable or does not match the verified domain suffix in Azure AD, you are afforded the opportunity to select the appropriate attribute.

A screen shot of Microsoft Azure AD Connect configuration wizard showing the configuration of the Azure AD sign-in configuration.

Figure 5-30 Microsoft Azure AD Connect Configuration Azure AD sign-in configuration

For each directory that you added previously in the wizard, you will have the opportunity select which domains and OUs you will synchronize. This is an opportunity to prune the number of objects that will synchronize to Azure AD. If you have objects which do not need to be projected to Azure AD, do not synchronize them. For example, service accounts that are dedicated to on-premises workloads may not need to exist in the cloud. Figure 5-31 shows an example configuration where only a single OU will be synchronized to Azure AD.

A screen shot of Microsoft Azure AD Connect configuration wizard showing the configuration Domain and OU filtering.

Figure 5-31 Microsoft Azure AD Connect Configuration Domain and OU filtering

To match users on-premises to their cloud identity, AAD Connect needs to know how to uniquely identify users in your directories on-premises (see Figure 5-32). If you have multiple forests or domains and users are represented more than once, this is where you will inform AAD Connect how to identify the source identity. You will also select how users should be matched in Azure AD through a source anchor. You can select any attribute in your on-premises directory as the anchor attribute but note that the configuration cannot be altered after it is set.

A screen shot of Microsoft Azure AD Connect configuration wizard showing configuration of user attribute matching.

Figure 5-32 Microsoft Azure AD Connect Configuration Uniquely identifying your users

You will next configure any optional filters for users and devices (see Figure 5-33). This allows you to synchronize a subset of users which may be appropriate for a pilot deployment or if you have objects you want to synchronize that are spread across multiple OUs and mixed with objects you do not want to synchronize.

A screen shot of Microsoft Azure AD Connect configuration wizard showing configuration of user and device filtering.

Figure 5-33 Microsoft Azure AD Connect Configuration Filter users and devices

Finally, you will have the opportunity to configuration any optional features (see Figure 5-34). For example, if you are going to configure SSPR with password writeback, this is where the feature would be enabled in Azure AD Connect. This screen will not have some options enabled if they are not available in your environment. For example, you will not be able to synchronize Exchange attributes if you do not have Exchange deployed and your on-premises schema extended.

A screen shot of Microsoft Azure AD Connect configuration wizard showing configuration of optional features.

Figure 5-34 Microsoft Azure AD Connect Configuration Optional features

With the configuration complete, you can now commit it and finalize the configuration of AAD Connect. You can choose to start the synchronization immediately or optionally configure the AAD Connect tooling to run in staging mode (see Figure 5-35).

: A screen shot of Microsoft Azure AD Connect configuration wizard showing the Ready to configure screen.

Figure 5-35 Microsoft Azure AD Connect Configuration Ready to configure

If this is your first AAD Connect installation, do not select Enable Staging Mode. Staging mode is used for high availability with AAD Connect or to test new configuration changes without impacting your existing synchronization jobs. When AAD Connect is running in staging mode, no outbound projections are made from AAD Connect to Azure AD or your on-premises directory (in the case of writeback) but all inbound rules and projections do run.

Selecting Install will enable synchronization for your Azure AD tenant and configure the management agents in AAD Connect. The Azure AD Connect Health agent for sync will also be installed at this time. After the installation is complete and a full synchronization has run, the users and groups from the on-premises AD appear in the Azure AD portal sourced from Windows Server AD.

A screen shot of Azure Active Directory users in the Azure Portal showing synchronized users.

Figure 5-36 Azure Active Directory synchronized users

Configure federation and single sign-on

Azure AD Connect can help you implement multiple forms of authentication for an Azure AD tenant, including federated single-sign on as well as single-sign on when using Password synchronization or Pass-through authentication.

Azure AD Connect single sign-on

Prior to configuring a domain in Azure AD for single sign-on with AAD Connect, you will need to add a custom domain and that domain will need to be verified. To deploy this feature, you also need to deploy AAD Connect to a Windows Server running Windows Server 2012 R2 or later and TLS 1.2 will need to be enabled. The server must also be a domain member of the same Active Directory forest as the users whose passwords you will need to validate.

Configuring single-sign on (see Figure 5-37) for use with Password synchronization or Pass-through authentication needs to be completed once for each forest that is being synchronized to Azure AD. To configure this feature, an account is created in the on-premises Active Directory and you will configure client machines to support single-sign on. Pass-through authentication is a tenant wide configuration, meaning it will apply to all of the custom (or managed) domains in your tenant. This also means that if you change the configuration later, such as on a staging server, it is possible to impact the configuration of your production deployment of AAD Connect.

A screen shot of the Microsoft Azure Active Directory Connect configuration wizard and the User sign-in screen.

Figure 5-37 Microsoft Azure Active Directory Connect User sign-in

To begin, you will select the appropriate sign-on method and then Enable Single Sign-On (see Figure 5-38). Then, for each domain that you will enter the credentials of an administrator with Domain Administrator rights to enable the creation of the new authentication broker accounts.

A screen shot of the Microsoft Azure Active Directory Connect configuration wizard and the Enable single sign-on screen.

Figure 5-38 Microsoft Azure Active Directory Connect Enable single sign-on

After SSO has been enabled, you will be able to view the configuration change in the Azure Portal (see Figure 5-39).

A screen shot of the Azure Portal showing Seamless single sign-on enabled.

Figure 5-39 Seamless single sign-on enabled in Azure AD

Password Hash Synchronization (PHS) and Pass-through authentication (PHA) vary slightly in the deployment of additional on-premises components. As a part of configuration with PHA, an agent will be installed on the local server where AAD Connect is running. This agent brokers the connection between Azure AD and your on-premises directory when users attempt to authenticate to Azure AD. By default, only one agent is deployed, but you can deploy additional agents to other servers in your environment to enable high availability. It is recommended that you deploy at least three of these authentication agents and not more than 12 can be deployed per tenant.

After configuring single-sign on in Azure AD Connect you will also need to enable clients for single sign-on. The configuration varies based on the client operating system and browser.

For Windows clients using Internet Explorer, this can be done through Group Policy by adding the site https://autologon.microsoftazuread-sso.com to the Local Intranet Zone in Internet Explorer through the Site to Zone Assignment List Group Policy that can be found at User ConfigurationAdministrative TemplatesWindows ComponentsInternet ExplorerInternet Control PanelSecurity PageSite to Zone Assignment List. You also need to enable the Allow Updates To Status Bar Via Script through Group Policy. This configuration is required for clients to successfully authenticate because by default Windows clients will not send Kerberos tickets to fully qualified domain names.

For other browsers, such as Firefox, Google Chrome, and Safari on macOS, refer to the configuration documentation at: https://docs.microsoft.com/azure/active-directory/hybrid/how-to-connect-sso-quick-start#browser-considerations.

This configuration only works for users that are:

  • Signed in to a domain joined device. Note the device does not need to be Azure AD Joined.

  • Directly connected to the domain at the time they authenticate to Azure AD. This means that for users that are off the network (e.g. remote workers not a on VPN) seamless SSO will not be possible with this method.

  • Accessing cloud apps that support modern authentication. Legacy authentication protocols are not supported with this method.

Azure AD Connect Federation

Azure AD Connect can also assist in the deployment of Active Directory Federation Services (or AD FS) and its associated roles if you do not have it deployed already. This is an optional part of the Azure AD Connect installation process. This potentially makes it easier to get AD FS installed and configured if you do not have any existing federation infrastructure or you are looking for any automated installation mechanism for AD FS. If there is already an AD FS infrastructure deployed, Azure AD Connect can perfectly integrate it as well.

Before configuring AD FS through Azure AD Connect, ensure that you have the following in place:

  • A Windows Server 2012 R2 or later server for the federation server with remote management enabled

  • A Windows Server 2012 R2 or later server for the Web Application Proxy server with remote management enabled

  • An SSL certificate for the federation service name you intend to use (for example sts. examref.com)

  • The credentials of a domain administrator

For the Web Application Proxy (WAP) server(s), you may need to perform additional configuration if they are not domain joined. From the server which you are going to run the AAD Connect installation and configuration wizard, you will need to add each WAP server to the TrustedHosts list for WSMan (Web Services for Management). This can be done by running the following command replacing the <DMZServerFQDNs> value with the value of your WAP server. If you have multiple WAP servers, you can use a comma separated list of servers as well.

Set-Item WSMan:localhostClientTrustedHosts –Value <DMZServerFQDNs> -Force
–Concatenate

The SSL certificate you will provide to the installation wizard must be an X509 certificate and the identity of the certificate must match the federation service name. The identity can be a SAN extension or common name of the certificate. Certificates with multiple SAN entries are supported as are wildcard certificates. Note that the installation wizard will not provision this certificate for you and you must obtain it prior to configuration.

Finally, for both the Federation server(s) and any WAPs you must have DNS records in place. You can use split-brain DNS for your federation services (e.g. point internal clients to your Federation server(s) and external clients to your WAPs). Your internal DNS must use an A record or Windows authentication will not function properly. If you are deploying a highly-available AD FS environment, ensure that the DNS entries point to the load-balanced endpoints for each segment.

To being configuration of AD FS federation with AAD Connect, select Federation With AD FS on the User sign-in screen (see Figure 5-40) in the configuration wizard.

A screen shot shows the Azure AD Connect wizard showing the User sign-in configuration screen with Federation with AD FS selected.

Figure 5-40 Configure Federation with AD FS in the Microsoft Azure Active Directory Connect installation wizard

Next, you will supply the credentials of a domain administrator (see Figure 5-41).

A screen shot shows the Azure AD Connect wizard showing the Domain administrator credentials screen prior to configuring an AD FS farm.

Figure 5-41 Microsoft Azure Active Directory Connect installation wizard Domain administrator credentials

From this point, the wizard varies. You will select whether you are configuring a new AD FS farm or using an existing farm. If you are configuring a new farm, you will need to supply the SSL certificate that meets the requires as stated above. For an existing farm, you will specify the server name for the primary server in the AD FS farm (see Figure 5-42).

A screen shot shows the Azure AD Connect wizard showing the AD FS farm configuration screen.

Figure 5-42 Microsoft Azure Active Directory Connect installation wizard AD FS farm

For the remainder of the example, we will focus on creating a new AD FS farm. On the next screens, you will add each of the Federation servers and each WAP. The selection of WAP servers is optional for the purposes of the wizard but recommended for a full AD FS deployment where users will be authentication from external locations.

After adding your servers, you will specify the AD FS service account (see Figure 5-43). The installation wizard can create a new group Managed Service Account (group MSA), use an existing group MSA, or use a domain account. When creating a new account, you will need to supply the credentials of an Enterprise Administrator and for existing accounts you will supply the account name or the account credentials. If you have Windows Server 2012 domain controllers and your AD FS member servers belong to the same domain, it is recommend to use a group MSA.

A screen shot shows the Azure AD Connect wizard showing the AD FS service account configuration screen.

Figure 5-43 Microsoft Azure Active Directory Connect installation wizard AD FS service account

Next, you will select the domain you will federate. On the first run of the configuration wizard, you can only select one domain. If you run the AAD Connect wizard again later, you can then select additional domains (Figure 5-44).

A screen shot shows the Azure AD Connect wizard showing the Azure AD domain configuration screen.

Figure 5-44 Microsoft Azure Active Directory Connect installation wizard Azure AD domain

If you have not previously verified the domain, for example in cases where the custom domain has been added as a part of the AAD Connect installation wizard, you will need to verify the domain before proceeding. Once you are ready to configure (see Figure 5-45), click the Configure button. After configuration has completed, you can test connectivity or re-run the AAD Connect wizard to add additional federated domains.

A screen shot shows the Azure AD Connect wizard showing the Ready to configure configuration screen.

Figure 5-45 Microsoft Azure Active Directory Connect installation wizard Ready to configure

Manage Azure AD Connect

Azure AD Connect can be managed through several tools including the AAD Connect installation wizard and PowerShell.

The most common will be running the installation wizard again to update or alter an existing configuration. For example, to change the user sign-in method or to add a new on-premises directory for synchronization you would simply run the wizard again.

You can find the installation wizard in the Start Menu named Azure AD Connect or on the Desktop for the user that installed the tool. When you launch the wizard, the synchronization service scheduler will be paused. This means that no synchronizations (e.g. delta synchronizations from your on-premises directory to Azure AD) will occur until the configuration updates are complete or the wizard is closed.

You will see a screen like the one in Figure 5-46. If you have deployed AD FS you will have even more options.

A screen shot shows the Azure AD Connect wizard being run a second time.

Figure 5-46 Azure AD Connect installation wizard being run a second time

Choosing Customize Synchronization Options and make bold will allow you to make changes to the current configuration. The options you see running the wizard a second time will be a subset of the options that were available in the initial installation. From this option, you can add more directories, update domain and organizational unit (or OU) filtering, remove group filtering, and change optional features such as enabling or disabling password writeback, group writeback, and Azure AD app and attribute filtering.

If you update the schema in your on-premises Active Directory forest you can use the Refresh directory schema option to update the schema for one or more directories to enable synchronization of newly created attributes.

The configure staging mode will allow you to enable or disable staging mode on the server. Staging mode can used for enabling high-availability, testing and deploying new configuration changes, and introducing new Azure AD Connect servers prior to decommissioning or retiring an existing server.

Finally, you can also change the user sign-in method to and from password hash sync, pass-through authentication, or federation. When changing sign-in methods, there can be disruptions to user connectivity.

Using PowerShell, you can use the ADSync module to view and update settings for the synchronization service, such as altering the sync schedule or manually initiating synchronizations.

To use the ADSync module, open a PowerShell prompt as an administrator on the server where AAD Connect is installed and import the module.

Import-Module ADSync

You can view the existing sync schedule with the Get-ADSyncScheduler cmdlet, as shown in Figure 5-47.

A screen shot of the output of the Get-ADSyncScheduler cmdlet.

Figure 5-47 Get-ADSyncScheduler output

By default, synchronization occurs every 30 minutes. If you need to alter the schedule, use the Set-ADSyncScheduler cmdler. For example, you could run the following command to set the scheduler to sync every hour.

Set-ADSyncScheduler -CustomizedSyncCycleInterval 01:00:00

To view the current sync status, use the Get-ADSyncConnectorRunStatus cmdlet.

To initiate a full or incremental synchronization, you can use the Start-ADSyncSyncCycle cmdlet and specify the PolicyType parameter. A PolicyType of Initial will start a full sync and while a PolicyType of Delta will start an incremental sync. Use the Get-ADSyncConnectorRunStatus cmdlet to view the status.

Manage password sync and writeback

AAD Connect supports a feature known as Password Hash Synchronization (PHS). With PHS, AAD Connect can be used to synchronize user passwords to Azure AD where they can then be leveraged for authentication. This is useful in scenarios where you want to allow users to sign-in to Azure AD with the same credentials they use on-premises but do not have the associated infrastructure to support federation or you do not require single sign-on.

The passwords that are synchronized to Azure AD are not sent or stored in clear text. They are instead a hash of a hash of a user’s password from your on-premises Active Directory.

PHS is enabled through the AAD Connect installation wizard on the User sign-in screen (Figure 5-48).

A screen shot of the Microsoft Azure Active Directory Connect User sign-in screen in the installation wizard with Password Hash Synchronization selected.

Figure 5-48 Microsoft Azure Active Directory Connect User sign-in

There is no additional configuration required to leverage the feature. PHS is a one-way synchronization from your on-premises directory to Azure AD. This means there is a delay between when a password is changed on-premises and when that change is reflected in Azure AD as synchronization must occur for the updated password to be written to the cloud.

For environments where PHS is configured, cloud passwords are set to never expire. Combined with the previously mentioned delay in synchronization, there are cases where a user will be able to authenticate to the cloud apps that use Azure AD as their identity provider with their old password until synchronization occurs. To force a synchronization manually, you can use the Start-ADSyncSyncCyle cmdlet.

Password writeback is a feature of Azure AD and AAD Connect that allows users to change their password in the cloud and have that password written back to an on-premises directory while adhering to your organization’s password policies and security controls. Password writeback is a user-friendly feature and provides immediate feedback to users as it is a synchronous operation.

Password writeback requires one of the following licenses:

  • Azure AD Premium P1

  • Azure AD Premium P2

  • Enterprise Mobility + Security E3 or A3

  • Enterprise Mobility + Security E5 or A5

  • Microsoft 365 E3 or A3

  • Microsoft 365 E5 or A5

  • Microsoft 365 F1

Password writeback also supports additional controls which ensure that password change requests adhere to your organizational policy. For example, when a user or administrator initiates a password reset, the password is checked for history, complexity, age, and any other filters you have in place on-premises. As resets are a synchronous operation, users are immediately informed of the status of their reset.

When password writeback is enabled, administrators will have the ability to change user passwords through the Azure Portal as well.

Password writeback is enabled through AAD Connect and by configuring self-service password reset (or SSPR). To enable writeback through AAD Connect, open the installation wizard and browse to the Optional Features page. From that page, select the box next to Password Writeback (highlighted in Figure 5-49) and click Next. On the Ready To Configure page, select Configure and wait for the process to finish.

A screen shot shows the Azure AD Connect wizard being run again to select Optional features.

Figure 5-49 Azure AD Connect installation wizard option features view

With password writeback enabled in Azure AD Connect, browse to your Azure AD tenant in the Azure Portal as a Global administrator and open the Password Reset blade and then choose on-premises integration. Set the option for Write Back Passwords To Your On-Premises directory to Yes and optionally set the option for Allow Users To Unlock Accounts Without Resetting Their Passwords to Yes. When complete, click Save.

Skill 5.4: Implementing multi-factor authentication (MFA)

Multi-Factor Authentication (MFA) is a security enhancement that is applicable to authentication for users and devices in Azure Active Directory (Azure AD) where users must present additional information before they can authenticate to services that use Azure AD as an identity provider. MFA is also sometimes referred to as two-step or two-factor (2FA) authentication because it is a discrete step, separate from the entry or presentation of credentials during the authentication of a user. While MFA can include more than two factors, the implementation in Azure is strictly a two-factor implementation.

In its most basic form, MFA requires two or more of the following authentication methods:

  • Something you know, for example a password or a pin.

  • Something you have, for example a smart card or a mobile phone.

  • Something you are, for example your fingerprint, which is unique to you.

MFA requires that your credentials come from two or more different sources to enhance security. For example, a user with MFA attempting to authenticate to the Azure mobile app will need their user name and password as well as a second factor such as a one-time pin generated by the Microsoft Authenticator app.

For organizations that need to be compliant with industry standards, such as PCI DSS version 3.2, MFA is a must-have capability to authenticate users. Beyond being compliant with industry standards, enforcing MFA to authenticate users can also help organizations to mitigate credential theft attacks.

MFA in Azure AD is provided through Azure Multi-Factor Authentication. Azure MFA helps safeguard access to data and applications that use Azure AD as an identity provider while maintaining simplicity for users with administrator-controlled functionality such as conditional MFA.

Multi-Factor Authentication

Before implementing MFA in Azure AD, there are several considerations. MFA is both a service that is configured through Azure AD and a feature that is assigned to users through an Azure AD license which includes usage rights for Azure MFA. Assigning your users a license that includes the features of MFA is not enough–you must also configure the service to meet your organizational requirements.

The MFA service comes in multiple versions:

  • Multi-Factor Authentication for Office 365 and Multi-Factor Authentication for Microsoft 365 Business

  • Multi-Factor Authentication for Azure AD Administrators

  • Azure Multi-Factor Authentication

Azure MFA for Office 365/Microsoft 365 is a version of the MFA service that works only with Office 365 applications and is managed through the Microsoft 365 administrative portal. Azure MFA for Azure AD Administrators is available for Global Administrators of an Azure AD tenant for no charge. Azure MFA is the full or complete version of MFA, and doesn’t have any limitations that are imposed when using just Azure MFA for Office 365 or Azure MFA for Azure AD Administrators.

Note Azure MFA Feature Comparison

For a feature comparison of the available versions of Azure MFA, refer to the documentation at: https://docs.microsoft.com/azure/active-directory/authentication/concept-mfa-licensing#feature-comparison-of-versions.

Azure MFA is included with Azure Active Directory Premium (both P1 and P2) licenses and other suites with equivalent licensing such as Enterprise Mobility + Security E3/E5. For some time, Azure MFA also could be purchased in a consumption model, but that is no longer possible, and the only way to obtain usage rights for Azure MFA is through the previously mentioned license.

Azure MFA per-user entitlements (licenses) enable the Azure MFA service, which then has two variations that vary in functionality. Azure MFA can be run purely in the cloud, and there is also an on-premises MFA server that can be deployed. PIN mode, one-time bypass, and caching are features that are exclusive to Azure MFA Server. The ability to remember MFA for trusted devices is exclusively to MFA in the cloud.

Images Exam Tip

You need to be able to identify features that will require Azure MFA Server and cannot be run exclusively in the cloud. For example, to leverage the one-type bypass features of Azure MFA, you must deploy the on-premises MFA Server and meet all of the prerequisites for that deployment, such as the use of AD FS and federated authentication. A full comparison of the features of Azure MFA across MFA in the cloud and MFA Server can be found at:
https://docs.microsoft.com/azure/active-directory/authentication/concept-mfa-whichversion#what-features-do-i-need.

Note Azure MFA Server

Azure MFA Server one-time bypass is discussed later in this chapter.

Configure Azure MFA

Configuring Azure MFA in the cloud begins with ensuring you meet the perquisites. In addition to obtaining user licensing that includes the MFA features of Azure AD, you will also need a Global Administrator account to access and configure the service.

Note Azure MFA Server Deployment Guidance

Throughout this section, we refer to the configuration of Azure MFA in the cloud. For specific deployment guidance of Azure MFA Server on-premises, refer to the documentation at https://docs.microsoft.com/azure/active-directory/authentication/howto-mfaserver-deploy. Features that are exclusive to MFA Server will be called out.

The MFA service requires the configuration of one or more authentication methods. The authentication methods that you select as a part of the configuration of the MFA service will drive how much information your users need to provide to successfully authenticate through Azure AD and the MFA service.

The authentication methods available for use with Azure MFA are:

  • Password This is the password of the user in Azure AD. This is a required authentication method and cannot be disabled.

  • Call to Phone Through this method a voice call is made through an automated calling service to the user’s registered phone number. The user will answer the call and press # to verify the call.

  • Text Message To Phone In this method an SMS is sent to the user’s registered mobile phone number. The SMS message contains a code that must be entered to authenticate to Azure AD.

  • Notification Through Mobile App This authentication method allows a user to register the Microsoft Authenticator app with Azure AD during registration and receive push notifications on their iOS or Android mobile device for each MFA-enforced authentication to Azure AD.

  • Verification Code From Mobile App Or Hardware Token This method allows users to use the Microsoft Authenticator app or a compatible third-party application to generate one-time pins (OTP). The application generating the pin is a software token that generates OATH verification codes. In the case of hardware tokens, Azure AD supports the use of OATH-TOTP SHA-1 tokens of both the 30 and 60 second varieties.

Note Hardware Tokens

The use of hardware tokens is currently in preview.

Note Authentication Method Best Practice

Consider configuring two or more authentication methods in addition to a password (which cannot be removed) when configuring the MFA service. Users may not have access to all of their methods at the time of authentication and having more than one method available will provide your users with more flexibility. For example, when a user is at their desk, they may not be able to receive calls on their mobile device, but they do have access to their office phone. In this case, it may be desirable to have Call To Phone and SMS or mobile app notifications configured.

You can also control the use of app passwords when configuring the MFA service. There may be applications that users authenticate through Azure Ad to access, but they do so with a non-browser-based application that cannot perform modern authentication. For example, users in your organization may access their Office 365 mailbox hosted in Exchange Online through a third-party email client that does not use modern authentication. In this case, you must allow users to create app passwords in the MFA service. It is also possible to leverage Azure MFA to block authentication attempts to applications that do not support modern authentication by blocking the ability to create app passwords. By default, app passwords are disabled and must be enabled as a part of the configuration of the MFA service.

Note App Password Authentication

If your organization uses federated identity with Azure AD (for example, with AD FS), be aware that the use of app passwords circumvents federation because the authentication occurs only in Azure AD.

To configure authentication methods (or verification options), or disallow the use of app passwords in the MFA service, browse to your Azure AD tenant in the Azure Portal and select the MFA blade as shown in Figure 5-50.

A screen shot of the Azure Portal showing the MFA blade highlighted in the Azure Active Directory service.

Figure 5-50 MFA in the Azure Portal

Note Navigating to Azure AD in the Azure Portal

If you do not see the Azure Active Directory service in the left navigation, you can find it by selecting All Services. There is also a dedicated URL for the quick management of Azure AD at https://aad.portal.azure.com.

From the MFA blade, click Additional Cloud-Based MFA Settings as shown in Figure 5-51.

A screen shot of the Azure Portal showing the Getting Started blade of the MFA service in Azure Active Directory.

Figure 5-51 MFA Getting Started blade

A new tab will open in your browser and you will be taken to the Service Settings tab for the MFA service. From this tab, you can configure:

  • App passwords

  • Trusted IPs

  • Verification methods

  • Device remember/re-authentication settings

Note Trusted IPs

The configuration of Trusted IPs is discussed later in this chapter.

Configure the service as needed based on your organization’s requirements, and click Save to persist the configuration, as shown in Figure 5-52.

A screen shot of the MFA service settings configuration tab.

Figure 5-52 MFA service settings tab

Configure user accounts for MFA

Before or after the configuration of the service settings for Azure MFA is complete, licenses can be assigned to users. In many cases, it is desirable to first configure the MFA service, onboard several test users to verify the configuration is performing as desired, and then onboard your remaining users.

MFA can be enabled for users in three ways:

  • Changing user state This is the most common method to enable MFA and works for both MFA in the cloud and MFA server. In this configuration, a license is assigned to each user who requires MFA and MFA is enabled for the account until the state is changed to disabled.

  • Through conditional access policies In this configuration, receive MFA challenges based on administrator-defined rules that allow or deny access to applications in Azure AD.

  • Through Azure AD Identity Protection In this configuration, risk policies in Azure AD conditionally enforce MFA authentication based on the sign-in risk associated with the authentication attempt.

To configure MFA for your users by changing user state, browse to Azure Active Directory in the Azure Portal and select the Users blade as shown in Figure 5-53.

A screen shot of the Azure Portal showing a callout for the Users blade in the Azure Active Directory service.

Figure 5-53 Azure Active Directory service and Users blade

From the All Users blade, select Multi-Factor Authentication in the toolbar as shown in Figure 5-54.

A screenshot of the Azure Portal showing the All users blade of Azure Active Directory with a callout for the Multi-Factor Authentication button in the toolbar.

Figure 5-54 Azure Active Directory All users blade

A new browser tab will open, and you will be taken to the Users tab of the MFA service as shown in Figure 5-55.

A screenshot of the MFA service configuration showing the users tab.

Figure 5-55 MFA service users tab

From the user settings screen, you can view the MFA status (user state) for your users. The user settings screen also supports filtering user attributes and roles through the Views dropdown. This includes filtering by Sign-in allowed users, Billing administrators, Global administrators, Password administrators, Service administrators, and User management administrators. It is also possible to further filter the list of users by user state, including Any, Enabled, or Enforced.

When a user’s state is Disabled, the user is not enrolled in MFA. When MFA is enabled for a user, their state changes to Enabled. Even though a user has been enabled for the MFA service, they have not yet performed registration (for example, setting their mobile or configuring other authentication methods). After a user has completed the registration process for Azure MFA, their state will change to Enforced.

Important Registering Users for MFA

When you have enabled MFA for a user, it is critical that they register for the MFA service as soon as possible if they are not yet registered. MFA cannot be enforced for a user until that user has completed registration. Enabling MFA for your users should be a coordinated effort between Azure AD administrators, your support desk, and your users. Users must be trained on how to register for the service, and how authentication to Azure AD applications will change with MFA in place.

Users can register for the MFA service before a license is assigned at https://aka.ms/mfasetup. This is recommended in most cases as your users will transition directly to Enforced when MFA is enabled on their accounts. By pre-registering your users, you can ensure that that users are given time to understand the MFA service and provided the proper training.

To update the state for a single user, select the user, and under quick steps select Enable to configure the user for MFA, as shown in Figure 5-56.

A screen shot of the MFA service configuration showing the users tab.

Figure 5-56 MFA service users tab

At the prompt, select Enable Multi-Factor Auth as shown in Figure 5-57.

A screen shot of the MFA service configuration showing the Enable Multi-Factor Auth button for a single user.

Figure 5-57 Enable Multi-Factor Auth for a single user

After the update has been made the user’s state will change to Enabled. Selecting the same user, you will now see that the options under Quick Steps have changed and Disable and Enforce are now options. In most cases, users in the enabled state will be prompted to perform registration on their next authentication attempt and be transitioned to a user state of Enforced. It is also possible for an administrator to force a user state of Enforced even if a user has not completed registration. In either case (whether in an Enabled state or an Enforced state), the user must still go through registration.

Note Manually Moving Users to Enforced State

Do not ever move users directly to the Enforced state. This can cause non-browser-based applications to stop working, because the user has not yet registered and will not have any app passwords configured.

It is also possible to perform bulk updates to user state using PowerShell or a CSV uploaded through the MFA service. CSV updates can only be used to enable or disable MFA for existing users, not to add new users to Azure AD. To perform CSV updates, from the Users tab in the MFA service, select the Bulk Update button, as shown in Figure 5-58.

A screenshot of the MFA service configuration showing the Bulk Update button on the users tab.

Figure 5-58 Enable multi-factor auth for a single user

In the prompt that appears, you can download a sample file or upload an existing CSV. The format for the CSV is two columns:

  • Username Where the value is the UPN of the user

  • MFA Status Where the status is the desired user state of Enabled or Disabled

For example:

Username, MFA Status
[email protected], Enabled
[email protected], Disabled
[email protected], Disabled
[email protected], Enabled
[email protected], Enabled

When uploading a file, it will be verified where a check is performed to validate UPNs and the MFA Status column.

To perform updates using PowerShell, you will need the MSOnline module. In an administrator-elevated PowerShell prompt, first install the module. After installing the module, you can connect to the online service using the Connect-MsolService cmdlet.

Install-Module MSOnline
Connect-MsolService

Create an array of users or retrieve the users from an existing data store, such as a CSV or a SQL database. In this example, we will use an array:

$users = "[email protected]", "[email protected]", "[email protected]"
foreach ($user in $users) {
  $st = New-Object -TypeName Microsoft.Online.Administration.
StrongAuthenticationRequirement
  $st.RelyingParty = "*"
  $st.State = "Enabled"
  $sta = @($st)
  Set-MsolUser -UserPrincipalName $user -StrongAuthenticationRequirements $sta
}

The user state is set through the State property on the object of type Microsoft.Online. Administration.StrongAuthenticationRequirement, and the Set-MsolUser cmdlet is used to update the MFA settings for each user.

Azure MFA advanced features

So far, we have examined some of the basic settings to onboard to the Azure MFA service, and how to also onboard users to the service. There are several configuration items in the Azure MFA service that can be used to improve the user experience for users who are subject to MFA authentication.

The features of Azure MFA that we will review are:

  • Trusted IPs

  • Conditional Access Polices

  • Fraud Alerts

  • One-time bypass

  • Azure Active Directory Identity Protection

Azure Active Directory Identity Protection requires Azure Active Directory Premium P2 licensing while the other features are available with either an Azure Active Directory Premium P1 or P2 license.

Configure Trusted IPs

One or more IP address ranges can be associated with the MFA service. When this is done, MFA is bypassed for authentication attempts from those configured ranges. This functionality is typically used to allow users on your Intranet or your internal network to authenticate to Azure AD applications without the additional verification step introduced with MFA. This way, users on your corporate network, or flagged network segments, can access required services in a more streamlined manner while they will still have to perform MFA when they are off the network or authenticating to Azure AD from an unknow network segment.

In addition to specifying a range of trusted IP addresses, you can also configure the MFA service to bypass MFA for federated users in your Azure AD tenant by including a custom claim from your identity provider to Azure AD after the user has authenticated in the federated identity provider. For example, if you federate a custom domain using AD FS, users who authenticate through AD FS can bypass MFA for authentication attempts that originate from within the corporate network.

Trusted IPs are configured through the MFA service settings. To access the service settings, in the Azure Portal browse to the Azure Active Directory service and select the MFA blade as shown in Figure 5-59.

A screenshot of the MFA service configuration showing the Bulk Update button on the users tab.

Figure 5-59 MFA in the Azure Portal

From the MFA blade, click Additional Cloud-Based MFA Settings, as shown in Figure 5-60.

A screenshot of the Azure Portal showing the Getting started blade of the MFA service in Azure Active Directory.

Figure 5-60 MFA Getting Started blade

On the Service Settings tab, in the Trusted IPSA section, enter one or more IP address ranges using CDIR notation. For example, if your on-premises clients are in the segment 10.1.0.0/16, enter that value in the text box, as shown in Figure 5-61. You can enter multiple ranges if needed.

To bypass MFA for federated users signing in from the corporate network, select the Skip Multi-Factor Authentication For Requests From Federated Users On My Intranet check box.

A screen shot of the MFA service settings page calling out the Trusted IPS section of the form.

Figure 5-61 MFA service settings Trusted IPS

To persist the configuration, click Save.

Note MFA Service Settings Limits

You can enter up to 50 IP addresses/address ranges in Service Settings when configuring Azure MFA.

If you have selected the Skip multi-factor authentication for requests from federated users on my intranet check box, you must also add inject an additional claim for users authenticating through your federated identity provider. If you are using AD FS, this can be done by adding a new claim rule. The format of the claim is:

c:[Type== "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"] =>
issue(claim = c);
Configure Conditional Access Policies

One of more conditional access policies can be configured to all your users to bypass MFA authentication based on the logic that is defined in the conditional access policy.

To configure a new conditional access policy, browse to the Azure Active Directory service in the Azure Portal and select the Conditional Access blade, as shown in Figure 5-62.

A screen shot of the Azure Portal showing the Azure Active Directory service with a callout for the Conditional Access blade.

Figure 5-62 Azure Active Directory service in the Azure Portal

From the Policies blade, click New Policy as shown in Figure 5-63.

A screen shot of the Azure Portal showing the Policies blade for Conditional Access with the New policy button highlighted.

Figure 5-63 Conditional Access Policies

Enter a name for your policy. In the example shown in Figure 5-64, the policy name will be Enforce MFA.

A screen shot of the Azure Portal showing the New policy blade when creating a conditional access policy.

Figure 5-64 New policy blade

In the Assignments blade, select the Users And Groups that the policy will apply to as shown in Figure 5-65. Note that you can select users and groups the policy will apply to in the Include tab and you can also select users or groups to exclude from the policy through the Exclude tab. It is possible with some policies to lock yourself out of your tenant and in some cases it is recommended that you leave at least one user who has access rights to manage policy excluded from restrictive policies. You can select multiple users and multiple groups if needed. Click Done.

A screen shot of the Azure Portal showing the New policy blade and the selection of users and groups under the Assignments section.

Figure 5-65 New policy blade Users and groups

Next, select the applications the policy will apply to, as shown in Figure 5-66. You can select All Cloud Apps or individual applications that are registered in your Azure AD tenant. It is also possible to exclude one or more cloud apps from a policy through the Exclude tab. Any apps selected on the Exclude tab are exempt from the policy. Click Done.

A screen shot of the Azure Portal showing the New policy blade and the selection of Cloud apps under the Assignments section.

Figure 5-66 New policy blade Cloud apps

Important User Exclusions in Conditional Access Policy

It is possible to lock yourself out of the cloud apps that you implement in a conditional access policy. It is a good practice to exclude a user or group from the user assignments with rights to update the policy in the event it does not perform as expected.

If you have any conditions you would like to configure, these can be done in the Conditions section. For example, if you have configured trusted IP ranges or defined locations based on country or geographic region, using the named locations feature of conditional access, you can apply the conditional logic here. You can also use the sign-in risk level from Azure Active Directory Identity Protection as a trigger for a condition. For the example provided, there will be no additional conditions, and the policy will simply trigger off of group membership for all cloud apps.

Note Named Locations in Conditional Access

If you configure a named location that uses an IP address range in Conditional Access, that IP range can be marked as a trusted location, and it will be configured in the MFA service settings for you.

In the Grant blade under the Access controls section of the New policy blade, select Grant Access and the check box for Require Multi-Factor Authentication, as shown in Figure 5-67. Click Select.

A screen shot of the Azure Portal showing the New Policy blade and the selection of Require multi-factor authentication in the New Policy blade.

Figure 5-67 New policy blade Grant blade

In the New Policy blade, select On for Enable Policy, and click Create to save the new policy, as shown in Figure 5-68.

A screen shot of the Azure Portal showing the New Policy blade and the selection of the Enable policy On switch with the Create button highlighted.

Figure 5-68 New policy Enable policy

The policy will be validated and then created. After several seconds you will receive a notification in the Portal that the policy has been successfully created, as shown in Figure 5-69. After the policy is created, it can still take several minutes before it takes effect.

A screen shot of the Azure Portal showing the toast notification after a new policy has been successfully created.

Figure 5-69 New policy successfully created

Configure Fraud Alerts

Fraud alerts in Azure MFA allow users to report what they suspect are fraudulent attempts to access their applications. For example, if a user that is configured for verification through the Microsoft Authenticator app receives a push notification when they are not attempting to sign in to a service, it may be a bad actor attempting to access the user’s applications. Remember, MFA challenges a user for their configured authentication methods only after a valid password has been provided, so if the user is not the one logging in, there is a very good chance that the user’s credentials have been compromised.

To configure fraud alerts, browse to Azure Active Directory in the Azure Portal and select the MFA blade, as shown in figure 5-70.

A screen shot of the Azure Portal showing the MFA blade highlighted in the Azure Active Directory service.

Figure 5-70 MFA in the Azure Portal

From the MFA blade, select Fraud Alert, as shown in Figure 5-71.

A screen shot of the Azure Portal showing the Fraud alert blade in the MFA service.

Figure 5-71 Fraud alert in the Azure Portal

To enable fraud alerts, turn the Allow Users To Submit Fraud Alerts button to On, as shown in Figure 5-72. You can also automatically block a user who reports fraud. If you configure this setting, the user account will be blocked and will remain blocked from all authentication attempts to Azure AD for 90 or until their account is unblocked by an administrator. This can be a good setting to leave enabled, as it will prevent fraudulent authentication attempts to all the cloud applications that a user can authenticate to using Azure AD.

There is also an option to configure a Code to report fraud during initial greeting. This code is used during voice verification. For example, if you set the value to 1, when a user receives a voice call for verification, they can press 1# and the fraud attempt will be reported. When the service is configured as needed, click Save.

A screen shot of the Azure Portal showing the Fraud Alert blade in the MFA service configured to On and a fraud report code of 1.

Figure 5-72 Fraud alert in the Azure Portal

After the service is configured, users can report fraud through the Microsoft Authenticator app or through the phone. Administrators can view fraud reports in the Azure AD sign-ins report.

Configure One-time Bypass

One-time bypass allows an administrator to exempt a user from MFA authentication for a short period of time. This can be useful if a user does not have access to their authentication method and your administrators still have a method to verify users are who they say they are. For example, if a user is configured for voice verification but their phone is stolen, they would not be able to perform two-step verification until they procure a new mobile phone and register their phone number in the MFA service.

Important One-Time Bypass and Azure MFA Server

One-time bypass is a feature of Azure MFA that is only available through the on-premises MFA Server.

To configure one-time bypass, browse to the MFA blade in the Azure Active Directory Service through the Azure Portal, as shown in Figure 5-73.

A screen shot of the Azure Portal showing the MFA blade highlighted in the Azure Active Directory service.

Figure 5-73 MFA in the Azure Portal

In the MFA service, select the One-Time Bypass blade, as shown in Figure 5-74.

A screen shot of the Azure Portal showing the One-Time Bypass blade in the MFA service.

Figure 5-74 One-Time Bypass blade in the MFA service

To create a bypass for a user, click the Add button. In the Add One-Time Bypass blade, enter the user principal name (also known as UPN or sign-in name) for a user, the number of seconds the bypass will be valid for, and a reason that will be captured with the bypass request. Click Ok to enable the bypass, as shown in Figure 5-75.

A screen shot of the Azure Portal showing the Add one-time bypass blade in the MFA service.

Figure 5-75 Add one-time bypass blade in the MFA service

The bypass will immediately be enabled and begin counting down. To view past bypass requests, browse to the One-Time Bypass blade in the MFA service. From this blade, you can add a new bypass as well as view current and past bypass requests. For current and valid requests, you can cancel them using the Cancel link, as shown in Figure 5-76.

A screen shot of the Azure Portal showing the One-Time Bypass blade in the MFA service with the Cancel button highlighted in the Bypassed users report.

Figure 5-76 One-Time Bypass blade in the MFA service

Configure Identity Protection

Azure Active Directory Identity Protection is a premium feature of Azure Active Directory, which requires Azure Active Directory Premium P2 licenses. Azure AD Identity Protection has features that are beyond the scope of MFA, and in this section, we will focus on the MFA registration policy feature of Azure AD Identity Protection.

The MFA registration policy can be used to assist in the rollout and implementation of Azure MFA through the creation of a policy that will enforce MFA registration for your users. Note that this policy is a feature of Azure AD Identity Protection and is not the same as a conditional access policy. The MFA registration policy enforces registration for the selected users and groups while conditional access can optionally enforce MFA for authentication to select cloud apps. For example, by enabling the MFA registration policy, you can ensure that all your users have registered for MFA and provided the needed inputs to configure their verification methods before you implement MFA. This can lower the burden on support staff and if left in place will enforce MFA registration for new users as well.

To configure the MFA registration policy, browse to the Azure AD Identity Protection service in the Azure Portal. There are multiple ways to access the service and, in the example, shown in Figure 5-77 you can browse to All Services, search for Identity, and then select the service.

A screen shot of the Azure Portal showing how to navigate to the Azure AD Identity Protection service in the All services blade.

Figure 5-77 Azure AD Identity Protection in All services

Note Enabling Azure AD Identity Protection

If you have not enabled Azure AD Identity Protection, you will need to do so before configuring the MFA registration policy. Guidance for enabling the service can be found at: https://docs.microsoft.com/azure/active-directory/identity-protection/enable.

In the Identity Protection service, select the MFA Registration blade, as shown in Figure 5-78.

A screen shot of the Azure Portal showing the MFA registration blade in Azure AD Identity Protection.

Figure 5-78 Azure AD Identity Protection MFA registration blade

To configure the policy, select the users for which you would like to enforce registration. In a manner like a conditional access policy, you can exclude users from the registration policy too. Select your users and/or groups, click Select, and then Done.

In the Access control blade, select Require Azure MFA Registration and click Select, as shown in Figure 5-79.

A screen shot of the Azure Portal showing the Access control blade of an MFA registration policy with the check box for Require Azure MFA registration checked.

Figure 5-79 Azure AD Identity Protection Require Azure MFA registration

In the Estimated Impact blade, you can view the current state of MFA registration in your Azure AD tenant. as shown in Figure 5-80.

A screen shot of the Azure Portal showing the Estimated Impact blade of an MFA registration policy.

Figure 5-80 Azure AD Identity Protection Estimated impact

To enable the policy, turn the Enforce Policy switch to On, and click Save, as shown in Figure 5-81.

A screen shot of the Azure Portal showing the MFA registration policy blade with the Enforce Policy set to On, and the Save button highlighted.

Figure 5-81 Azure AD Identity Protection enable MFA registration policy

After the policy has been successfully saved, you will see a notification in the portal as shown in Figure 5-82.

A screen shot of the Azure Portal showing the MFA registration policy being successfully saved.

Figure 5-82 Azure AD Identity Protection enable MFA registration policy successfully

Thought experiment

In this thought experiment, apply what you have learned. You can find answers to these questions in the next section.

You are the administrator for Trey Research Pharmaceuticals. As a leader in the design and manufacturing of cutting-edge treatments for cancer patients, Trey Research needs to ensure that the users within the organization are protected as they access cloud apps from Microsoft such as Office 365 and external cloud apps including Salesforce CRM for their sales department.

Trey Research needs to ensure cloud identity implementation has the following features:

  1. When users log in to Office 365 and Salesforce they should be redirected to an existing on-premises AD FS Farm. For disaster recovery purposes when the AD FS Farm is unavailable users should be able to log in to their cloud apps with the same user name and password that they use on-premises.

  2. Users in the research department are all members of a security group. Users in this group handle sensitive data and must use multi-factor authentication (MFA) when accessing cloud apps.

  3. Due to the sensitive nature of the intellectual property that users in the research group interact with; Trey Research would like to implement period reviews to verify group membership.

  4. To make it easier for users to manage their credentials, Trey Research would like users to be able to update their passwords both on-premises and in the cloud.

Thought experiment answers

This section contains the answers to the thought experiment for the chapter.

  1. Add and verify a custom domain in Azure AD that matches the on-premises user principal name suffix. Install Azure AD Connect and configure domain federation so that users are redirected to the on-premises AD FS farm when they attempt to login to Office 365. To meet the requirements for disaster recovery, configure Azure AD Connect with password hash synchronization. In the event the AD FS farm is unavailable, a global administrator can configure the domain from a federated to a managed domain that allows the users to login to Azure AD authenticated cloud apps with the same user name and password they use on-premises.

  2. A global administrator should enable Azure AD Identity Protection and configure a multi-factor authentication registration policy that requires MFA for the Research security group.

  3. From the Access reviews service, an administrator should create a new access review for the Research security group in the default program. When configuring the access review, the administrator will need to select the recurrence rules for the review and any necessary reviewers.

  4. An administrator should re-run the Azure AD Connect installation wizard and enable password writeback in the Optional features section of the wizard. This can be done by opening the wizard, selecting Customize synchronization options and proceeding through the wizard to the Optional features screen where Password writeback can be selected. After reconfiguring Azure AD Connect, a global administrator should configure self-service password reset through the Azure AD Portal by browsing to the Azure AD tenant.

Chapter summary

Below are some of the key takeaways from this chapter:

  • Custom domains can be added to Azure AD, such as contoso.com, but there is always a default onmicrosoft.com domain.

  • Azure AD Identity Protection enables administrators to configuration Azure AD tenant-wide policies for multi-factor authentication, sign-in risk, and user risk.

  • Windows 10 can be added to Azure AD as a device to be managed, enabling BYOD or corporate cloud only deployments with Azure AD Join.

  • Azure AD Join enables administrators to manage device identity independently of users. For example, dynamic security groups can be created based on device attributes and then conditional access policies could be applied to those groups.

  • Downstream Windows clients can be managed through Azure AD using Azure AD hybrid join.

  • Enterprise State Roaming allows Windows 10 clients to synchronize settings and application data securely across multiple corporate devices.

  • Conditional access is a feature of Azure AD which allows administrators to control access to cloud applications through additional checks such as user location, the device the user is accessing the cloud app from, and more.

  • Multiple Azure AD tenants can be created and managed through Azure. This includes creating new directories and deleting existing directories.

  • Users and groups can be created through the Azure Portal, Azure PowerShell, the Azure CLI, and the Graph API.

  • Users and groups can be managed in bulk with tools like PowerShell.

  • Azure AD supports hybrid identity scenarios with Azure AD Connect.

  • Azure AD supports federated logins and single-sign on. When federated identity is not required, Azure AD also single sign-on with both password hash synchronization and pass-through authentication.

  • Self-service password reset can be combined with the password writeback features of Azure AD Connect to allow users to reset their passwords from the cloud while adhering to on-premises password standards.

  • Many advanced features of Azure AD require Azure AD Premium P1 or Azure AD Premium P2 licenses. When considering Azure AD features, administrators need to be aware of the licensing boundaries.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.207.98.249