Design for cloud/hybrid identity

The public cloud is growing. More cloud providers are offering services. New services are being offered. And the capabilities of cloud services are ever expanding. As an administrator, you need to be familiar with the different cloud offerings and know how to integrate them with your on-premises environment to create a seamless hybrid environment. In a hybrid environment, users might have an identity in your on-premises environment, an identity in your public cloud environment, or a single identity that enables them to authenticate across your on-premises environment and your public cloud environment.

The 70-398 exam focuses on planning and managing devices in an enterprise environment. But, today, most enterprise environments are using the cloud in some capacities and often are integrated closely with the cloud. Thus, you need to be comfortable in a cloud environment, especially a hybrid cloud environment. This chapter covers many Microsoft Azure Active Directory (Azure AD) features and tools. Azure’s ongoing development includes portal enhancements, new features, and updated features. Thus, some of the technologies described in this chapter are currently in preview, which is an Azure mode that enables users to test-drive features before they become generally available and supported in a production environment.

Skills covered in this chapter:

• Plan for Azure Active Directory identities
• Design for Active Directory synchronization with Azure AD Connect

Skill 1.1: Plan for Azure Active Directory identities

Many administrators have experience working with identities, especially on-premises identities, through technologies such as Active Directory Domain Services (AD DS). But relying on just AD DS for identity and access management becomes difficult when your organization begins using the public cloud to host applications and services. To address the limitations of on-premises AD DS for public cloud and hybrid cloud environments, Azure AD was introduced. With Azure AD, your identities live in the cloud, alongside your cloud applications and services, either independently or as part of an integration with an on-premises AD DS environment. Along with the identities, premium features expand the capabilities of Azure AD.

Design Azure AD identities

Microsoft Azure AD has three defined identities you can use. The use of identity in this way refers to a user account that you can use to authenticate to applications and services. These identity types are often referred to as integration scenarios in Microsoft documentation. The three identities are:

• Cloud identity A cloud identity is any user account that you have created in Azure AD (often for a cloud-based application). For the purposes of this exam, a cloud identity is an Azure AD user account. You create and maintain these accounts in the cloud. Cloud identities are best suited for small organizations because when you manually create and maintain user accounts your administrative overhead increases. Large enterprise environments have a large number of users and should choose one of the other options to reduce the administrative overhead of managing identities.
• Synced identity A synced identity is a user account in an on-premises AD DS environment that is synced to Azure AD. The sync process requires a directory synchronization application such as Azure Active Directory Connect (Azure AD Connect). It is most common to sync users and password hashes. This allows Azure AD to authenticate users for cloud-based applications while AD DS authenticates users for on-premises applications.
• Federated identity A federated identity is an identity that is linked to an on-premises AD DS user account. Federated identities require a federation trust, which is an agreement between two organizations (such as your company and Microsoft) that establishes a federation where on-premises AD DS/Active Directory Federation Services (AD FS) establishes a federation trust with Microsoft Azure. When a user authenticates to an Azure-based resource, the authentication is routed back to the on-premises AD DS environment for handling.

From a design perspective, you need to consider several factors before you choose which identity is best suited for your environment. Compare the three identities across the key considerations in Table 1-1, which shows how the three identities rate from low to high in terms of administrative overhead, security, and complexity, and also rates overall user experience.

TABLE 1-1 Cloud identities and their distinguishing characteristics

Identity	Administrative overhead	Security	Complexity	User experience
Cloud identity	High	Medium	Low	Poor
Synced identity	Low	Medium-High	Medium	Good
Federated identity	Medium	High	High	Best

The rest of this section walks through the identities and includes diagrams to show which components are used in each identity scenario and how authentication works.

Cloud identity

You can use the cloud identity in a couple of different ways. First, you can use a cloud identity as the only identity a user has, as shown in Figure 1-1. This is often best suited for companies that solely use the cloud for all of their application and service needs. Every time users access an application or a service in the cloud, they enter their cloud identity username and password and authentication is performed in Azure AD. Figure 1-1 is a diagram of a simple cloud identity environment.

For larger companies and those that have an internal AD DS environment, you can use a cloud identity in addition to the on-premises identity. For such cases, users who access on-premises applications can authenticate with their AD DS credentials. When they access cloud-based applications, they authenticate with their Azure AD credentials. Figure 1-2 is a diagram of a cloud identity environment with AD DS being used on-premises.

The primary downside to using a cloud identity when you already have AD DS on-premises is that users have two user accounts. Each user account has its own password. Password policies might be different. Users have to deal with having two separate accounts (adhere to the password policies, update passwords based on maximum password age, and remember which account to use for specific scenarios). Often, the thought of having multiple accounts is enough to cause you to look at a synced identity instead, which you can consider when you review it in the next section.

Synced identity

A synced identity environment provides users with the benefit of using a single username and password to authenticate to applications, whether those applications are on-premises or in the cloud. You can accomplish this by installing and configuring Microsoft Azure Active Directory Connect (Azure AD Connect). Azure AD Connect synchronizes from an on-premises AD DS environment to Azure AD. In a synced identity environment, password hash syncing is the optional setting that is the key because it provides users with the benefit of using only one username and password.

Figure 1-3 shows a synced identity environment.

For companies that have AD DS on-premises, a synced identity environment provides a better user experience compared to a cloud identity environment. The downside is that authentication takes place in two different places. That complicates the auditing process and makes troubleshooting a bit more complex. Additionally, if a user is terminated and is disabled in the on-premises AD DS environment, it might take up to three hours before the user account is disabled in Azure AD. The three-hour delay is based on the default sync time of every three hours. You can run a sync on demand or configure your sync to occur more often to reduce the risk of disabled users still having some access through Azure AD after disablement.

Federated identity

A federated identity environment is an environment where all authentication is handled by the on-premises AD DS environment. It is the most complex environment because it requires the most components and requires the most planning. Figure 1-4 is a diagram of a federated identity environment.

In the federated identity environment shown in Figure 1-4, a company has an internal environment with AD DS, AD FS, Web Application Proxy servers, a web server, and a sync server. In Microsoft Azure, the company subscribes to Office 365 and has a web server in an Azure VM. Users are synced from AD DS to Azure AD but passwords are not synced. When a user authenticates to a resource in Azure, credentials are validated by the internal AD DS environment (first through the Web Application Proxy cluster, then through the AD FS servers, then to AD DS). For companies that have a security or compliance policies that mandate that all authentication is handled by their on-premises AD DS environment, you should consider a federated identity environment. Hybrid environments, where a company has some resources on-premises and some resources in the cloud, are also good candidates for a federated identity environment. One key security benefit of using federated identities is that you can immediately disable a user and all access is immediately revoked. The primary downside of using federated identities is that the overall environment is complex and requires more cost and administrative overhead.

From an exam perspective, you need to be able to distinguish the characteristics between the identities. You might be presented with a scenario and a single fact in the scenario might disqualify one design option. For example, a scenario might be presented where a company does not have a perimeter network and they do not allow direct Internet communication between computers on the local area network (LAN) and computers on the Internet. In that case, identities that require syncing or federation would be disqualified, because those solutions require a sync through the Internet. Administrative overhead is a common trait that you need to distinguish between the identity solutions. In a scenario where a company’s IT department is overworked and understaffed, introducing a federated identity might not be optimal without considering the impact on the IT department resources.

Take a look at one more scenario. A company is planning to subscribe to several cloud-based applications. The company wants to maximize the user experience. The scenario might end there and you might be asked to choose one of the listed solutions. Providing single sign-on is probably the answer. But the solution might not present that information or say that directly. It might say something about using federated identities or something similar. Or, the scenario could offer some constraints such as reducing the complexity while also maximizing the user experience (seemingly conflicting goals). The answer might be to use synced identities. By knowing the pros and cons of the identity solution, you are prepared to answer scenario questions such as these on the exam.

Each of the identity solutions has some prerequisites. While some of that information was mentioned at a high level earlier in this section, the following list documents all of the high-level prerequisites for the solutions.

• Cloud identity The cloud identity has the least amount of prerequisites. Thus, it is often the quickest and easiest to use, especially for initial testing and proof of concept (PoC) work. The only prerequisite is having a Microsoft Azure subscription, Azure AD, and an administrative account to create and manage identities.

• Synced identity You need to meet the following prerequisites to use synced identities:

  • On-premises AD DS environment. This is the source of the sync.
  • Synchronization. Azure AD Connect is the free software that Microsoft makes to handle syncing an on-premises AD DS environment with Azure AD. You need to have it running and syncing with Azure AD.
  • Microsoft Azure subscription, Azure AD, and administrative account. While this can often be assumed, watch for scenarios that don’t call it out and answer choices that call out purchasing a subscription.

• Federated identity You need to have the following prerequisites to use federated identities:

  • On-premises AD DS environment. This is the service that authenticates users.
  • Synchronization. Azure AD Connect is the free software that Microsoft makes to handle syncing an on-premises AD DS environment with Azure AD. You need to have it running and syncing with Azure AD.
  • AD FS servers on the LAN. These are the servers that help handle the authentication. The proxy servers communicate with these servers. By having proxy servers in the perimeter network, you avoid having to expose your AD FS servers to the Internet.
  • Web Application Proxy in the perimeter network (optional but a good practice). Beware of answers that call out AD FS proxy servers in the perimeter network, especially if one answer calls out AD FS proxy server and another calls out Web Application Proxy. The Web Application Proxy is the new name for an AD FS proxy. The AD FS proxy technology is still valid, but for older server operating systems such as Windows 2012 and older. The Web Application Proxy was first introduced with Windows Server 2012 R2.
  • Microsoft Azure subscription, Azure AD, and administrative account.
  • Federation trust with Microsoft Federation Gateway (MFG).

Active Directory integration

Integrating your on-premises Active Directory environment with Azure enables you to use synced identities and federated identities. In addition, you can synchronize users and enable several other features such as password synchronization, password writeback, and more.

Review the reasons why you would integrate your on-premises AD DS environment with Microsoft Azure:

• You want to provide single sign-on (SSO) for users. Full SSO is achieved through the use of on-premises AD DS, AD FS, and federation. On the exam, pay close attention to the details so you know whether a question is referring to federation or synced identities.
• You want users to use the same username and password for on-premises and cloud applications. This is another form of SSO. While users use the same username and password, the user accounts are actually separate – one in AD DS and one in Azure AD. They are synced. Users sometimes can’t distinguish between this and federation-based SSO because they use the same username and password.
• You want all cloud-based authentication to be handled by your on-premises AD DS. Because you reviewed the federated identity earlier in this chapter, you already know how on-premises AD DS handles the authentication. For the exam, an answer could be Integrate Active Directory with Azure AD and never mention the type of identity being used. Thus, you need to know the benefits of integration, outside of just the identity solution.
• You want to simplify the provisioning process. When new employees start at a company, the process to get all of the IT systems ready for them is often called “onboarding”. When employees leave a company, the process to remove them from the IT systems is often called “off boarding”. As companies begin to use cloud-based applications, onboarding and off boarding becomes more complex. Automating the processes becomes more challenging. And this is often the point at which administrators begin realizing that they need a simpler way to handle it. Integrating AD DS with Azure AD is the start of that simplification because you can reduce the number of identities for a user, reduce the amount of applications that you have to configure, and reduce the administrative time required to maintain all of the systems and processes.

Besides knowing about the benefits of integration, you should also understand the differences between the versions of Azure AD and the features that you can use for the Azure AD you have selected. Azure AD offers three versions: Free, Basic, and Premium.

For this section, we’ll focus on the integration features. We’ll also call out differences between the versions in other sections, where applicable.

In the following section, the three Azure AD versions are shown along with the features that are supported for each.

• Features supported by all three versions With all three versions, you get directory as a service, user and group management using the UI or Windows PowerShell cmdlets, device registration, Access Panel portal for SSO-based user access to SaaS and custom applications, self-service password change for cloud users, Azure AD Connect, standard security reports, B2B collaboration (cross-organization collaboration).
• Features supported by Basic and Premium only With Basic or Premium, you get customization of company logo and colors to the Sign In and Access Panel pages, self-service password reset for cloud users, Application Proxy: Secure Remote Access and SSO to on-premises web applications, group-based application access management and provisioning, high availability SLA uptime (99.9 percent).
• Features supported only by Premium With Premium, you get advanced application usage reporting, self-service group management for cloud users, self-service password reset with on-premises writeback, Microsoft Identity Manager (MIM) user licenses–for on-premises identity and access management, advanced anomaly security reports machine learning-based, cloud app discovery, Multi-Factor Authentication service for cloud users, Multi-Factor Authentication server for on-premises users, Azure Active Directory Connect Health to monitor the health of on-premises Active Directory infrastructure and getting usage statistics.

Office 365 licenses enable some features too, but that is beyond the scope of this exam and book.

Azure Multi-Factor Authentication

On October 4, 2012, Microsoft announced that it had purchased a company named Phone-Factor, which specializes in two-factor authentication. Ultimately, the purchase enabled Microsoft to offer Azure MFA, a service that enables you to require multiple authentication factors when users authenticate to an application or service. Figure 1-5 shows the high-level process flow for Azure MFA.

You need to know a couple of key points about the process flow:

• The multi-factor authentication process starts after a user successfully authenticates (most often by username/password).
• The multi-factor authentication is only initiated for users that are configured for Azure MFA.

Azure MFA is a cloud service run by Microsoft in the Azure public cloud. In the simplest configuration, you just enable users to use Azure MFA. In a more complex configuration, you configure on-premises Azure MFA servers and provide multi-factor authentication for your Azure resources and your on-premises resources. Figure 1-6 shows how the service works in a common scenario.

The following steps describe the steps shown in Figure 1-6.

1. In Step 1, a user is connected to the corporate network by using a VPN. The user initiates a connection to the MFA server by using Remote Desktop Connection. The MFA server is configured to perform multi-factor authentication on terminal services connections.
2. In Step 2, the MFA server validates the user’s AD DS credentials with the on-premises AD DS domain. If successful, then the multi-factor authentication tasks begin. If unsuccessful, the user might authenticate again until successful or until the connection is ended.
3. In Step 3, the MFA server communicates with the Azure MFA service over TCP port 443 and requests that the service perform the two-factor authentication.
4. In Step 4, the Azure MFA service performs the two-factor authentication process based on the user’s configuration. For example, if the user is configured for a phone call, then Azure MFA calls the user’s configured phone number.
5. In Step 5, the user receives notification (phone call, text message, or app notification) that they need to confirm the authentication request. The user must respond to the notification, which varies based on the configuration. For example, by default a phone call from the Azure MFA service requires that the user press the pound (#) key to confirm the authentication.
6. In Step 6, after a successful response from the user in Step 5, the Azure MFA service notifies the on-premises MFA server that the authentication was successful. The MFA server confirms the authentication and the Remote Desktop Connection session begins.

An authentication factor is a form of authentication. One factor is a username and password. Another factor is an app on a smartphone. Azure MFA supports multiple authentication factors, as shown in a typical user’s configuration page in Figure 1-7.

A username and password aren’t shown as one of the factors when configuring Azure MFA because the username and password are authenticated prior to Azure MFA’s second factor authentication. The factors that Azure MFA supports are:

• Phone call You can have Azure MFA call any phone number, including a land line and smartphone. After you answer the call, you press the pound (#) key to complete the authentication. Optionally, you can configure Azure MFA to require a PIN instead of the pound key.
• Text message You can have a text message sent to a smartphone. Upon receiving the message, you have to send a text message back with the code provided in the received message. That completes the authentication.
• Smartphone app Microsoft provides a free smartphone app named Azure Authenticator. Upon authentication, the app notifies you that an authentication request needs to be verified. You tap the Verify button in the app and that completes the multi-factor authentication process.
• OATH token An OATH token is an access token issued by a third-party that provides another authentication factor in a multi-factor authentication scenario. The term OATH and OAUTH mean the same thing. While OAUTH is the most popular term for this open authentication solution, Azure’s MFA uses the term OATH in spots in the application. To use OATH tokens with Azure MFA, you need to add the tokens to the MFA server or import them to the MFA server. Then, each token is associated with a user. To use them, each user must be configured to use OATH.

Now that you have an overview of the authentication methods that Azure MFA supports, take a look at some import information for the exam:

• App passwords may be required Some versions of Outlook, Lync, and some other non-browser based apps that require authentication do not support native multi-factor authentication. For those apps, you must generate and use app passwords, which are passwords generated for each app that take the place of a second factor authentication method. You can generate a password for an app or for a device. When you generate a password for a device, it can be used for all apps on that device that do not support Azure MFA. As an administrator, you can clear out all app passwords for a user, which is useful when troubleshooting. Note the limit of 40 app passwords per user.
• Self-service setup Users can choose their preferred second-factor authentication method–phone call, text message, or smartphone app. And, they can perform some of their own account management from the Azure Access Panel, which is a topic covered in the next section.
• Azure MFA requires Azure AD Premium or the Enterprise Mobility Suite You must have Azure AD Premium or the Azure Mobility Suite to take advantage of Azure MFA for cloud users or on-premises users. The only exception is users with an Office 365 subscription. Office 365 comes with Azure MFA but only for Office 365 services (whereas you can use Azure MFA, when it comes with Azure AD Premium, across a wide variety of services in the cloud and on-premises).

• You can choose between two usage models Azure MFA offers two usage models. It is important to know about these because generally, you choose a model in the architecture and planning phase of a project. The two usage models are:

  • Per authentication In this model, you are charged for every ten authentications that occur over Azure MFA. This model makes sense if your users are authenticating occasionally and you have a large number of users. The breakeven point, in the current pricing model, is 10 authentications per month. If your users authenticate with Azure MFA 10 or less times per month, then the per authentication usage model is the most cost effective.
  • Per enabled user In this model, you are charged a flat rate for every user enabled for Azure MFA, no matter how many authentications they have over Azure MFA. This model makes sense if your users perform authentications often and the total number of users is not large. The breakeven point, in the current pricing model, is 10 authentications per month. If users authenticate more than that, then you can save money by choosing the per-enabled usage model.
• A subset of Azure MFA is available just for administrators, for free If you haven’t provisioned Azure MFA for directory users, a subset of Azure MFA is available for free for Azure Global Administrators.

User self-service from the Azure Access Panel

Users can go to the Azure Access Panel at https://myapps.microsoft.com to access applications and perform self-service tasks such as resetting their password and updating their contact information. Before users can do that, however, you need to enable the option to allow users to reset their own password and choose the methods that they can use. Figure 1-8 shows the portion of the Azure AD Configure tab with the applicable settings.

After users are configured for multi-factor authentication, you will occasionally perform additional management tasks. One common task is to force users to provide their updated contact methods for multi-factor authentication. This is handy when users have updated phone numbers because they can perform the updates themselves, without having to involve IT. When you view your Azure AD from the Azure portal, there is a link to manage multi-factor auth. A separate web page opens where you can manage users (enable/disable) and manage user settings (one of which requires users to verify their contact information the next time that they sign in to an Azure portal). The setting to require users to verify their contact information is shown in Figure 1-9.

When a user is configured to have to verify their contact information, they see a prompt during their next sign-in. If they choose to perform the verification during that sign-in, they’ll see a web page similar to the page in Figure 1-10.

From an exam perspective, know that self-service reduces IT administrative overhead (and thus overall costs). It improves the user experience by empowering users and allowing them to take care of some of their own account management tasks without resorting to calling the Helpdesk or putting in a trouble ticket. In environments where the IT department is understaffed, self-service would be helpful. You can review more about self-service, especially around group management, later in this chapter.

Azure AD reporting

Azure AD has a number of built-in reports. Table 1-2 shows the available anomalous activity reports and which version of Azure AD you need to have to access the reports.

TABLE 1-2 Azure anomalous activity reports

Report name	Azure Description	Supported Azure AD versions
Sign ins from unknown sources	Might indicate an attempt to sign in without being traced	Free/basic/premium
Signs ins after multiple failures	Might indicate a successful brute force attack	Free/basic/premium
Sign ins from multiple geographies	Might indicate that multiple users are signing in with the same account	Free/basic/premium
Sign ins from IP addresses with suspicious activity	Might indicate a successful sign in after a sustained intrusion attempt	Premium only
Sign ins from possibly infected devices	Might indicate an attempt to sign in from possibly infected devices	Premium only
Irregular sign in activity	Might indicate event anomalous to users’ sign in patterns	Premium only
Users with leaked credentials	Users with leaked credentials.	Premium only
Users with threatened credentials	Users with threatened credentials	Premium only

Table 1-3, shows the available activity log reports and which version of Azure AD you need to have to access the reports.

TABLE 1-3 Azure activity log reports

Report name	Azure Description	Supported Azure AD versions
Audit report	Audited events in your directory	Free/basic/premium
Password reset activity	Provides a detailed view of password resets that occur in your organization	Premium only
Password reset registration activity	Provides a detailed view of password reset registrations that occur in your organization	Premium only
Self service groups activity	Provides an activity log to all group self-service activity in your directory	Premium only

Table 1-4 shows the available integrated applications reports and which version of Azure AD you need to have to access the reports.

TABLE 1-4 Azure integrated applications reports

Report name	Azure Description	Supported Azure AD versions
Application usage	Provides a usage summary for all SaaS applications integrated with your directory	Premium only
Account provisioning activity	Provides a history of attempts to provision accounts to external applications	Free/basic/premium
Password rollover status	Provides a detailed overview of automatic password rollover status of SaaS applications	Premium only
Account provisioning errors	Indicates an impact to users’ access to external applications	Free/basic/premium

You can run reports on demand and save reports to .CSV format. From a management perspective, there isn’t much to it. From a design consideration perspective, the key item to focus on is the Azure AD version. As an administrator, you need to know your organization’s requirements, especially around security, to figure out whether Azure AD Premium is necessary to meet the requirements.

Company branding

One of the initial downsides to moving to the cloud is the loss of your company identity in some of the tools and portals. The familiar designs, logos, and associated branding material are not part of a default cloud configuration for most applications. Luckily, Azure offers some customizations. You can customize the following elements for your Sign-In page and Access Panel page:

• Banner logo The size should be a maximum of 60x300. To maximize performance, the graphics file should be between 5 KB and 10 KB in size. This logo can be reduced in size for smaller displays, such as those of a smartphone.
• Square logo The square logo can have dimensions up to 240x240. It is used to represent user accounts in various parts of the portals. It should be between 5 KB and 10 KB in size to maximize performance.
• Square logo, dark theme The dark theme square logo takes the place of the square logo in certain situations such as when a Windows 10 device is joined to Azure AD. If your logo already looks good in a dark colored theme, you do not have to use a dark themed square logo. Instead, use your square logo.
• User ID placeholder On the Sign-In page, the default text in the email address text box shows the email address of someone@example.com. Instead, you can opt to use your domain’s email syntax such as first.last@tailspintoys.com. This can be helpful to users, especially when users are still new to Azure.
• Sign-In page text heading You can customize the text that is displayed above your customized Sign-In page text.
• Sign-In page text This is the text shown near the bottom of the sign-in page. It can be up to 500 characters long and is mostly used to give users instructions on who to contact or how to obtain help.
• Sign-In page illustration This is the graphic that is displayed on the left side of the sign-in page. The recommended resolution is 1420 by 1200. The maximum size of the file is 500 KB. The graphic can be reduced in size for smaller displays.
• Sign-In page background color If users have a high-latency connection, the sign-in page illustration might not load. In such cases, use the specified background color. You can match the color with your company color, if desired. You must use an RGB color code to specify the color.
• Hide KMSI This option enables you to hide the Keep Me Signed In check box on the Sign-In page. By default, KMSI is displayed to users.
• Post logout link label After users log out of an Azure AD web application, you can display a label (along with a corresponding URL).
• Post logout link URL After users log out of an Azure AD web application, you can display a URL (along with a corresponding label).

Beyond customizing these elements, you can also have a customized Sign-In page based on the language. For example, for Spanish language users, you can set your customized text to Spanish and use a different sign-in page illustration.

In Figure 1-11, a customized Sign-In page for Tailspin Toys is shown. The figure shows where the Sign-In page illustration is, where the banner logo is, where the user ID placeholder is, and where the Sign-In page text is.

To customize your Sign-In and Access Panel pages, perform the following high-level steps.

1. Sign in to the Azure portal. Navigate to Active Directory. Click the Configure tab in the top pane. Then click the Customizing Branding button, as shown in Figure 1-12. If you don’t see the button, it might be because you do not have Azure Active Directory Premium.

   

   FIGURE 1-12 A properties page with the Customize Branding button

2. On the Customize Branding page, click the right arrow button in the lower-right corner.

3. On the Customize Default Branding page (page 2), browse for logo files and update the desired text. In Figure 1-13, an administrator at Tailspin Toys is using tt-logo4.jpg as the banner logo and has updated the text. When finished, click the right arrow.

   

   FIGURE 1-13 The customization options available for the Sign-In and Access Panel pages

4. On the Customize Default Branding page (page 3), browse for the Sign-In page illustration file, type an RGB value for a background color, set the KMSI behavior, and add logout URLs, if desired. Figure 1-14 shows the page. An administrator at Tailspin Toys is planning to use Toys.jpg as the Sign-In page illustration. When finished, click the check mark to save the changes.

   

   FIGURE 1-14 The customization options available for the Sign-In and Access Panel pages

After you customize your Sign-In and Access Panel page, it can take up to 1 hour for the changes to be visible on the pages. Thereafter, you can go back anytime and perform additional customizations.

Look at some important information about customization for the exam:

• Customization requires Azure AD Basic or Azure AD Premium You cannot customize your Sign-In or Access Panel pages with the Free version of Azure AD. An exception is that Office 365 also enables customization.
• Customization improves the user experience In scenarios where the user experience is an important design consideration, think about customization because it helps users become comfortable with a solution more quickly, which often leads to more successful migration projects.
• To maximize the customizations across devices, you must test Your customized pages might be viewed on high-resolution monitors, outdated smartphones with small screens, and tablet computers. To ensure that your customizations work well across all of those scenarios, you need to test the customizations across a variety of devices, operating systems, and platforms. Based on the testing, you can make minor adjustments to the graphics files and text to enhance the look and feel across all of the devices.

Design Azure AD Premium features

Some of the most advanced features of Azure AD are only available with the Azure AD Premium. For the exam, you should be familiar with the features that come with Azure AD Premium. While you have reviewed Azure MFA, you need to review the rest of the Premium features as well. Also note that the customizations discussed in the previous section are a feature of the Basic and Premium versions of Azure AD (and thus already covered). The Premium features you have yet to review in detail yet are:

• Advanced application usage reporting The advanced usage reporting feature brings new advanced reports to customers. The list of the reports is shown in Table 1-2, Table 1-3, and Table 1-4.
• Self-service group management for cloud users This feature gives cloud users (users with a cloud identity) a way to create and manage cloud-based security groups. The users use a web portal to create and manage groups and the groups can be used for application access.
• Self-service password reset with on-premises writeback Self-service password reset is one feature and it comes with the Basic and Premium versions of Azure AD. The on-premises writeback feature of self-service password reset comes only with the Premium version of Azure AD. It enables users to reset their on-premises password and their cloud identity password, or both, from the Azure portal.
• Microsoft Identity Manager (MIM) user licenses These MIM user licenses can be used with on-premises identity and access management solutions. MIM offers a self-service portal for users, group management, and some automated provisioning and deprovisioning.
• Advanced anomaly security reports (machine learning-based) The advanced reports are focused on security, such as authentications from possibly infected hosts. See Table 1-2, Table 1-3, and Table 1-4 for a list of the reports.
• Cloud app discovery This feature uses client computer agents to look for cloud apps in use. It works for cloud apps that are communicated with only over HTTP and HTTPS. You can run reports to find out things such as which apps are the most widely used, how many apps are being used, and whether or not the apps are integrated with Azure AD.
• Azure Active Directory Connect Health This feature monitors the health of your directory environment including Active Directory Federation Services (AD FS), AD DS (on-premises), and Azure Active Directory Connect (the sync). You can quickly ascertain if the environment is healthy. The next section of this chapter offers details about this feature.

Advanced application usage reporting

As outlined in Table 1-2, Table 1-3, and Table 1-4, the Premium version of Azure AD offers some advanced application usage reporting. You can run reports from the Azure portal. Figure 1-15 displays the application usage report.

Figure 1-16 shows the output of the irregular sign in activity report. For this report, one user is shown as having irregular sign in activity.

In Figure 1-16, note the small text that indicates that sign-ins up until a certain date and time have been processed. Most of these reports are not in real time. They are often up to 12 hours behind real time. If you run a report and expect to see an entry but don’t, check the date and time that the report indicates to see if the activity hasn’t been processed yet.

Another premium report is the password reset registration activity report. This report, shown in Figure 1-17, displays activity related to users registering for self-service password reset such as registering a phone number.

Besides just viewing reports, you can download individual reports to .CSV format. When viewing a report, the bottom of the web page has a Download button. You can also configure Azure AD to send email (or not send email) notifications of anomalous sign-ins. This option emails global administrators when there have been 10 anomalous sign-ins (or more) within a 30day window. The option to email the anomalous sign-in activity is enabled by default. At the time of this writing, you cannot configure which email addresses are notified (currently, the global administrators’ primary and secondary email address are notified) and you cannot email notifications for any other reports.

Self-service group management for cloud users

Self-service group management enables users to create, manage, and delete groups. Owners of a group can perform the following tasks:

• Add members The owner of a group can add group members to the group. Members can be Azure users or synced users.
• Edit the group By editing the group, the owner can change the display name, the description, and the approval (whether joining a group requires owner approval or not).
• Set the owners of the group The owner of a group has rights to manage the group. You can set one owner or multiple owners. Only groups that you own are displayed in the Azure Access Panel.
• Leave the group If the group is configured to allow people to join it without approval, you can opt to leave a group.
• Delete the group Deleting a group renders the group unusable and all permissions are revoked at the deletion time.

For the exam, it is important to know what you can do with self-service group management. But it is even more important to understand the design considerations for self-service group management. First, self-service group management is not enabled by default. You can enable and configure self-service group management on the Configure tab of Azure AD. The configuration options are shown in Figure 1-18.

Look at some of the design considerations for self-service group management.

• Group management becomes decentralized In traditional environments without self-service group management, the IT team creates and maintains groups. Often, a naming standard is used for groups so that users can identify the purpose of a group. Additionally, groups are often stored together in an OU for easy delegation to other administrators or managers. With self-service, group management becomes decentralized. In such cases, naming conventions are difficult to enforce. Sometimes, multiple users decide to create a group to do the same thing without realizing that they are creating duplicate groups. Eventually, organizations sometimes end up with a very large number of groups. This is sometimes referred to as “group sprawl.” To minimize the risk of these things, you can limit some of the self-service to subsets of users instead of all users.
• IT administrative overhead is reduced Reducing IT administrative overhead is an important consideration. Organizations are focusing on having IT work on value-added activities such as deploying solutions that impact sales and profitability. Managing groups is a repetitive task that often keeps IT resources away from the value-added activities. Self-service, in general, is a good way to reduce administrative overhead and get more value from IT. Self-service groups is a good way to start.
• There is added complexity in a hybrid environment In organizations that have an on-premises AD DS environment and Azure AD, you manage groups on-premises and in Azure. While self-service helps with Azure AD groups, you have to use a separate self-service solution on-premises or rely on IT to perform all on-premises group management. If an organization also has Office 365, it increases complexity. Users might require extra education about managing groups and the IT team might have to spend more time on group management than they would in a less complex environment (such as one that only existed in Azure). To minimize the chances of a complex group management environment, you can move all your groups to Azure AD and use self-service management. You can also disable self-service group management until you move all the groups to Azure AD.

Once you enable self-service group management, you can use the Access Panel to create new groups, view groups that you own, and manage groups that you own. Figure 1-19 shows the view in the Access Panel. In this example, you own three groups.

You can get a high-level overview of a group by clicking the group, as shown in Figure 1-20.

Besides merely viewing the high-level information about the group, the user also has buttons to perform the management actions discussed earlier in the section (add members, edit, set owners, leave group, delete group), as shown in Figure 1-21.

Now that we have covered the self-service group management feature, take a look at another self-service feature, but this time for password resets.

Self-service password reset with on-premises writeback

Earlier in this chapter, you reviewed the self-service password reset feature. In this section, it is time to specifically discuss the on-premises writeback enhancement. The Password Writeback feature syncs password resets performed in the cloud with your on-premises AD DS, if the user account is a synced account. Based on that description, you can probably infer that you need an on-premises AD DS environment syncing to Azure AD in order to take advantage of this feature. And you would be right! In addition, you must configure your Azure AD Connect for password writeback and your Azure AD for password writeback.

First, take a look at the Azure AD Connect password writeback configuration. In Figure 1-22, the Azure AD Connect configuration is shown. The Password Hash Synchronization and the Password Writeback features are enabled.

Next, look at the Azure portal configuration for password writeback. Figure 1-23 shows the option to enable writeback. Notice that the Password Writeback Service Status shows as Configured. This is required to have writeback functionality and is a good indication that everything is configured correctly and functional for the on-premises configuration and the Azure configuration. If the writeback status is set to something other than Configured, there is likely a configuration issue in the environment.

Microsoft Identity Manager (MIM) user licenses

MIM is the Microsoft flagship identity management product that provides identity management and self-service features for your on-premises environment. One of the benefits of Azure AD Premium is that you get user licenses for MIM. For hybrid environments, this allows you to use self-service in Azure and MIM for self-service for on-premises. For the exam, you need to be aware of scenarios that are presented where MIM could be a key solution to a requirement or problem, such as the following scenarios:

• You have multiple directories on-premises. MIM can synchronize your internal directories. This enables you to sync a single forest to Azure AD. Or, if your users are located in a directory other than AD DS, MIM can sync users and groups to AD DS, which enables you to sync users to Azure AD.
• You want to provide privileged identity management to employees. MIM offers privileged identity management, which enables you to provide temporary administrative access to resources and control administrative access with granularity.
• You want to provide users with self-service group management in the cloud and on-premises. While Azure AD offers self-service group management as a feature, it is for groups in Azure AD. You can opt to use group writeback to bring those groups back to AD DS. Or, you can use MIM to provide self-service group management for your on-premises AD DS environment.

Advanced anomaly security reports (machine learning-based)

Earlier in this chapter, you reviewed the lists of all of the reports, including the advanced anomaly security reports. You also looked at the actions you can perform as an administrator such as running reports and saving reports to .CSV. From the exam perspective, the most important thing to know is the additional reports that you get with Azure AD Premium:

• Sign ins from IP addresses with suspicious activity
• Sign ins from possibly infected devices
• Irregular sign-in activity
• Users with leaked credentials
• Users with threatened credentials

Cloud app discovery

The cloud app discovery technology finds apps that users are using on the Internet and tracks the total number of users and the total amount of activity (amount of data transferred, files upload, files downloaded, and a few other data points). The information is made available in report form in the Azure portal under Cloud App Discovery. The following two components make up this technology:

• Azure Cloud App Discovery You can add the app for free as part of Azure AD Premium. Once added, you can view application usage reports and set up apps with Azure AD integration.
• Cloud App Discovery endpoint agent To discover apps, you need to need the Cloud App Discovery endpoint agent on your users’ computers. The app listens for HTTP and HTTPS connections (whether in a browser or in an app) and logs the details of the connections for report data. The information captured includes the IP address, the destination URL, the username, and information about the connectivity (data transferred and similar).

The promise of cloud app discovery is the centralization of user identities. Today, many organizations’ users have multiple identities–one or more on-premises identities, an Azure cloud identity, and many cloud-based app identities. Managing those identities is a challenge, especially when IT manages some of them and the user manages the rest of them. To add to the challenge, users are often using their own devices for work-related activities. So work identities and personal identities are comingling and the lines between them are becoming blurred. To reduce the associated challenges, you can centralize identities to Azure AD. It starts with syncing and/or federating with Azure. But to take full advantage of the benefits, you need deeper integration, of which the use of cloud app discovery is one part. Integrating as many of the apps into Azure AD as possible reduces the overhead of identity management and strengthens the overall security of your environment by reducing the reliance on so many identities.

After you begin using cloud app discovery and gather some data from endpoint agents, you can view activity in the Azure portal. Figure 1-24 shows the apps discovered by agents. Once apps are integrated with Azure AD, they show a status of Managed. Apps that were discovered but have not been integrated with Azure AD show a status of Unmanaged.

Now that you have reviewed what cloud app discovery does, walk through the process of integrating an application with Azure AD. First, you have to add the app. From the Azure AD Applications tab in the Azure portal, click the Add button at the bottom of the page. That opens a window asking you the type of app that you want to add, as shown in Figure 1-25.

For this walk-through, you need to choose an app from the Azure gallery. At the time of this writing, the gallery contains 2,527 apps. In the gallery, click Microsoft Developer Network (MSDN), as shown in Figure 1-26. After selecting MSDN, click a check mark to complete the process (the check mark is not shown in Figure 1-26).

After an app is added, it is displayed in the apps list and is ready to be configured, as shown in Figure 1-27.

To configure the app for single sign-on, click the Configure Single Sign-On Button. A window displays showing the following three options:

• Federated Single Sign-On This option is only displayed if you have federation with Azure already configured. If you don’t have federation, this option is not displayed.
• Password Single Sign-On This option enables users to store account credentials in Azure. For example, they would input their MSDN username and password into the Access Panel app and the credentials would be saved. An administrator can also enter the credentials on a user’s behalf although this isn’t as common of a method unless you are working with shared accounts or do not want users to know the password to an account. Password single sign-on requires a browser plug-in/add-on.
• Existing Single Sign-On This option requires an existing SSO solution such as AD FS. If you have such a solution, then you should consider this option.

After you choose the SSO method, you must assign users to the application. If you don’t assign users, they cannot use the Access Panel to go to the app. The steps to assign the application to a user are:

1. Click the Assign Accounts button.
2. At the top of the page, click the dropdown menu next to Show, click All Users, and then click the check mark on the right. This displays all of your user accounts.
3. Click the user that you want to assign the app to and click the Assign button at the bottom of the page.
4. In the Assign Users window, click the check mark. Optionally, you can click the option to enter credentials and then enter the credentials.

Summary

• You can use three identities with Azure: a cloud identity is an identity that is created and maintained in Azure AD. It is best suited for small organizations or organizations that have all of their services in the cloud. A synced identity is an identity that is synchronized from an on-premises AD DS environment to Azure AD. Password hashes are synced and a user with a synced identity can be authenticated by AD DS for on-premises resources or by Azure AD for cloud-based resources. A federated identity is an identity that is synchronized from an on-premises AD DS environment to Azure AD. Password hashes are not synced and all user authentication is handled by the on-premises AD DS environment.
• With Azure AD Premium, you get additional features including advanced application usage reporting, self-service group management for cloud users, self-service password reset with on-premises writeback, Microsoft Identity Manager (MIM) user licenses–for on-premises identity and access management, advanced anomaly security reports (machine learning-based), cloud app discovery, Multi-Factor Authentication service for cloud users, Multi-Factor Authentication server for on-premises users, Azure Active Directory Connect Health to monitor the health of on-premises Active Directory infrastructure and getting usage statistics.
• Azure MFA is a cloud-based multi-factor authentication service that enables you to require multiple authentication factors when authenticating to some cloud-based resources or some on-premises resources. Azure MFA supports a phone call, a TXT message, a smartphone app verification, or an OATH token as a second factor of authentication. You need to run an on-premises Azure MFA server to protect on-premises resources with multi-factor authentication.
• Users can go to the Azure Access Panel at myapps.microsoft.com to access applications and perform self-service tasks such as resetting their password, going to apps by using SSO, and updating their contact information.
• Azure AD offers built-in reporting to report on directory related activities such as sign-ins, password resets, and use of integrated applications. Some reports are only available with Azure AD Premium such as the password reset activity report and the self-service groups activity report. You should know which reports are only offered as part of Azure AD Premium.
• If you have Azure AD Premium, you can customize the look of the Azure Sign-In page (full-featured customization) and Access Panel page (limited customization). You can customize the banner, logo, user ID placeholder, text heading, help text, the graphic on the Sign-In page, and the logout text and URL.
• You can integrate SaaS applications with your Azure AD to enable SSO for users. Users subsequently add integrated applications to their Access Panel pages, which provide users with quick links to go to the applications. When you integrate applications with Azure AD, you can have your SaaS username and password saved and automatically entered when you visit the application page, or you can rely on federation or a third-party identity provider such as OKTA.