-

-Azure AD B2C uses [Microsoft Entra ID monitoring](../active-directory/reports-monitoring/overview-monitoring-health.md). Unlike Microsoft Entra tenants, an Azure AD B2C tenant can't have a subscription associated with it. So, we need to take extra steps to enable the integration between Azure AD B2C and Log Analytics, which is where we send the logs.

-Once you've configured company branding, enable it in your custom policy. Configure the [page layout version](contentdefinitions.md#migrating-to-page-layout) with page `contract` version for *all* of the content definitions in your custom policy. The format of the value must contain the word `contract`: _urn:com:microsoft:aad:b2c:elements:**contract**:page-name:version_. To specify a page layout in your custom policies that use an old **DataUri** value. For more information, learn how to [migrate to page layout](contentdefinitions.md#migrating-to-page-layout) with page version.

-By default, the password is set not to expire. However, the value is configurable by using the [Set-MsolPasswordPolicy](/powershell/module/msonline/set-msolpasswordpolicy) cmdlet from the Azure AD Module for Windows PowerShell. This command updates the tenant, so that all users' passwords expire after number of days you configure.

-1. Define a [page layout version](contentdefinitions.md#migrating-to-page-layout) with page `contract` version for *all* of the content definitions in your custom policy. The format of the value must contain the word `contract`: _urn:com:microsoft:aad:b2c:elements:**contract**:page-name:version_.

-1. Go to [Azure-AD-B2C-HYPR-Sample/policy/](https://github.com/HYPR-Corp-Public/Azure-AD-B2C-HYPR-Sample/tree/master/policy).

-1. Install the latest version of Microsoft Graph PowerShell Module on a Windows workstation or server.

-5. Create a B2C policy key under identity experience framework in the Microsoft Entra ID blade in the **Azure portal**. Use the `Generate` option and name this key `tdnaHashedId`.

-To enable custom attributes in your policy, provide **Application ID** and Application **Object ID** in the AAD-Common technical profile metadata. The *AAD-Common* technical profile is found in the base [Microsoft Entra ID](active-directory-technical-profile.md) technical profile, and provides support for Microsoft Entra user management. Other Microsoft Entra technical profiles include the AAD-Common to use its configuration. Override the AAD-Common technical profile in the extension file.

-The [azure-ad-b2c/user-migration](https://github.com/azure-ad-b2c/user-migration) repository on GitHub contains a seamless migration custom policy example and REST API code sample:

-[Seamless user migration custom policy & REST API code sample](https://aka.ms/b2c-account-seamless-migration)

-## Get audit logs with the Microsoft Entra ID reporting API

-Audit logs are published to the same pipeline as other activities for Microsoft Entra ID, so they can be accessed through the [Microsoft Entra ID reporting API](/graph/api/directoryaudit-list). For more information, see [Get started with the Microsoft Entra ID reporting API](../active-directory/reports-monitoring/howto-configure-prerequisites-for-reporting-api.md).

-1. Search for each of the following application IDs. For Azure Global, search for AppId value *2565bd9d-da50-47d4-8b85-4c97f669dc36*. For other Azure clouds, search for AppId value *6ba9a5d4-8456-4118-b521-9c5ca10cdf84*. If no existing application is found, follow the *Resolution* steps to create the service principal or re-register the namespace.

- | 443155a6-77f3-45e3-882b-22b3a8d431fb | [Re-register the Microsoft.AAD namespace](#re-register-the-microsoft-aad-namespace) |

- | abba844e-bc0e-44b0-947a-dc74e5d09022 | [Re-register the Microsoft.AAD namespace](#re-register-the-microsoft-aad-namespace) |

- | d87dcbc6-a371-462e-88e3-28ad15ec4e64 | [Re-register the Microsoft.AAD namespace](#re-register-the-microsoft-aad-namespace) |

-If application ID *443155a6-77f3-45e3-882b-22b3a8d431fb*, *abba844e-bc0e-44b0-947a-dc74e5d09022*, or *d87dcbc6-a371-462e-88e3-28ad15ec4e64* is missing from your Microsoft Entra directory, complete the following steps to re-register the *Microsoft.AAD* resource provider:

-1. Search for *Microsoft.AAD*, then select **Re-register**.

-Instead, a group managed service account (gMSA) can be created in the Microsoft Entra Domain ServiceS managed domain. The Windows OS automatically manages the credentials for a gMSA, which simplifies the management of large groups of resources.

-You can create a user in the Microsoft Entra portal or by using Graph PowerShell or Graph API. You can also read, update, and delete users. The next sections show how to do these operations in the Microsoft Entra portal.

-You can create a new user using the Microsoft Entra portal.

-## Use RSAT tools to connect to a Microsoft Entra DS managed domain and view users

- 

-* [Microsoft Entra DS Overview](overview.md)

-description: Learn how the synchronization process works between Microsoft Entra or an on-premises environment to a Microsoft Entra Domain Services managed domain.

- 1. Install the AADCloudSyncTools PowerShell module as described in [AADCloudSyncTools PowerShell Module for Microsoft Entra Connect cloud sync](../hybrid/cloud-sync/reference-powershell.md#install-the-aadcloudsynctools-powershell-module).

-1. Browse to **Identity** > **Hybrid management** > **Azure AD Connect** > **Cloud Sync** > **Agents**.

- > Please use different provisioning agents for on-premises application provisioning and Azure AD Connect Cloud Sync / HR-driven provisioning. All three scenarios should not be managed on the same agent.

-1. The provisioning agent uses the operating system's web browser to display a popup window for you to authenticate to Azure AD, and potentially also your organization's identity provider. If you are using Internet Explorer as the browser on Windows Server, then you may need to add Microsoft web sites to your browser's trusted site list to allow JavaScript to run correctly.

-1. Provide credentials for an Azure AD administrator when you're prompted to authorize. The user is required to have the Hybrid Identity Administrator or Global Administrator role.

- > If you just assigned the agent to the application, please wait 10 minutes for the registration to complete. The connectivity test won't work until the registration completes. Forcing the agent registration to complete by restarting the provisioning agent on your server can speed up the registration process. Go to your server, search for **services** in the Windows search bar, identify the **Azure AD Connect Provisioning Agent** service, right-click the service, and restart.

- > If you just assigned the agent to the application, please wait 10 minutes for the registration to complete. The connectivity test won't work until the registration completes. Forcing the agent registration to complete by restarting the provisioning agent on your server can speed up the registration process. Go to your server, search for **services** in the Windows search bar, identify the **Azure AD Connect Provisioning Agent Service**, right-click the service, and restart.

-1. Expand **Mappings** and select **Provision Azure Active Directory Users**. If this is the first time you've configured the attribute mappings for this application, there will be only one mapping present, for a placeholder.

-1. To confirm that the schema is available in Azure AD, select the **Show advanced options** checkbox and select **Edit attribute list for ScimOnPremises**. Ensure that all the attributes selected in the configuration wizard are listed. If not, then wait several minutes for the schema to refresh, and then reload the page. Once you see the attributes listed, then cancel from this page to return to the mappings list.

-1. Browse to **Identity** > **Hybrid management** > **Azure AD Connect** > **Cloud Sync** > **Agents**.

-1. Now either wait 10 minutes or restart the **Microsoft Azure AD Connect Provisioning Agent** before proceeding to the next step & testing the connection.

-All activities performed by the provisioning service are recorded in the Microsoft Entra audit logs. You can route Microsoft Entra audit logs to Azure Monitor logs for further analysis. With Azure Monitor logs (also known as Log Analytics workspace), you can query data to find events, analyze trends, and perform correlation across various data sources. Watch this [video](https://youtu.be/MP5IaCTwkQg) to learn the benefits of using Azure Monitor logs for Microsoft Entra ID logs in practical user scenarios.

- > For Cloud HR provisioning app (Workday/SuccessFactors to AD/Azure AD), the input value is different.

-* On-demand provisioning supports provisioning one user at a time through the Microsoft Entra portal.

-The table below provides the default attribute mapping between SuccessFactors attributes listed above and AD/Azure AD attributes. In the Microsoft Entra provisioning app "Mapping" blade, you can modify this default mapping to include attributes from the list above.

-| \# | SuccessFactors Entity | SuccessFactors Attribute | Default AD/Azure AD attribute mapping | Processing Remark |

- | SuccessFactors to Microsoft Entra User Provisioning | `accountEnabled` | `Switch([emplStatus], "False", "A", "True", "U", "True", "P", "True")` |

- | SuccessFactors to Microsoft Entra User Provisioning | `accountEnabled` | `Switch([activeEmploymentsCount], "True", "0", "False")` | `Switch([emplStatus], "False", "A", "True", "U", "True", "P", "True")` |

-> The behavior of the Microsoft Entra SCIM implementation was last updated on December 18, 2018. For information on what changed, see [SCIM 2.0 protocol compliance of the Microsoft Entra User Provisioning service](application-provisioning-config-problem-scim-compatibility.md).

-* Don't require a case-sensitive match on structural elements in SCIM, in particular **PATCH** `op` operation values, as defined in [section 3.5.2](https://tools.ietf.org/html/rfc7644#section-3.5.2). Azure AD emits the values of `op` as **Add**, **Replace**, and **Remove**.

-* Microsoft Azure AD makes requests to fetch a random user and group to ensure that the endpoint and the credentials are valid. It's also done as a part of the **Test Connection** flow.

-* Microsoft Azure AD only uses the following operators: `eq`, `and`

-Cloud sync will automatically discover your extensions in on-premises Active Directory when you go to add a new mapping. Use the steps below to autodiscover these attributes and set up a corresponding mapping to Azure AD.

-1. Browse to **Identity** > **Hybrid management** > **Azure AD Connect** > **Cloud Sync**.

-1. Select your Workday to AD/Azure AD user provisioning application.

-1. Add the following attributes definitions and mark them as "Required". These attributes aren't mapped to any attribute in AD or Azure AD. They serve as signals to the connector to retrieve the Cost Center, Cost Center Hierarchy and Pay Group information.

-To retrieve pronouns from Workday, update your Azure AD provisioning app to query Workday using v38.1 of the Workday Web Services. We recommend testing this configuration first in your test/sandbox environment before implementing the change in production.

-1. Select your Workday to AD/Azure AD user provisioning application and go to **Provisioning** .

- > To provide high availability for applications authenticating through the Microsoft Entra application proxy, you can install connectors on multiple VMs. Repeat the same steps listed in the previous section to install the connector on other servers joined to the Microsoft Entra DS managed domain.

-This sample requires the [Microsoft Entra V2 PowerShell for Graph module preview version](/powershell/azure/active-directory/install-adv2?view=azureadps-2.0-preview&preserve-view=true) (AzureADPreview).

- * Use Windows PowerShell to configure this setting

-* [External Identities in Azure AD](../external-identities/external-identities-overview.md)

-### Microsoft Entra ID logs archived and integrated with incident response plans

-Having access to sign-in activity, audits and risk events for Microsoft Entra ID is crucial for troubleshooting, usage analytics, and forensics investigations. Microsoft Entra ID provides access to these sources through REST APIs that have a limited retention period. A security information and event management (SIEM) system, or equivalent archival technology, is key for long-term storage of audits and supportability. To enable long-term storage of Microsoft Entra ID Logs, you must either add them to your existing SIEM solution or use [Azure Monitor](../reports-monitoring/concept-activity-logs-azure-monitor.md). Archive logs that can be used as part of your incident response plans and investigations.

- Applications or resources that required servers can be migrated to Azure infrastructure as a service (IaaS). Use Microsoft Entra Domain Services (Microsoft Entra DS) to decouple trust and dependency on on-premises instances of Active Directory. To achieve this decoupling, make sure virtual networks used for Microsoft Entra DS don't have a connection to corporate networks. See [Microsoft Entra Domain Services](../../active-directory-domain-services/overview.md).

-After you configure your environment to protect your Microsoft 365 from an on-premises compromise, proactively monitor the environment. For more information, see [What is Microsoft Entra ID monitoring](../reports-monitoring/overview-monitoring.md).

- The log strategy must include the following Microsoft Entra ID logs:

- You can stream Microsoft Entra ID logs to Azure Monitor logs. See [Integrate Microsoft Entra ID logs with Azure Monitor logs](../reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md).

-* [microsoft-authentication-library-for--js](https://github.com/AzureAD/microsoft-authentication-library-for-js/releases)

-* [microsoft-authentication-library-for--dotnet](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/releases)

-* [microsoft-authentication-library-for--python](https://github.com/AzureAD/microsoft-authentication-library-for-python/releases)

-* [microsoft-authentication-library-for--java](https://github.com/AzureAD/microsoft-authentication-library-for-java/releases)

-* [microsoft-authentication-library-for--objc](https://github.com/AzureAD/microsoft-authentication-library-for-objc/releases)

-* [microsoft-authentication-library-for--android](https://github.com/AzureAD/microsoft-authentication-library-for-android/releases)

-* [microsoft-authentication-library-for--js](https://github.com/AzureAD/microsoft-authentication-library-for-js/releases)

-* [microsoft-identity-web](https://github.com/AzureAD/microsoft-identity-web/releases)

-If you develop resource APIs, go to openid.net for [Shared Signals ΓÇô A Secure Webhooks Framework](https://openid.net/wg/sse/).

-The log strategy must include the following Microsoft Entra ID logs for each tenant used in the organization:

-Microsoft Entra Domain Services (Microsoft Entra DS) provides a managed domain to facilitate authentication for Azure workloads using legacy protocols. Supported servers are moved from an on-premises AD DS forest and joined to a Microsoft Entra DS managed domain and continue to use legacy protocols for authentication (for example, Kerberos authentication).

-* Microsoft Entra Domain Services (Microsoft Entra DS) joined virtual machines

-* When you sign in to an Azure Windows Server VM via remote desktop protocol (RDP), you're generally logging on to the server using your domain credentials, which performs a Kerberos authentication against an on-premises AD DS domain controller or Microsoft Entra DS. Alternatively, if the server isn't domain-joined then a local account can be used to sign in to the virtual machines.

-When a requirement exists to deploy IaaS workloads to Azure that require identity isolation from AD DS administrators and users in another forest, then a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain can be deployed. Microsoft Entra DS is a service that provides a managed domain to facilitate authentication for Azure workloads using legacy protocols. This provides an isolated domain without the technical complexities of building and managing your own AD DS. The following considerations need to be made.

-

-**Microsoft Entra DS managed domain** - Only one Microsoft Entra DS managed domain can be deployed per Microsoft Entra tenant and this is bound to a single VNet. It's recommended that this VNet forms the "hub" for Microsoft Entra DS authentication. From this hub, "spokes" can be created and linked to allow legacy authentication for servers and applications. The spokes are additional VNets on which Microsoft Entra DS joined servers are located and are linked to the hub using Azure network gateways or VNet peering.

-**Managed domain location** - A location must be set when deploying a Microsoft Entra DS managed domain. The location is a physical region (data center) where the managed domain is deployed. It's recommended you:

-* Consider a location that is geographically closed to the servers and applications that require Microsoft Entra DS services.

-**Object provisioning** - Microsoft Entra DS synchronizes identities from the Microsoft Entra ID that is associated with the subscription that Microsoft Entra DS is deployed into. It's also worth noting that if the associated Microsoft Entra ID has synchronization set up with Microsoft Entra Connect (user forest scenario) then the life cycle of these identities can also be reflected in Microsoft Entra DS. This service has two modes that can be used for provisioning user and group objects from Microsoft Entra ID.

-* **All**: All users and groups are synchronized from Microsoft Entra ID into Microsoft Entra DS.

-* **Scoped**: Only users in scope of a group(s) are synchronized from Microsoft Entra ID into Microsoft Entra DS.

-When you first deploy Microsoft Entra DS, an automatic one-way synchronization is configured to replicate the objects from Microsoft Entra ID. This one-way synchronization continues to run in the background to keep the Microsoft Entra DS managed domain up to date with any changes from Microsoft Entra ID. No synchronization occurs from Microsoft Entra DS back to Microsoft Entra ID. For more information, see [How objects and credentials are synchronized in a Microsoft Entra Domain Services managed domain](../../active-directory-domain-services/synchronization.md).

-It's worth noting that if you need to change the type of synchronization from All to Scoped (or vice versa), then the Microsoft Entra DS managed domain will need to be deleted, recreated and configured. In addition, organizations should consider the use of "scoped" provisioning to reduce the identities to only those that need access to Microsoft Entra DS resources as a good practice.

-**Group Policy Objects (GPO)** - To configure GPO in a Microsoft Entra DS managed domain you must use Group Policy Management tools on a server that has been domain joined to the Microsoft Entra DS managed domain. For more information, see [Administer Group Policy in a Microsoft Entra Domain Services managed domain](../../active-directory-domain-services/manage-group-policy.md).

-**Secure LDAP** - Microsoft Entra DS provides a secure LDAP service that can be used by applications that require it. This setting is disabled by default and to enable secure LDAP a certificate needs to be uploaded, in addition, the NSG that secures the VNet that Microsoft Entra DS is deployed on to must allow port 636 connectivity to the Microsoft Entra DS managed domains. For more information, see [Configure secure LDAP for a Microsoft Entra Domain Services managed domain](../../active-directory-domain-services/tutorial-configure-ldaps.md).

-**Administration** - To perform administration duties on Microsoft Entra DS (for example, domain join machines or edit GPO), the account used for this task needs to be part of the Microsoft Entra DC Administrators group. Accounts that are members of this group can't directly sign-in to domain controllers to perform management tasks. Instead, you create a management VM that is joined to the Microsoft Entra DS managed domain, then install your regular AD DS management tools. For more information, see [Management concepts for user accounts, passwords, and administration in Microsoft Entra Domain Services](../../active-directory-domain-services/administration-concepts.md).

-**Password hashes** - For authentication with Microsoft Entra DS to work, password hashes for all users need to be in a format that is suitable for NT LAN Manager (NTLM) and Kerberos authentication. To ensure authentication with Microsoft Entra DS works as expected, the following prerequisites need to be performed.

-* **Users created in Microsoft Entra ID** - Need to reset their password for the correct hashes to be generated for usage with Microsoft Entra DS. For more information, see [Enable synchronization of password hashes](../../active-directory-domain-services/tutorial-configure-password-hash-sync.md).

-**Network** - Microsoft Entra DS is deployed on to an Azure VNet so considerations need to be made to ensure that servers and applications are secured and can access the managed domain correctly. For more information, see [Virtual network design considerations and configuration options for Microsoft Entra Domain Services](../../active-directory-domain-services/network-considerations.md).

-* Microsoft Entra DS must be deployed in its own subnet: Don't use an existing subnet or a gateway subnet.

-* **A network security group (NSG)** - is created during the deployment of a Microsoft Entra DS managed domain. This network security group contains the required rules for correct service communication. Don't create or use an existing network security group with your own custom rules.

-* **Microsoft Entra DS requires 3-5 IP addresses** - Make sure that your subnet IP address range can provide this number of addresses. Restricting the available IP addresses can prevent Microsoft Entra DS from maintaining two domain controllers.

-* **VNet DNS Server** - As previously discussed about the "hub and spoke" model, it's important to have DNS configured correctly on the VNets to ensure that servers joined to the Microsoft Entra DS managed domain have the correct DNS settings to resolve the Microsoft Entra DS managed domain. Each VNet has a DNS server entry that is passed to servers as they obtain an IP address and these DNS entries need to be the IP addresses of the Microsoft Entra DS managed domain. For more information, see [Update DNS settings for the Azure virtual network](../../active-directory-domain-services/tutorial-create-instance.md).

-* Some Microsoft Entra DS configuration can only be administered from a Microsoft Entra DS joined server.

-* Only one Microsoft Entra DS managed domain can be deployed per Microsoft Entra tenant. As we describe in this section the hub and spoke model is recommended to provide Microsoft Entra DS authentication to services on other VNets.

-For this isolated model, it's assumed that there's no connectivity to the VNet that hosts the Microsoft Entra DS managed domain from the customer's corporate network and that there are no trusts configured with other forests. A jumpbox or management server should be created to allow a point from which the Microsoft Entra DS can be managed and administered.

-From the Azure portal, you can view Microsoft Entra audit logs and download as comma separated value (CSV) or JavaScript Object Notation (JSON) files. Use the Azure portal to integrate Microsoft Entra ID logs with other tools to automate monitoring and alerting:

-* **Azure Event Hubs integrated with a SIEM** - integrate Microsoft Entra ID logs with SIEMs such as Splunk, ArcSight, QRadar and Sumo Logic with Azure Event Hubs

- * [Tutorial: Stream Microsoft Entra ID logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md)

-| Failed sign-in attempts| Medium - if Isolated incident<br>High - if many accounts are experiencing the same pattern | Microsoft Entra Sign-ins log | Status = failed<br>-and-<br>Sign-in error code 50126 - Error validating credentials due to invalid username or password.<br>-and-<br>Application == "CPIM PowerShell Client"<br>-or-<br>Application == "ProxyIdentityExperienceFramework" | Define a baseline threshold, and then monitor and adjust to suit your organizational behaviors and limit false alerts from being generated. |

-| Smart lock-out events| Medium - if Isolated incident<br>High - if many accounts are experiencing the same pattern or a VIP | Microsoft Entra Sign-ins log | Status = failed<br>-and-<br>Sign-in error code = 50053 ΓÇô IdsLocked<br>-and-<br>Application == "CPIM PowerShell Client"<br>-or-<br>Application =="ProxyIdentityExperienceFramework" | Define a baseline threshold, and then monitor and adjust to suit your organizational behaviors and limit false alerts. |

-| Failed authentications from countries or regions you don't operate from| Medium | Microsoft Entra Sign-ins log | Status = failed<br>-and-<br>Location = \<unapproved location><br>-and-<br>Application == "CPIM PowerShell Client"<br>-or-<br>Application == "ProxyIdentityExperienceFramework" | Monitor entries not equal to provided city names. |

-| Increased failed authentications of any type | Medium | Microsoft Entra Sign-ins log | Status = failed<br>-and-<br>Application == "CPIM PowerShell Client"<br>-or-<br>Application == "ProxyIdentityExperienceFramework" | If you don't have a threshold, monitor and alert if failures increase by 10%, or greater. |

-| Account disabled/blocked for sign-ins | Low | Microsoft Entra Sign-ins log | Status = Failure<br>-and-<br>error code = 50057, The user account is disabled. | This scenario could indicate someone trying to gain access to an account after they left an organization. The account is blocked, but it's important to log and alert this activity. |

-| Measurable increase of successful sign-ins | Low | Microsoft Entra Sign-ins log | Status = Success<br>-and-<br>Application == "CPIM PowerShell Client"<br>-or-<br>Application == "ProxyIdentityExperienceFramework" | If you don't have a threshold, monitor and alert if successful authentications increase by 10%, or greater. |

-| Sign-in failure, bad password threshold | High | Microsoft Entra Sign-ins log | Status = Failure<br>-and-<br>error code = 50126 | Define a baseline threshold and monitor and adjust to suit your organizational behaviors. Limit false alerts. |

-| Failure because of Conditional Access requirement | High | Microsoft Entra Sign-ins log | Status = Failure<br>-and-<br>error code = 53003<br>-and-<br>Failure reason = Blocked by Conditional Access | The event can indicate an attacker is trying to get into the account. |

-| Interrupt | High, medium | Microsoft Entra Sign-ins log | Status = Failure<br>-and-<br>error code = 53003<br>-and-<br>Failure reason = Blocked by Conditional Access | The event can indicate an attacker has the account password, but can't pass the MFA challenge. |

-| Account lockout | High | Microsoft Entra Sign-ins log | Status = Failure<br>-and-<br>error code = 50053 | Define a baseline threshold, then monitor and adjust to suit your organizational behaviors. Limit false alerts. |

-| Account disabled or blocked for sign-ins | low | Microsoft Entra Sign-ins log | Status = Failure<br>-and-<br>Target = User UPN<br>-and-<br>error code = 50057 | The event could indicate someone trying to gain account access after they've left the organization. Although the account is blocked, log and alert this activity. |

-| MFA fraud alert or block | High | Microsoft Entra Sign-ins log/Azure Log Analytics | Sign-ins>Authentication details<br> Result details = MFA denied, fraud code entered | Privileged user indicates they haven't instigated the MFA prompt, which could indicate an attacker has the account password. |

-| MFA fraud alert or block | High | Microsoft Entra Sign-ins log/Azure Log Analytics | Activity type = Fraud reported - User is blocked for MFA or fraud reported - No action taken, based on fraud report tenant-level settings | Privileged user indicated no instigation of the MFA prompt. The scenario can indicate an attacker has the account password. |

-| Privileged account sign-ins outside of expected controls | High | Microsoft Entra Sign-ins log | Status = Failure<br>UserPricipalName = \<Admin account> <br> Location = \<unapproved location> <br> IP address = \<unapproved IP><br>Device info = \<unapproved Browser, Operating System> | Monitor and alert entries you defined as unapproved. |

-| Outside of normal sign-in times | High | Microsoft Entra Sign-ins log | Status = Success<br>-and-<br>Location =<br>-and-<br>Time = Outside of working hours | Monitor and alert if sign-ins occur outside expected times. Find the normal working pattern for each privileged account and alert if there are unplanned changes outside normal working times. Sign-ins outside normal working hours could indicate compromise or possible insider threat. |

-| Applications that are using the ROPC authentication flow | Medium | Microsoft Entra Sign-ins log | Status=Success<br>Authentication Protocol-ROPC | High level of trust is placed in this application because the credentials can be cached or stored. If possible, move to a more secure authentication flow. Use the process only in automated application testing, if ever. |

-| Dangling URI | High | Microsoft Entra ID Logs and Application Registration | Service-Core Directory<br>Category-ApplicationManagement<br>Activity: Update Application<br>Success ΓÇô Property Name AppAddress | For example, look for dangling URIs pointing to a domain name that is gone, or one you donΓÇÖt own. |

-| Redirect URI configuration changes | High | Microsoft Entra ID logs | Service-Core Directory<br>Category-ApplicationManagement<br>Activity: Update Application<br>Success ΓÇô Property Name AppAddress | Look for URIs not using HTTPS*, URIs with wildcards at the end or the domain of the URL, URIs that are **not** unique to the application, URIs that point to a domain you don't control. |

-| Changes to AppID URI | High | Microsoft Entra ID logs | Service-Core Directory<br>Category-ApplicationManagement<br>Activity: Update Application<br>Activity: Update Service principal | Look for AppID URI modifications, such as adding, modifying, or removing the URI. |

-| Changes to application ownership | Medium | Microsoft Entra ID logs | Service-Core Directory<br>Category-ApplicationManagement<br>Activity: Add owner to application | Look for instances of users added as application owners outside normal change management activities. |

-| Changes to sign out URL | Low | Microsoft Entra ID logs | Service-Core Directory<br>Category-ApplicationManagement<br>Activity: Update Application<br>-and-<br>Activity: Update service principle | Look for modifications to a sign out URL. Blank entries or entries to non-existent locations would stop a user from terminating a session.

-From the Azure portal, you can view the Microsoft Entra audit logs and download as comma-separated value (CSV) or JavaScript Object Notation (JSON) files. The Azure portal has several ways to integrate Microsoft Entra ID logs with other tools that allow for greater automation of monitoring and alerting:

-* **[Azure Event Hubs](../../event-hubs/event-hubs-about.md) -integrated with a SIEM**- [Microsoft Entra ID logs can be integrated to other SIEMs](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) such as Splunk, ArcSight, QRadar, and Sumo Logic via the Azure Event Hubs integration.

-From the Azure portal, you can view the Microsoft Entra audit logs and download as comma separated value (CSV) or JavaScript Object Notation (JSON) files. The Azure portal has several ways to integrate Microsoft Entra ID logs with other tools that allow for greater automation of monitoring and alerting:

-* **[Azure Event Hubs](../../event-hubs/event-hubs-about.md)** integrated with a SIEM - [Microsoft Entra ID logs can be integrated to other SIEMs](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) such as Splunk, ArcSight, QRadar and Sumo Logic via the Azure Event Hubs integration.

-Legacy authentication is captured in the Microsoft Entra Sign-ins log as part of the detail of the event. You can use the Azure Monitor workbook to help with identifying legacy authentication usage. For more information, see [Sign-ins using legacy authentication](../reports-monitoring/howto-use-azure-monitor-workbooks.md), which is part of [How to use Azure Monitor Workbooks for Microsoft Entra ID reports](../reports-monitoring/howto-use-azure-monitor-workbooks.md). You can also use the Insecure protocols workbook for Microsoft Sentinel. For more information, see [Microsoft Sentinel Insecure Protocols Workbook Implementation Guide](https://techcommunity.microsoft.com/t5/azure-sentinel/azure-sentinel-insecure-protocols-workbook-implementation-guide/ba-p/1197564). Specific activities to monitor include:

-| Legacy authentications|High | Microsoft Entra Sign-ins log| ClientApp : POP<br>ClientApp : IMAP<br>ClientApp : MAPI<br>ClientApp: SMTP<br>ClientApp : ActiveSync go to EXO<br>Other Clients = SharePoint and EWS| In federated domain environments, failed authentications aren't recorded and don't appear in the log. |

-| Errors associated with SSO and Kerberos validation failures|Medium | Microsoft Entra Sign-ins log| | Single sign-on list of error codes at [Single sign-on](../hybrid/connect/tshoot-connect-sso.md). |

-In Microsoft Entra ID, you can protect access to your resources by configuring Conditional Access policies. As an IT administrator, you want to ensure your Conditional Access policies work as expected to ensure that your resources are protected. Monitoring and alerting on changes to the Conditional Access service ensures policies defined by your organization for access to data are enforced. Microsoft Entra ID logs when changes are made to Conditional Access and also provides workbooks to ensure your policies are providing the expected coverage.

-From the Azure portal, you can view the Microsoft Entra audit logs. Download logs as comma separated value (CSV) or JavaScript Object Notation (JSON) files. The Azure portal has several ways to integrate Microsoft Entra ID logs with other tools that allow for greater automation of monitoring and alerting:

-* **[Azure Event Hubs](../../event-hubs/event-hubs-about.md)** integrated with a SIEM. Microsoft Entra ID logs can be integrated to other SIEMs such as Splunk, ArcSight, QRadar and Sumo Logic via the Azure Event Hubs integration. For more information, see [Stream Microsoft Entra ID logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md).

-| Sign-in failure, bad password threshold | High | Microsoft Entra Sign-ins log | Status = Failure<br>-and-<br>error code = 50126 | Define a baseline threshold and then monitor and adjust to suit your organizational behaviors and limit false alerts from being generated.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/PrivilegedAccountsSigninFailureSpikes.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Failure because of Conditional Access requirement |High | Microsoft Entra Sign-ins log | Status = Failure<br>-and-<br>error code = 53003<br>-and-<br>Failure reason = Blocked by Conditional Access | This event can be an indication an attacker is trying to get into the account.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SigninLogs/UserAccounts-CABlockedSigninSpikes.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Account lockout | High | Microsoft Entra Sign-ins log | Status = Failure<br>-and-<br>error code = 50053 | Define a baseline threshold, and then monitor and adjust to suit your organizational behaviors and limit false alerts from being generated.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/MultipleDataSources/PrivilegedAccountsLockedOut.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Account disabled or blocked for sign-ins | Low | Microsoft Entra Sign-ins log | Status = Failure<br>-and-<br>Target = User UPN<br>-and-<br>error code = 50057 | This event could indicate someone is trying to gain access to an account after they've left the organization. Although the account is blocked, it's still important to log and alert on this activity.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/SigninLogs/UserAccounts-BlockedAccounts.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| MFA fraud alert or block | High | Microsoft Entra Sign-ins log/Azure Log Analytics | Sign-ins>Authentication details Result details = MFA denied, fraud code entered | Privileged user has indicated they haven't instigated the multi-factor authentication prompt, which could indicate an attacker has the password for the account.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SigninLogs/MFARejectedbyUser.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Privileged account sign-ins outside of expected controls | | Microsoft Entra Sign-ins log | Status = Failure<br>UserPricipalName = \<Admin account\><br>Location = \<unapproved location\><br>IP address = \<unapproved IP\><br>Device info = \<unapproved Browser, Operating System\> | Monitor and alert on any entries that you've defined as unapproved.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/SigninLogs/SuspiciousSignintoPrivilegedAccount.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Outside of normal sign-in times | High | Microsoft Entra Sign-ins log | Status = Success<br>-and-<br>Location =<br>-and-<br>Time = Outside of working hours | Monitor and alert if sign-ins occur outside of expected times. It's important to find the normal working pattern for each privileged account and to alert if there are unplanned changes outside of normal working times. Sign-ins outside of normal working hours could indicate compromise or possible insider threats.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/MultipleDataSources/AnomolousSignInsBasedonTime.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Change in legacy authentication protocol | High | Microsoft Entra Sign-ins log | Client App = Other client, IMAP, POP3, MAPI, SMTP, and so on<br>-and-<br>Username = UPN<br>-and-<br>Application = Exchange (example) | Many attacks use legacy authentication, so if there's a change in auth protocol for the user, it could be an indication of an attack.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/17ead56ae30b1a8e46bb0f95a458bdeb2d30ba9b/Hunting%20Queries/SigninLogs/LegacyAuthAttempt.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| New device or location | High | Microsoft Entra Sign-ins log | Device info = Device ID<br>-and-<br>Browser<br>-and-<br>OS<br>-and-<br>Compliant/Managed<br>-and-<br>Target = User<br>-and-<br>Location | Most admin activity should be from [privileged access devices](/security/compass/privileged-access-devices), from a limited number of locations. For this reason, alert on new devices or locations.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/SigninLogs/SuspiciousSignintoPrivilegedAccount.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Administrators authenticating to other Microsoft Entra tenants| Medium| Microsoft Entra Sign-ins log| Status = success<br><br>Resource tenantID != Home Tenant ID| When scoped to Privileged Users, this monitor detects when an administrator has successfully authenticated to another Microsoft Entra tenant with an identity in your organization's tenant. <br><br>Alert if Resource TenantID isn't equal to Home Tenant ID<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/SigninLogs/AdministratorsAuthenticatingtoAnotherAzureADTenant.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-Configure monitoring on the data within the Microsoft Entra Sign-ins Logs to ensure that alerting occurs and adheres to your organization's security policies. Some examples of this are:

-| Users authenticating to other Microsoft Entra tenants.| Low| Microsoft Entra Sign-ins log| Status = success<br>Resource tenantID != Home Tenant ID| Detects when a user has successfully authenticated to another Microsoft Entra tenant with an identity in your organization's tenant.<br>Alert if Resource TenantID isn't equal to Home Tenant ID <br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/AuditLogs/UsersAuthenticatingtoOtherAzureADTenants.yaml)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

-| Failed sign-in attempts.| Medium - if Isolated Incident<br>High - if many accounts are experiencing the same pattern or a VIP.| Microsoft Entra Sign-ins log| Status = failed<br>-and-<br>Sign-in error code 50126 - <br>Error validating credentials due to invalid username or password.| Define a baseline threshold, and then monitor and adjust to suite your organizational behaviors and limit false alerts from being generated.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/SigninLogs/SpikeInFailedSignInAttempts.yaml)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Smart lock-out events.| Medium - if Isolated Incident<br>High - if many accounts are experiencing the same pattern or a VIP.| Microsoft Entra Sign-ins log| Status = failed<br>-and-<br>Sign-in error code = 50053 ΓÇô IdsLocked| Define a baseline threshold, and then monitor and adjust to suite your organizational behaviors and limit false alerts from being generated.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/SigninLogs/SmartLockouts.yaml)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

-| Interrupts| Medium - if Isolated Incident<br>High - if many accounts are experiencing the same pattern or a VIP.| Microsoft Entra Sign-ins log| 500121, Authentication failed during strong authentication request. <br>-or-<br>50097, Device authentication is required or 50074, Strong Authentication is required. <br>-or-<br>50155, DeviceAuthenticationFailed<br>-or-<br>50158, ExternalSecurityChallenge - External security challenge wasn't satisfied<br>-or-<br>53003 and Failure reason = blocked by Conditional Access| Monitor and alert on interrupts.<br>Define a baseline threshold, and then monitor and adjust to suite your organizational behaviors and limit false alerts from being generated.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/MultipleDataSources/AADPrivilegedAccountsFailedMFA.yaml)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Multi-factor authentication (MFA) fraud alerts.| High| Microsoft Entra Sign-ins log| Status = failed<br>-and-<br>Details = MFA Denied<br>| Monitor and alert on any entry.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SigninLogs/MFARejectedbyUser.yaml)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

-| Failed authentications from countries/regions you don't operate out of.| Medium| Microsoft Entra Sign-ins log| Location = \<unapproved location\>| Monitor and alert on any entries. <br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SigninLogs/AuthenticationAttemptfromNewCountry.yaml)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Failed authentications for legacy protocols or protocols that aren't used.| Medium| Microsoft Entra Sign-ins log| Status = failure<br>-and-<br>Client app = Other Clients, POP, IMAP, MAPI, SMTP, ActiveSync| Monitor and alert on any entries.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/9bd30c2d4f6a2de17956cd11536a83adcbfc1757/Hunting%20Queries/SigninLogs/LegacyAuthAttempt.yaml)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Failures blocked by Conditional Access.| Medium| Microsoft Entra Sign-ins log| Error code = 53003 <br>-and-<br>Failure reason = blocked by Conditional Access| Monitor and alert on any entries.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SigninLogs/UserAccounts-CABlockedSigninSpikes.yaml)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Increased failed authentications of any type.| Medium| Microsoft Entra Sign-ins log| Capture increases in failures across the board. That is, the failure total for today is >10% on the same day, the previous week.| If you don't have a set threshold, monitor and alert if failures increase by 10% or greater.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/SigninLogs/SpikeInFailedSignInAttempts.yaml) |

-| Authentication occurring at times and days of the week when countries/regions don't conduct normal business operations.| Low| Microsoft Entra Sign-ins log| Capture interactive authentication occurring outside of normal operating days\time. <br>Status = success<br>-and-<br>Location = \<location\><br>-and-<br>Day\Time = \<not normal working hours\>| Monitor and alert on any entries.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/MultipleDataSources/AnomolousSignInsBasedonTime.yaml) |

-| Account disabled/blocked for sign-ins| Low| Microsoft Entra Sign-ins log| Status = Failure<br>-and-<br>error code = 50057, The user account is disabled.| This could indicate someone is trying to gain access to an account once they have left an organization. Although the account is blocked, it is important to log and alert on this activity.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/SigninLogs/UserAccounts-BlockedAccounts.yaml)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Authentications of privileged accounts outside of expected controls.| High| Microsoft Entra Sign-ins log| Status = success<br>-and-<br>UserPricipalName = \<Admin account\><br>-and-<br>Location = \<unapproved location\><br>-and-<br>IP Address = \<unapproved IP\><br>Device Info= \<unapproved Browser, Operating System\><br>| Monitor and alert on successful authentication for privileged accounts outside of expected controls. Three common controls are listed. <br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SigninLogs/AuthenticationsofPrivilegedAccountsOutsideofExpectedControls.yaml)<br>[Sigma ruless](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| When only single-factor authentication is required.| Low| Microsoft Entra Sign-ins log| Status = success<br>Authentication requirement = Single-factor authentication| Monitor periodically and ensure expected behavior.<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Successful authentications from countries/regions your organization doesn't operate out of.| Medium| Microsoft Entra Sign-ins log| Status = success<br>Location = \<unapproved country/region\>| Monitor and alert on any entries not equal to the city names you provide.<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Successful authentication, session blocked by Conditional Access.| Medium| Microsoft Entra Sign-ins log| Status = success<br>-and-<br>error code = 53003 ΓÇô Failure reason, blocked by Conditional Access| Monitor and investigate when authentication is successful, but session is blocked by Conditional Access.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SigninLogs/UserAccounts-CABlockedSigninSpikes.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Successful authentication after you have disabled legacy authentication.| Medium| Microsoft Entra Sign-ins log| status = success <br>-and-<br>Client app = Other Clients, POP, IMAP, MAPI, SMTP, ActiveSync| If your organization has disabled legacy authentication, monitor and alert when successful legacy authentication has taken place.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/9bd30c2d4f6a2de17956cd11536a83adcbfc1757/Hunting%20Queries/SigninLogs/LegacyAuthAttempt.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Authentications to MBI and HBI application using single-factor authentication.| Low| Microsoft Entra Sign-ins log| status = success<br>-and-<br>Application ID = \<HBI app\> <br>-and-<br>Authentication requirement = single-factor authentication.| Review and validate this configuration is intentional.<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Authentications at days and times of the week or year that countries/regions do not conduct normal business operations.| Low| Microsoft Entra Sign-ins log| Capture interactive authentication occurring outside of normal operating days\time. <br>Status = success<br>Location = \<location\><br>Date\Time = \<not normal working hours\>| Monitor and alert on authentications days and times of the week or year that countries/regions do not conduct normal business operations.<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-| Measurable increase of successful sign ins.| Low| Microsoft Entra Sign-ins log| Capture increases in successful authentication across the board. That is, success totals for today are >10% on the same day, the previous week.| If you don't have a set threshold, monitor and alert if successful authentications increase by 10% or greater.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/SigninLogs/UserAccountsMeasurableincreaseofsuccessfulsignins.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

-Methods enabled in the Authentication methods policy can typically be used anywhere in Microsoft Entra ID - for both authentication and password reset scenarios. The exception is that some methods are inherently limited to use in authentication, such as FIDO2 and Windows Hello for Business, and others are limited to use in password reset, such as security questions. For more control over which methods are usable in a given authentication scenario, consider using the **Authentication Strengths** feature.

-Two other policies, located in **multifactor authentication** settings and **Password reset** settings, provide a legacy way to manage some authentication methods for all users in the tenant. You can't control who uses an enabled authentication method, or how the method can be used. A [Global Administrator](../roles/permissions-reference.md#global-administrator) is needed to manage these policies.

-To manage the legacy MFA policy, click **Security** > **multifactor authentication** > **Additional cloud-based multifactor authentication settings**.

-To check the status of this feature in your own tenant, sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least an [Authentication Policy Administrator](../roles/permissions-reference.md#authentication-policy-administrator), then click **Protection** > **multifactor authentication** > **Phone call settings**. Check **Operator required to transfer extensions** to see if the setting is **On** or **Off**.

-1. Start Windows PowerShell with administrator privileges.

- > If CBA is enabled on the tenant, all users will see the link to **Use a certificate or smart card** on the password page. However, only the users in scope for CBA will be able to authenticate successfully against an application that uses Microsoft Entra ID as their Identity provider (IdP).

-1. Microsoft Entra ID will request a client certificate, the user picks the client certificate, and clicks **Ok**.

-1. If a unique user is found with a Conditional Access policy that requires multifactor authentication, and the [certificate authentication binding rule](how-to-certificate-based-authentication.md#step-3-configure-authentication-binding-policy) satisfies MFA, then Microsoft Entra ID signs the user in immediately. If MFA is required but the certificate satisfies only a single factor, either passwordless sign-in or FIDO2 will be offered as a second factor if they are already registered.

-Microsoft Entra CBA is an MFA (multifactor authentication) capable method, that is Microsoft Entra CBA can be either Single (SF) or multifactor (MF) depending on the tenant configuration. Enabling CBA for a user indicates the user is potentially capable of MFA. This means a user may need additional configuration to get MFA and proof up to register other authentication methods when the user is in scope for CBA.

-If CBA enabled user only has a Single Factor (SF) certificate and need MFA

- 1. Use Password + SF certificate.

- 1. Issue Temporary Access Pass (TAP)

- 1. Admin adds Phone Number to user account and allows Voice/text message method for user.

-If CBA enabled user has not yet been issued a certificate and need MFA

- 1. Issue Temporary Access Pass (TAP)

- 1. Admin adds Phone Number to user account and allows Voice/text message method for user.

-If CBA enabled user cannot use MF cert (such as on mobile device without smart card support) and need MFA

- 1. Issue Temporary Access Pass (TAP)

- 1. User Register another MFA method (when user can use MF cert)

- 1. Use Password + MF cert (when user can use MF cert)

- 1. Admin adds Phone Number to user account and allows Voice/text message method for user

-1. CBA (first factor) + passwordless phone sign-in (PSI as second factor)

-1. CBA (first factor) + FIDO2 security keys (second factor)

-1. Password (first factor) + CBA (second factor)

->A user will be considered MFA capable when a user is in scope for Certificate-based authentication auth method. This means user will not be able to use proof up as part of their authentication to registerd other available methods. Make sure users who do not have a valid certificate are not part of CBA auth method scope. More info on [Microsoft Entra multifactor authentication](../authentication/concept-mfa-howitworks.md)

- >In the above configuration under step 4, please choose **Passwordless** option. Change the mode for each groups added for PSI for **Authentication mode**, choose **Passwordless** for passwordless sign-in to work with CBA. If the admin configures "Any", CBA + PSI will not work.

-1. Select **Protection** > **multifactor authentication** > **Additional cloud-based multifactor authentication settings**.

-1. Because the certificate is configured to be single-factor authentication strength, the user needs a second factor to meet MFA requirements. The user will see available second factors, which in this case is passwordless sign-in. Select **Approve a request on my Microsoft Authenticator app**.

-1. Select **Yes** and user will be authenticated and signed in.

-The authentication binding policy helps determine the strength of authentication as either single-factor or multifactor. An administrator can change the default value from single factor to multifactor, or set up custom policy configurations either by using issuer subject or policy OID fields in the certificate.

-1. Exact match is used for strong authentication by using policy OID. If you have a certificate A with policy OID **1.2.3.4.5** and a derived credential B based on that certificate has a policy OID **1.2.3.4.5.6**, and the custom rule is defined as **Policy OID** with value **1.2.3.4.5** with MFA, only certificate A will satisfy MFA, and credential B will satisfy only single-factor authentication. If the user used derived credential during sign-in and was configured to have MFA, the user will be asked for a second factor for successful authentication.

-1. Policy OID rules will take precedence over certificate issuer rules. If a certificate has both policy OID and Issuer, the policy OID is always checked first, and if no policy rule is found then the issuer subject bindings are checked. Policy OID has a higher strong authentication binding priority than the issuer.

-There are four supported methods. In general, mapping types are considered high-affinity if they're based on identifiers that you can't reuse (Such as Subject Key Identifiers or SHA1 Public Key). These identifiers convey a higher assurance that only a single certificate can be used to authenticate the respective user. Therefore, all mapping types based on usernames and email addresses are considered low-affinity. Therefore, Microsoft Entra ID implements two mappings considered low-affinity (based on reusable identifiers), and the other two are considered high-affinity bindings. For more information, see [certificateUserIds](concept-certificate-based-authentication-certificateuserids.md).

-|Certificate mapping Field | Examples of values in certificateUserIds | User object attributes | Type |

-|PrincipalName | ΓÇ£X509:\<PN>bob@woodgrove.comΓÇ¥ | userPrincipalName <br> onPremisesUserPrincipalName <br> certificateUserIds | low-affinity |

-|RFC822Name | ΓÇ£X509:\<RFC822>user@woodgrove.comΓÇ¥ | userPrincipalName <br> onPremisesUserPrincipalName <br> certificateUserIds | low-affinity |

-|X509SKI | ΓÇ£X509:\<SKI>123456789abcdefΓÇ¥| certificateUserIds | high-affinity |

-|X509SHA1PublicKey |ΓÇ£X509:\<SHA1-PUKEY>123456789abcdefΓÇ¥ | certificateUserIds | high-affinity |

-1. If the X.509 certificate field is on the presented certificate, Microsoft Entra ID will match the value in the certificate field to the user object attribute value.

->When using multiple bindings, Microsoft Entra CBA authentication is only as secure as your low-affinity binding as Microsoft Entra CBA will validate each of the bindings to authenticate the user. In order to eliminate a scenario where a single certificate matching multiple Microsoft Entra accounts, the tenant administrator should:

->The maximum size of a CRL for Microsoft Entra ID to successfully download on an interactive sign-in and cache is 20 MB in Azure Global and 45 MB in Azure US Government clouds, and the time required to download the CRL must not exceed 10 seconds. If Microsoft Entra ID can't download a CRL, certificate-based authentications using certificates issued by the corresponding CA will fail. As a best practice to keep CRL files within size limits, keep certificate lifetimes within reasonable limits and to clean up expired certificates. For more information, see [Is there a limit for CRL size?](certificate-based-authentication-faq.yml#is-there-a-limit-for-crl-size-).

-When a user performs an interactive sign-in with a certificate, and the CRL exceeds the interactive limit for a cloud, their initial sign-in will fail with the following error:

-After the error, Microsoft Entra ID will attempt to download the CRL subject to the service-side limits (45 MB in Azure Global and 150 MB in Azure US Government clouds).

->If the admin skips the configuration of the CRL, Microsoft Entra ID will not perform any CRL checks during the certificate-based authentication of the user. This can be helpful for initial troubleshooting, but shouldn't be considered for production use.

-1. Microsoft Entra ID will attempt to download the CRL at the first sign-in event of any user with a certificate of the corresponding trusted issuer or certificate authority.

-1. Microsoft Entra ID will cache and re-use the CRL for any subsequent usage. It will honor the **Next update date** and, if available, **Next CRL Publish date** (used by Windows Server CAs) in the CRL document.

-1. The user certificate-based authentication will fail if:

- - Microsoft Entra ID will attempt to download a new CRL from the distribution point if the cached CRL document is expired.

->Microsoft Entra ID will check the CRL of the issuing CA and other CAs in the PKI trust chain up to the root CA. We have a limit of up to 10 CAs from the leaf client certificate for CRL validation in the PKI chain. The limitation is to make sure a bad actor will not bring down the service by uploading a PKI chain with a huge number of CAs with a bigger CRL size.

-If the tenantΓÇÖs PKI chain has more than 5 CAs and in case of a CA compromise, the administrator should remove the compromised trusted issuer from the Microsoft Entra tenant configuration.

-If CBA fails on a browser, even if the failure is because you cancel the certificate picker, you need to close the browser session and open a new session to try CBA again. A new session is required because browsers cache the certificate. When CBA is re-tried, the browser will send the cached certificate during the TLS challenge, which causes sign-in failure and the validation error.

-Once a user authenticates successfully using CBA, the user's MostRecentlyUsed (MRU) authentication method will be set to CBA. Next time, when the user enters their UPN and clicks **Next**, the user will be taken to the CBA method directly, and need not select **Use the certificate or smart card**.

-description: When should you use an Auth Provider with Azure MFA?

-A Microsoft Entra multifactor authenticationentication Provider is used to take advantage of features provided by Microsoft Entra multifactor authentication for users who **do not have licenses**.

-Password expiration policies are unchanged but they're included in this topic for completeness. A *Global Administrator* or *User Administrator* can use the [Microsoft Entra Module for Windows PowerShell](/powershell/module/Azuread/) to set user passwords not to expire.

-| Password expiry duration (Maximum password age) |Default value: **90** days.<br>The value is configurable by using the `Set-MsolPasswordPolicy` cmdlet from the Microsoft Entra Module for Windows PowerShell. |

-| Password expiry duration (Maximum password age) |Default value: **90** days. If the tenant was created after 2021, it has no default expiration value. You can check current policy with [Get-MsolPasswordPolicy](/powershell/module/msonline/get-msolpasswordpolicy).<br>The value is configurable by using the `Set-MsolPasswordPolicy` cmdlet from the Microsoft Entra Module for Windows PowerShell.|

-A *Global Administrator* or *User Administrator* can use the [Microsoft Entra Module for Windows PowerShell](/powershell/module/Azuread/) to set user passwords not to expire.

-1. Browse to **Protection** > then **multifactor authentication**.

-|Workday to Microsoft Entra User Provisioning | &#x2705; |

-|SuccessFactors to Microsoft Entra User Provisioning | &#x2705; |

-|Provisioning agent configuration and registration with Gov cloud tenant| Works with special undocumented command-line invocation:<br> AADConnectProvisioningAgent.Installer.exe ENVIRONMENTNAME=AzureUSGovernment |

-1. The protection level attribute has a default value of **Single-factor authentication**. Select **multifactor authentication** to change the default value to MFA.

- 1. Click **multifactor authentication**.

- 1. Click **multifactor authentication**.

-1. For **State**, click **Microsoft managed** or **Enabled**. In the following screenshot, the registration campaign is **Microsoft managed**. That setting allows Microsoft to set the default value to be either Enabled or Disabled. For the registration campaign, the Microsoft managed value is Enabled for voice call and text message users with free and trial subscriptions. For more information, see [Protecting authentication methods in Microsoft Entra ID](concept-authentication-default-enablement.md).

-|state|"enabled"<br>"disabled"<br>"default"|Allows you to enable or disable the feature.<br>Default value is used when the configuration hasn't been explicitly set and will use Microsoft Entra ID default value for this setting. Currently maps to disabled.<br>Change states to either enabled or disabled as needed.|

- # Install the Azure AD Kerberos PowerShell Module.

-6. On the **multifactor authentication** page, select the **Allow users to create app passwords to sign in to non-browser apps** option.

-1. Browse to **Protection** > **multifactor authentication** > **Account lockout**.

-1. Go to **Protection** > **Multi-Factor Authentication** > **Notifications**.

-An Authentication Policy Administrator can sign in to the [Microsoft Entra admin center](https://entra.microsoft.com), go to **Protection** > **multifactor authentication** > **OATH tokens**, and upload the CSV file.

-You can access service settings from the [Microsoft Entra admin center](https://entra.microsoft.com) by going to **Protection** > **multifactor authentication** > **Getting started** > **Configure** > **Additional cloud-based MFA settings**. A window or tab opens with additional service settings options.

-1. Browse to **Protection** > **multifactor authentication** > **Service settings**.

-1. Under **multifactor authentication** at the top of the page, select **Service settings**.

-1. Under **multifactor authentication** at the top of the page, select **service settings**.

-Next, you need to configure certificates for use by the NPS extension to ensure secure communications and assurance. The NPS components include a Windows PowerShell script that configures a self-signed certificate for use with NPS.

-To view the successful sign-in events in the Windows Event Viewer logs, you can issue the following Windows PowerShell command to query the Windows Terminal Services and Windows Security logs.

-If the Microsoft Azure Active Directory PowerShell Module is not already present, it is installed with a configuration script that you run as part of the setup process. There is no need to install the module ahead of time if it is not already installed.

-To ensure secure communications and assurance, configure certificates for use by the NPS extension. The NPS components include a Windows PowerShell script that configures a self-signed certificate for use with NPS.

-The Azure AD PowerShell Module for Windows PowerShell is also installed through a configuration script you run as part of the setup process, if not already present. There's no need to install this module ahead of time if it's not already installed.

-1. Browse to **Protection** > **multifactor authentication** and enable for the test account.

-1. Select **multifactor authentication**. You may need to scroll to the right to see this menu option. Select the example screenshot below to see the full window and menu location:

-12. To use your newly registered adapter, edit the global authentication policy in AD FS. In the AD FS management console, go to the **Authentication Policies** node. In the **multifactor authentication** section, click the **Edit** link next to the **Global Settings** section. In the **Edit Global Authentication Policy** window, select **multifactor authentication** as an additional authentication method, and then click **OK**. The adapter is registered as WindowsAzureMultiFactorAuthentication. Restart the AD FS service for the registration to take effect.

-1. Browse to **Protection** > **multifactor authentication** > **Server settings**.

-> An administrator can unlock the users' cloud account if they have been locked out by the Smart Lockout capability, without the need of waiting for the lockout duration to expire. For more information, see [Reset a user's password using Azure Active Directory](../fundamentals/users-reset-password-azure-portal.md).

-1. On the **Connect to Microsoft Entra ID** page, enter a global administrator credential for your Azure tenant, and then select **Next**.

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least an [Authentication Policy Administrator](../roles/permissions-reference.md#authentication-policy-administrator).

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least an [Authentication Policy Administrator](../roles/permissions-reference.md#authentication-policy-administrator).

-1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least an [Authentication Policy Administrator](../roles/permissions-reference.md#authentication-policy-administrator).

-1. Browse to **Protection** > **multifactor authentication** > **MFA registration policy**.

-Many developers have previously worked with the Azure AD v1.0 platform to authenticate work and school accounts (provisioned by Azure AD) by requesting tokens from the Azure AD v1.0 endpoint, using Azure AD Authentication Library (ADAL), Azure portal for application registration and configuration, and the Microsoft Graph API for programmatic application configuration.

-# Azure Active Directory Authentication Libraries

-> Looking for the Azure AD v2.0 libraries (MSAL)? Checkout the [MSAL library guide](../develop/reference-v2-libraries.md).

-> It's a good idea to log all errors and exceptions when using ADAL and Azure AD. Logs are not only helpful for understanding the overall health of your application, but are also important when debugging broader problems. While your application may recover from certain errors, they may hint at broader design problems that require code changes in order to resolve.

-* [Azure AD Authentication Libraries][AAD-Auth-Libraries]

-* [Azure AD Authentication Scenarios][AAD-Auth-Scenarios]

-* [Integrating Applications with Azure AD Authentication][AAD-Integrating-Apps]

-[![Shows the "Sign in with Microsoft" button][AAD-Sign-In]][AAD-Sign-In]

-[AAD-Auth-Libraries]: ./active-directory-authentication-libraries.md

-[AAD-Auth-Scenarios]:v1-authentication-scenarios.md

-[AAD-Integrating-Apps]:../develop/quickstart-register-app.md?toc=/azure/active-directory/azuread-dev/toc.json&bc=/azure/active-directory/azuread-dev/breadcrumb/toc.json

-[AAD-Sign-In]:./media/active-directory-devhowto-multi-tenant-overview/sign-in-with-microsoft-light.png

-If the access control assigned to the policy uses **Require approved client app**, the user is directed to install and use the Outlook mobile client. In the case that **Multifactor Authentication**, **Terms of use**, or **custom controls** are required, affected users are blocked, because basic authentication doesnΓÇÖt support these controls.

-This article shows an example of how to migrate a classic policy that requires **multifactor authentication** for a cloud app.

-The information in this article can be used to troubleshoot unexpected sign-in outcomes related to Conditional Access using error messages and Microsoft Entra sign-ins log.

- 

-To determine the service dependency, check the sign-ins log for the application and resource called by the sign-in. In the following screenshot, the application called is **Azure Portal** but the resource called is **Windows Azure Service Management API**. To target this scenario appropriately all the applications and resources should be similarly combined in Conditional Access policy.

-If you're building a service on Microsoft Entra ID that exposes APIs for other clients to call, you may wish to support automated access with app roles (app-only permissions). You can define the app roles for your application in the **App roles** section of your app registration in Microsoft Entra portal. For more information on how to create app roles, see [Declare roles for an application](./howto-add-app-roles-in-apps.md#declare-roles-for-an-application).

-> As of January 30, 2021 you cannot configure refresh and session token lifetimes. Microsoft Entra ID no longer honors refresh and session token configuration in existing policies. New tokens issued after existing tokens have expired are now set to the [default configuration](#configurable-token-lifetime-properties). You can still configure access, SAML, and ID token lifetimes after the refresh and session token configuration retirement.

-> For the code sample for this quickstart to work, you need to add a reply URL as **msal://redirect**.

-**Anomalous sign in detection.** The Microsoft identity platform processes more than a billion sign-ins a day, while using machine learning algorithms to detect suspicious activity and notify IT administrators of possible problems. By supporting the Microsoft identity platform sign-in, your application gets the benefit of this protection. Learn more about [viewing Microsoft Entra access report](../reports-monitoring/overview-reports.md).

-For testing, you can use a self-signed public certificate instead of a Certificate Authority (CA)-signed certificate. In this how-to, you'll use Windows PowerShell to create and export a self-signed certificate.

-Use the certificate you create using this method to authenticate from an application running from your machine. For example, authenticate from Windows PowerShell.

-[Microsoft Authentication Library for JavaScript](https://github.com/AzureAD/microsoft-authentication-library-for-js) (MSAL.js, also known as *msal-browser*) 2.x is the authentication library we recommend using with JavaScript applications on the Microsoft identity platform. This article highlights the changes you need to make to migrate an app that uses the ADAL.js to use MSAL.js 2.x

-The following diagram shows the v2.0 vs v1.0 endpoint experience at a high level, including the app registration experience, SDKs, endpoints, and supported identities.

-

-MSAL leverages all the [benefits of Microsoft identity platform (v2.0) endpoint](../azuread-dev/azure-ad-endpoint-comparison.md).

-> > [Tutorial: Sign in users and call Microsoft Graph](./single-page-app-tutorial-01-register-app.md)

-For information about the federation metadata documents that Microsoft Entra ID publishes, see [Federation Metadata](../azuread-dev/azure-ad-federation-metadata.md).

-Install the packages by running `npm install` in the folder where *package.json* file resides. Then, import **msal-node** package:

-The Microsoft identity platform uses public-key cryptography built on industry standards to establish trust between itself and the applications that use it. In practical terms, this works in the following way: The Microsoft identity platform uses a signing key that consists of a public and private key pair. When a user signs in to an application that uses the Microsoft identity platform for authentication, the Microsoft identity platform creates a security token that contains information about the user. This token is signed by the Microsoft identity platform using its private key before it's sent back to the application. To verify that the token is valid and originated from Microsoft identity platform, the application must validate the tokenΓÇÖs signature using the public keys exposed by the Microsoft identity platform that is contained in the tenantΓÇÖs [OpenID Connect discovery document](https://openid.net/specs/openid-connect-discovery-1_0.html) or SAML/WS-Fed [federation metadata document](../azuread-dev/azure-ad-federation-metadata.md).

-### <a name="passport"></a>Web applications / APIs protecting resources using Node.js passport-azure-ad module

-To check and update signing keys with PowerShell, you'll need the [MSIdentityTools](https://www.powershellgallery.com/packages/MSIdentityTools) PowerShell Module.

-1. Install the [MSIdentityTools](https://www.powershellgallery.com/packages/MSIdentityTools) PowerShell Module:

-To check and update signing keys with PowerShell, you'll need the [MSIdentityTools](https://www.powershellgallery.com/packages/MSIdentityTools) PowerShell Module.

-1. Install the [MSIdentityTools](https://www.powershellgallery.com/packages/MSIdentityTools) PowerShell Module:

-description: Call an API from a React single-page app.

-#Customer intent: As a React developer, I want to know how to create a user interface and access the Microsoft Graph API

-# Tutorial: Call an API from a React single-page app

-Before being able to interact with the single-page app (SPA), we need to initiate an API call to Microsoft Graph and create the user interface (UI) for the application. After this is added, we can sign in to the application and get profile data information from the Microsoft Graph API.

-In this tutorial, you learn how to:

-> [!div class="checklist"]

-> * Create the API call to Microsoft Graph

-> * Create a UI for the application

-> * Import and use components in the application

-> * Create a component that renders the user's profile information

-> * Call the API from the application

-## Prerequisites

-* Completion of the prerequisites and steps in [Tutorial: Create components for sign in and sign out in a React single-page app](single-page-app-tutorial-03-sign-in-users.md).

-## Creating a helper the Microsoft Graph client

-To allow the SPA to request access to Microsoft Graph, a reference to the `graphConfig` object needs to be added. This contains the Graph REST API endpoint defined in *authConfig.js* file.

-### [Visual Studio](#tab/visual-studio)

-1. Right click on the *src* folder, select **Add** > **New Item**. Create a new file called *graph.js* and select **Add**.

-1. Replace the contents of the file with the following code snippet to request access to Microsoft Graph;

- :::code language="javascript" source="~/ms-identity-docs-code-javascript/react-spa/src/graph.js" :::

-### [Visual Studio Code](#tab/visual-studio-code)

-1. In the *src* folder, create a new file called *graph.js*.

-1. Add the following code snippet to request access to Microsoft Graph;

- :::code language="javascript" source="~/ms-identity-docs-code-javascript/react-spa/src/graph.js" :::

-## Change filename and add required imports

-By default, the application runs via a JavaScript file called *App.js*. It needs to be changed to *App.jsx* file, which is an extension that allows a developer to write HTML in React.

-1. Rename *App.js* to *App.jsx*.

-1. Replace the existing imports with the following snippet;

- ```javascript

- import React, { useState } from 'react';

- import { PageLayout } from './components/PageLayout';

- import { loginRequest } from './authConfig';

- import { callMsGraph } from './graph';

- import { ProfileData } from './components/ProfileData';

- import { AuthenticatedTemplate, UnauthenticatedTemplate, useMsal } from '@azure/msal-react';

- import './App.css';

- import Button from 'react-bootstrap/Button';

- ```

-### Adding the `ProfileContent` function

-The `ProfileContent` function is used to render the user's profile information. In the *App.jsx* file, add the following code below your imports:

-```javascript

-/**

-* Renders information about the signed-in user or a button to retrieve data about the user

-*/

-const ProfileContent = () => {

- const { instance, accounts } = useMsal();

- const [graphData, setGraphData] = useState(null);

-

- function RequestProfileData() {

- // Silently acquires an access token which is then attached to a request for MS Graph data

- instance

- .acquireTokenSilent({

- ...loginRequest,

- account: accounts[0],

- })

- .then((response) => {

- callMsGraph(response.accessToken).then((response) => setGraphData(response));

- });

- }

-

- return (

- <>

- <h5 className="card-title">Welcome {accounts[0].name}</h5>

- <br/>

- {graphData ? (

- <ProfileData graphData={graphData} />

- ) : (

- <Button variant="secondary" onClick={RequestProfileData}>

- Request Profile Information

- </Button>

- )}

- </>

- );

-};

-```

-### Replacing the default function to render authenticated information

-The following code will render based on whether the user is authenticated or not. Replace the default function `App()` to render authenticated information with the following code:

-```javascript

-/**

-* If a user is authenticated the ProfileContent component above is rendered. Otherwise a message indicating a user is not authenticated is rendered.

-*/

-const MainContent = () => {

- return (

- <div className="App">

- <AuthenticatedTemplate>

- <ProfileContent />

- </AuthenticatedTemplate>

-

- <UnauthenticatedTemplate>

- <h5>

- <center>

- Please sign-in to see your profile information.

- </center>

- </h5>

- </UnauthenticatedTemplate>

- </div>

- );

-};

-

-export default function App() {

- return (

- <PageLayout>

- <center>

- <MainContent />

- </center>

- </PageLayout>

- );

-}

-```

-## Calling the API from the application

-All the required code snippets have been added, so the application can now be called and tested in a web browser.

-1. Navigate to the browser previously opened in [Tutorial: Prepare an application for authentication](./single-page-app-tutorial-02-prepare-spa.md). If your browser is closed, open a new window with the address `http://localhost:3000/`.

-1. Select the **Sign In** button. For the purposes of this tutorial, choose the **Sign in using Popup** option.

- :::image type="content" source="./media/single-page-app-tutorial-04-call-api/sign-in-window.png" alt-text="Screenshot of React App sign-in window.":::

-1. After the popup window appears with the sign-in options, select the account with which to sign-in.

- :::image type="content" source="./media/single-page-app-tutorial-04-call-api/pick-account.png" alt-text="Screenshot requesting user to choose Microsoft account to sign into.":::

-1. A second window may appear indicating that a code will be sent to your email address. If this happens, select **Send code**. Open the email from the sender **Microsoft account team**, and enter the 7-digit single-use code. Once entered, select **Sign in**.

- :::image type="content" source="./media/single-page-app-tutorial-04-call-api/enter-code.png" alt-text="Screenshot prompting user to enter verification code to sign-in.":::

-1. For **Stay signed in**, you can select either **No** or **Yes**.

- :::image type="content" source="./media/single-page-app-tutorial-04-call-api/stay-signed-in.png" alt-text="Screenshot prompting user to decide whether to stay signed in or not.":::

-1. The app will now ask for permission to sign-in and access data. Select **Accept** to continue.

- :::image type="content" source="./media/single-page-app-tutorial-04-call-api/permissions-requested.png" alt-text="Screenshot prompting user to allow the application to access permissions.":::

-1. The SPA will now display a button saying **Request Profile Information**. Select it to display the Microsoft Graph profile data acquired from the Microsoft Graph API.

- :::image type="content" source="./media/single-page-app-tutorial-04-call-api/display-api-call-results.png" alt-text="Screenshot of React App depicting the results of the API call.":::

-## Next steps

-Learn how to use the Microsoft identity platform by trying out the following tutorial series on how to build a web API.

-> [!div class="nextstepaction"]

-> [Tutorial: Register a web API with the Microsoft identity platform](web-api-tutorial-01-register-app.md)

-> > [Tutorial: Sign in users and call Microsoft Graph from a React single-page app](./single-page-app-tutorial-01-register-app.md)

-You can find the source code for all of the MSAL.js libraries in the [microsoft-authentication-library-for-js](https://github.com/AzureAD/microsoft-authentication-library-for-js) repository on GitHub.

-1. Run the following commands to create a new Angular project with the name _msal-angular-tutorial_, install Angular Material component libraries, MSAL Browser, MSAL Angular and generate home and profile components.

-Once you have [Node.js](https://nodejs.org/en/download/) installed, create a folder to host your application, for example *msal-spa-tutorial*.

-> 3rd party identity providers need to support the WS-Trust protocol to enable PRT issuance on Windows 10 or newer devices. Without WS-Trust, PRT cannot be issued to users on Microsoft Entra hybrid joined or Microsoft Entra joined devices. On ADFS only usernamemixed endpoints are required. Both adfs/services/trust/2005/windowstransport and adfs/services/trust/13/windowstransport should be enabled as intranet facing endpoints only and **must NOT be exposed** as extranet facing endpoints through the Web Application Proxy.

-1. Once the command prompt is open, type ΓÇ£*dsregcmd.exe /status*ΓÇ¥.

-1. For expected output, the **AzureAdJoined** field value should be ΓÇ£YESΓÇ¥, **WamDefaultSet** field value should be ΓÇ£YESΓÇ¥, and the **WamDefaultGUID** field value should be a GUID with ΓÇ£(AzureAD)ΓÇ¥ at the end.

-### Microsoft Entra portal

- > Replace `<TenantID>` with the Azure AD tenant ID that's associated with the Azure subscription. If you need to find the tenant ID, you can hover over your account name or select **Identity** > **Overview** > **Properties** > **Tenant ID**.

- 1. Value data: The GUID or **Tenant ID** of your Microsoft Entra instance (This value can be found in the **Microsoft Entra admin center** > **Identity** > **Properties** > **Tenant ID**).

-You can verify the existence of the object and retrieve the discovery values by using the following Windows PowerShell script:

- ```PowerShell

-> - Deleting devices in your on-premises AD or Microsoft Entra ID does not remove registration on the client. It will only prevent access to resources using device as an identity (e.g. Conditional Access). Read additional information on how to [remove registration on the client](faq.yml).

- * *FAILED. ERROR* if the test was unable to run. This test requires network connectivity to Microsoft Entra ID.

-1. Event 1006 in the analytics logs denotes the start of the PRT acquisition flow, and event 1007 in the analytics logs denotes the end of the PRT acquisition flow. All events in the Microsoft Entra ID logs (analytics and operational) that are logged between events 1006 and 1007 were logged as part of the PRT acquisition flow.

- |**4** |**Account**|Displays the Microsoft Entra User Account, which owns the PRT in the format: **`UserObjectId.TenantId-login.windows.net`** |

-If you suspect that a PRT problem exists, we recommend that you first collect Microsoft Entra ID logs, and follow the steps that are outlined in the troubleshooting checklist. Do this for any Microsoft Entra client issue first, ideally within a repro session. Complete this process before you file a support request.

-## Reset redemption using MSIdentityTools PowerShell Module

-MSIdentityTools PowerShell Module is a collection of cmdlets and scripts, which you use in the Microsoft identity platform and Microsoft Entra ID. Use the cmdlets and scripts to augment PowerShell SDK capabilities. See, [microsoftgraph/msgraph-sdk-powershell](https://github.com/microsoftgraph/msgraph-sdk-powershell).

-### Microsoft Entra ID PowerShell cmdlets for the ForceTakeover option

-Be sure to uninstall any older version of the Azure Active Directory PowerShell for Graph Module for Windows PowerShell and install [Azure Active Directory PowerShell for Graph - Public Preview Release 2.0.0.137](https://www.powershellgallery.com/packages/AzureADPreview/2.0.0.137) before you run the PowerShell commands.

-Be sure to uninstall any older version of the Azure Active Directory PowerShell for Graph Module for Windows PowerShell and install [Azure Active Directory PowerShell for Graph - Public Preview Release (later than 2.0.0.137)](https://www.powershellgallery.com/packages/AzureADPreview) before you run the PowerShell commands.

-To set the allow or blocklist by using PowerShell, you must install the preview version of the Azure AD PowerShell Module for Windows PowerShell. Specifically, install the AzureADPreview module version 2.0.0.98 or later.

-2. Run the following command to see if you have any versions of the Azure AD PowerShell Module for Windows PowerShell installed on your computer:

-You can use access reviews to periodically verify whether guest users still need access to your resources. The **Access reviews** feature is available in **Microsoft Entra ID** under **External Identities** > **Access reviews**. You can also search for "access reviews" from **All services** in the Azure portal. To learn how to use access reviews, see [Manage guest access with Microsoft Entra access reviews](../governance/manage-guest-access-with-access-reviews.md).

-The Microsoft Entra audit logs provide records of system and user activities, including activities initiated by guest users. To access audit logs, in **Microsoft Entra ID**, under **Monitoring**, select **Audit logs**. To access audit logs of one specific user, select **Microsoft Entra ID** > **Users** > select the user > **Audit logs**.

-# Authentication and Conditional Access for External Identities

-Microsoft Entra B2B direct connect is a feature of External Identities that lets you set up a mutual trust relationship with another Microsoft Entra organization for seamless collaboration. This feature currently works with Microsoft Teams shared channels. With B2B direct connect, users from both organizations can work together using their home credentials and a shared channel in Teams, without having to be added to each otherΓÇÖs organizations as guests. Use B2B direct connect to share resources with external Microsoft Entra organizations. Or use it to share resources across multiple Microsoft Entra tenants within your own organization.

-This article contains recommendations and best practices for business-to-business (B2B) collaboration in Microsoft Entra ID.

-| Carefully plan your cross-tenant access and external collaboration settings | Microsoft Entra ID gives you a flexible set of controls for managing collaboration with external users and organizations. You can allow or block all collaboration, or configure collaboration only for specific organizations, users, and apps. Before configuring settings for cross-tenant access and external collaboration, take a careful inventory of the organizations you work and partner with. Then determine if you want to enable [B2B direct connect](b2b-direct-connect-overview.md) or [B2B collaboration](what-is-b2b.md) with other Microsoft Entra tenants, and how you want to manage [B2B collaboration invitations](external-collaboration-settings-configure.md). |

-#Customer intent: As a tenant admin, I want to walk through the B2B invitation workflow so that I can understand how to add a guest user in the portal, and understand the end user experience.

-The updated experience for creating new users covered in this article is available as a Microsoft Entra ID preview feature. This feature is enabled by default, but you can opt out by going to **Microsoft Entra ID** > **Preview features** and disabling the **Create user experience** feature. For more information about previews, see [Universal License Terms for Online Services](https://www.microsoft.com/licensing/terms/product/ForOnlineServices/all).

-You can also bulk invite guest users [via the portal](tutorial-bulk-invite.md) or [via PowerShell](bulk-invite-powershell.md).

-description: In this quickstart, you learn how to use PowerShell to send an invitation to an external Microsoft Entra B2B collaboration user. You'll use the Microsoft Graph Identity Sign-ins and the Microsoft Graph Users PowerShell modules.

-#Customer intent: As a tenant admin, I want to walk through the B2B invitation workflow so that I can understand how to add a user through PowerShell.

-There are many ways you can invite external partners to your apps and services with Microsoft Entra B2B collaboration. In the previous quickstart, you saw how to add guest users directly in the Azure portal. You can also use PowerShell to add guest users, either one at a time or in bulk. In this quickstart, youΓÇÖll use the New-MgInvitation command to add one guest user to your Azure tenant.

-### PowerShell Module

-Install the [Microsoft Graph Identity Sign-ins module](/powershell/module/microsoft.graph.identity.signins/?view=graph-powershell-beta&preserve-view=true) (Microsoft.Graph.Identity.SignIns) and the [Microsoft Graph Users module](/powershell/module/microsoft.graph.users/?view=graph-powershell-beta&preserve-view=true) (Microsoft.Graph.Users). You can use the `#Requires` statement to prevent running a script unless the required PowerShell modules are met.

-### Get a test email account

-You need a test email account that you can send the invitation to. The account must be from outside your organization. You can use any type of account, including a social account such as a gmail.com or outlook.com address.

-1. To verify that the invited user was added to Microsoft Entra ID, run the following command (replace **john\@contoso.com** with your invited email):

-In this quickstart, you invited and added a single guest user to your directory using PowerShell. You can also invite a guest user using the [Azure portal](b2b-quickstart-add-guest-users-portal.md). Additionally you can [invite guest users in bulk using PowerShell](tutorial-bulk-invite.md).

-# Customer intent: As a tenant administrator, I want to know how to add sponsors to guest users in Microsoft Entra ID.

-# B2B collaboration user claims mapping in Microsoft Entra ID

-Microsoft Entra ID supports customizing the claims that are issued in the SAML token for [B2B collaboration](what-is-b2b.md) users. When a user authenticates to the application, Microsoft Entra ID issues a SAML token to the app that contains information (or claims) about the user that uniquely identifies them. By default, this claim includes the user's user name, email address, first name, and last name.

-Microsoft Entra organizations can use External Identities cross-tenant access settings to manage how they collaborate with other Microsoft Entra organizations and other Microsoft Azure clouds through B2B collaboration and [B2B direct connect](cross-tenant-access-settings-b2b-direct-connect.md). [Cross-tenant access settings](cross-tenant-access-settings-b2b-collaboration.md) give you granular control over how external Microsoft Entra organizations collaborate with you (inbound access) and how your users collaborate with external Microsoft Entra organizations (outbound access). These settings also let you trust multi-factor authentication (MFA) and device claims ([compliant claims and Microsoft Entra hybrid joined claims](../conditional-access/howto-conditional-access-policy-compliant-device.md)) from other Microsoft Entra organizations.

-description: Use cross-tenant collaboration settings to manage how you collaborate with other Microsoft Entra organizations. Learn how to configure outbound access to external organizations and inbound access from external Microsoft Entra ID for B2B collaboration.

-description: Use cross-tenant access settings to manage how you collaborate with other Microsoft Entra organizations. Learn how to configure outbound access to external organizations and inbound access from external Microsoft Entra ID for B2B direct connect.

-In this article, you learn to generate a self-signed certificate by using [Azure Key Vault](https://azure.microsoft.com/products/key-vault/) on the Azure portal, OpenSSL or Windows PowerShell. If you have a client secret already, you'll learn how to safely delete it.

-We've had many customers tell us that they want to customize the invitation process. [With our API](/graph/api/resources/invitation), you can customize the invitation process in a way that works best for your organization.

-# Add Microsoft Entra ID as an identity provider for External Identities

-Microsoft Entra B2B can be configured to federate with IdPs that use the WS-Fed protocol with the specific requirements listed below. Currently, the two WS-Fed providers have been tested for compatibility with Microsoft Entra External ID include AD FS and Shibboleth. Here, weΓÇÖll use Active Directory Federation Services (AD FS) as an example of the WS-Fed IdP. For more information about establishing a relying party trust between a WS-Fed compliant provider with Microsoft Entra External ID, download the Microsoft Azure AD Identity Provider Compatibility Docs.

->- *Direct federation* in Microsoft Entra ID is now referred to as *SAML/WS-Fed identity provider (IdP) federation*.

-# External Identities in Microsoft Entra ID

-With External Identities, external users can "bring their own identities." Whether they have a corporate or government-issued digital identity, or an unmanaged social identity like Google or Facebook, they can use their own credentials to sign in. The external userΓÇÖs identity provider manages their identity, and you manage access to your apps with Microsoft Entra ID or Azure AD B2C to keep your resources protected.

-B2B direct connect is a new way to collaborate with other Microsoft Entra organizations. This feature currently works with Microsoft Teams shared channels. With B2B direct connect, you create two-way trust relationships with other Microsoft Entra organizations to allow users to seamlessly sign in to your shared resources and vice versa. B2B direct connect users aren't added as guests to your Microsoft Entra directory. When two organizations mutually enable B2B direct connect, users authenticate in their home organization and receive a token from the resource organization for access. Learn more about [B2B direct connect in Microsoft Entra ID](b2b-direct-connect-overview.md).

-Although Azure AD B2C is built on the same technology as Microsoft Entra ID, it's a separate service with some feature differences. For more information about how an Azure AD B2C tenant differs from a Microsoft Entra tenant, see [Supported Microsoft Entra features](../../active-directory-b2c/supported-azure-ad-features.md) in the [Azure AD B2C documentation](../../active-directory-b2c/index.yml).

-| **multifactor authentication** | If inbound trust settings to accept MFA claims from the user's home tenant are configured, and MFA policies have already been met in the user's home tenant, the external user can sign in. If MFA trust isn't enabled, the user is presented with an MFA challenge from the resource organization. [Learn more](authentication-conditional-access.md#mfa-for-azure-ad-external-users) about MFA for Microsoft Entra external users. | If inbound trust settings to accept MFA claims from the user's home tenant are configured, and MFA policies have already been met in the user's home tenant, the external user can sign in. If MFA trust isn't enabled, and Conditional Access policies require MFA, the user is blocked from accessing resources. You *must* configure your inbound trust settings to accept MFA claims from the organization. [Learn more](authentication-conditional-access.md#mfa-for-azure-ad-external-users) about MFA for Microsoft Entra external users. | [Integrates directly](../../active-directory-b2c/multi-factor-authentication.md) with Microsoft Entra multifactor authentication. |

-Microsoft Entra B2B collaboration and B2B direct connect are features Microsoft Entra ID, and they're managed in the Azure portal through the Microsoft Entra service. To control inbound and outbound collaboration, you can use a combination of *cross-tenant access settings* and *external collaboration settings*.

-You'll need Azure AD PowerShell module version 2.0.2.130 or later. Use the following command to update to the latest AzureAD PowerShell module and invite the internal user to B2B collaboration:

-If you're notified that you don't have permissions to invite users, verify that your user account is authorized to invite external users under Microsoft Entra ID > User settings > External users > Manage external collaboration settings:

-## I receive the error that Microsoft Entra ID can't find the aad-extensions-app in my tenant

-To view guest users with PowerShell, you'll need the [Microsoft.Graph.Users PowerShell Module](/powershell/module/microsoft.graph.users/?view=graph-powershell-beta&preserve-view=true). Then sign in using the `Connect-MgGraph` command with an admin account to consent to the required scopes:

-Microsoft Entra B2B collaboration is a feature within External Identities that lets you invite guest users to collaborate with your organization. With B2B collaboration, you can securely share your company's applications and services with external users, while maintaining control over your own corporate data. Work safely and securely with external partners, large or small, even if they don't have Microsoft Entra ID or an IT department.

-You can do all of your administrative tasks using the Microsoft Entra portal, including creating a new tenant for your organization.

-| [Azure AD B2B / External Identities](../external-identities/what-is-b2b.md) | [[`azure-ad-b2b`]](/answers/topics/azure-ad-b2b.html) |

-This policy applies to all users who are accessing Azure Resource Manager services, whether they're an administrator or a user.

-| **Restrict users from recovering the BitLocker key(s) for their owned devices** | This setting can be found in the Microsoft Entra ID and Microsoft Entra portal in the Device Settings. Setting this option to **Yes** restricts users from being able to self-service recover BitLocker key(s) for their owned devices. Users will have to contact their organization's helpdesk to retrieve their BitLocker keys. Setting this option to **No** allows users to recover their BitLocker key(s). |

-description: Configure an Azure Logic App for use with Lifecycle Workflows

- ```LCW Logic App code view template

-

-1. On the left of the screen, select **Identity**.

-1. Select Save.

-1. For Logic Apps authorization policy, we need the managed identities **Application ID**. Since the Microsoft Entra admin center only shows the Object ID, we need to look up the Application ID. You can search for the managed identity by Object ID under **Enterprise Applications in the Microsoft Entra portal** to find the required Application ID.

- Policy name: POP-Policy

-

- Policy type: AADPOP

-1. For Logic Apps authorization policy, we need the managed identities **Application ID**. Since the Microsoft Entra admin center only shows the Object ID, we need to look up the Application ID. You can search for the managed identity by Object ID under **Enterprise Applications in the Microsoft Entra portal** to find the required Application ID.

- Policy name: AzureADLifecycleWorkflowsAuthPolicy

- Policy type: AAD

- Policy name: AzureADLifecycleWorkflowsAuthPolicyV2App

- Policy type: AAD

-1. If there isn't already a setting, select **Add diagnostic setting**. Use the instructions in [Integrate Microsoft Entra ID logs with Azure Monitor logs](../reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md) to send the Microsoft Entra audit log to the Azure Monitor workspace.

- [Get-AzOperationalInsightsWorkspace](/powershell/module/Az.OperationalInsights/Get-AzOperationalInsightsWorkspace) operates in one subscription at a time. So, if you have multiple Azure subscriptions, you want to make sure you connect to the one that has the Log Analytics workspace with the Microsoft Entra ID logs.

-If you have multiple Log Analytics workspaces in that subscription, then the cmdlet [Get-AzOperationalInsightsWorkspace](/powershell/module/Az.OperationalInsights/Get-AzOperationalInsightsWorkspace) returns the list of workspaces. Then you can find the one that has the Microsoft Entra ID logs. The `CustomerId` field returned by this cmdlet is the same as the value of the "Workspace ID" displayed in the Microsoft Entra admin center in the Log Analytics workspace overview.

-|Workday to Microsoft Entra User Provisioning|Can use a direct mapping. No expression is needed but may be used to adjust the time portion of EmployeeHireDate and EmployeeLeaveDateTime|EmployeeHireDate and EmployeeLeaveDateTime||

-|SuccessFactors to Microsoft Entra User Provisioning|Can use a direct mapping. No expression is needed but may be used to adjust the time portion of EmployeeHireDate and EmployeeLeaveDateTime|EmployeeHireDate and EmployeeLeaveDateTime||

-Use these [Azure AD PowerShell Module for Windows PowerShell](/powershell/module/msonline/) commands to enable synchronization for a production tenant, a prerequisite for being able to call the Administration Web Service for that tenant.

-<a name='entra-portal-agent-verification'></a>

-### Microsoft Entra portal agent verification

-Learn more about [Microsoft Entra Connect: ADSyncTools PowerShell Module](reference-connect-adsynctools.md)

-The PowerShell Module named [ADSyncConfig.psm1](reference-connect-adsyncconfig.md) was introduced with build 1.1.880.0 (released in August 2018) that includes a collection of cmdlets to help you configure the correct Active Directory permissions for your Microsoft Entra Connect deployment.

-## Using the ADSyncConfig PowerShell Module

-You can run the following Windows PowerShell command: `PS C:\>Get-AdfsProperties | FL AutoCert*, Certificate*`.

-1. Open the Azure AD PowerShell Module for Windows PowerShell. Alternatively, open Windows PowerShell, and then run the `Import-Module msonline` command.

-To change the logo of the company that's displayed on the **Sign-in** page, use the following Windows PowerShell cmdlet and syntax.

-To add a sign-in page description to the **Sign-in page**, use the following Windows PowerShell cmdlet and syntax.

-> You can download the MSOnline PowerShell Module directly from the PowerShell Gallery.

-1. Open the Azure AD PowerShell Module for Windows PowerShell.

-## Install Windows PowerShell for sign-on with SAML 2.0 identity provider

-After you have configured your SAML 2.0 identity provider for use with Microsoft Entra sign-on, the next step is to download and install the Azure AD PowerShell Module for Windows PowerShell. Once installed, you will use these cmdlets to configure your Microsoft Entra domains as federated domains.

-The Azure AD PowerShell Module for Windows PowerShell is a download for managing your organizations data in Microsoft Entra ID. This module installs a set of cmdlets to Windows PowerShell; you run those cmdlets to set up single sign-on access to Microsoft Entra ID and in turn to all of the cloud services you are subscribed to. For instructions about how to download and install the cmdlets, see [/previous-versions/azure/jj151815(v=azure.100)](/previous-versions/azure/jj151815(v=azure.100))

-Before configuring federation on a Microsoft Entra domain, it must have a custom domain configured. You cannot federate the default domain that is provided by Microsoft. The default domain from Microsoft ends with ΓÇ£onmicrosoft.comΓÇ¥.

-You will run a series of cmdlets in the Windows PowerShell command-line interface to add or convert domains for single sign-on.

-Before you can authenticate your users to Microsoft 365, you must provision Microsoft Entra ID with user principals that correspond to the assertion in the SAML 2.0 claim. If these user principals are not known to Microsoft Entra ID in advance, then they cannot be used for federated sign-in. Either Microsoft Entra Connect or Windows PowerShell can be used to provision user principals.

-Windows PowerShell can also be used to automate adding new users to Microsoft Entra ID and to synchronize changes from the on-premises directory. To use the Windows PowerShell cmdlets, you must download the [Azure AD PowerShell Module](/powershell/azure/active-directory/install-adv2).

-3. Install Windows PowerShell for single sign-on with SAML 2.0 identity provider

-5. Provisioned a known test user principal to Microsoft Entra ID (Microsoft 365) either through Windows PowerShell or Microsoft Entra Connect.

- 

->For more information, see [Migrate from Azure Access Control Service](../../azuread-dev/active-directory-acs-migration.md).

->

-1. On your AD FS federation server open **AD FS Management.**

-2. On the left, expand **Trust Relationships** and **Relying Party Trusts**

-4. On a machine that has [Azure AD PowerShell Module for Windows PowerShell](/previous-versions/azure/jj151815(v=azure.100)) installed on it run the following PowerShell: `$cred=Get-Credential`.

-6. In PowerShell, enter `Connect-MsolService -Credential $cred`

-7. In PowerShell, enter `Update-MSOLFederatedDomain -DomainName <Federated Domain Name> -SupportMultipleDomain`. This update is for the original domain. So using the above domains it would be: `Update-MsolFederatedDomain -DomainName bmcontoso.com -SupportMultipleDomain`

-1. On a machine that has [Azure AD PowerShell Module for Windows PowerShell](/previous-versions/azure/jj151815(v=azure.100)) installed on it run the following PowerShell: `$cred=Get-Credential`.

-2. Enter the username and password of a Hybrid Identity Administratoristrator for the Microsoft Entra domain you are federating with

-> We recommend using Microsoft Graph PowerShell SDK with [Windows PowerShell 7](/powershell/scripting/whats-new/migrating-from-windows-powershell-51-to-powershell-7?view=powershell-7.3&preserve-view=true).

- 1. Microsoft Entra ID Logs get populated per the activity in the tenant.

-User authentication takes place against Microsoft Entra rather than against the organization's own Active Directory instance. The SHA256 password data stored in Microsoft Entra ID--a hash of the original MD4 hash--is more secure than what is stored in Active Directory. Further, because this SHA256 hash cannot be decrypted, it cannot be brought back to the organization's Active Directory environment and presented as a valid user password in a pass-the-hash attack.

-An administrator can manually reset your password directly in Microsoft Entra ID by using Windows PowerShell (unless the user is in a Federated Domain).

-2. You can register the Authentication Agent with our service using Windows PowerShell. Create a PowerShell Credentials object `$cred` that contains a global administrator username and password for your tenant. Run the following command, replacing *\<username\>* and *\<password\>*:

- 

-It is recommended to leave the sync process on for the server in Staging Mode, so if it becomes active, it will quickly take over and won't have to do a large sync to catch up to the current state of the AD/Azure AD objects in scope.

-This topic explains how the following features of the **Microsoft Entra Connect Sync service** work and how you can configure them using Windows PowerShell.

-These settings are configured by the [Azure AD PowerShell Module for Windows PowerShell](/previous-versions/azure/jj151815(v=azure.100)). Download and install it separately from Microsoft Entra Connect. The cmdlets documented in this topic were introduced in the [2016 March release (build 9031.1)](https://social.technet.microsoft.com/wiki/contents/articles/28552.microsoft-azure-active-directory-powershell-module-version-release-history.aspx#Version_9031_1). If you do not have the cmdlets documented in this topic or they do not produce the same result, then make sure you run the latest version.

-* **multifactor authentication** with push notification or verification code

-> A new PowerShell Module named *ADSyncConfig.psm1* was introduced with build 1.1.880.0 (released in August 2018). The module includes a collection of cmdlets that help you configure the correct Windows Server AD permissions for the Microsoft Entra DS Connector account.

-The following documentation provides reference information for the ADConnectivityTools PowerShell Module that is included with Microsoft Entra Connect in `C:\Program Files\Microsoft Azure Active Directory Connect\Tools\ADConnectivityTool.psm1`.

-# Microsoft Entra Connect: ADSync PowerShell Reference

-The following documentation provides reference information for the ADSync.psm1 PowerShell Module that is included with Microsoft Entra Connect.

-The following documentation provides reference information for the ADSyncConfig.psm1 PowerShell Module that is included with Microsoft Entra Connect.

-The following documentation provides reference information for the ADSyncTools.psm1 PowerShell Module that is included with Microsoft Entra Connect.

-## Install the ADSyncTools PowerShell Module

-To install the ADSyncTools PowerShell Module do the following:

-* [What is the ADConnectivityTool PowerShell Module?](./how-to-connect-adconnectivitytools.md)

- * Upgrade Azure AD Connect to build 1.1.524.0 or after. In Azure AD Connect build 1.1.524.0, the out-of-box synchronization rules have been updated to not export attributes userCertificate and userSMIMECertificate if the attributes have more than 15 values. For details on how to upgrade Azure AD Connect, refer to article [Microsoft Entra Connect: Upgrade from a previous version to the latest](./how-to-upgrade-previous-version.md).

-> The preceding steps are only applicable to newer versions (1.1.xxx.x) of Azure AD Connect with the built-in scheduler. If you are using older versions (1.0.xxx.x) of Azure AD Connect that uses Windows Task Scheduler, or you are using your own custom scheduler (not common) to trigger periodic synchronization, you need to disable them accordingly.

-> The preceding steps are only applicable to newer versions (1.1.xxx.x) of Azure AD Connect with the built-in scheduler. If you are using older versions (1.0.xxx.x) of Azure AD Connect that uses Windows Task Scheduler, or you are using your own custom scheduler (not common) to trigger periodic synchronization, you need to disable them accordingly.

-Ensure that the Seamless SSO feature is still **Enabled** on your tenant. You can check the status by going to the **Identity** > **Hybrid management** > **Azure AD Connect** > **Connect Sync** pane in the [[Microsoft Entra admin center](https://entra.microsoft.com)](https://portal.azure.com/).

-Or install [PackageManagement PowerShell Modules Preview - March 2016 for PowerShell 3.0/4.0](/powershell/module/PackageManagement)

-By routing logs to an Azure storage account, you can keep it for longer than the default retention period. For more information, see the article [Tutorial: Archive Microsoft Entra ID logs to an Azure storage account](../reports-monitoring/quickstart-azure-monitor-route-logs-to-storage-account.md).

-Azure Event Hubs can look at incoming data from sources like Microsoft Entra ID Protection and provide real-time analysis and correlation. For more information, see the article [Tutorial: Stream Microsoft Entra ID logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md)

-1. Browse to **Identity** > **Applications** > **Enterprise applications** > **All applications**. For example, the application that you created in the previous quickstart named **Azure AD SAML toolkit 1**.

-Microsoft Entra ID has a gallery that contains thousands of pre-integrated applications that use SSO. This article uses an enterprise application named **Azure AD SAML toolkit 1** as an example, but the concepts apply for most pre-configured enterprise applications in the gallery.

-1. Enter the name of the existing application in the search box, and then select the application from the search results. For example, **Azure AD SAML toolkit 1**.

-1. The process of configuring an application to use Microsoft Entra ID for SAML-based SSO varies depending on the application. For any of the enterprise applications in the gallery, use the **configuration guide** link to find information about the steps needed to configure the application. The steps for the **Azure AD SAML toolkit 1** are listed in this article.

-1. In the **Set up Azure AD SAML toolkit 1** section, record the values of the **Login URL**, **Microsoft Entra Identifier**, and **Logout URL** properties to be used later.

-1. Open a new browser window and browse to the sign-in URL for the application. For the **Azure AD SAML toolkit** application, the address is `https://samltoolkit.azurewebsites.net`.

- :::image type="content" source="media/add-application-portal-setup-sso/toolkit-register.png" alt-text="Register a user account in the Azure AD SAML toolkit application.":::

-1. In the **Test single sign-on with Azure AD SAML toolkit 1** section, on the **Set up single sign-on with SAML** pane, select **Test**.

-In this quickstart, you use the Microsoft Entra admin center to add an enterprise application to your Microsoft Entra tenant. Microsoft Entra ID has a gallery that contains thousands of enterprise applications that have been preintegrated. Many of the applications your organization uses are probably already in the gallery. This quickstart uses the application named **Azure AD SAML toolkit** as an example, but the concepts apply for most [enterprise applications in the gallery](../saas-apps/tutorial-list.md).

-1. The **Browse Microsoft Entra Gallery** pane opens and displays tiles for cloud platforms, on-premises applications, and featured applications. Applications listed in the **Featured applications** section have icons indicating whether they support federated single sign-on (SSO) and provisioning. Search for and select the application. In this quickstart, **Azure AD SAML toolkit* is being used.

-[Apps, permissions, and consent in Azure Active Directory (v1 endpoint)](../develop/quickstart-register-app.md)<br>

-[Scopes, permissions, and consent in the Microsoft Entra ID (v2.0 endpoint)](../develop/permissions-consent-overview.md)

-1. Enter the name of the existing application in the search box, and then select the application from the search results. In this article, we use the **Azure AD SAML toolkit 1** as an example.

- 

- ```New-ADUser -Name "F5 BIG-IP Delegation Account" UserPrincipalName $HOST_SPN SamAccountName "f5-big-ip" -PasswordNeverExpires $true Enabled $true -AccountPassword (Read-Host -AsSecureString "Account Password") ```

- ```Set-AdUser -Identity f5-big-ip -ServicePrincipalNames @Add="host/f5-big-ip.contoso.com"} ```

- ```Get-ADComputer -identity <name_of_account> -properties ServicePrincipalNames | Select-Object -ExpandProperty ServicePrincipalNames ```

- ```Get-ADUser -identity <name_of_account> -properties ServicePrincipalNames | Select-Object -ExpandProperty ServicePrincipalNames ```

- Get-ADComputer -identity f5-big-ip -properties ServicePrincipalNames | Select-Object -ExpandProperty ServicePrincipalNames

- ```Set-ADComputer -Identity APP-VM-01 -ServicePrincipalNames @{Add="http/myexpenses.contoso.com"} ```

- ```Get-ADUser -Identity f5-big-ip | Set-ADAccountControl -TrustedToAuthForDelegation $true ```

- ```Set-ADUser -Identity f5-big-ip -Add @{'msDS-AllowedToDelegateTo'=@('HTTP/myexpenses.contoso.com')} ```

-Use an SPN defined against a web application service account. For better security, use a dedicated SPN that matches the host header of the application. For example, because the web application host header in this example is myexpenses.contoso.com, add HTTP/myexpenses.contoso.com to the application service account object in Active Directory (AD):

-```Set-AdUser -Identity web_svc_account -ServicePrincipalNames @{Add="http/myexpenses.contoso.com"} ```

-```$big-ip= Get-ADComputer -Identity f5-big-ip -server dc.contoso.com ```

-```Set-ADUser -Identity web_svc_account -PrincipalsAllowedToDelegateToAccount ```

-```$big-ip Get-ADUser web_svc_account -Properties PrincipalsAllowedToDelegateToAccount ```

-```$big-ip= Get-ADComputer -Identity f5-big-ip -server dc.contoso.com ```

-```Set-ADComputer -Identity web_svc_account -PrincipalsAllowedToDelegateToAccount ```

-```$big-ip Get-ADComputer web_svc_account -Properties PrincipalsAllowedToDelegateToAccount ```

- 

-3. In the gallery, search for F5 and select **F5 BIG-IP APM Azure AD integration**.

-| **IdP federation metadata**<p>Location of the IdP's publicly available federation metadata. (Some apps use federation metadata as an alternative to the administrator configuring URLs, identifier, and token signing certificate individually.)| Find the AD FS federation metadata URL in AD FS Management under **Service > Endpoints > Metadata > Type: Federation Metadata**. For example: `https://fs.contoso.com/FederationMetadat). |

-5. Confirm there are no users enabled for legacy MFA: On the **multifactor authentication** menu, on **multifactor authentication status**, select **Enabled** and **Enforced**. If the tenant has users in the following views, disable them in the legacy menu.

-Import-module AzureAD

-3. On the **Uniquely identifying your users** page, under **Select how users should be identified with Azure AD**, select **Choose a specific attribute**.

- 

- 

- 

- - For federated applications (OpenID and SAML/WS-Fed), the application must support the [software-as-a-service (SaaS) model](https://azure.microsoft.com/overview/what-is-saas/). Enterprise gallery applications must support multiple user configurations and not any specific user.

- - For federated applications (OpenID and SAML/WS-Fed), the application can be single **or** multitenanted

- - For OpenID Connect, if the application is multitenanted the [Microsoft Entra consent framework](../develop/application-consent-experience.md) must be correctly implemented.

-When your application is added to the gallery, documentation is created that explains the step-by-step process. For an example, see [Tutorials for integrating SaaS applications with Microsoft Entra ID](../saas-apps/tutorial-list.md). This documentation is created based on your submission to the gallery. You can easily update the documentation if you make changes to your application by using your GitHub account.

-Listing an **SAML 2.0 or WS-Fed application** in the gallery takes 7 to 10 business days.

-Listing an **OpenID Connect application** in the gallery takes 2 to 5 business days.

- > The value of the `resource` parameter must be an exact match for what is expected by Azure AD. When using the Resource Manager resource ID, you must include the trailing slash on the URI. 

-1. In the portal, navigate to your Linux VM and in the **Overview**, select **Connect**.  

-2. **Connect** to the VM with the SSH client of your choice. 

-3. In the terminal window, using `curl`, make a request to the local managed identities for Azure resources endpoint to get an access token for Azure Resource Manager.  

- The `curl` request for the access token is below.  

-

- ```bash

- curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/' -H Metadata:true   

- ```

-

- > [!NOTE]

- > The value of the “resource” parameter must be an exact match for what is expected by Azure AD.  In the case of the Resource Manager resource ID, you must include the trailing slash on the URI. 

-

- The response includes the access token you need to access Azure Resource Manager. 

-

- Response:  

- ```bash

- {"access_token":"eyJ0eXAiOi...",

- "refresh_token":"",

- "expires_in":"3599",

- "expires_on":"1504130527",

- "not_before":"1504126627",

- "resource":"https://management.azure.com",

- "token_type":"Bearer"} 

- ```

-

- You can use this access token to access Azure Resource Manager, for example to read the details of the Resource Group to which you previously granted this VM access. Replace the values of \<SUBSCRIPTION ID\>, \<RESOURCE GROUP\>, and \<ACCESS TOKEN\> with the ones you created earlier. 

-

- > [!NOTE]

- > The URL is case-sensitive, so ensure if you are using the exact same case as you used earlier when you named the Resource Group, and the uppercase “G” in “resourceGroup”.  

-

- ```bash

- curl https://management.azure.com/subscriptions/<SUBSCRIPTION ID>/resourceGroups/<RESOURCE GROUP>?api-version=2016-09-01 -H "Authorization: Bearer <ACCESS TOKEN>" 

- ```

-

- The response back with the specific Resource Group information: 

-  

- ```bash

- {"id":"/subscriptions/98f51385-2edc-4b79-bed9-7718de4cb861/resourceGroups/DevTest","name":"DevTest","location":"westus","properties":{"provisioningState":"Succeeded"}} 

- ```

-In this quickstart, you learned how to use a system-assigned managed identity to access the Azure Resource Manager API. To learn more about Azure Resource Manager see:

-description: Learn about the four types of sign-in logs available in Microsoft Entra Monitoring and health.

-Registration is needed even if you're accessing the reporting API using a script. The registration gives you an **Application ID**, which is required for the authorization calls and enables your code to receive tokens. To configure your directory to access the Microsoft Entra ID reporting API, you must sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) in one of the required roles.

-To access the Microsoft Entra ID reporting API, you must grant your app *Read directory data* and *Read all audit log data* permissions for the Microsoft Graph API.

-To use PowerShell to access the Microsoft Entra ID reporting API, you need to gather a few configuration settings. These settings were created as a part of the [app registration process](#register-an-azure-ad-application).

-### Troubleshoot errors in Microsoft Entra ID reporting API

-* [Get data using the Microsoft Entra ID reporting API with certificates](./howto-configure-prerequisites-for-reporting-api.md)

- * The deployment runs a Windows PowerShell script, so you must enable PowerShell to run scripts on the machine where you want to deploy the connector.

-description: Provides a general overview of Microsoft Entra Monitoring and health.

-# What is Microsoft Entra Monitoring and health?

-The features of Microsoft Entra Monitoring and health provide a comprehensive view of identity related activity in your environment. This data enables you to:

-# Microsoft Entra Monitoring & health deployment dependencies

-To deploy Microsoft Entra Monitoring & health you'll need a user who is a Global Administrator or Security Administrator for the Microsoft Entra tenant.

-## Plan and deploy a Microsoft Entra Monitoring & health deployment project

-description: Learn why you should migrate from the Azure Active Directory Library to the Microsoft Authentication Libraries.

-# Microsoft Entra recommendation: Migrate from the Azure Active Directory Library to the Microsoft Authentication Libraries

-> These PowerShell cmdlets currently only work with the [Microsoft Entra ID Preview](/powershell/module/azuread/?view=azureadps-2.0-preview&preserve-view=true#directory_auditing) Module. Please note that the preview module is not suggested for production use.

-You can retain the audit and sign-in activity data for longer than the default retention period outlined in the previous table by routing it to an Azure storage account using Azure Monitor. For more information, see [Archive Microsoft Entra ID logs to an Azure storage account](quickstart-azure-monitor-route-logs-to-storage-account.md).

-> | Perform all Microsoft Entra Domain Services tasks | [AAD DC Administrators group](../../active-directory-domain-services/tutorial-create-management-vm.md#administrative-tasks-you-can-perform-on-a-managed-domain) | |

-> This tutorial describes a connector built on top of the Microsoft Entra user Provisioning Service. For important details on what this service does, how it works, and frequently asked questions, see [Automate user provisioning and deprovisioning to SaaS applications with Microsoft Entra ID](../app-provisioning/user-provisioning.md).

-This section defines all properties that you would normally use to manually configure a new BIG-IP SAML application within your Microsoft Entra tenant. Easy Button provides a set of pre-defined application templates for Oracle PeopleSoft, Oracle E-business Suite, Oracle JD Edwards, SAP ERP as well as generic SHA template for any other apps. For this scenario select **F5 BIG-IP APM Microsoft Entra Integration > Add**.

-Add existing user accounts to the Admin or User groups on the Azure AD side, following Parallels's Azure SSO setup guide that can be found on [this page](https://kb.parallels.com/en/129240). When a user account gets deactivated following their departure from the organization, that is immediately reflected in the user count of the Parallels's product license.

- 

-| **IA-2(1)**<br>The information system implements multifactor authentication for network access to privileged accounts.<br><br>**IA-2(3)**<br>The information system implements multifactor authentication for local access to privileged accounts. | **multifactor authentication for all access to privileged accounts.** <p>Configure the following elements for a complete solution to ensure all access to privileged accounts requires multifactor authentication.<p>Configure Conditional Access policies to require multifactor authentication for all users.<br> Implement Microsoft Entra Privileged Identity Management to require multifactor authentication for activation of privileged role assignment prior to use.<p>With Privileged Identity Management activation requirement, privilege account activation isn't possible without network access, so local access is never privileged.<p>multifactor authentication and Privileged Identity Management<br> <li>[Conditional Access: Require multifactor authentication for all users](../conditional-access/howto-conditional-access-policy-all-users-mfa.md)<br> <li>[Configure Microsoft Entra role settings in Privileged Identity Management](../privileged-identity-management/pim-how-to-change-default-settings.md?tabs=new) |

-

-* Authenticate with [Azure Active Directory (AAD)](#authenticate-with-an-access-token)

-These sample requests demonstrates how to use the `Ocp-Apim-Subscription-Key` header. Keep in mind, when using this sample you'll need to include a valid resource key.

-This article shows you how to enable and manage the cluster autoscaler in an AKS cluster.

-To adjust to changing application demands, such as between workdays and evenings or weekends, clusters often need a way to automatically scale. AKS clusters can scale in one of two ways:

-* The **cluster autoscaler** watches for pods that can't be scheduled on nodes because of resource constraints. The cluster then automatically increases the number of nodes. For more information, see [How does scale-up work?](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#how-does-scale-up-work)

-* The **horizontal pod autoscaler** uses the Metrics Server in a Kubernetes cluster to monitor the resource demand of pods. If an application needs more resources, the number of pods is automatically increased to meet the demand.

-Both the horizontal pod autoscaler and cluster autoscaler can decrease the number of pods and nodes as needed. The cluster autoscaler decreases the number of nodes when there has been unused capacity after a period of time. Any pods on a node removed by the cluster autoscaler are safely scheduled elsewhere in the cluster.

-With autoscaling enabled, when the node pool size is lower than the minimum or greater than the maximum it applies the scaling rules. Next, the autoscaler waits to take effect until a new node is needed in the node pool or until a node may be safely deleted from the current node pool. For more information, see [How does scale-down work?](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#how-does-scale-down-work)

-The cluster autoscaler uses startup parameters for things like time intervals between scale events and resource thresholds. For more information on what parameters the cluster autoscaler uses, see [using the autoscaler profile](#use-the-cluster-autoscaler-profile).

-The cluster autoscaler and horizontal pod autoscaler can work together and are often both deployed in a cluster. When combined, the horizontal pod autoscaler runs the number of pods required to meet application demand, and the cluster autoscaler runs the number of nodes required to support the scheduled pods.

-> [!NOTE]

-> Manual scaling is disabled when you use the cluster autoscaler. Let the cluster autoscaler determine the required number of nodes. If you want to manually scale your cluster, [disable the cluster autoscaler](#disable-the-cluster-autoscaler-on-a-cluster).

-## Use the cluster autoscaler on your AKS cluster

-***Use *Azure CNI* when**:

-> Both system-assigned and user-assigned managed identities are supported when you create and use your own VNet and route table with the azure network plugin. We highly recommend using a user-assigned managed identity for BYO scenarios.