• Introduction
• Describe the different authentication methods of Azure AD
• Describe Multi-factor authentication in Azure AD
• Describe Windows Hello
• Describe self-service password reset in Azure AD
• Describe password protection & management capabilities of Azure AD
• Knowledge check
• Summary and resources

Introduction

In this lesson, you will learn about the authentication capabilities of Azure AD. Authentication is the process of verifying an identity to be legitimate. Passwords are commonly used to authenticate users, but they have many problems. Passwords are difficult for users to remember, and easy for hackers to guess. Because good passwords are necessarily difficult to remember, users often use the same password for multiple applications, providing multiple points of entry for a compromised identity.

In this lesson you will learn about multi-factor authentication, and how it improves security. You will also learn about the password protection and management capabilities of Azure AD.

After completing this lesson, you will be able to:

• Describe the authentication methods of Azure AD.

• Describe the password protection and management capabilities of Azure AD.

Describe the different authentication methods of Azure AD

Legacy applications have relied on a single form of authentication, most often a password. However, passwords are problematic for users, and easily compromised. Multi-factor authentication (MFA) requires more than one form of verification to prove that an identity is legitimate, such as a trusted device or a fingerprint scan. That means that even when an identity’s password has been compromised, a hacker cannot gain entry to a resource.

Multi-factor authentication dramatically improves the security of an identity, whilst still being simple for users. The additional authentication factor must be something that is difficult for an attacker to obtain or duplicate.

To learn more about the problem with passwords, and why multi-factor authentication is so important watch The new sign-in standard: Passwordless authentication.

Azure Active Directory Multi-Factor Authentication works by requiring:

• Something you know – typically a password or PIN and

• Something you have – such as a trusted device that is not easily duplicated, like a phone or hardware key or

• Something you are - biometrics like a fingerprint or face scan.

Multi-factor authentication verification prompts are configured to be part of the Azure AD sign-in event. Azure AD automatically requests and processes multi-factor authentication, without you making any changes to your applications or services. When a user signs in, they receive an MFA prompt, and can choose from one of the additional verification forms that they've registered.

An administrator can require certain verification methods, or the user can access their MyAccount to edit or add verification methods.

The following additional forms of verification can be used with Azure Active Directory multi-factor authentication:

• Microsoft Authenticator app

• SMS

• Voice call

• OATH Hardware token

Security defaults and MFA

Security defaults are a set of basic identity security mechanisms recommended by Microsoft. When enabled, these recommendations will be automatically enforced in your organization. The goal is to ensure that all organizations have a basic level of security enabled at no extra cost. These defaults enable some of the most common security features and controls, including:

• Enforcing Azure Active Directory Multi-Factor Authentication registration for all users

• Forcing Administrators to use Multi-Factor Authentication

• Requiring all users to perform Multi-Factor Authentication when needed

Security defaults are a great option for organizations that want to increase their security posture but don’t know where to start, or for organizations using the free tier of Azure AD licensing. Security defaults may not be appropriate for organizations with Azure AD premium licenses or more complex security requirements. To learn more, refer to What are security defaults?

Describe Multi-factor authentication in Azure AD

In the previous topic you learned about multi-factor authentication, and why it improves security. In this topic, we consider the different authentication methods that can be used with Azure AD multi-factor authentication.

Passwords

Passwords have many problems. If they're easy enough to remember, they're easy for a hacker to compromise. Strong passwords, which aren't easily hacked, are difficult to remember and have an impact on user productivity when forgotten.

Password and additional verification

With modern authentication and security features in Azure AD, passwords are supplemented or replaced with more secure authentication methods.

Phone

You can also use your phone as an additional means of authentication, configured for either phone calls or text message.

If you set up your additional security verification to receive a phone call, you'll receive a phone call from Microsoft asking you to press a key on your mobile device to verify your identity.

If you set up your additional security verification to receive a text message, you will be sent a code by text. You then enter the code to verify your identity.

Microsoft Authenticator app

The Microsoft Authenticator app is a phone app that allows you to securely verify your identity. The Authenticator app can be used to provide the additional authentication required for two-step or multi-factor authentication. Microsoft Authenticator can also be configured to use biometrics, such as a fingerprint or facial scan.

To use Microsoft Authenticator, you must download the phone app from the Microsoft store, and register your Microsoft account. Microsoft Authenticator is available for Android and iOS. When a user chooses Authenticator as their additional authentication method, a notification is pushed to the phone or tablet. if the notification is legitimate, the user selects Approve, otherwise, they select Deny.

OATH

OATH (Open Authentication) is an open standard that specifies how time-based one-time passwords (TOTP) codes are generated. One-time password codes can be used to authenticate a user. OATH TOTP can be implemented using either software or hardware to generate the codes.

Software OATH tokens are typically applications such as the Microsoft Authenticator app and other authenticator apps.

OATH TOTP hardware tokens typically come with a secret key, pre-programmed in the token, which must be input into Azure AD. Users are associated with a specific hardware token. The hardware token does a refresh of the code every 30 or 60 seconds.

Passwordless Authentication

Passwordless authentication is based on “something you are” rather than “something you know”. For example, a biometric facial scan used in Windows Hello for Business is an example of “something you are”. A fingerprint scan used by the Microsoft Authenticator app or a FIDO2 security device, is also “something you are”.

Passwordless authentication with Azure AD, such as with the Microsoft Authenticator app or FIDO keys, is particularly applicable for shared PCs and where a mobile phone isn't a viable option, such as for help desk personnel, public kiosk, or hospital team.

Biometrics

Biometric sign-in uses human characteristics, such as a hand, iris, face, or fingerprint. Windows Hello uses facial or fingerprint biometric data to authenticate a user. You'll learn more about Windows Hello in the next topic. The Microsoft Authenticator app can also be used in passwordless mode, using biometric data such as a fingerprint scan, or a facial scan.

FIDO2

FIDO is an abbreviation for Fast Identity Online, an alliance which promotes open authentication standards and aims to reduce the reliance on passwords as a form of authentication.

Azure AD supports FIDO2, a passwordless authentication method that can come in different forms. FIDO2 allows users to sign in using an external security key. The external key may be a USB device, lightning connector, Bluetooth, or NFC. In whichever form FIDO2 is implemented, the user never has to enter a password.

Users can also register and select a FIDO2 security key as their main means of authentication.

Describe Windows Hello

Windows Hello, an authentication feature built into Windows 10, replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or PIN.

Windows Hello lets users authenticate to:

• A Microsoft account.

• An Active Directory account.

• An Azure Active Directory (Azure AD) account.

• Identity Provider Services or Relying Party Services that support Fast ID Online (FIDO) v2.0 authentication (in preview)

After initial verification of the user during enrollment, Windows Hello is set up on the user's device and Windows asks the user to set a gesture, which can be a biometric, such as a fingerprint, or a PIN. The user provides the gesture to verify their identity. Windows then uses Windows Hello to authenticate users.

Windows stores PIN and biometric data securely on the local device; it's never sent to external devices or servers. That means there is no single collection point that an attacker might compromise.

There are two configurations for Windows Hello: Windows Hello and Windows Hello for Business.

• Windows Hello is configured by a user on their personal device and is referred to as Windows Hello for convenience PIN. Windows Hello convenience PIN is not backed by asymmetric (public/private key) or certificate-based authentication.

• Windows Hello for Business is configured by Group Policy or mobile device management (MDM) policy, such as Microsoft Intune. In addition, the PIN or biometric used with Windows Hello for Business is backed by key-based or certificate-based authentication, making it more secure than Windows Hello convenience PIN.

Why is Windows Hello safer than a password?

Windows Hello in Windows 10 enables users to sign in to their device using a PIN. Although a PIN looks much like a password, a Windows Hello PIN is more secure because it's tied to the specific device on which it was set up. Without the hardware, the PIN is useless.

A regular password is transmitted to a server where it can be intercepted in transmission or stolen from a server. A PIN is local to the device; it isn't transmitted anywhere, and it isn't stored on a server.

The Windows Hello PIN is backed by a Trusted Platform Module (TPM) chip, which is a secure crypto processor that is designed to carry out cryptographic operations. The chip includes multiple physical security mechanisms to make it tamper resistant, and malicious software is unable to tamper with the security functions of the TPM. Many mobiles phones and modern laptops have TPM.

Describe self-service password reset in Azure AD

Self-service password reset (SSPR) is a feature of Azure AD that allows users to change or reset their password, without administrator or help desk involvement.

If a user's account is locked or they forget their password, users can follow a prompt to reset their password and get back to work. Self-service password reset has several benefits:

• It increases security, as help desks add an additional security layer, which could be compromised.

• It saves the organization money by reducing the number of calls and requests to help desk staff.

• It increases productivity, allowing the user can get back to work faster.

Self-service password reset works in the following scenarios:

• Password change - when a user knows their password but wants to change it to something new.

• Password reset - when a user can't sign in, such as when they forgot password, and want to reset their password.

• Account unlock - when a user can't sign in because their account is locked out and want to unlock their account.

To use self-service password reset, users must be:

• Assigned an Azure AD license.

• Enabled for SSPR by an administrator.

• Registered, with the authentication methods they want to use. Two or more authentication methods are recommended in case one is unavailable.

The following authentication methods are available for SSPR:

• Mobile app notification

• Mobile app code

• Email

• Mobile phone

• Office phone

• Security questions

IMPORTANT: By default, administrator accounts are enabled for self-service password reset and are required to use two authentication methods to reset their password, such as an email address, authenticator app, or a phone number. Administrators don't have the ability to use security questions.

When a user resets their password using self-service password reset, that password can also be written back to an on-premises Active Directory. Password writeback allows users to use their updated credentials with on-premises devices and applications without a delay.

To keep users informed about account activity, admins can configure e-mail notifications to be sent when an SSPR event happens. These notifications can cover both regular user accounts and admin accounts. For admin accounts, this notification provides an additional layer of awareness when a privileged administrator account password is reset using SSPR. All global admins would be notified when SSPR is used on an admin account.

Interactive Guide

In this interactive guide, you'll enable self-service password reset for users in Azure Active Directory. Select the link below to get started.

Interactive guide - enable self-service password reset for users in Azure Active Directory.

Knowledge check

Multiple choice

Multiple choice

Multiple choice

• Introduction
• Describe conditional access in Azure AD
• Describe Azure AD roles
• Knowledge check
• Summary and resources

Introduction

One of the main purposes of Azure AD is to manage access. The security perimeter has shifted away from organizational boundaries to user, device, and service identities. In this module, you will learn how Azure AD uses intelligent access management capabilities to protect organizational assets. This lesson considers how conditional access helps you to improve security, and how to use Azure AD roles to control access to Azure AD resources in a directory.

After completing this lesson, you'll be able to:

• Describe Conditional Access and its benefits.

• Describe Azure AD roles.

Describe conditional access in Azure AD

Conditional Access is a feature of Azure AD that provides an additional layer of security before allowing authenticated users to access data or other assets. Conditional Access is implemented through policies that are created and managed in Azure AD. A Conditional Access policy analyses signals including user, location, device, application, and risk to automate decisions for authorizing access to resources (apps and data).

A conditional access policy might state that IF a user belongs to a certain group, then they're required to provide multi-factor authentication to sign in to an application.

Watch this video, Conditional Access, to see how Conditional Access policies work.

Conditional Access signals

Conditional Access can use the following signals to control the who, what, and where of the policy:

• User or group membership. Policies can be targeted to specific users and groups (including admin roles), giving administrators fine-grained control over access.

• Named location information. Named location information can be created using IP address ranges, then used when making policy decisions. Also, Administrators can opt to block or allow traffic from an entire countries IP range.

• Device. Users with devices of specific platforms or marked with a specific state can be used/

• Application. Users attempting to access specific applications can trigger different Conditional Access policies.

• Real-time sign in risk detection. Signals integration with Azure AD Identity Protection allows Conditional Access policies to identify risky sign-in behavior. Policies can then force users to perform password changes or multi-factor authentication to reduce their risk level or be blocked from access until an administrator takes manual action.

• Cloud apps or actions. Cloud apps or actions can include or exclude cloud applications or user actions that will be subject to the policy.

• User risk. For customers with access to Identity Protection, user risk can be evaluated as part of a Conditional Access policy. User risk represents the probability that a given identity or account is compromised. User risk can be configured for high, medium, low probability.

Access controls

Once the conditional access policy has been applied, an informed decision is reached whether to grant access, block access, or require additional verification. Common decisions are:

• Block access

• Grant access

• Require one or more conditions to be met before granting access:

  • Require multi-factor authentication.

  • Require device to be marked as compliant.

  • Require hybrid Azure AD joined device.

  • Require approved client app.

  • Require app protection policy.

  • Require password change.

• Control user access based on session controls to enable limited experiences within specific cloud applications. As an example, Conditional Access App Control, uses signals from Microsoft Cloud app security (MCAS) to block, download, cut, copy and print of sensitive documents, or to require labeling of sensitive files. Other session controls include sign-in frequency and application enforced restrictions. For selected applications, application enforced restrictions use device information to provide users with a limited or full experience, depending on the device state.

Conditional access policies can be targeted to members of specific groups or guests, for example, you can create a policy to exclude all guest accounts from accessing sensitive resources. Conditional Access is a feature of paid Azure AD editions.

Interactive Guide

In this interactive guide, you'll create a conditional access policy for a group of users. Select the link below to get started.

Interactive guide - create a conditional access policy for a group of users.

Describe Azure AD roles

Azure AD roles control permissions to manage Azure AD resources, such as allowing user accounts to be created, or billing information viewed. Azure AD supports built-in and custom roles.

Built-in roles

A few of the most common built-in roles include:

• Global Administrator - Users with this role have access to all administrative features in Azure Active Directory. The person who signs up for the Azure Active Directory tenant automatically becomes a Global Administrator.

• User administrator - Users with this role can create and manage all aspects of users and groups. Additionally, this role includes the ability to manage support tickets and monitor service health.

• Billing administrator – users with this role makes purchases, manages subscriptions, manages support tickets, and monitors service health.

There are many different built-in roles for different areas of responsibility. All built-in roles are pre-configured bundles of permissions designed for specific tasks.

Custom roles

Although there are many built-in admin roles in Azure AD, custom roles give flexibility when granting access.

Granting permission using custom Azure AD roles is a two-step process that involves creating a custom role definition, which consists of a collection of permissions that you add from a preset list. These permissions are the same permissions used in the built-in roles. Once you’ve created your role definition, you can assign it to a user by creating a role assignment. A role assignment grants the user the permissions in a role definition, at a specified scope. A custom role can be assigned at org-wide scope, meaning the role member has the role permissions over all resources in the organization. A custom role can also be assigned at an object scope. An example of an object scope would be a single application.

Unlike built-in roles, which are assigned at a tenant level and are pre-configured bundles of permissions designed for specific tasks; custom roles can be assigned at the resource level (such as a single application) and allow permissions to be added to a custom role definition.

Custom roles require an Azure AD Premium P1 or P2 license.

Azure AD role-based access control

Managing access using roles is known as role-based access control (RBAC). Azure AD built-in and custom roles are a form of RBAC in that Azure AD roles control access to Azure AD resources.

Only grant the access users need

It's a best practice, and more secure, to grant users the least privilege to get their work done. This means that if someone mostly manages users, you should assign the user administrator role, and not global administrator. This mitigates the risk of a user account being compromised, and a hacker locking you out of your account. By assigning least privileges, you limit the damage that could be done with a compromised account.

Knowledge check

Multiple choice

Multiple choice

Multiple choice

Summary and resources

In this lessib, you've learned about Conditional Access and how it's used to protect resources. You've seen how Conditional Access policies use if then statements with signals to determine whether to grant access, require more information, or block access.

You also learned about built-in admin roles, and custom roles in Azure AD. And you found out about the concept of least privilege access, and how this protects resources.

Now that you've completed this lesson, you'll be able to:

• Describe Conditional Access and its benefits.

• Describe Azure AD roles.

Learn more

For more information about the topics raised in this lesson, see:

• Conditional Access

• Security defaults

• Understand roles in Azure Active Directory

• Azure AD built-in roles

• Overview of role-based access control in Azure Active Directory

• Introduction
• Describe identity governance in Azure AD
• Describe entitlement management, access reviews, and terms of use
• Describe the capabilities of Privileged identity Management
• Describe Azure Identity Protection
• Knowledge check
• Summary and resources

Introduction

Identity governance is concerned with balancing identity security with user productivity in a way that can be justified and audited. Azure AD provides many identity protection and governance capabilities, including Privileged Identity Management, Identity Protection, and terms of use statements.

After completing this lesson, you'll be able to:

• Describe the identity governance capabilities of Azure AD.

• Describe the benefits of Privileged Identity Management (PIM).

• Describe the capabilities of Azure AD Identity Protection.

Describe identity governance in Azure AD

Azure AD identity governance gives organizations the ability to do the following tasks:

• Govern the identity lifecycle.

• Govern access lifecycle.

• Secure privileged access for administration.

These actions can be completed for employees, business partners and vendors, and across services and applications, both on-premises and in the cloud.

It's intended to help organizations address these four key questions:

• Which users should have access to which resources?

• What are those users doing with that access?

• Are there effective organizational controls for managing access?

• Can auditors verify that the controls are working?

Identity lifecycle

Managing users’ identity lifecycle is at the heart of identity governance.

When planning identity lifecycle management for employees, for example, many organizations model the “join, move, and leave” process. Or, when an individual first joins an organization, a new digital identity is created if one isn't already available. When an individual moves between organizational boundaries, more access authorizations may need to be added or removed to their digital identity. When an individual leaves, access may need to be removed, and the identity might no longer be required, other than for audit purposes.

The diagram below shows a simplified version of the identity lifecycle.

For many organizations, this identity lifecycle for employees is tied to the representation of that user in a human resources (HR) system such as Workday or SuccessFactors. The HR system is authoritative for providing the current list of employees, and some of their properties, such as name or department.

Azure AD Premium offers integration with cloud-based HR systems. When a new employee is added to an HR system, Azure AD can create a corresponding user account. Similarly, when their properties, such as department or employment status, change in the HR system, synchronization of those updates to Azure AD ensures consistency.

Azure AD Premium also includes Microsoft Identity Manager, which can import records from on-premises HR systems such as SAP HCM, Oracle eBusiness, and Oracle PeopleSoft.

In general, managing the lifecycle of an identity is about updating the access that users need, whether through integration with an HR system, or through the user provisioning applications.

Access lifecycle

Access lifecycle is the process of managing access throughout the user’s organizational life. Users require different levels of access from the point at which they join an organization to when they leave it. At various stages in between, they'll need access rights to different resources depending on their role and responsibilities.

Organizations can automate the access lifecycle process through technologies such as dynamic groups. Dynamic groups enable admins to create attribute-based rules to determine membership of groups. When any attributes of a user or device change, the system evaluates all dynamic group rules in a directory to see if the change would trigger any users to be added or removed from a group. If a user or device satisfies a rule for a group, they're added as a member of that group. If they no longer satisfy the rule, they're removed.

Privileged access lifecycle

Monitoring privileged access is a key part of identity governance. When employees, vendors, and contractors are assigned administrative rights, there should be a governance process because of the potential for misuse.

Azure AD Privileged Identity Management (PIM), provides extra controls tailored to securing access rights. PIM helps you minimize the number of people who have access to resources across Azure AD, Azure, and other Microsoft online services. PIM provides a comprehensive set of governance controls to help secure your company's resources. PIM is a feature of Azure AD Premium P2.

Describe entitlement management, access reviews, and terms of use

Entitlement management is an identity governance feature that enables organizations to manage identity and access lifecycle at scale. Entitlement management automates access request workflows, access assignments, reviews, and expiration.

Enterprise organizations often face challenges when managing employee access to resources such as:

• Users may not know what access they should have, and even if they do, they might have difficulty locating the right individuals to approve it.

• When users find and receive access to a resource, they may hold on to access longer than is required for business purposes.

• Managing access for external users.

Entitlement management includes the following capabilities to address these challenges:

• Delegate the creation of access packages to non-administrators. These access packages contain resources that users can request. The delegated access package managers then define policies that include rules such as which users can request access, who must approve their access, and when access expires.

• Managing external users. When a user who isn't yet in your directory requests access, and is approved, they're automatically invited into your directory and assigned access. When their access expires, if they have no other access package assignments, their B2B account in your directory can be automatically removed.

The video, What is Azure AD entitlement management? introduces entitlement management, and looks at how access packages are used to give access to resources.

Entitlement management is a feature of Azure AD Premium P2.

Azure AD access reviews

Azure Active Directory (AD) access reviews enable organizations to efficiently manage group memberships, access to enterprise applications, and role assignment. Regular access reviews ensure that only the right people have access to resources. Excessive access rights are a known security risk. However, when people move between teams, or take on or relinquish responsibilities, access rights can be difficult to control.

Access reviews are helpful when:

• You have too many users in privileged roles, such as global administrator.

• When automation isn't possible, such as when HR data isn't in Azure AD.

• You want to control business critical data access.

• Your governance policies require periodic reviews of access permissions.

Access reviews can be created through Azure AD access reviews, or Azure AD Privileged Identity Management (PIM). Access reviews can be used to review and manage access for both users and guests. When an access review is created, it can be set up so that each user reviews their own access, or to have one or more users review everyone's access. Similarly, all guests can be asked to review their own access, or have it looked at by one or more users.

Admins who create access reviews can track progress as the reviewers complete their process. No access rights are changed until the review is finished. You can, however, stop a review before it reaches its scheduled end.

When the review is complete, it can be set to manually or auto-apply changes to remove access from a group membership or application assignment, except for a dynamic group or a group that originates on-premises. In those cases, the changes must be applied directly to the group.

Access reviews are a feature of Azure AD Premium P2.

Azure AD terms of use

Azure AD terms of use allow information to be presented to users, before they access data or an application. Terms of use ensure users read relevant disclaimers for legal or compliance requirements.

Employees or guests can be required to accept terms of use in the following situations:

• Before they access sensitive data or an application.

• On a recurring schedule, so they're reminded of regulations.

• When terms of use are required in different languages.

• Based on user attributes, such as terms applicable to certain roles.

• Presenting terms for all users in your organization.

Terms of use are presented in a PDF format, using content that you create, such as an existing contract document. Terms of use can also be presented to users on mobile devices.

Conditional Access policies are used to require a terms of use statement being displayed, and ensuring the user has agreed to those terms before accessing an application. Admins can then view who has agreed to terms of use, and who has declined.

Describe the capabilities of Privileged identity Management

Privileged Identity Management (PIM) is a service in Azure Active Directory (Azure AD) that enables you to manage, control, and monitor access to important resources in your organization. These include resources in Azure AD, Azure, and other Microsoft online services such as Microsoft 365 or Microsoft Intune. PIM mitigates the risks of excessive, unnecessary, or misused access permissions. It requires justification to understand why users want permissions, and enforces multifactor authentication to activate any role.

PIM is:

• Just in time, providing privileged access only when needed, and not before.

• Time-bound, by assigning start and end dates that indicate when a user can access resources.

• Approval-based, requiring specific approval to activate privileges.

• Visible, sending notifications when privileged roles are activated.

• Auditable, allowing a full access history to be downloaded.

Privileged Identity Management is a feature of Azure AD Premium P2.

Why use PIM?

PIM reduces the chance of a malicious actor getting access by minimizing the number of people who have access to secure information or resources. By time-limiting authorized users, it reduces the risk of an authorized user inadvertently affecting sensitive resources. PIM also provides oversight for what users are doing with their administrator privileges. PIM mitigates the risk to organizations of elevated privileges.

For a more detailed look at PIM and why you might use it, watch What is Privileged Identity Management?.

Describe Azure Identity Protection

Identity Protection is a tool that allows organizations to accomplish three key tasks:

• Automate the detection and remediation of identity-based risks.

• Investigate risks using data in the portal.

• Export risk detection data to third-party utilities for further analysis.

Microsoft analyses 6.5 trillion signals per day to identify potential threats. These signals come from learnings Microsoft has acquired from their position in organizations with Azure AD, the consumer space with Microsoft Accounts, and in gaming with Xbox.

The signals generated by these services are fed to Identity Protection, so they can then be used by tools such as Conditional Access, which uses Identity Protection signals to make access decisions. These signals are also fed to security information and event management (SIEM) tools, such as Sentinel, for further investigation.

Identity Protection categorizes risk into three tiers: low, medium, and high. Additionally, it can calculate the sign-in risk, and user identity risk.

Sign-in risk is the probability that the sign-in wasn’t performed by the user, and uses the following signals to calculate the risk:

• Atypical travel. Sign in from an atypical location based on the user's recent sign-ins.

• Anonymous IP address. Sign in from an anonymous IP address (for example: Tor browser, anonymized VPNs).

User risk is a probability that the user identity has been compromised, and uses the following signals to calculate the risk:

• Unfamiliar sign-in properties. Sign in with properties we've not seen recently for the given user.

• Malware linked IP address. Sign in from a malware linked IP address.

• Leaked Credentials. Indicates that the user's valid credentials have been leaked.

• Password spray. Indicates that multiple usernames are being attacked using common passwords in a unified, brute-force manner.

• Azure AD threat intelligence. Microsoft's internal and external threat intelligence sources have identified a known attack pattern.

These risk signals can trigger actions such as requiring users to provide multi-factor authentication, reset their password, or block access until an administrator takes action.

Identity Protection provides organizations with three reports that they can use to investigate identity risks in their environment. These reports are the risky users, risky sign-ins, and risk detections reports. Investigation of events is key to understanding and identifying any weak points in your security strategy.

After completing an investigation, admins will want to take action to remediate the risk or unblock users. Organizations also have the option to enable automated remediation using their risk policies. Microsoft recommends closing events as soon as possible because time matters when working with risk.

Identity protection is a feature of Azure AD Premium P2.

Knowledge check

Multiple choice

Multiple choice

Multiple choice

Multiple choice