Forum

SC-900 - Module 2 D...
 
Notifications
Clear all

SC-900 - Module 2 Describe the capabilities of Microsoft identity and access management solutions

4 Posts
1 Users
0 Reactions
8,787 Views
Posts: 108
Topic starter
(@taichi)
Member
Joined: 4 years ago

Introduction

When it comes to security, your organization can no longer rely on its network boundary. To allow employees, partners, and customers to collaborate securely, identity has become the new security perimeter. Using an identity provider gives your organization the ability to manage all aspects of identity security.

This lesson introduces you to Azure Active Directory (Azure AD), Microsoft’s cloud-based identity and access management service. In this module, you'll learn about the benefits of using a cloud-based identity provider, including single sign-on for users. You'll also find out about the different Azure AD editions, the identity types supported by Azure AD, and how you can use it to support external users.

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

  • Describe what Azure AD does.

  • Describe the identity types that Azure AD supports.

 

Describe the basic identity services and identity types of Azure AD

Describe Azure Active Directory

Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management service. Organizations use Azure AD to enable their employees, guests, and others to sign in and access the resources they need, including:

  • Internal resources, such as apps on your corporate network and intranet, and cloud apps developed by your own organization.

  • External services, such as Microsoft Office 365, the Azure portal, and any SaaS applications used by your organization.

Azure AD simplifies the way organizations manage authorization and access by providing a single identity system for their cloud and on-premises applications. Azure AD can be synchronized with your existing on-premises Active Directory, synchronized with other directory services, or used as a standalone service.

Azure AD also allows organizations to securely enable the use of personal devices, such as mobiles and tablets, and enable collaboration with business partners and customers.

Azure Active Directory works with cloud apps such as M365, devices, and on-premises applications

Azure Active Directory works with cloud apps such as M365, devices, and on-premises applications

Azure AD is used by IT admins to control access to corporate apps and resources, based on business requirements. It can also be set up to require multi-factor authentication when accessing important organizational resources. Azure AD can be used to automate user provisioning between an existing Windows Server AD and cloud apps, including Microsoft 365. Finally, Azure AD provides powerful tools to automatically help protect user identities and credentials and to meet an organization’s access governance requirements.

Developers use Azure AD as a standards-based approach for adding single sign-on (SSO) to their apps, so that users can sign in with their pre-existing credentials. Azure AD also provides APIs that allow developers to build personalized app experiences using existing organizational data.

Each Microsoft 365, Office 365, Azure, or Dynamics 365 Online subscription automatically uses an Azure AD tenant. Users of these services can take advantage of Azure AD services such as self-service password reset, provided it has been configured by their organization’s admins.

Azure AD is available in four editions: Free, Office 365 Apps, Premium P1, and Premium P2. For more information on what is included with each of these editions, refer to Azure Active Directory Pricing.

Describe the Azure AD identity types

Azure AD manages different types of identities: users, service principals, managed identities, and devices. In this topic, we consider each type of Azure AD identity.

User

A user identity is a representation of something that is managed by Azure AD. Employees and guests are represented as users in Azure AD. If you have several users with the same access needs, you can create a group. Groups allow you to assign access permissions to all the members of the group, instead of having to assign the access rights individually.

Azure AD business-to-business (B2B) collaboration, a feature within External Identities, includes the capability to add guest users. With B2B collaboration, an organization can securely share applications and services with guest users from another organization.

Interactive guide

In the following interactive guide, you will add a new user to Azure Active Directory. Select the link below to get started.

Interactive guide - Add a new user to Azure Active Directory

Service Principal

A service principal is a security identity used by applications or services to access specific Azure resources. You can think of it as an identity for an application.

For an application to delegate its identity and access functions to Azure AD, the application must first be registered with Azure AD. The process of registering the application creates a globally unique app object which is stored in your home tenant or directory. A service principal is created in each tenant where the application is used and references the globally unique app object. The service principal defines what the app can do in the tenant, such as who can access the app, and what resources the app can access.

Managed Identity

A managed identity is an identity in Azure Active Directory that is automatically managed by Azure. Managed identities are typically used to manage the credentials for authenticating a cloud application with an Azure service.

There are several benefits to using managed identities, including:

  • Application developers can authenticate to services that support managed identities for Azure resources. For a complete list of services, refer to Azure Services that support managed identities.

  • Any Azure service that supports Azure AD authentication can use managed identities to authenticate to another Azure service, for example accessing Azure Key Vault.

  • Managed identities can be used without any additional cost.

There are two types of managed identities: system-assigned and user-assigned.

System-assigned. Some Azure services allow you to enable a managed identity directly on a service instance. When you enable a system-assigned managed identity, an identity is created in Azure AD that is tied to the lifecycle of that service instance. When the resource is deleted, Azure automatically deletes the identity for you. By design, only that Azure resource can use this identity to request tokens from Azure AD.

User-assigned. You may also create a managed identity as a standalone Azure resource. A user-assigned managed identity is assigned to one or more instances of an Azure service. You can create a user-assigned managed identity and assign it to one or more instances of an Azure service. In the case of user-assigned managed identities, the identity is managed separately from the resources that use it.

The following table summarizes the differences between system-assigned and user-assigned managed identities:

Property

System-assigned managed identity

User-assigned managed identity

Creation

Created as part of an Azure resource, such as an Azure virtual machine or Azure App Service.

Created as a stand-alone Azure resource.

Life cycle

Shared life cycle with the Azure resource. When the parent resource is deleted, the managed identity is also deleted.

Independent life cycle. Must be explicitly deleted.

Sharing across Azure resources

Cannot be shared. Associated with a single Azure resource.

Can be shared. A user-assigned managed identity can be associated with more than one Azure resource.

Common use cases

Workloads that are contained within a single Azure resource. Workloads for which you need independent identities, such as an application that runs on a single virtual machine.

Workloads that run on multiple resources and which can share a single identity. Workloads that need pre-authorization to a secure resource as part of a provisioning flow. Workloads where resources are recycled frequently, but permissions should stay consistent. For example, a workload where multiple virtual machines need to access the same resource.

Device

A device is a piece of hardware, such as a mobile device, laptop, server, or printer. Device identities can be set up in different ways in Azure AD, which determine properties such as who owns the device. Managing devices in Azure AD allows an organization to protect its assets by using tools such as Microsoft Intune to ensure standards for security and compliance. Azure AD also enables single sign-on to devices, apps, and services from anywhere through these devices.

There are multiple options for getting devices into Azure AD:

  • Azure AD registered devices can be Windows 10, iOS, Android, or macOS devices. Devices that are Azure AD registered are typically owned personally, rather than by the organization. They are signed in with a personal Microsoft account or another local account.

  • Azure AD joined devices exist only in the cloud. Azure AD joined devices are owned by an organization and signed in with an organization Azure AD account. Users sign in to their devices with their Azure AD or synced Active Directory work or school accounts. You can configure Azure AD joined devices for all Windows 10 devices (except Windows 10 Home).

  • Hybrid Azure AD joined devices can be Windows 7, 8.1, or 10 or Windows Server 2008 or newer. Devices that are hybrid Azure AD joined are owned by an organization and are signed in with an Active Directory Domain Services account belonging to that organization. They exist in the cloud and on-premises.

IT admins can use tools like Microsoft Intune, a mobile device management (MDM) solution, to manage devices. Refer to Microsoft Intune for more information.

 

Describe the types external identities

Today’s world is about collaboration, working with people both inside and outside of your organization. That means that you sometimes need to provide access to your organization’s applications or data to external users.

Azure AD External Identities is a set of capabilities that enable organizations to allow access to external users, such as customers or partners. Your customers, partners, and other guest users can “bring their own identities” to sign in.

The ability for external users to “bring their own identities” to sign in is enabled through Azure AD support of external identity providers like other Azure AD tenants, Facebook, Google, or enterprise identity providers. Admins can set up federation with identity providers so your external users can sign in with their existing social or enterprise accounts instead of creating a new account just for your application.

There are two different Azure AD External Identities: B2B or B2C.

  • B2B collaboration allows you to share your apps and resources with external users.

  • B2C is an identity management solution for consumer/customer facing apps.

B2B collaboration

B2B collaboration allows you to share your organization’s applications and services with guest users from other organizations, while maintaining control over your own data. B2B collaboration uses an invitation and redemption process, allowing external users to access your resources with their credentials. Developers can customize the invitation and redemption process using Azure AD business-to-business APIs.

With B2B collaboration, external users are managed in the same directory as employees but are typically annotated as guest users. Guest users can be managed the same way as employees, added to the same groups, and so on. With B2B, SSO to all Azure AD-connected apps is supported.

B2C access management

Azure AD B2C is a customer identity access management (CIAM) solution. Azure AD B2C allows external users to sign in with their preferred social, enterprise, or local account identities to get single sign-on to your applications. Azure AD B2C can support millions of users and billions of authentications per day. It takes care of the scaling and safety of the authentication platform, monitoring, and automatically handling threats like denial-of-service, password spray, or brute force attacks.

With Azure AD B2C, external users are managed in the Azure AD B2C directory, separately from the organization's employee and partner directory. With Azure AD B2C, SSO to customer owned apps within the Azure AD B2C tenant is supported.

Azure AD B2C is an authentication solution that you can customize with your brand so that it blends seamlessly with your web and mobile applications.

Azure AD B2C customized sign-in screen

Azure AD External Identities is a feature of Premium P1 and P2 Azure AD editions, and pricing is based on Monthly Active Users. Refer to Azure AD pricing for more details.

 

Describe the concept of hybrid identities

Organizations may use the hybrid identity model, or the cloud only identity model. In the hybrid model, identities are created in Windows Active Directory or another identity provider, and then synchronized to Azure AD. In the cloud-only model, identities are created and wholly managed in Azure AD. Whether identities are created on-premises or in the cloud, users can access both cloud and on-premises resources.

With the hybrid model, users accessing both on-premise and cloud apps are hybrid users managed in the on-premise Active Directory. When you make an update in your on-premises AD DS, all updates to user accounts, groups, and contacts are synchronized to your Azure AD. The synchronization is managed with Azure AD Connect.

Azure AD connect manages the synchronization to Azure Active Directory

Azure AD connect manages the synchronization to Azure Active Directory

When using the hybrid model, authentication can either be done by Azure AD, which is known as managed authentication. Or Azure AD redirects the client requesting authentication to another identity provider, which is known as federated authentication.

One of three authentication methods can be used (they are listed in order of resilience):

  1. Password hash synchronization. This is the simplest way to enable authentication for on-premises directory objects in Azure AD. Users can use the same username and password that they use on-premises without any additional infrastructure being needed. Password hash synchronization is a type of managed authentication.

  2. Pass-through authentication (PTA). Provides a simple password validation for Azure AD authentication services by using a software agent that runs on one or more on-premises servers. The servers validate the users directly with an on-premises Active Directory, which ensures that the password validation doesn't happen in the cloud. PTA is a type of managed authentication.

  3. Federated authentication. Azure AD hands off the authentication process to a separate trusted authentication system, such as on-premises Active Directory Federation Services (AD FS), to validate the user’s password.

  4. Knowledge check

    Multiple choice

    Item 1. Your organization is launching a new app for customers. You want your customers to use a sign-in screen that is customized with your brand identity. Which type of Azure External identity authentication solution should you use?

    Multiple choice

    Item 2. Within your organization, all your users have Microsoft 365 cloud identities. Which identity model should you use?

    Multiple choice

    Item 3. You have developed an app and want users to be able to sign in with their Facebook, Google, or Twitter credentials. What type of authentication will you use?

  5. Summary and resources

    In this lesson, you've gained an insight into the features and capabilities of Azure Active Directory. You've learned about the different Azure AD editions, the identity types supported by Azure AD, and how you can use it to support external users. Finally, you learned about the hybrid model, where all user identities are managed in your on-premises Active Directory Domain Services (AD DS) directory, and changes are synchronized to your Azure AD.

    Now that you’ve completed this lesson, you should be able to:

    • Describe what Azure AD does.

    • Describe the identity types that Azure AD supports.

    Learn more

    For more information on the topics covered in this lesson, see:

3 Replies
Posts: 108
Topic starter
(@taichi)
Member
Joined: 4 years ago

 

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

Microsoft authenticator app

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 should be supplemented or replaced

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.

Microsoft authenticator app

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

Item 1. After hearing of a security breach at a competitor, you want to improve identity security within your organization. What should you implement immediately to provide the greatest protection to user identities?

Multiple choice

Item 2. To improve identity security within your organization, you want to implement Windows Hello for Business. When explaining the benefits of Windows Hello for Business to your colleagues, which of the following is true?

Multiple choice

Item 3. You've been asked to find ways to reduce IT costs, without compromising security. Which feature should you consider implementing?

 

Summary and resources

In this lesson, you've seen why passwords are a problematic form of authentication. You've learned about the different types of authentication that can be used with Azure AD, including biometric data, Windows Hello, Microsoft Authenticator app, and using your phone for voice or SMS authentication.

You've learned how Azure AD can be configured to allow users to reset their own passwords, and how Azure AD Password Protection mitigates against the inherent risks associated with passwords.

Now that you’ve completed this lesson, you should be able to:

  • Describe the secure authentication methods of Azure AD.

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

Learn more

Reply
Posts: 108
Topic starter
(@taichi)
Member
Joined: 4 years ago

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).

Conditional Access policies use signals to decide whether to allow or block access

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

Item 1. You've been asked to implement conditional access for your organization, what must you do?

Multiple choice

Item 2. Sign in risk is a signal used by conditional access policies to decide whether to grant or deny access. What is sign in risk?

Multiple choice

Item 3. You've been asked to review Azure AD roles assigned to users to improve organizational security. Which of the following should you implement?

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:

Reply
Posts: 108
Topic starter
(@taichi)
Member
Joined: 4 years ago

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.

Identity lifecycle management is the foundation for identity governance

Identity Governance - Azure Active Directory | Microsoft Docs

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.

Access reviews invite users to review access rights

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

Item 1. Your organization has implemented important changes in their customer facing web-based applications. You want to ensure that any user who wishes to access these applications agrees to the legal disclaimers. Which Azure AD feature should you implement?

Multiple choice

Item 2. Your organization is project-oriented with employees often working on more than one project at a time. Which solution is best suited to managing user access to your organization’s resources?

Multiple choice

Item 3. Your organization has recently conducted a security audit and found that four people who have left the organization were still active and assigned Global Admin roles. The users have now been deleted and you've been asked to recommend a solution to prevent a similar security lapse happening in future. Which solution should you recommend?

Multiple choice

Item 4. You've recently discovered that several user accounts in the Finance Department have been compromised. Your CTO has asked for your help in finding a solution to reduce the impact of compromised user accounts. They've asked you to look at three Azure AD features, which one should you recommend?

 

Summary and resources

In this lesson, you learned how Azure AD provides tools to help you govern the identity lifecycle and the access lifecycle. You've seen how Azure AD can be synchronized with human resources (HR) systems to manage identity lifecycles at scale. You also learned how dynamic groups can automate attribute-based rules to determine who is in a particular group.

This lesson discussed entitlement management, which automates access requests, access assignments, reviews, and expiration. You also learned about how these reviews can help you monitor who has access to what resources.

Finally, you learned how Privileged Identity Management (PIM) can help you minimize the number of users who have access to important resources, and how Identity Protection can detect potential identity risks.

Now that you’ve completed this lesson, you should be able to:

  • Describe the identity governance capabilities of Azure AD.

  • Describe the benefits of PIM.

  • Describe the capabilities of Azure AD Identity Protection.

Learn more

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

Reply
Share: