+5. In the **Mappings** section, select the mapping that you want to configure a scoping filter for: for example, "Synchronize Microsoft Entra users to ServiceNow".

+5. In the **Mappings** section, select the mapping that you want to configure a scoping filter for: for example, "Provision Microsoft Entra users".

+This expression fixes the issue by appending a random number to the UPN value accepted by Microsoft Entra ID.

+It doesn't refer to the attribute mappings that you perform in the Microsoft Entra admin center provisioning app between source SCIM schema elements and target Microsoft Entra / on-premises Active Directory attributes.

+This article on [AdminSDHolder issues with Microsoft Entra Connect](https://c7solutions.com/2017/03/administrators-aadconnect-and-adminsdholder-issues) has more examples on DSACLS usage.

+This article lists the versions and features of Microsoft Entra Connect Provisioning Agent that have been released. The Microsoft Entra team regularly updates the Provisioning Agent with new features and functionality. Please ensure that you do not use the same agent for on-premises provisioning and Cloud Sync / HR-driven provisioning.

+In cases where an application doesn't support SCIM, partners have built [custom ECMA connectors](on-premises-custom-connector.md) and SCIM gateways to integrate Microsoft Entra ID with numerous applications. **This document serves as a place for partners to attest to integrations that are compatible with Microsoft Entra ID, and for customers to discover these partner-driven integrations.** Custom ECMA connectors and SCIM gateways are built, maintained, and owned by the third-party vendor.

+* [Microsoft Entra synchronization API overview](/graph/api/resources/synchronization-overview)

+- [Microsoft Entra synchronization API overview](/graph/api/resources/synchronization-overview)

+For each SuccessFactors user, the provisioning service looks for an account in the target (Microsoft Entra ID / on-premises Active Directory) using the matching attribute defined in the mapping. For example: if *personIdExternal* maps to *employeeId* and is set as the matching attribute, then the provisioning service uses the *personIdExternal* value to search for the user with *employeeId* filter. If a user match is found, then it updates the target attributes. If no match is found, then it creates a new entry in the target.

+

+* The service determines what operation to perform in the target (Microsoft Entra ID / Active Directory).

+There are many different ways to implement a model in which a single service provider deploys and maintains Microsoft Entra related services for multiple companies. Connector groups help the admin segregate the connectors and applications into different groups. One way, which is suitable for small companies, is to have a single Microsoft Entra tenant while the different companies have their own domain name and networks. This is also true for M&A scenarios and situations where a single IT division serves several companies for regulatory or business reasons.

+ > In order to make the above changes you require rights to modify application objects in Microsoft Entra ID. The user needs to be assigned [Application Administrator](../roles/delegate-app-roles.md#assign-built-in-application-admin-roles) role which grants application modification rights in Microsoft Entra ID to the user.

+The following table includes links to PowerShell script examples for Microsoft Entra application proxy. These samples require either the [Azure Active Directory PowerShell 2.0 for Graph module](/powershell/azure/active-directory/install-adv2) or the [Azure Active Directory PowerShell 2.0 for Graph module preview version](/powershell/azure/active-directory/install-adv2?view=azureadps-2.0-preview&preserve-view=true), unless otherwise noted.

+| [Get all Application Proxy apps with a token lifetime policy](scripts/powershell-get-all-app-proxy-apps-with-policy.md) | Lists all Application Proxy apps in your directory with a token lifetime policy and its details. This sample requires the [Azure Active Directory PowerShell 2.0 for Graph module preview version](/powershell/azure/active-directory/install-adv2?view=azureadps-2.0-preview&preserve-view=true). |

+Some features, for example entitlement management, are available with a Microsoft Entra ID P1 or P2 license. Microsoft 365 E5 and Office 365 E5 licenses include Microsoft Entra ID P2 licenses. Learn more in the following entitlement management section.

+description: Learn about the official collection of Microsoft Entra ID icons that you can use in architectural diagrams, training materials, or documentation.

+# Customer intent: As a new or existing customer, I want to learn how I can use the official Microsoft Entra ID icons in architectural diagrams, training materials, or documentation.

+Helping our customers design and architect new solutions is core to the Microsoft Entra mission. Architecture diagrams can help communicate design decisions and the relationships between components of a given workload. This article provides information about the official collection of Microsoft Entra ID icons that you can use in architectural diagrams, training materials, or documentation.

+* [Create and configure a Microsoft Entra Domain Services instance](../../active-directory-domain-services/tutorial-create-instance.md)

+* [Configure virtual networking for a Microsoft Entra Domain Services instance](../../active-directory-domain-services/tutorial-configure-networking.md)

+* [Configure Secure LDAP for a Microsoft Entra Domain Services managed domain](../../active-directory-domain-services/tutorial-configure-ldaps.md)

+* [Create an outbound forest trust to an on-premises domain in Microsoft Entra Domain Services](../../active-directory-domain-services/tutorial-create-forest-trust.md)

+ Title: Microsoft Entra synchronization protocol overview

+| Citrix ADC SAML Connector for Azure AD | No | SAML SP-initiated |

+* See, [`AzureADAssessment`](https://github.com/AzureAD/AzureADAssessment) and confirm validity

+The free PowerShell sample collects service principal OAuth2 grants and credential information, records them in a comma-separated values (CSV) file, and a Power BI sample dashboard. For more information, see [`AzureADAssessment`](https://github.com/AzureAD/AzureADAssessment).

+- Microsoft Entra logs integrated with Azure Monitor logs. Learn how to [Integrate Microsoft Entra sign-in logs with Azure Monitor Stream.](../reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md)

+* **Use of other Microsoft Entra related solutions for all apps**

+- [Microsoft Entra audit API reference](/graph/api/resources/directoryaudit)

+- Scenario D - Use Litware's non-Microsoft identity infrastructure (if Litware isn't using Active Directory / Microsoft Entra ID)

+- **Provision from cloud HR apps to Microsoft Entra ID.** This provisioning enables an on-premises compromise to be isolated. This isolation doesn't disrupt your joiner-mover-leaver cycle from your cloud HR apps to Microsoft Entra ID.

+ Monitor all Microsoft Entra risk events for suspicious activity. See [How To: Investigate risk](../identity-protection/howto-identity-protection-investigate-risk.md). Microsoft Entra ID Protection is natively integrated with [Microsoft Defender for Identity](/defender-for-identity/what-is).

+* [Migrate from Azure Multi-Factor Authentication Server to Microsoft Entra multifactor authentication](../authentication/how-to-migrate-mfa-server-to-azure-mfa.md)

+For example, Azure Arc helps bring many of the features that exist in Active Directory together into a single view when you use Microsoft Entra ID for identity and access management (IAM). You can also use Microsoft Entra Domain Services to domain-join servers in Microsoft Entra ID, especially when you want those servers to use GPOs for specific business or technical reasons.

+* If you must wait to migrate or perform a partial migration, you can use GPOs with [Microsoft Entra Domain Services](https://azure.microsoft.com/services/active-directory-ds/).

+If you require management of application servers with Microsoft Configuration Manager, you can't achieve this requirement by using Microsoft Entra Domain Services. Microsoft Configuration Manager isn't supported to run in a Microsoft Entra Domain Services environment. Instead, you need to extend your on-premises Active Directory instance to a domain controller running on an Azure VM. Or, you need to deploy a new Active Directory instance to an Azure IaaS virtual network.

+1. Deploy Microsoft Entra Domain Services into an Azure virtual network and [extend the schema](/azure/active-directory-domain-services/concepts-custom-attributes) to incorporate additional attributes needed by the applications.

+2. Lift and shift legacy apps to VMs on the Azure virtual network that are domain-joined to Microsoft Entra Domain Services.

+4. As legacy apps retire through attrition, eventually decommission Microsoft Entra Domain Services running in the Azure virtual network.

+>* Use Microsoft Entra Domain Services if the dependencies are aligned with [common deployment scenarios for Microsoft Entra Domain Services](../../active-directory-domain-services/scenarios.md).

+>* To validate if Microsoft Entra Domain Services is a good fit, you might use tools like [Service Map in Azure Marketplace](https://azuremarketplace.microsoft.com/marketplace/apps/Microsoft.ServiceMapOMS?tab=Overview) and [automatic dependency mapping with Service Map and Live Maps](https://techcommunity.microsoft.com/t5/system-center-blog/automatic-dependency-mapping-with-service-map-and-live-maps/ba-p/351867).

+| Strategy | Microsoft Entra Domain Services | Extend Active Directory to IaaS | Independent Active Directory instance in IaaS |

+Microsoft Entra Domain Services allows you to migrate application servers to the cloud IaaS and decouple from Active Directory, while using Microsoft Entra application proxy to enable remote access. To learn more about this scenario, check [Deploy Microsoft Entra application proxy for Microsoft Entra Domain Services](../../active-directory-domain-services/deploy-azure-app-proxy.md).

+* Some legacy apps are authenticated in the cloud through Microsoft Entra Domain Services and Application Proxy.

+* **Suspicious activity** - All [Microsoft Entra risk events](../identity-protection/overview-identity-protection.md) should be monitored for suspicious activity. All tenants should define the network [named locations](../conditional-access/location-condition.md) to avoid noisy detections on location-based signals. [Microsoft Entra ID Protection](../identity-protection/overview-identity-protection.md) is natively integrated with Azure Security Center. It's recommended that any risk detection investigation includes all the environments the identity is provisioned (for example, if a human identity has an active risk detection in the corporate tenant, the team operating the customer facing tenant should also investigate the activity of the corresponding account in that environment).

+Microsoft Entra ID also provides information on the actions that are being performed within Microsoft Entra ID, and reports on security risks. For more information, see [Microsoft Entra reports and monitoring](../reports-monitoring/index.yml).

+

+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 logs with other tools, which allow more automation of monitoring and alerting:

+* **[Azure Event Hubs](../../event-hubs/event-hubs-about.md) integrated with a SIEM**- [Microsoft Entra 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.

+| Applications that are using the ROPC authentication flow|Medium | Microsoft Entra sign-in log|Status=Success<br><br>Authentication Protocol-ROPC| High level of trust is being placed in this application as the credentials can be cached or stored. Move if possible to a more secure authentication flow. This should only be used in automated testing of applications, if at all. For more information, see [Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials](../develop/v2-oauth-ropc.md)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+|Applications using the Device code flow |Low to medium|Microsoft Entra sign-in log|Status=Success<br><br>Authentication Protocol-Device Code|Device code flows are used for input constrained devices, which may not be in all environments. If successful device code flows appear, without a need for them, investigate for validity. For more information, see [Microsoft identity platform and the OAuth 2.0 device authorization grant flow](../develop/v2-oauth2-device-code.md)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Dangling URI| High| Microsoft Entra logs and Application Registration| Service-Core Directory, Category-ApplicationManagement<br>Activity: Update Application<br>Success ΓÇô Property Name AppAddress| For example, look for dangling URIs that point to a domain name that no longer exists or one that you donΓÇÖt explicitly own.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AuditLogs/URLAddedtoApplicationfromUnknownDomain.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

+| Redirect URI configuration changes| High| Microsoft Entra logs| Service-Core Directory, 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.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AuditLogs/ApplicationRedirectURLUpdate.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

+| Changes to AppID URI| High| Microsoft Entra logs| Service-Core Directory, Category-ApplicationManagement<br>Activity: Update<br>Application<br>Activity: Update Service principal| Look for any AppID URI modifications, such as adding, modifying, or removing the URI.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AuditLogs/ApplicationIDURIChanged.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

+| Changes to application ownership| Medium| Microsoft Entra logs| Service-Core Directory, Category-ApplicationManagement<br>Activity: Add owner to application| Look for any instance of a user being added as an application owner outside of normal change management activities.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AuditLogs/ChangestoApplicationOwnership.yaml)<br><br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure) |

+| Changes to log-out URL| Low| Microsoft Entra logs| Service-Core Directory, Category-ApplicationManagement<br>Activity: Update Application<br>-and-<br>Activity: Update service principle| Look for any modifications to a sign-out URL. Blank entries or entries to non-existent locations would stop a user from terminating a session.<br>[Microsoft Sentinel template](https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AuditLogs/ChangestoApplicationLogoutURL.yaml) <br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+* Microsoft Entra monitoring configuration information for SIEMs - [Partner tools with Azure Monitor integration](../..//azure-monitor/essentials/stream-monitoring-data-event-hubs.md)

+To configure monitoring for Application Proxy, see [Troubleshoot Application Proxy problems and error messages](../app-proxy/application-proxy-troubleshoot.md). The data file that logs information can be found in Applications and Services Logs\Microsoft\AadApplicationProxy\Connector\Admin. For a complete reference guide to audit activity, see [Microsoft Entra audit activity reference](../reports-monitoring/reference-audit-activities.md). Specific things to monitor:

+Legacy authentication is captured in the Microsoft Entra sign-in 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 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:

+Complete reference for Microsoft Entra audit activities is available at [Microsoft Entra audit activity reference](../reports-monitoring/reference-audit-activities.md).

+* **Microsoft Entra application proxy Connector** - Lightweight agents that sit on-premises and facilitate the outbound connection to the Application Proxy service. For more information, see [Understand Microsoft Entra Application Proxy connectors](../app-proxy/application-proxy-connectors.md).

+## Privileged Identity Management Alerts

+Privileged Identity Management (PIM) generates alerts when there's suspicious or unsafe activity in your Microsoft Entra ID organization. When an alert is generated, it appears in the Privileged Identity Management dashboard. You can also configure an email notification or send to your SIEM via GraphAPI. Because these alerts focus specifically on administrative roles, you should monitor closely for any alerts.

+| What to monitor| Risk Level| Where | Filter/sub-filter UX | Notes |

+| - |- |- |- |- |

+| [Roles are being assigned outside of Privileged Identity Management](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) | High |Privileged Identity Management, Alerts |[Roles are being assigned outside of Privileged Identity Management](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) |[How to configure security alerts](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) <br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| [Potential stale accounts in a privileged role](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) | Medium |Privileged Identity Management, Alerts |[Potential stale accounts in a privileged role](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) |[How to configure security alerts](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) <br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| [Administrators aren't using their privileged roles](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) | Low |Privileged Identity Management, Alerts |[Administrators aren't using their privileged roles](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) |[How to configure security alerts](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) <br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| [Roles don't require multi-factor authentication for activation](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) | Low |Privileged Identity Management, Alerts |[Roles don't require multi-factor authentication for activation](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) |[How to configure security alerts](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) <br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| [The organization doesn't have Microsoft Entra ID P2 or Microsoft Entra ID Governance](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) | Low |Privileged Identity Management, Alerts |[The organization doesn't have Microsoft Entra ID P2 or Microsoft Entra ID Governance](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) |[How to configure security alerts](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) <br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| [There are too many global administrators](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) | Low |Privileged Identity Management, Alerts |[There are too many global administrators](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts)|[How to configure security alerts](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) <br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| [Roles are being activated too frequently](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) | Low |Privileged Identity Management, Alerts |[Roles are being activated too frequently](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts)|[How to configure security alerts](../privileged-identity-management/pim-how-to-configure-security-alerts.md#security-alerts) <br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+<a name='azure-ad-roles-assignment'></a>

+| Leaked credentials user risk detection| High| Microsoft Entra risk detection logs| UX: Leaked credentials <br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Microsoft Entra Threat Intelligence user risk detection| High| Microsoft Entra risk detection logs| UX: Microsoft Entra threat intelligence <br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Anonymous IP address sign-in risk detection| Varies| Microsoft Entra risk detection logs| UX: Anonymous IP address <br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Atypical travel sign-in risk detection| Varies| Microsoft Entra risk detection logs| UX: Atypical travel <br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Anomalous Token| Varies| Microsoft Entra risk detection logs| UX: Anomalous Token <br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Malware linked IP address sign-in risk detection| Varies| Microsoft Entra risk detection logs| UX: Malware linked IP address <br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Suspicious browser sign-in risk detection| Varies| Microsoft Entra risk detection logs| UX: Suspicious browser <br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Unfamiliar sign-in properties sign-in risk detection| Varies| Microsoft Entra risk detection logs| UX: Unfamiliar sign-in properties <br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Malicious IP address sign-in risk detection| Varies| Microsoft Entra risk detection logs| UX: Malicious IP address<br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Suspicious inbox manipulation rules sign-in risk detection| Varies| Microsoft Entra risk detection logs| UX: Suspicious inbox manipulation rules<br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Password Spray sign-in risk detection| High| Microsoft Entra risk detection logs| UX: Password spray<br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Impossible travel sign-in risk detection| Varies| Microsoft Entra risk detection logs| UX: Impossible travel<br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| New country/region sign-in risk detection| Varies| Microsoft Entra risk detection logs| UX: New country/region<br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Activity from anonymous IP address sign-in risk detection| Varies| Microsoft Entra risk detection logs| UX: Activity from Anonymous IP address<br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Suspicious inbox forwarding sign-in risk detection| Varies| Microsoft Entra risk detection logs| UX: Suspicious inbox forwarding<br><br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+| Microsoft Entra threat intelligence sign-in risk detection| High| Microsoft Entra risk detection logs| UX: Microsoft Entra threat intelligence<br>API: See [riskDetection resource type - Microsoft Graph](/graph/api/resources/riskdetection)| See [What is risk? Microsoft Entra ID Protection](../identity-protection/concept-identity-protection-risks.md)<br>[Sigma rules](https://github.com/SigmaHQ/sigma/tree/master/rules/cloud/azure)|

+* **Microsoft Entra ID**: Microsoft Entra ID synchronizes identity information (users, groups) from organization's on-premises LDAP directories via Microsoft Entra Connect.

+Office apps with modern authentication enabled send '*prompt=login*' to Microsoft Entra ID in their request. By default, Microsoft Entra ID translates '*prompt=login*' in the request to AD FS as '*wauth=usernamepassworduri*' (asks AD FS to do U/P Auth) and '*wfresh=0*' (asks AD FS to ignore SSO state and do a fresh authentication). If you want to enable certificate-based authentication for these apps, you need to modify the default Microsoft Entra behavior. Set the '*PromptLoginBehavior*' in your federated domain settings to '*Disabled*'.

+For cloud-only users, only users with roles **Global Administrators**, **Privileged Authentication Administrator** can write into certificateUserIds. Cloud-only users can use both UX and MSGraph to write into certificateUserIds. For synched users, AD users with role **Hybrid Identity Administrator** can write into the attribute. Only Microsoft Entra Connect can be used to update CertificateUserIds by syncing the value from on-prem for synched users.

+The endpoint performs TLS mutual authentication, and requests the client certificate as part of the TLS handshake. You'll see an entry for this request in the sign-in log.

+ :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-log.png" alt-text="Screenshot of the sign-in log in Microsoft Entra ID." lightbox="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-log.png":::

+Authentication providers can be found in the [Microsoft Entra admin center](https://entra.microsoft.com). Sign in as at least an [Authentication Policy Administrator](../roles/permissions-reference.md#authentication-policy-administrator). Browse to **Protection** > **Multifactor authentication** > **Providers**. Click the listed providers to see details and configurations associated with that provider.

+> In September 2022, Microsoft announced deprecation of Azure Multi-Factor Authentication Server. Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+* Multi-Factor Authentication Server status

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

+If you have a Microsoft Entra ID P1 or P2 license, we recommend using Conditional Access policy for *Persistent browser session*. This policy overwrites the *Stay signed in?* setting and provides an improved user experience. If you don't have a Microsoft Entra ID P1 or P2 license, we recommend enabling the stay signed in setting for your users.

+If you use *Remember MFA* and have Microsoft Entra ID P1 or P2 licenses, consider migrating these settings to Conditional Access Sign-in Frequency. Otherwise, consider using *Keep me signed in?* instead.

+Two-way SMS for Azure Multi-Factor Authentication Server was originally deprecated in 2018, and no longer supported after February 24, 2021, except for organizations that received a support extension until August 2, 2021. Administrators should enable another method for users who still use two-way SMS.

+AD FS adapter requires number matching on supported versions of Windows Server. On earlier versions, users continue to see the **Approve**/**Deny** experience and donΓÇÖt see number matching until you upgrade. The AD FS adapter supports number matching only after you install one of the updates in the following table. For more information about how to set up AD FS adapter, see [Configure Azure Multi-Factor Authentication Server to work with AD FS in Windows Server](howto-mfaserver-adfs-windows-server.md).

+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. From Sept. 25 to Oct. 20, 2023, the Microsoft managed value for the registration campaign will change to **Enabled** for voice call and text message users across all tenants. For more information, see [Protecting authentication methods in Microsoft Entra ID](concept-authentication-default-enablement.md).

+|Preparations |[Identify Azure Multi-Factor Authentication Server dependencies](#identify-azure-ad-mfa-server-dependencies) |

+||[Backup Azure Multi-Factor Authentication Server datafile](#backup-azure-ad-mfa-server-datafile) |

+<a name='identify-microsoft-entra-multifactor-authentication-server-dependencies'></a>

+### Identify Azure Multi-Factor Authentication Server dependencies

+<a name='backup-microsoft-entra-multifactor-authentication-server-datafile'></a>

+### Backup Azure Multi-Factor Authentication Server datafile

+Make a backup of the MFA Server data file located at %programfiles%\Multi-Factor Authentication Server\Data\PhoneFactor.pfdata (default location) on your primary MFA Server. Make sure you have a copy of the installer for your currently installed version in case you need to roll back. If you no longer have a copy, contact Customer Support Services.

+Run the new installer on the Primary MFA Server. Before you upgrade a server, remove it from load balancing or traffic sharing with other MFA Servers. You don't need to uninstall your current MFA Server before running the installer. The installer performs an in-place upgrade using the current installation path (for example, C:\Program Files\Multi-Factor Authentication Server). If you're prompted to install a Microsoft Visual C++ 2015 Redistributable update package, accept the prompt. Both the x86 and x64 versions of the package are installed. It isn't required to install updates for User portal, Web SDK, or AD FS Adapter.

+After installing the MFA Server update, open an elevated PowerShell command prompt: hover over the PowerShell icon, right-click, and click **Run as Administrator**. Run the .\Configure-MultiFactorAuthMigrationUtility.ps1 script found in your MFA Server installation directory (C:\Program Files\Multi-Factor Authentication Server by default).

+Once complete, navigate to the Multi-Factor Authentication Server folder, and open the **MultiFactorAuthMigrationUtilityUI** application. You should see the following screen:

+Migrating user data doesn't remove or alter any data in the Multi-Factor Authentication Server database. Likewise, this process won't change where a user performs MFA. This process is a one-way copy of data from the on-premises server to the corresponding user object in Microsoft Entra ID.

+Multifactor authentication is important to securing your infrastructure and assets from bad actors. Azure Multi-Factor Authentication Server (MFA Server) isn't available for new deployments and will be deprecated. Customers who are using MFA Server should move to using cloud-based Microsoft Entra multifactor authentication.

+Refer to the help file topic **GetUserInfo** > **userSettings** > **OathTokenSerialNumber** in Multi-Factor Authentication Server on your MFA Server.

+Multifactor authentication helps secure your infrastructure and assets from bad actors. Microsoft Multi-Factor Authentication Server (MFA Server) is no longer offered for new deployments. Customers who are using MFA Server should move to Microsoft Entra multifactor authentication (Microsoft Entra multifactor authentication).

+1. Clear the **Azure Multi-Factor Authentication Server** checkbox.

+* Uninstall Multi-Factor Authentication Server from the Control Panel on the server.

+

+1. Uncheck the box next to **Azure Multi-Factor Authentication Server**.

+* Uninstall Multi-Factor Authentication Server from the Control Panel on the server

+Users register their passwordless method as a part of the **combined security information workflow** at [https://aka.ms/mysecurityinfo](https://aka.ms/mysecurityinfo). Microsoft Entra logs registration of security keys and the Authenticator app, and any other changes to the authentication methods.

+> In September 2022, Microsoft announced deprecation of Azure Multi-Factor Authentication Server. Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their users' authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+Microsoft Entra Connect doesn't write info back from Microsoft Entra ID to Active Directory DS. The utility includes the PowerShell module to create the Kerberos Server Object in AD DS and publish it in Microsoft Entra ID.

+Yes. A user must be in the Domain Users group to be able to sign-in using Microsoft Entra Kerberos.

+* By default, the Microsoft Entra user Principal Name (UPN) is set to the same value as the on-premises UPN.

+Prior to the availability of the NPS extension for Azure, customers who wished to implement two-step verification for integrated NPS and Microsoft Entra multifactor authentication environments had to configure and maintain a separate MFA Server in the on-premises environment as documented in [Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS](howto-mfaserver-nps-rdg.md).

+* Microsoft Entra synched with on-premises Active Directory

+<a name='azure-active-directory-synched-with-on-premises-active-directory'></a>

+### Microsoft Entra synched with on-premises Active Directory

+[Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS](howto-mfaserver-nps-rdg.md)

+Prior to the availability of the NPS extension for Azure, customers who wanted to implement two-step verification for integrated NPS and MFA environments had to configure and maintain a separate MFA server in an on-premises environment. This type of authentication is offered by Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS.

+* Microsoft Entra ID synced with on-premises Active Directory

+<a name='azure-active-directory-synced-with-on-premises-active-directory'></a>

+### Microsoft Entra ID synced with on-premises Active Directory

+[Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS](howto-mfaserver-nps-rdg.md)

+This document explains how to find user information collected by Azure Multi-Factor Authentication Server (MFA Server), Microsoft Entra multifactor authentication (Cloud-based), and self-service password reset (SSPR) in the event you would like to remove it.

+ [](media/howto-mfa-userstates/selectmfa.png#lightbox)

+ Title: Use Azure Multi-Factor Authentication Server with AD FS 2.0

+# Configure Azure Multi-Factor Authentication Server to work with AD FS 2.0

+This article is for organizations that are federated with Microsoft Entra ID, and want to secure resources that are on-premises or in the cloud. Protect your resources by using the Azure Multi-Factor Authentication Server and configuring it to work with AD FS so that two-step verification is triggered for high-value end points.

+This documentation covers using the Azure Multi-Factor Authentication Server with AD FS 2.0. For information about AD FS, see [Securing cloud and on-premises resources using Azure Multi-Factor Authentication Server with Windows Server](howto-mfaserver-adfs-windows-server.md).

+> In September 2022, Microsoft announced deprecation of Azure Multi-Factor Authentication Server. Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Microsoft Entra multifactor authentication service by using the latest Migration Utility included in the most recent [Azure Multi-Factor Authentication Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure Multi-Factor Authentication Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+To secure AD FS 2.0 with a proxy, install the Azure Multi-Factor Authentication Server on the AD FS proxy server.

+1. In the Azure Multi-Factor Authentication Server, click the **IIS Authentication** icon in the left menu.

+You can secure AD FS when the AD FS proxy isn't used. Install the Azure Multi-Factor Authentication Server on the AD FS server and configure the Server per the following steps:

+1. Within the Azure Multi-Factor Authentication Server, click the **IIS Authentication** icon in the left menu.

+# Configure Azure Multi-Factor Authentication Server to work with AD FS in Windows Server

+If you use Active Directory Federation Services (AD FS) and want to secure cloud or on-premises resources, you can configure Azure Multi-Factor Authentication Server to work with AD FS. This configuration triggers two-step verification for high-value endpoints.

+In this article, we discuss using Azure Multi-Factor Authentication Server with AD FS beginning with Windows Server 2016. For more information, read about how to [secure cloud and on-premises resources by using Azure Multi-Factor Authentication Server with AD FS 2.0](howto-mfaserver-adfs-2.md).

+> In September 2022, Microsoft announced deprecation of Azure Multi-Factor Authentication Server. Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+<a name='secure-windows-server-ad-fs-with-azure-multifactor-authentication-server'></a>

+## Secure Windows Server AD FS with Azure Multi-Factor Authentication Server

+When you install Azure Multi-Factor Authentication Server, you have the following options:

+* Install Azure Multi-Factor Authentication Server locally on the same server as AD FS

+* Install the Azure multifactor authentication adapter locally on the AD FS server, and then install Multi-Factor Authentication Server on a different computer

+* You don't have to install Azure Multi-Factor Authentication Server on your AD FS server. However, you must install the multifactor authentication adapter for AD FS on a Windows Server 2012 R2 or Windows Server 2016 that is running AD FS. You can install the server on a different computer if you install the AD FS adapter separately on your AD FS federation server. See the following procedures to learn how to install the adapter separately.

+* For information about installing the Web Service SDK with the user portal, see [deploying the user portal for Azure Multi-Factor Authentication Server.](howto-mfaserver-deploy-userportal.md)

+<a name='install-azure-multifactor-authentication-server-locally-on-the-ad-fs-server'></a>

+### Install Azure Multi-Factor Authentication Server locally on the AD FS server

+1. Download and install Azure Multi-Factor Authentication Server on your AD FS server. For installation information, read about [getting started with Azure Multi-Factor Authentication Server](howto-mfaserver-deploy.md).

+2. In the Azure Multi-Factor Authentication Server management console, click the **AD FS** icon. Select the options **Allow user enrollment** and **Allow users to select method**.

+7. In the installation wizard, click **Next**. Azure Multi-Factor Authentication Server creates the PhoneFactor Admins group and adds the AD FS service account to the PhoneFactor Admins group.

+At this point, Multi-Factor Authentication Server is set up to be an additional authentication provider to use with AD FS.

+1. Install the Web Service SDK on the server that is running Multi-Factor Authentication Server.

+2. Copy the following files from the \Program Files\Multi-Factor Authentication Server directory to the server on which you plan to install the AD FS adapter:

+Finally, to register the adapter, run the \Program Files\Multi-Factor Authentication Server\Register-MultiFactorAuthenticationAdfsAdapter.ps1 script in PowerShell. The adapter is registered as WindowsAzureMultiFactorAuthentication. Restart the AD FS service for the registration to take effect.

+description: Deploy multiple instances of Azure Multi-Factor Authentication Server in configurations that provide high availability.

+# Configure Azure Multi-Factor Authentication Server for high availability

+> In September 2022, Microsoft announced deprecation of Azure Multi-Factor Authentication Server. Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+# Enable mobile app authentication with Azure Multi-Factor Authentication Server

+> In September 2022, Microsoft announced deprecation of Azure Multi-Factor Authentication Server. Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+> If you have installed Azure Multi-Factor Authentication Server v8.x or higher, most of the steps below are not required. Mobile app authentication can be set up by following the steps under [Configure the mobile app](#configure-the-mobile-app-settings-in-mfa-server).

+To use the Authenticator app, you must be running Azure Multi-Factor Authentication Server v8.x or higher

+- [Advanced scenarios with Azure Multi-Factor Authentication Server and third-party VPNs](howto-mfaserver-nps-vpn.md).

+ Title: Upgrade PhoneFactor to Azure Multi-Factor Authentication Server

+description: Get started with Azure Multi-Factor Authentication Server when you upgrade from the older phonefactor agent.

+# Upgrade the PhoneFactor Agent to Azure Multi-Factor Authentication Server

+To upgrade the PhoneFactor Agent v5.x or older to Azure Multi-Factor Authentication Server, uninstall the PhoneFactor Agent and affiliated components first. Then the Multi-Factor Authentication Server and its affiliated components can be installed.

+> In September 2022, Microsoft announced deprecation of Azure Multi-Factor Authentication Server. Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+<a name='install-the-multifactor-authentication-server'></a>

+## Install the Multi-Factor Authentication Server

+The installation path is picked up from the registry from the previous PhoneFactor Agent installation, so it should install in the same location (for example, C:\Program Files\PhoneFactor). New installations have a different default install path (for example, C:\Program Files\Multi-Factor Authentication Server). The data file left by the previous PhoneFactor Agent should be upgraded during installation, so your users and settings should still be there after installing the new Multi-Factor Authentication Server.

+1. If prompted, activate the Multi-Factor Authentication Server and ensure it is assigned to the correct replication group.

+2. If the Web Service SDK was previously installed, install the new Web Service SDK through the Multi-Factor Authentication Server User Interface.

+3. If the User portal was previously installed on the PhoneFactor Agent Server, install the new multifactor authentication User portal through the Multi-Factor Authentication Server User Interface.

+ The default virtual directory name is now **MultiFactorAuth** instead of **PhoneFactor**. If you want to use the previous name, you must change the name of the virtual directory during installation. Otherwise, if you allow the install to use the new default name, you should click the User portal icon in the Multi-Factor Authentication Server and update the User portal URL on the Settings tab.

+ The default virtual directory name is now **MultiFactorAuth** instead of **PhoneFactor**. If you want to use the previous name, you must change the name of the virtual directory during installation. Otherwise, if you allow the install to use the new default name, you should click the User portal icon in the Multi-Factor Authentication Server and update the User portal URL on the Settings tab. Existing users need to be informed of the new URL.

+- [Install the users portal](howto-mfaserver-deploy-userportal.md) for the Azure Multi-Factor Authentication Server.

+description: Steps and guidance to upgrade the Azure Multi-Factor Authentication Server to a newer version.

+# Upgrade to the latest Azure Multi-Factor Authentication Server

+This article walks you through the process of upgrading Azure Multi-Factor Authentication Server v6.0 or higher. If you need to upgrade an old version of the PhoneFactor Agent, refer to [Upgrade the PhoneFactor Agent to Azure Multi-Factor Authentication Server](howto-mfaserver-deploy-upgrade-pf.md).

+> In September 2022, Microsoft announced deprecation of Azure Multi-Factor Authentication Server. Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+1. Use the instructions in [Download the Azure Multi-Factor Authentication Server](howto-mfaserver-deploy.md#download-the-mfa-server) to get the latest version of the Azure MFA Server installer.

+2. Make a backup of the MFA Server data file located at C:\Program Files\Multi-Factor Authentication Server\Data\PhoneFactor.pfdata (assuming the default install location) on your primary MFA Server.

+ > You do not need to uninstall your current MFA Server before running the installer. The installer performs an in-place upgrade. The installation path is picked up from the registry from the previous installation, so it installs in the same location (for example, C:\Program Files\Multi-Factor Authentication Server).

+These instructions only apply if you run Multi-Factor Authentication Server separately from your AD FS servers. If both services run on the same servers, skip this section and go to the installation steps.

+# User portal for the Azure Multi-Factor Authentication Server

+Depending on your environment, you may want to deploy the user portal on the same server as Azure Multi-Factor Authentication Server or on another internet-facing server.

+> In September 2022, Microsoft announced deprecation of Azure Multi-Factor Authentication Server. Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+> The user portal is only available with Multi-Factor Authentication Server. If you use multifactor authentication in the cloud, refer your users to the [Set-up your account for two-step verification](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc) or [Manage your settings for two-step verification](https://support.microsoft.com/account-billing/change-your-two-step-verification-method-and-settings-c801d5ad-e0fc-4711-94d5-33ad5d4630f7).

+In either scenario, if the Microsoft Entra multifactor authentication Web Service SDK is **not** already installed on the Azure Multi-Factor Authentication Server, complete the steps that follow.

+1. Open the Multi-Factor Authentication Server console.

+<a name='deploy-the-user-portal-on-the-same-server-as-the-microsoft-entra-multifactor-authentication-server'></a>

+## Deploy the user portal on the same server as the Azure Multi-Factor Authentication Server

+The following pre-requisites are required to install the user portal on the **same server** as the Azure Multi-Factor Authentication Server:

+1. Open the Azure Multi-Factor Authentication Server console, click the **User Portal** icon in the left menu, then click **Install User Portal**.

+If the server where Azure Multi-Factor Authentication Server is running isn't internet-facing, you should install the user portal on a **separate, internet-facing server**.

+* Use v6.0 or higher of the Azure Multi-Factor Authentication Server.

+* Ensure that the user portal can authenticate to the Microsoft Entra multifactor authentication Web Service SDK using the credentials of a service account in the "PhoneFactor Admins" security group. This service account and group should exist in Active Directory if the Azure Multi-Factor Authentication Server is running on a domain-joined server. This service account and group exist locally on the Azure Multi-Factor Authentication Server if it isn't joined to a domain.

+Installing the user portal on a server other than the Azure Multi-Factor Authentication Server requires the following steps:

+1. **On the MFA Server**, browse to the installation path (Example: C:\Program Files\Multi-Factor Authentication Server), and copy the file **MultiFactorAuthenticationUserPortalSetup64** to a location accessible to the internet-facing server where you'll install it.

+<a name='configure-user-portal-settings-in-the-microsoft-entra-multifactor-authentication-server'></a>

+## Configure user portal settings in the Azure Multi-Factor Authentication Server

+Now that the user portal is installed, you need to configure the Azure Multi-Factor Authentication Server to work with the portal.

+1. In the Azure Multi-Factor Authentication Server console, click the **User Portal** icon. On the Settings tab, enter the URL to the user portal in the **User Portal URL** textbox. If email functionality has been enabled, this URL is included in the emails that are sent to users when they're imported into the Azure Multi-Factor Authentication Server.

+Azure Multi-Factor Authentication Server provides several options for the user portal. The following table provides a list of these options and an explanation of what they're used for.

+| Enable logging | Enable logging on the user portal. The log files are located at: C:\Program Files\Multi-Factor Authentication Server\Logs. |

+If the administrators have configured the Azure Multi-Factor Authentication Server to collect security questions and answers, the user is then taken to the Security Questions page. The user must select four security questions and provide answers to their selected questions.

+- [Deploy the Azure Multi-Factor Authentication Server Mobile App Web Service](howto-mfaserver-deploy-mobileapp.md)

+ Title: Getting started Azure Multi-Factor Authentication Server

+description: Step-by-step get started with Azure Multi-Factor Authentication Server on-premises

+# Getting started with the Azure Multi-Factor Authentication Server

+This page covers a new installation of the server and setting it up with on-premises Active Directory. If you already have the MFA server installed and are looking to upgrade, see [Upgrade to the latest Azure Multi-Factor Authentication Server](howto-mfaserver-deploy-upgrade.md). If you're looking for information on installing just the web service, see [Deploying the Azure Multi-Factor Authentication Server Mobile App Web Service](howto-mfaserver-deploy-mobileapp.md).

+> In September 2022, Microsoft announced deprecation of Azure Multi-Factor Authentication Server. Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Microsoft Entra multifactor authentication service by using the latest Migration Utility included in the most recent [Azure Multi-Factor Authentication Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure Multi-Factor Authentication Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+Before you download the Azure Multi-Factor Authentication Server, think about what your load and high availability requirements are. Use this information to decide how and where to deploy.

+Do you need to set up multiple servers for high availability or load balancing? There are many ways to set up this configuration with Azure Multi-Factor Authentication Server. When you install your first Azure Multi-Factor Authentication Server, it becomes the master. Any other servers become subordinate, and automatically synchronize users and configuration with the master. Then, you can configure one primary server and have the rest act as backup, or you can set up load balancing among all the servers.

+When a master Azure Multi-Factor Authentication Server goes offline, the subordinate servers can still process two-step verification requests. However, you can't add new users and existing users can't update their settings until the master is back online or a subordinate gets promoted.

+| Azure Multi-Factor Authentication Server Requirements | Description |

+¹If Azure Multi-Factor Authentication Server fails to activate on an Azure VM that runs Windows Server 2019 or later, try using an earlier version of Windows Server.

+<a name='microsoft-entra-multifactor-authentication-server-components'></a>

+### Azure Multi-Factor Authentication Server Components

+There are three web components that make up Azure Multi-Factor Authentication Server:

+<a name='azure-multifactor-authentication-server-firewall-requirements'></a>

+### Azure Multi-Factor Authentication Server firewall requirements

+Follow these steps to download the Azure Multi-Factor Authentication Server:

+> In September 2022, Microsoft announced deprecation of Azure Multi-Factor Authentication Server. Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Microsoft Entra multifactor authentication service by using the latest Migration Utility included in the most recent [Azure Multi-Factor Authentication Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure Multi-Factor Authentication Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+5. Back on the page that you downloaded the server from, click the **Generate Activation Credentials** button. Copy this information into the Azure Multi-Factor Authentication Server in the boxes provided and click **Activate**.

+1. In the Azure Multi-Factor Authentication Server, on the left, select **Users**.

+1. In the Azure Multi-Factor Authentication Server, on the left, select **Directory Integration**.

+<a name='how-the-microsoft-entra-multifactor-authentication-server-handles-user-data'></a>

+## How the Azure Multi-Factor Authentication Server handles user data

+When you use the Multi-Factor Authentication Server on-premises, a user's data is stored in the on-premises servers. No persistent user data is stored in the cloud. When the user performs a two-step verification, the MFA Server sends data to the Microsoft Entra multifactor authentication cloud service to perform the verification. When these authentication requests are sent to the cloud service, the following fields are sent in the request and logs so that they are available in the customer's authentication/usage reports. Some of the fields are optional so they can be enabled or disabled within the Multi-Factor Authentication Server. The communication from the MFA Server to the MFA cloud service uses SSL/TLS over port 443 outbound. These fields are:

+<a name='back-up-and-restore-microsoft-entra-multifactor-authentication-server'></a>

+## Back up and restore Azure Multi-Factor Authentication Server

+To back up Azure Multi-Factor Authentication Server, ensure that you have a copy of the **C:\Program Files\Multi-Factor Authentication Server\Data** folder including the **PhoneFactor.pfdata** file.

+1. Reinstall Azure Multi-Factor Authentication Server on a new server.

+2. Activate the new Azure Multi-Factor Authentication Server.

+- Set up and configure the Azure Multi-Factor Authentication Server with [Active Directory Federation Service](multi-factor-authentication-get-started-adfs.md), [RADIUS Authentication](howto-mfaserver-dir-radius.md), or [LDAP Authentication](howto-mfaserver-dir-ldap.md).

+- Set up and configure [Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS](howto-mfaserver-nps-rdg.md).

+- [Deploy the Azure Multi-Factor Authentication Server Mobile App Web Service](howto-mfaserver-deploy-mobileapp.md).

+description: Deploying RADIUS Authentication and Azure Multi-Factor Authentication Server.

+# Integrate RADIUS authentication with Azure Multi-Factor Authentication Server

+RADIUS is a standard protocol to accept authentication requests and to process those requests. The Azure Multi-Factor Authentication Server can act as a RADIUS server. Insert it between your RADIUS client (VPN appliance) and your authentication target to add two-step verification. Your authentication target could be Active Directory, an LDAP directory, or another RADIUS server. For Azure multifactor authentication to function, you must configure the Azure MFA Server so that it can communicate with both the client servers and the authentication target. The Azure MFA Server accepts requests from a RADIUS client, validates credentials against the authentication target, adds Azure multifactor authentication, and sends a response back to the RADIUS client. The authentication request only succeeds if both the primary authentication and the Azure multifactor authentication succeed.

+> In September 2022, Microsoft announced deprecation of Azure Multi-Factor Authentication Server. Beginning September 30, 2024, Azure Multi-Factor Authentication Server deployments will no longer service multifactor authentication requests, which could cause authentications to fail for your organization. To ensure uninterrupted authentication services and to remain in a supported state, organizations should [migrate their usersΓÇÖ authentication data](how-to-migrate-mfa-server-to-mfa-user-authentication.md) to the cloud-based Azure MFA service by using the latest Migration Utility included in the most recent [Azure MFA Server update](https://www.microsoft.com/download/details.aspx?id=55849). For more information, see [Azure MFA Server Migration](how-to-migrate-mfa-server-to-azure-mfa.md).

+To configure RADIUS authentication, install the Azure Multi-Factor Authentication Server on a Windows server. If you have an Active Directory environment, the server should be joined to the domain inside the network. Use the following procedure to configure the Azure Multi-Factor Authentication Server:

+1. In the Azure Multi-Factor Authentication Server, click the RADIUS Authentication icon in the left menu.

+5. Enter the IP address of the appliance/server that will authenticate to the Azure Multi-Factor Authentication Server, an application name (optional), and a shared secret.

+ The shared secret needs to be the same on both the Azure Multi-Factor Authentication Server and appliance/server.

+ The shared secret needs to be the same on both the Azure Multi-Factor Authentication Server and RADIUS server. Change the Authentication port and Accounting port if different ports are used by the RADIUS server.

+1. Add the Azure MFA Server as a RADIUS client in the other RADIUS server so that it can process access requests sent to it from the Azure MFA Server. Use the same shared secret configured in the Azure Multi-Factor Authentication Server.

+You've successfully configured the Azure Multi-Factor Authentication Server. The Server is now listening on the configured ports for RADIUS access requests from the configured clients.

+* Configure your appliance/server to authenticate via RADIUS to the Azure Multi-Factor Authentication Server's IP address, which acts as the RADIUS server.

+Azure Multi-Factor Authentication Server (Azure MFA Server) can be used to seamlessly connect with various third-party VPN solutions. This article focuses on Cisco&reg; ASA VPN appliance, Citrix NetScaler SSL VPN appliance, and the Juniper Networks Secure Access/Pulse Secure Connect Secure SSL VPN appliance. We created configuration guides to address these three common appliances. Azure MFA Server can also integrate with most other systems that use RADIUS, LDAP, IIS, or claims-based authentication to AD FS. You can find more details in [Azure MFA Server configurations](howto-mfaserver-deploy.md#next-steps).

+description: Deploying Windows Authentication and Azure Multi-Factor Authentication Server.

+# Windows Authentication and Azure Multi-Factor Authentication Server

+Use the Windows Authentication section of the Azure Multi-Factor Authentication Server to enable and configure Windows authentication for applications. Before you set up Windows Authentication, keep the following list in mind:

+1. In the Azure Multi-Factor Authentication Server click the Windows Authentication icon.

+| Online courses|[Managing Identities in Microsoft Entra ID](https://www.pluralsight.com/courses/microsoft-azure-active-directory-managing-identities) Use SSPR to give your users a modern, protected experience. See especially the "[`Managing Microsoft Entra Users and Groups`](https://app.pluralsight.com/library/courses/microsoft-azure-active-directory-managing-identities/table-of-contents)" module. |

+* Secure cloud and on-premises resources using Azure Multi-Factor Authentication Server

+For information on setting up either Microsoft Entra multifactor authentication or the Azure Multi-Factor Authentication Server with AD FS, see the following articles:

+* [Secure cloud and on-premises resources using Azure Multi-Factor Authentication Server with Windows Server](howto-mfaserver-adfs-windows-server.md)

+* [Secure cloud and on-premises resources using Azure Multi-Factor Authentication Server with AD FS 2.0](howto-mfaserver-adfs-2.md)

+The setup guides help you configure the core functionality of Microsoft Entra ID. If you need to set up a more advanced configuration, the setup guide points you to the appropriate location in the Microsoft Entra admin center.

+ :::image type="content" source="./media/troubleshoot-authentication-strengths/sign-in-logs-authentication-details.png" alt-text="Screenshot showing the authentication strength in the sign-in log.":::

+ :::image type="content" source="./media/troubleshoot-authentication-strengths/sign-in-logs-control.png" alt-text="Screenshot showing the authentication strength under Conditional Access Policy details in the sign-in log.":::

+The **Require users to consent on every device** setting enables you to require end users to accept your terms of use policy on every device they're accessing from. The end user's device must be registered in Microsoft Entra ID. When the device is registered, the device ID is used to enforce the terms of use policy on each device. Their experience is dependent on permissions to join devices as well as the platform and software used, for more information see, [device identity in Microsoft Entra ID](../devices/overview.md).

+ Microsoft Entra tenant-independent key endpoint ([https://login.microsoftonline.com/common/discovery/v2.0/keys](https://login.microsoftonline.com/common/discovery/v2.0/keys)) returns a document like:

+Allows you to securely access Microsoft Entra protected resources from external apps and services without needing to manage secrets (for supported scenarios). For more information, see [workload identity federation](../workload-identities/workload-identity-federation.md).

+ Title: Microsoft Entra federation metadata

+description: This article describes the federation metadata document that Microsoft Entra ID publishes for services that accept Microsoft Entra tokens.

+* A registered domain name of a Microsoft Entra tenant, such as: `contoso.onmicrosoft.com`.

+For **tenant-independent endpoints**, the `TenantDomainName` is `common`. This document lists only the Federation Metadata elements that are common to all Microsoft Entra tenants that are hosted at login.microsoftonline.com.

+The following section provides information needed by services that consume the tokens issued by Microsoft Entra ID.

+When a service receives a token that is issued by a Microsoft Entra tenant, the signature of the token must be validated with a signing key that is published in the federation metadata document. The federation metadata includes the public portion of the certificates that the tenants use for token signing. The certificate raw bytes appear in the `KeyDescriptor` element. The token signing certificate is valid for signing only when the value of the `use` attribute is `signing`.

+A federation metadata document published by Microsoft Entra ID can have multiple signing keys, such as when Microsoft Entra ID is preparing to update the signing certificate. When a federation metadata document includes more than one certificate, a service that is validating the tokens should support all certificates in the document.

+The federation metadata includes the URL that is Microsoft Entra ID uses for single sign-in and single sign-out in WS-Federation protocol. This endpoint appears in the `PassiveRequestorEndpoint` element.

+The federation metadata includes the URL that Microsoft Entra ID uses for single sign-in and single sign-out in SAML 2.0 protocol. These endpoints appear in the `IDPSSODescriptor` element.

+**Promote your application to the millions of organizations who are already using Microsoft Entra ID.** Users who search and browse these marketplaces are already using one or more cloud services, making them qualified cloud service customers. Learn more about promoting your application in [the Azure Marketplace](https://azure.microsoft.com/marketplace/partner-program/).

+Your ΓÇ£get the appΓÇ¥ link must redirect the user to the Microsoft Entra ID grant access (authorize) page, to allow an organizationΓÇÖs administrator to authorize your app to have access to their organizationΓÇÖs data, which is hosted by Microsoft. Details on how to request access are discussed in the [Integrating Applications with Microsoft Entra ID](./quickstart-register-app.md) article.

+The Microsoft Authentication Library for iOS and macOS (MSAL) is built to work with all Microsoft identities such as Microsoft Entra accounts, personal Microsoft accounts, and Azure AD B2C accounts via the Microsoft identity platform (formerly the Azure AD v2.0 endpoint).

+An important difference between the Azure Active Directory v1.0 versus 2.0 endpoints is about how the resources are accessed. When using ADAL.js with the **v1.0** endpoint, you would first register a permission on app registration portal, and then request an access token for a resource (such as Microsoft Graph) as shown below:

+1. Extract the zip file to a local folder close to the root of the disk, such as `C:\Azure-Samples`.

+1. Navigate to the `msal-client-credential-secret` subfolder.

+1. Edit `src\main\resources\application.properties` and replace the values of the fields `AUTHORITY`, `CLIENT_ID`, and `SECRET` with the following snippet:

+> 1. On the front page, select the **Login** button to redirect users to Microsoft Entra ID and prompt them for credentials.

+3. Open a Command Prompt window. Go to the root folder of this sample (where the `pom.xml` file is located), and run `mvn package` to build the project.

+ - This command will generate a `msal-web-sample-0.1.0.war` file in your `/targets` directory.

+ - Rename this file to `msal4jsample.war`.

+ - To deploy the `msal4jsample.war` file, copy it to the `/webapps/` directory in your Tomcat installation, and then start the Tomcat server.

+4. After the file is deployed, go to `https://localhost:8443/msal4jsample` by using a browser.

+> | ASP.NET Core|[Active Directory Federation Services to Microsoft Entra migration](https://github.com/Azure-Samples/ms-identity-dotnet-adfs-to-aad) | [MSAL.NET](/entra/msal/dotnet) | &#8226; SAML <br/> &#8226; OpenID connect |

+> | Web application |[Active Directory Federation Services to Microsoft Entra migration](https://github.com/Azure-Samples/ms-identity-dotnet-adfs-to-aad) | [MSAL.NET](/entra/msal/dotnet) | &#8226; SAML <br/> &#8226; OpenID connect |

+### Azure AD (v1.0) resources

+The initialization code differences are platform dependant. For ASP.NET Core and ASP.NET, signing in users is delegated to the OpenID Connect middleware. The ASP.NET or ASP.NET Core template generates web applications for the Azure AD v1.0 endpoint. Some configuration is required to adapt them to the Microsoft identity platform.

+> This code uses the legacy **Microsoft.AspNetCore.Authentication.AzureAD.UI** NuGet package which is used to create an Azure Active Directory v1.0 application. This article explains how to create a Microsoft identity platform v2.0 application which replaces that code.

+To learn more about these packages refer to the documentation in [`msal-browser`](/javascript/api/@azure/msal-browser), [`msal-common`](/javascript/api/@azure/msal-common), [`msal-react`](/javascript/api/@azure/msal-react).

+

+* For more Microsoft Entra code samples, see [samples](sample-v2-code.md).

+> 1. On the front page, select the **Login** button to redirect users to Microsoft Entra ID and prompt them for credentials.

+Microsoft Entra joined Device Local Administrators are assigned to all Microsoft Entra joined devices. You canΓÇÖt scope this role to a specific set of devices. Updating the Azure AD Joined Device Local Administrator role doesn't necessarily have an immediate impact on the affected users. On devices where a user is already signed into, the privilege elevation takes place when *both* the below actions happen:

+- The value for **DeviceTrustType** is **Domain Joined**. This setting is equivalent to the **Microsoft Entra hybrid joined** state on the **Devices** page in the Microsoft Entra admin center.

+

+- **WamDefaultGUID**: The WAM provider's (Microsoft Entra ID / Microsoft account) GUID for the default WAM WebAccount.

+Scenario: An application developed to use MSAL (Example: **Microsoft To Do** client) that is running on an Apple device needs to sign the user in with their Microsoft Entra account in order to access a Microsoft Entra protected service (Example: **Microsoft To Do Service**).

+1. MSAL-developed applications invoke the SSO extension directly, and send the PRT to the Microsoft Entra token endpoint along with the application's request for a token for a Microsoft Entra protected resource

+1. The SSO extension broker then passes the token to the MSAL client application, which then sends it to the Microsoft Entra protected resource

+Scenario: A user on an Apple device opens up the Safari web browser (or any Non-MSAL native app that supports the Apple Networking Stack) to sign into a Microsoft Entra protected resource (Example: `https://office.com`).

+1. The application-specific token is given to the Non-MSAL client application, and the client application sends the token to access the Microsoft Entra protected service

+To acquire a fresh PRT that has the new credentials, wait for the Microsoft Entra synchronization to finish.

+> While LinkedIn integration is not fully enabled until your users consent to connect their accounts, access to public LinkedIn profile information is available without requiring individual consent. Full integration (two-way consent and additional fields) is not enabled without each user's consent. Your users can see the available LinkedIn profile of anyone that matches the name searched, regardless of whether that match is in the same enabled group or not.

+<a name='microsoft-entra-id-monitoring-and-audit-logs'></a>

+### Microsoft Entra monitoring and audit logs

+See [Configure external collaboration settings](external-collaboration-settings-configure.md) for B2B collaboration with non Microsoft Entra identities, social identities, and non-IT managed external accounts.

+ <!-- -->

+ <!-- -->

+- `Microsoft.Identity.Client` - This package contains the binaries of the Microsoft Authentication Library for .NET (MSAL.NET).

+- `Microsoft.Extensions.Configuration.Json` - This package contains JSON configuration provider implementation for Microsoft.Extensions.Configuration.

+- `Microsoft.Extensions.Configuration.Binder` - This package contains functionality to bind an object to data in configuration providers for Microsoft.Extensions.Configuration.

+- `Microsoft.Extensions.Configuration.Abstractions` - This package contains abstractions of key-value pair based configuration.

+- `Microsoft.Identity.Client.Extensions.Msal` - This package contains extensions to Microsoft Authentication Library for .NET (MSAL.NET).

+ Title: "What's new in Microsoft Entra ID for customers"

+description: "New and updated documentation for the Microsoft Entra ID for customers documentation."

+# Microsoft Entra ID for customers: What's new

+Welcome to what's new in Microsoft Entra ID for customers documentation. This article lists new docs that have been added and those that have had significant updates in the last three months.

+This month, we renamed Microsoft Entra ID to Microsoft Entra ID. For more information about the rebranding, see the [New name for Microsoft Entra ID](/azure/active-directory/fundamentals/new-name) article.

+- [Microsoft Entra ID for customers documentation](index.yml) - Editorial review

+- [Tutorial: Secure an ASP.NET web API registered in the Microsoft Entra ID for customer's tenant](tutorial-protect-web-api-dotnet-core-build-app.md)

+> Make sure you have the latest version of the Azure AD PowerShell module or AzureADPreview PowerShell module.

+1. In the Application type menu, select **Web application**. Give the application a suitable name, like `Microsoft Entra B2B`. Under **Authorized redirect URIs**, add the following URIs:

+1. In the **Identity providers** list, select one or more identity providers that your external users can use to log into your application. **Microsoft Entra ID Sign up** is selected by default. (See [Before you begin](#before-you-begin) earlier in this article to learn how to add identity providers.)

+|**Policy enforcement limitation** | Manage corporate proxies by adding tenants to the Microsoft Entra traffic allowlist. The character limit of the header value in Restrict-Access-To-Tenants: `<allowed-tenant-list>` limits the number of tenants that can be added. | Managed by a cloud policy in the cross-tenant access policy. A partner policy is created for each external tenant. Currently, the configuration for all external tenants is contained in one policy with a 25KB size limit. |

+where `<DirectoryID>` is your Microsoft Entra tenant ID and `<policyGUID>` is the object ID for your cross-tenant access policy.

+where `<DirectoryID>` is your Microsoft Entra tenant ID and `<policyGUID>` is the object ID for your cross-tenant access policy. For details, see [Set up tenant restrictions v2 on your corporate proxy](#option-2-set-up-tenant-restrictions-v2-on-your-corporate-proxy)

+>- B2B authentication of consumer accounts, or "passthrough" authentication, where Azure apps and Office.com apps use Microsoft Entra ID to sign in consumer users in a consumer context.

+Microsoft Entra tenants come with an initial domain name like, `domainname.onmicrosoft.com`. You can't change or delete the initial domain name, but you can add your organization's name to the initial domain. By adding your custom domain name, you can then add user names that are familiar to your users, such as `alain@contoso.com`.

+> When updating domain information, you may be unable to complete the process and encounter a HTTP 500 Internal Server Error message. Under some conditions, this error may be expected. This message may appear if you try to use a protected DNS suffix. Protected DNS suffixes may only be used by Microsoft. If you believe that this operation should have been completed successfully, please contact your Microsoft representative for assistance.

+Microsoft Entra ID provides several ways to manage access to resources, applications, and tasks. With Microsoft Entra groups, you can grant access and permissions to a group of users instead of for each individual user. Limiting access to Microsoft Entra resources to only those users who need access is one of the core security principles of [Zero Trust](/security/zero-trust/zero-trust-overview).

+This article provides an overview of how groups and access rights can be used together to make managing your Microsoft Entra users easier while also applying security best practices.

+It can seem daunting trying to secure your workers in today's world, especially when you have to respond rapidly and provide access to many services quickly. This article is meant to provide a concise list of all the actions to take, helping you identify and prioritize which order to deploy the Microsoft Entra features based on the license type you own.

+Microsoft Entra ID offers many features and provides many layers of security for your Identities, navigating which feature is relevant can sometimes be overwhelming. This document is intended to help organizations deploy services quickly, with secure identities as the primary consideration.

+- Configure access to SaaS and on-premises applications in a secure and protected manner

+- Both cloud and hybrid identities

+- Users working remotely or in the office

+This guide assumes that your cloud only or hybrid identities have been established in Microsoft Entra ID already. For help with choosing your identity type see the article, [Choose the right authentication method for your Microsoft Entra hybrid identity solution](../hybrid/connect/choose-ad-authn.md).

+## Guidance for Microsoft Entra ID Free, Office 365, or Microsoft 365 customers

+| [Enable Security Defaults](security-defaults.md) | Protect all user identities and applications by enabling MFA and blocking legacy authentication. |

+| [Enable Password Hash Sync](../hybrid/connect/how-to-connect-password-hash-synchronization.md) (if using hybrid identities) | Provide redundancy for authentication and improve security (including Smart Lockout, IP Lockout, and the ability to discover leaked credentials). |

+| [Integrate supported SaaS applications from the gallery to Microsoft Entra ID and enable Single sign on](../manage-apps/add-application-portal.md) | Microsoft Entra ID has a gallery that contains thousands of preintegrated applications. Some of the applications your organization uses are probably in the gallery accessible directly from the Azure portal. Provide access to corporate SaaS applications remotely and securely with improved user experience (SSO). |

+## Guidance for Microsoft Entra ID P1 customers

+| [Configure MFA settings for your organization](../authentication/howto-mfa-getstarted.md) | Ensure accounts are protected from being compromised with multifactor authentication. |

+| [Enable self-service password reset](../authentication/tutorial-enable-sspr.md) | This ability reduces help desk calls and loss of productivity when a user can't sign into their device or an application. |

+| [Deploy passwordless authentication methods for your users](../authentication/concept-authentication-passwordless.md) | Provide your users with convenient passwordless authentication methods. |

+## Guidance for Microsoft Entra ID P2 customers

+| [Configure MFA settings for your organization](../authentication/howto-mfa-getstarted.md) | Ensure accounts are protected from being compromised with multifactor authentication. |

+| [Enable self-service password reset](../authentication/tutorial-enable-sspr.md) | This ability reduces help desk calls and loss of productivity when a user can't sign into their device or an application. |

+| [Enable Privileged Identity Management](../privileged-identity-management/pim-configure.md) | Enables you to manage, control, and monitor access to important resources in your organization, ensuring admins have access only when needed and with approval. |

+In this quickstart article, you'll learn how to get to the Azure portal and Microsoft Entra ID, and you'll learn how to create a basic tenant for your organization.

+1. On the overview page, select **Manage tenants**.

+1. Select **Next: Configuration** to move to the Configuration tab.

+1. Select **Next: Review + Create**. Review the information you entered and if the information is correct, select **Create** in the lower left corner.

+- Change or add other domain names, see [How to add a custom domain name to Microsoft Entra ID](add-custom-domain.md).

+- Add groups and members, see [Create a basic group and add members](./how-to-manage-groups.md).

+ 

+In this article, learn about data operational considerations for your configuration. There's information about how log files and other features work in relation to Microsoft Entra ID, such as usage data and operator security. YouΓÇÖll learn about physical security considerations in addition to guidance on how the Microsoft Entra team defines deployments and change.

+To roll out changes to the service across data centers, the Microsoft Entra team defines the layers of a deployment environment. Applying the change layers is constrained by strict exit criteria. The amount of time to roll a change across layers is defined by the operations team and is based on potential effects. Typically a rollout takes between 1 to 2 weeks. Critical changes, such as security fixes or hot fixes, can be deployed faster. If a change doesn't meet the exit criteria when applied to a deployment layer, it's rolled back to the prior, stable state.

+**Auditing**: Access is audited. For example, authorized actions such as create user and password reset create an audit trail that can be used by a tenant administrator to manage compliance efforts or investigations. Tenant administrators can generate audit reports by using the Microsoft Entra audit API.

+Microsoft Entra ID is available in the following clouds:

+MFA stores Identity Customer Data in global datacenters. To learn more about the user information collected and stored by cloud-based Microsoft Entra multifactor authentication and Azure Multi-Factor Authentication Server, see [Microsoft Entra multifactor authentication user data collection](../authentication/concept-mfa-data-residency.md).

+Microsoft Entra ID stores customer data in a geographic location based on how a tenant was created and provisioned. The following list provides information about how the location is defined:

+* **EU Data Residency** - For customers who provided a location in Europe, Microsoft Entra ID stores most of the customer data in Europe, except where noted later in this article.

+* **EU Data Boundary** - For customers who provided a location that is within the [EU Data Boundary](/privacy/eudb/eu-data-boundary-learn#eu-data-boundary-countries-and-datacenter-locations) (members of the EU and EFTA), Microsoft Entra ID stores and processes most of the customer data in the EU Data Boundary, except where noted later in this article.

+Services and applications that integrate with Microsoft Entra ID have access to customer data. Review how each service and application stores and processes customer data, and verify that they meet your company's data handling requirements.

+Learn to integrate your applications with Microsoft Entra ID, which is a cloud-based identity and access management service. Organizations use Microsoft Entra ID for secure authentication and authorization so customers, partners, and employees can access applications.

+With Microsoft Entra ID, features such as Conditional Access, Microsoft Entra multifactor authentication, single sign-on, and application provisioning make identity and access management easier to manage and more secure.

+See: [Quickstart: Add an enterprise application](../manage-apps/add-application-portal.md)

+Microsoft Entra ID has a gallery of integrated applications to make it easy to get started. Add a gallery app to your Microsoft Entra organization (see previous link) and learn about integrating software as a service (SaaS) tutorials.

+See: [Tutorials for integrating SaaS applications with Microsoft Entra ID](../saas-apps/tutorial-list.md)

+* Tutorial: [Microsoft Entra SSO integration with ServiceNow](../saas-apps/servicenow-tutorial.md)

+* Tutorial: [Microsoft Entra SSO integration with Workday](../saas-apps/workday-tutorial.md)

+* Tutorial: [Microsoft Entra SSO integration with Salesforce](../saas-apps/salesforce-tutorial.md)

+* Tutorial: [Microsoft Entra SSO integration with AWS Single-Account Access](../saas-apps/amazon-web-service-tutorial.md)

+* Tutorial: [Microsoft Entra SSO integration with Slack](../saas-apps/slack-tutorial.md)

+See: [Review the application activity report](../manage-apps/migrate-adfs-application-activity.md)

+See: [Resources for migrating applications to Microsoft Entra ID](../manage-apps/migration-resources.md)

+ * See: [Create collections on the My Apps portal](../manage-apps/access-panel-collections.md)

+* Zip file: [Editable Microsoft Entra App Integration One-Pager](https://aka.ms/AppOnePager)

+* Microsoft PowerPoint presentation: [Microsoft Entra application integration guidelines](https://aka.ms/AppGuideline)

+ 

+See: [Using Microsoft Entra application proxy to publish on-premises apps for remote users](../app-proxy/what-is-application-proxy.md)

+See: [Tutorial: Add an on-premises application for remote access through Application Proxy in Microsoft Entra ID](../app-proxy/application-proxy-add-on-premises-application.md)

+See: [Secure hybrid access: Protect legacy apps with Microsoft Entra ID](../manage-apps/secure-hybrid-access.md)

+## Sign up options

+### Sign up using your existing Azure or Microsoft 365 subscription

+### Sign up using your Enterprise Mobility + Security licensing plan

+### Sign up using your Microsoft Volume Licensing plan

+- For 250 or more licenses, see [Microsoft Enterprise Agreement](https://www.microsoft.com/en-us/licensing/licensing-programs/enterprise.aspx).

+- For 5 to 250 licenses, see [Open Volume License](https://www.microsoft.com/en-us/licensing/licensing-programs/open-license.aspx).

+- For more information about volume licensing purchase options, see [How to purchase through Volume Licensing](https://www.microsoft.com/en-us/licensing/how-to-buy/how-to-buy.aspx).

+1. Open the confirmation email you received from Microsoft after you signed up, and then select either **Sign In** or **Sign Up**.

+ 

+1. Select **Sign in** or **Sign up**.

+ - **Sign in.** Choose this link if you have an existing tenant, and then sign in using your existing administrator account. You must be a Global Administrator on the tenant where the licenses are being activated.

+ - **Sign up.** Choose this link if you want to open the **Create Account Profile** page and create a new Microsoft Entra tenant for your licensing plan.

+ 

+Reviewing the default user permissions may also help you determine the type of user you need to create. For more information, see [Set default user permissions](users-default-permissions.md).

+- **User principal name**: Enter a unique username and select a domain from the menu after the @ symbol. Select **Domain not listed** if you need to create a new domain. For more information, see [Add your custom domain name](add-custom-domain.md).

+You can delete an existing user using the [Microsoft Entra admin center](https://entra.microsoft.com/).

+The default sign-in experience is the global look and feel that applies across all sign-ins to your tenant. Before you customize any settings, the default Microsoft branding appears in your sign-in pages. You can customize this default experience with a custom background image and/or color, favicon, layout, header, and footer. You can also upload a custom CSS file.

+- Microsoft Entra ID P1 or P2

+- Microsoft Entra ID P1 or P2

+Microsoft Entra ID P1 or P2 editions are available for customers in China using the worldwide instance of Microsoft Entra ID. Microsoft Entra ID P1 or P2 editions aren't currently supported in the Azure service operated by 21Vianet in China.

+### Basics

+### Layout

+- **Visual Templates**: Customize the layout of your sign-in page using templates or a custom CSS file.

+- **Custom CSS**: Upload a custom CSS file to replace the Microsoft default style of the page.

+### Header

+### Footer

+### Sign-in form

+### Review

+### Customize the sign-in experience by browser language

+- [View the CSS template reference guide](reference-company-branding-css-template.md)

+* [Join the Microsoft Technical Community](https://techcommunity.microsoft.com/)

+If a user doesn't act on the **Stay signed in?** prompt but abandons the sign-in attempt, a sign-in log entry appears in the Microsoft Entra sign-in logs. The prompt the user sees is called an "interrupt."

+If you selected the **Edit properties** option:

+If you selected the **Properties** tab option:

+- [View Microsoft Entra enterprise user management documentation](../enterprise-users/index.yml)

+Azure Active Directory (Azure AD) has been renamed to Microsoft Entra ID to better communicate the multicloud, multiplatform functionality of the product and unify the naming of the Microsoft Entra product family.

+Before changing instances of Azure AD to Microsoft Entra ID in your documentation or content, familiarize yourself with the guidance in [New name for Azure AD](new-name.md) to:

+### Communicate the change to your customers

+- Authentication proves the identity of a user, machine, or software component.

+- Authorization grants or denies the user, machine, or software component access to certain resources.

+The doors to the hotel rooms and other areas have keycard sensors. Swiping the keycard in front of a sensor is the "authorization process". The keycard only lets you open the doors to rooms you're permitted to access, such as your hotel room and the hotel exercise room. If you swipe your keycard to enter any other hotel guest room, your access is denied.

+Individual [permissions](/azure/active-directory/fundamentals/users-default-permissions?context=/azure/active-directory/roles/context/ugr-context), such as accessing the exercise room and a specific guest room, are collected into [roles](/azure/active-directory/roles/concept-understand-roles) which can be granted to individual users. When you're staying at the hotel, you're granted the Hotel Patron role. Hotel room service staff would be granted the Hotel Room Service role. This role permits access to all hotel guest rooms (but only between 11am and 4pm), the laundry room, and the supply closets on each floor.

+- Learn about [Multi-factor authentication (MFA)](/azure/active-directory/authentication/concept-mfa-howitworks).

+description: Instructions about how to assign or remove Microsoft Entra ID licenses from your users or groups.

+There are several Microsoft Entra ID license plans:

+Not all Microsoft services are available in all locations. Before a license can be assigned to a group, you must specify the **Usage location** for all members. You can set this value in Microsoft Entra by going to **Identity** > **Users** > **All users** > *select a user* > **Properties**.

+When assigning licenses to a group or bulk updates, such as disabling the synchronization status for the organization, any user whose usage location isn't specified inherits the location of the tenant.

+ > - **Total**: Total number of licenses purchased

+ > - **Assigned**: Number of licenses assigned to users

+ > - **Available**: Number of licenses available for assignment including expiring soon

+ > - **Expiring soon**: Number of licenses expiring soon

+ Title: Microsoft Entra ID preview program terms

+description: In this article we go over the terms in effect when participating in Microsoft Entra ID preview programs.

+# Customer intent: I am trying to find information on the terms and conditions for Microsoft Entra ID preview programs.

+# Microsoft Entra ID preview program terms

+Microsoft has reamed Azure Active Directory (Azure AD) to Microsoft Entra ID for the following reasons: (1) to communicate the multicloud, multiplatform functionality of the products, (2) to alleviate confusion with Windows Server Active Directory, and (3) to unify the [Microsoft Entra](/entra) product family.

+If you're currently using Azure AD today or are have previously deployed Azure AD in your organizations, you can continue to use the service without interruption. All existing deployments, configurations, and integrations continue to function as they do today without any action from you.

+Service plan display names will change on October 1, 2023. Microsoft Entra ID Free, Microsoft Entra ID P1, and Microsoft Entra ID P2 will be the new names of standalone offers, and all capabilities included in the current Azure AD plans remain the same. Microsoft Entra ID ΓÇô previously known as Azure AD ΓÇô continues to be included in Microsoft 365 licensing plans, including Microsoft 365 E3 and Microsoft 365 E5. Details on pricing and whatΓÇÖs included are available on the [pricing and free trials page](https://aka.ms/PricingEntra).

+| [Microsoft Entra ID (previously known as Azure AD)](../index.yml) | [Microsoft Entra Verified ID](../verifiable-credentials/index.yml) | [Microsoft Entra Internet Access](https://aka.ms/GlobalSecureAccessDocs) |

+Customers using Azure AD Free as part of their Azure, Microsoft 365, Dynamics 365, Teams, or Intune subscription continue to have access to the same capabilities. It will be called Microsoft Entra ID Free. Get the free version at <https://www.microsoft.com/security/business/microsoft-entra-pricing>.

+Microsoft Entra ID ΓÇô previously known as Azure AD ΓÇô continues to be available within Microsoft 365 enterprise and business premium offers. Office 365 was renamed Microsoft 365 in 2022. Unique capabilities in the Azure AD for Office 365 apps (such as company branding and self-service sign-in activity search) are now be available to all Microsoft customers in Microsoft Entra ID Free.

+There are no changes to the identity features and functionality available in Microsoft 365 E3. Microsoft 365 E3 includes Microsoft Entra ID P1, previously known as Azure AD Premium P1.

+In addition to the capabilities they already have, Microsoft 365 E5 customers also get access to new identity protection capabilities like token protection, Conditional Access based on GPS-based location and step-up authentication for the most sensitive actions. Microsoft 365 E5 includes Microsoft Entra P2, previously known as Azure AD Premium P2.

+### What's changing for identity developer and devops experiences?

+Your privacy and technical information is located in the **Properties** area of the Microsoft Entra admin center.

+On the trust configuration in BTP, we recommend that "Create Shadow Users During Logon" is enabled. This way, users who haven't yet been created in BTP, automatically get an account when they sign in through IAS / Microsoft Entra ID for the first time. If this setting would be disabled, only pre-provisioned users would be allowed to sign in.

+- [Requiring all users to register for multifactor authentication](#require-all-users-to-register-for-azure-ad-multifactor-authentication)

+- [Requiring administrators to do multifactor authentication](#require-administrators-to-do-multifactor-authentication)

+- [Requiring users to do multifactor authentication when necessary](#require-users-to-do-multifactor-authentication-when-necessary)

+- [Blocking legacy authentication protocols](#block-legacy-authentication-protocols)

+- [Protecting privileged activities like access to the Azure portal](#protect-privileged-activities-like-access-to-the-azure-portal)

+- Organizations using the free tier of Microsoft Entra ID licensing.

+- If your organization has complex security requirements, you should consider [Conditional Access](../conditional-access/concept-conditional-access-policy-common.md#template-categories).

+- Haven't enabled Conditional Access policies

+- Don't have premium licenses

+- ArenΓÇÖt actively using legacy authentication clients

+1. Select **Manage security defaults**.

+- Clients that don't use modern authentication (for example, an Office 2010 client)

+- Any client that uses older mail protocols such as IMAP, SMTP, or POP3

+1. Select **Manage security defaults**.

+After you delete a user, the account remains in a suspended state for 30 days. During that 30-day window, the user account can be restored, along with all its properties.

+After that 30-day window passes, the permanent deletion process is automatically started and can't be stopped. During this time, the management of soft-deleted users is blocked. This limitation also applies to restoring a soft-deleted user via a match during Tenant sync cycle for on-premises hybrid scenarios.

+The lifecycle of functionality, features, and services are governed by policy, support timelines, data, also leadership and engineering team decisions. Lifecycle information allows customers to predictably plan long-term deployment aspects, transition from outdated to new technology, and help improve business outcomes.

+> ![NOTE]

+> If you're currently using Azure AD today or are have previously deployed Azure AD in your organizations, you can continue to use the service without interruption. All existing deployments, configurations, and integrations continue to function as they do today without any action from you.

+|[Azure Multi-Factor Authentication Server](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Retirement|Sep 30, 2024|

+|[Microsoft Entra Domain Services virtual network deployments](../../active-directory-domain-services/overview.md)|Retirement|Mar 1, 2023|

+* [Microsoft Entra change announcement blog](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-november-2022-train/ba-p/2967452)

+Microsoft Entra ID is a cloud-based identity and access management service that enables your employees access external resources. Example resources include Microsoft 365, the Azure portal, and thousands of other SaaS applications.

+Microsoft Entra ID also helps them access internal resources like apps on your corporate intranet, and any cloud apps developed for your own organization. To learn how to create a tenant, see [Quickstart: Create a new tenant in Microsoft Entra ID](./create-new-tenant.md).

+To learn the differences between Active Directory and Microsoft Entra ID, see [Compare Active Directory to Microsoft Entra ID](compare.md). You can also refer to [Microsoft Cloud for Enterprise Architects Series](/microsoft-365/solutions/cloud-architecture-models) posters to better understand the core identity services in Azure like Microsoft Entra ID and Microsoft-365.

+ Title: Archive for What's new in Azure Sovereign Clouds?

+ Title: What's new in Azure Sovereign Clouds? Release notes

+description: Learn what is new with Azure Sovereign Clouds.

+# What's new in Azure Sovereign Clouds?

+description: Learn what is new with Microsoft Entra ID, such as the latest release notes, known issues, bug fixes, deprecated functionality, and upcoming changes.

+# What's new in Microsoft Entra ID?

+Microsoft Entra ID (previously known as Azure AD) receives improvements on an ongoing basis. To stay up to date with the most recent developments, this article provides you with information about:

+> ![NOTE]

+> If you're currently using Azure AD today or are have previously deployed Azure AD in your organizations, you can continue to use the service without interruption. All existing deployments, configurations, and integrations continue to function as they do today without any action from you.

+|B|If the application uses group claims in addition to application role assignments.| An application may use Active Directory or Microsoft Entra group membership, distinct from application roles to express finer-grained access. Here, you can choose based on your business requirements either to have the users who have application role assignments reviewed, or to review the users who have group memberships. If the groups do not provide comprehensive access coverage, in particular if users may have access to the application even if they aren't a member of those groups, then we recommend reviewing the application role assignments, as in pattern A above.|

+1. If provisioning is configured, then click on **Edit Attribute Mappings**, expand the Mapping section and click on **Provision Microsoft Entra users**. Check that in the list of attribute mappings, there is a mapping for `isSoftDeleted` to the attribute in the application's data store that you would like to set to false when a user loses access. If this mapping isn't present, then Microsoft Entra ID will not notify the application when a user has gone out of scope, as described in [how provisioning works](../app-provisioning/how-provisioning-works.md).

+You can create your own queries on Microsoft Entra audit events, including entitlement management events.

+1. Your workspace should be shown in the upper left of the query page. If you have multiple Azure Monitor workspaces, and the workspace you're using to store Microsoft Entra audit events isn't shown, select **Select Scope**. Then, select the correct subscription and workspace.

+ 1. Go to Start\Microsoft Entra Connect\ and open the Synchronization Rules Editor

+1. **Select which roles and groups have membership that are to be governed in Microsoft Entra ID.** Based on compliance and risk management requirements, organizations often prioritize those application roles or groups that give privileged access or access to sensitive information.

+1. **If your organization is governing access already with an organizational role model, plan to bring that organizational role model into Microsoft Entra ID.** You may have an [organizational role](identity-governance-organizational-roles.md) defined which assigns access based on a user's property, such as their position or department. These processes can ensure users lose access eventually when access is no longer needed, even if there isn't a pre-determined project end date.

+[Azure Automation](../../automation/overview.md) is an Azure cloud service that allows you to automate common or repetitive systems management and processes. Microsoft Graph is the Microsoft unified API endpoint for Microsoft Entra features that manage users, groups, access packages, access reviews, and other resources in the directory. You can manage Microsoft Entra ID at scale from the PowerShell command line, using the [Microsoft Graph PowerShell SDK](/powershell/microsoftgraph/get-started). You can also include the Microsoft Graph PowerShell cmdlets from a [PowerShell-based runbook in Azure Automation](/azure/automation/automation-intro), so that you can automate Microsoft Entra tasks from a simple script.

+|Reporting and analytics|Admins can retrieve audit logs of recent user provisioning and sign on activity. Integration with Azure Monitor and 'who has access' via access packages.|[Microsoft Entra reports](../reports-monitoring/overview-reports.md) and [monitoring](../reports-monitoring/overview-monitoring.md)|

+- [Microsoft Entra audit activity reference](../reports-monitoring/reference-audit-activities.md)

+|[Invoke](https://aka.ms/InvokeEntraIDGov) |"Invoke's Identity Solution Journey begins with assessments, building trust by showcasing security & compliance risk mitigation, along with productivity gains. In cost-sensitive markets, they deliver economic assessments, reporting cost savings by transitioning to a Microsoft-centric solution. By partnering with the Microsoft Entra team, they jointly empower customers to achieve more." |

+- [Microsoft Entra Synchronization API](/graph/api/resources/synchronization-overview?view=graph-rest-beta&preserve-view=true)

+This cmdlet requires `TenantId` of the Microsoft Entra tenant. It will verify if Accidental Deletion Prevention feature, set on the tenant with Microsoft Entra Connect (ADSync, not Cloud Sync), is enabled and disables it.

+This expression should be read as: if the user mailbox is located in Microsoft Entra ID, then flow the attribute from Microsoft Entra ID to Active Directory. If not, do not flow anything back to Active Directory. In this case, it would keep the existing value in AD.

+[Azure Monitor](../../../azure-monitor/overview.md) is a unified monitoring portal for all Microsoft Entra logs, which provides deep insights, advanced analytics, and smart machine learning. With Azure Monitor, you can consume metrics and logs within the portal and via APIs to gain more visibility into the state and performance of your resources. It enables a single pane of glass experience within the portal while enabling a wide range of product integrations via APIs and data export options that support traditional third-party SIEM systems. Azure Monitor also gives you the ability to configure alert rules to get notified or to take automated actions on issues impacting your resources.

+Set-ADSyncToolsDirSyncOverridesUser 'User1@Contoso.com' -MobilePhoneInAAD '999888777' -AlternateMobilePhonesInAAD '0987654','1234567'

+Set-ADSyncToolsDirSyncOverridesUser 'User1@Contoso.com' -MobileInAD '999888777' -OtherMobileInAD '0987654','1234567'

+Clear-ADSyncToolsDirSyncOverridesUser 'User1@Contoso.com' -MobilePhoneInAAD -AlternateMobilePhonesInAAD

+Clear-ADSyncToolsDirSyncOverridesUser 'User1@Contoso.com' -MobileInAD -OtherMobileInAD

+For successful federation between Microsoft Entra ID and Active Directory Federation Services (AD FS), the certificates used by AD FS to sign security tokens to Microsoft Entra ID should match what is configured in Microsoft Entra ID. Any mismatch can lead to broken trust. Microsoft Entra ID ensures that this information is kept in sync when you deploy AD FS and Web Application Proxy (for extranet access).

+|IDPEmail|The User Principal Name (UPN) is listed in the SAML response as an element with the name IDPEmail The userΓÇÖs UserPrincipalName (UPN) in Microsoft Entra ID / Microsoft 365. The UPN is in email address format. UPN value in Windows Microsoft 365 (Microsoft Entra ID).|

+- A Microsoft Entra ID P1 or P2 license

+- A Microsoft Entra tenant with a Microsoft Entra ID P1 or P2 license.

+| You have a Microsoft Entra ID P1 or P2 subscription. |Microsoft Entra Connect Health is a feature of Microsoft Entra ID P1 or P2. For more information, see [Sign up for Microsoft Entra ID P1 or P2](../../fundamentals/get-started-premium.md). <br /><br />To start a free 30-day trial, see [Start a trial](https://azure.microsoft.com/trial/get-started-active-directory/). |

+| The Microsoft Entra Connect Health agent is installed on each targeted server. | Health agents must be installed and configured on targeted servers so that they can receive data and provide monitoring and analytics capabilities. <br /><br />For example, to get data from your Active Directory Federation Services (AD FS) infrastructure, you must install the agent on the AD FS server and on the Web Application Proxy server. Similarly, to get data from your on-premises Microsoft Entra Domain Services infrastructure, you must install the agent on the domain controllers. |

+- Get started using Microsoft Entra Connect Health for Microsoft Entra Domain

+ - [Download the Microsoft Entra Connect Health agent for Microsoft Entra Domain Services](https://go.microsoft.com/fwlink/?LinkID=820540).

+> Remember that you must have Microsoft Entra ID P1 or P2 to use Microsoft Entra Connect Health. If you don't have Microsoft Entra ID P1 or P2, you can't complete the configuration in the [Microsoft Entra admin center](https://entra.microsoft.com). For more information, see the [requirements](how-to-connect-health-agent-install.md#requirements).

+<a name='install-the-agent-for-microsoft-entra-ds'></a>

+## Install the agent for Microsoft Entra Domain Services

+- [Using Microsoft Entra Connect Health with Microsoft Entra Domain Services](how-to-connect-health-adds.md)

+> Since all attributes in Microsoft Entra ID are going to be overwritten by the on-premises value, make sure you have good data on-premises. For example, if you only have managed email address in Microsoft 365 and not kept it updated in on-premises AD DS, then you lose any values in Microsoft Entra ID / Microsoft 365 not present in AD DS.

+We have added a configuration option to disable the Soft Matching feature in Microsoft Entra Connect. We advise customers to disable soft matching unless they need it to take over cloud only accounts.

+To disable Soft Matching, use the [Update-MgDirectoryOnPremiseSynchronization](/powershell/module/microsoft.graph.identity.directorymanagement/update-mgdirectoryonpremisesynchronization) Microsoft Graph PowerShell cmdlet:

+```powershell

+Import-Module Microsoft.Graph.Beta.Identity.DirectoryManagement

+Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"

+$onPremisesDirectorySynchronizationId = "<TenantID>"

+$params = @{

+ features = @{

+ blockSoftMatchEnabled = $true

+ }

+}

+Update-MgDirectoryOnPremiseSynchronization -OnPremisesDirectorySynchronizationId $onPremisesDirectorySynchronizationId -BodyParameter $params

+```

+> [!NOTE]

+>

+> blockSoftMatchEnabled - Use to block soft match for all objects if enabled for the tenant. Customers are encouraged to enable this feature and keep it enabled until soft matching is required again for their tenancy. This flag should be enabled again after any soft matching has been completed and is no longer needed.

+- You're currently using an on-premises Multi-Factor Authentication Server.

+ The scoping filter determines to which on-premises AD objects this inbound synchronization rule is applied. In this example, we use the same scoping filter used in the *In from AD ΓÇô User Common* out-of-box synchronization rule, which prevents the synchronization rule from being applied to User objects created through the Microsoft Entra user writeback feature. You might need to tweak the scoping filter according to your Microsoft Entra Connect deployment.

+In order to use the new V2 endpoint, you'll need to use Azure AD v2.0. When you deploy AADConnect V2.0, the V2 endpoint will be automatically enabled.

+ Title: Connectors in the Microsoft Entra Synchronization Service Manager UI'

+ > [Add your custom domain name using the Microsoft Entra admin center](../../fundamentals/add-custom-domain.md)

+| Not verified |Microsoft Entra Connect found a matching custom domain in Microsoft Entra ID, but it isn't verified. The UPN suffix of the users of this domain will be changed to the default .onmicrosoft.com suffix after synchronization if the domain isn't verified. | [Verify the custom domain in Microsoft Entra ID.](../../fundamentals/add-custom-domain.md#verify-your-custom-domain-name) |

+

+Generates a file with all Microsoft Entra ID synchronized users containing the ImmutableID value in GUID format

+ Title: Microsoft Entra Connect Health Version History

+description: This document describes the releases for Microsoft Entra Connect Health and what has been included in those releases.

+# Microsoft Entra Connect Health: Version Release History

+The Microsoft Entra team regularly updates Microsoft Entra Connect Health with new features and functionality. This article lists the versions and features that have been released.

+> Microsoft Entra Connect Health agents are updated automatically when new version is released.

+Microsoft Entra Connect Health for Sync is integrated with Microsoft Entra Connect installation. Read more about [Microsoft Entra Connect release history](./reference-connect-version-history.md)

+Microsoft Entra Connect Health ADFS Agents (versions 4.5.x)

+- New version of the Microsoft Entra Connect Health ADFS agent that uses an updated architecture.

+Microsoft Entra Connect Health AD DS and ADFS Health Agents (version 3.2.2256.26, Download Center Only)

+- Microsoft Entra Connect Health agent for Microsoft Entra Connect (version 3.2.2188.23)

+ - We fixed a bug where, under certain circumstances, Microsoft Entra Connect Sync errors were not getting uploaded or shown in the portal.

+- Microsoft Entra Connect Health agent for AD FS (version 3.1.113.0)

+- Microsoft Entra Connect Health agent for AD FS (version 3.1.99.0)

+- Microsoft Entra Connect Health agent for AD FS (version 3.1.95.0)

+ - Fix to display correct values in the **Protocol** and **Authentication Type** fields in Microsoft Entra sign-in report for certain sign-in scenarios.

+ - Fix to display IP addresses in Microsoft Entra sign-in report's IP chain field in order of the request.

+ - Fix for AD FS application identifier property to display in Microsoft Entra sign-in report.

+- Microsoft Entra Connect Health agent for AD FS (version 3.1.77.0)

+* Microsoft Entra Connect Health agent for AD FS (version 3.1.59.0)

+* Microsoft Entra Connect Health agent for AD FS (version 3.1.56.0)

+* Microsoft Entra Connect Health agent for AD DS (version 3.1.56.0)

+* Microsoft Entra Connect Health agent for AD FS (version 3.1.51.0)

+* Microsoft Entra Connect Health agent for AD FS (version 3.1.46.0)

+* Microsoft Entra Connect Health agent for AD DS (version 3.1.41.0)

+* Microsoft Entra Connect Health agent for AD FS (version 3.1.41.0)

+* Microsoft Entra Connect Health for Sync - Diagnose and remediate duplicated attribute sync errors from the portal

+* Microsoft Entra Connect Health agent for AD DS (version 3.1.24.0)

+* Microsoft Entra Connect Health agent for AD FS (version 3.1.24.0)

+* Microsoft Entra Connect Health agent for Sync (version 3.1.7.0) released with Microsoft Entra Connect version 1.1.880.0

+* Microsoft Entra Connect Health for Sync - Diagnose and remediate duplicated attribute sync errors from the portal

+* Microsoft Entra Connect Health agent for AD DS (version 3.1.7.0)

+* Microsoft Entra Connect Health agent for AD FS (version 3.1.7.0)

+* Microsoft Entra Connect Health agent for AD FS (version 3.1.2.0)

+* Microsoft Entra Connect Health agent for AD DS (version 3.0.244.0)

+* Microsoft Entra Connect Health agent for AD FS (version 3.0.244.0)

+* Microsoft Entra Connect Health agent for Sync (version 3.0.164.0) released with Microsoft Entra Connect version 1.1.819.0

+* Microsoft Entra Connect Health for AD FS - Risky IP report and alert.

+* Microsoft Entra Connect Health agent for AD DS (version 3.0.176.0)

+* Microsoft Entra Connect Health agent for AD FS (version 3.0.176.0)

+* Microsoft Entra Connect Health agent for Sync (version 3.0.129.0) released with Microsoft Entra Connect version 1.1.750.0

+* Microsoft Entra Connect Health agent for AD DS (version 3.0.145.0)

+* Microsoft Entra Connect Health agent for AD FS (version 3.0.145.0)

+ * Microsoft Entra Connect Health agent for Sync (version 3.0.129.0) released with Microsoft Entra Connect version 1.1.649.0

+<br></br> Fixed a version compatibility issue between Microsoft Entra Connect and Microsoft Entra Connect Health Agent for Sync. This issue affects customers who are performing Microsoft Entra Connect in-place upgrade to version 1.1.647.0, but currently has Health Agent version 3.0.127.0. After the upgrade, the Health Agent can no longer send health data about Microsoft Entra Connect Synchronization Service to Microsoft Entra Health Service. With this fix, Health Agent version 3.0.129.0 is installed during Microsoft Entra Connect in-place upgrade. Health Agent version 3.0.129.0 does not have compatibility issue with Microsoft Entra Connect version 1.1.649.0.

+* Microsoft Entra Connect Health agent for AD DS (version 3.0.68.0)

+* Microsoft Entra Connect Health agent for AD FS (version 3.0.68.0)

+* Microsoft Entra Connect Health agent for Sync (version 3.0.68.0) released with Microsoft Entra Connect version 1.1.614.0

+* Microsoft Entra Connect Health agent for AD FS (version 3.0.12.0)

+* Microsoft Entra Connect Health agent for AD DS (version 3.0.12.0)

+* Microsoft Entra Connect Health agent for AD FS (version 2.6.408.0)

+* Microsoft Entra Connect Health agent for AD DS (version 2.6.408.0)

+* Microsoft Entra Connect Health agent for Sync (version 2.6.353.0) released with Microsoft Entra Connect version 1.1.281.0

+* Synchronization Error Reports for Microsoft Entra Connect

+* Microsoft Entra Connect Health for AD FS - IP address field is available in the report about top 50 users with bad username/password.

+* [Microsoft Entra Connect Health for AD DS](how-to-connect-health-adds.md).

+* Microsoft Entra Connect Health agent for AD FS (version 2.6.91.1512)

+* [Test Connectivity Tool for Microsoft Entra Connect Health Agents](how-to-connect-health-agent-install.md#test-connectivity-to-azure-ad-connect-health-service)

+* [Microsoft Entra Connect Health for sync](how-to-connect-health-sync.md).

+* Improvements in Microsoft Entra Connect Health Agent for AD FS for connectivity and data upload.

+**Initial release of Microsoft Entra Connect Health for AD FS and AD FS Proxy.**

+* Simpler Agent Deployment using Microsoft Entra Global Administrator credentials.

+ Title: 'Microsoft Entra Connect: Version release history archive'

+description: This article lists all archived releases of Microsoft Entra Connect and Azure AD Sync

+# Microsoft Entra Connect: Version release history archive

+The Microsoft Entra team regularly updates Microsoft Entra Connect with new features and functionality. Not all additions are applicable to all audiences.

+> This article contains version reference information about all archived versions of Microsoft Entra ID - 1.5.42.0 and older. For current releases, see the [Microsoft Entra Connect Version release history](reference-connect-version-history.md)

+Includes a public preview of the functionality to export the configuration of an existing Microsoft Entra Connect server into a .JSON file. This file can be used when installing a new Microsoft Entra Connect server to create a copy of the original server.

+- Fixed an error where Microsoft Entra Connect would fail to install on a DC, giving error "member not found".

+>This version includes the new Microsoft Entra Connect Sync V2 endpoint API. This new V2 endpoint is currently in public preview. This version or later is required to use the new V2 endpoint API. However, simply installing this version does not enable the V2 endpoint. You will continue to use the V1 endpoint unless you enable the V2 endpoint. You need to follow the steps under [Microsoft Entra Connect Sync V2 endpoint API (public preview)](how-to-connect-sync-endpoint-api-v2.md) in order to enable it and opt-in to the public preview.

+- Added support for the mS-DS-ConsistencyGuid feature for group objects. Allows you to move groups between forests or reconnect groups in AD to Microsoft Entra ID where the AD group objectID has changed. For more information, see [Moving groups between forests](how-to-connect-migrate-groups.md).

+- Fixed a bug in the group writeback forest/OU selector on rerunning the Microsoft Entra Connect wizard after disabling the feature.

+- Fixed an issue with the creation of the Microsoft Entra synchronization account where enabling Directory Extensions or PHS may fail because the account hasn't propagated across all service replicas before attempted use.

+- We updated Password Hash Sync for Microsoft Entra Domain Services to properly account for padding in Kerberos hashes. Provides a performance improvement during password synchronization from Microsoft Entra ID to Microsoft Entra Domain Services.

+- Release 1.4.18.0 had a bug where the PowerShell cmdlet for DSSO was using the login Windows credentials instead of the admin credentials provided while running ps. As a result of which it wasn't possible to enable DSSO in multiple forest through the Microsoft Entra Connect user interface.

+- A fix was made to enable DSSO simultaneously in all forest through the Microsoft Entra Connect user interface

+>Due to an internal schema change in this release of Microsoft Entra Connect, if you manage AD FS trust relationship configuration settings using MSOnline PowerShell then you must update your MSOnline PowerShell module to version 1.1.183.57 or higher

+This version fixes an issue with existing Microsoft Entra hybrid joined devices. This release contains a new device sync rule that corrects this issue.

+This rule change may cause deletion of obsolete devices from Microsoft Entra ID. These device objects aren't used by Microsoft Entra ID during Conditional Access authorization. For some customers, the number of devices that will be deleted through this rule change can exceed the deletion threshold. If you see the deletion of device objects in Microsoft Entra exceeding the Export Deletion Threshold, it's advised to allow the deletions to go through. [How to allow deletes to flow when they exceed the deletion threshold](how-to-connect-sync-feature-prevent-accidental-deletes.md)

+>We are investigating an incident where some customers are experiencing an issue with existing Microsoft Entra hybrid joined devices after upgrading to this version of Microsoft Entra Connect. We advise customers who have deployed Microsoft Entra hybrid join to postpone upgrading to this version until the root cause of these issues are fully understood and mitigated. More information will be provided as soon as possible.

+>With this version of Microsoft Entra Connect some customers may see some or all of their Windows devices disappear from Microsoft Entra ID. These device identities aren't used by Microsoft Entra ID during Conditional Access authorization. For more information, see [Understanding Microsoft Entra Connect 1.4.xx.x device disappearance](/troubleshoot/azure/active-directory/reference-connect-device-disappearance)

+- Add support for national clouds in Microsoft Entra Connect troubleshooting script.

+- Using an Enterprise or Domain admin as the connector account is no longer supported in new Microsoft Entra Connect Deployments. Current Microsoft Entra Connect deployments using an Enterprise or Domain admin as the connector account will not be affected by this release.

+- Added a deprecation warning for the sync service manager on the connector properties page. This warning notifies the user that changes should be made through the Microsoft Entra Connect wizard.

+- Enabled six federation management tasks for all sign-in methods in Microsoft Entra Connect. (Previously, only the "Update AD FS TLS/SSL certificate" task was available for all sign-ins.)

+- Added a warning when changing the sign-in method from federation to PHS or PTA that all Microsoft Entra domains and users will be converted to managed authentication.

+- Removed token-signing certificates from the "Reset Microsoft Entra ID and AD FS trust" task and added a separate sub-task to update these certificates.

+- Fixed a bug to make Microsoft Entra Connect install on a machine using an existing Named Pipes WCF service more robust.

+- Fixed a bug where non-Windows 10 computers were syncing unexpectedly. Note that the effect of this change is that non-Windows-10 computers that were previously synced will now be deleted. This does not affect any features as the sync of Windows computers is only used for Hybrid Microsoft Entra domain join, which only works for Windows-10 devices.

+>There is a known issue with upgrading Microsoft Entra Connect from an earlier version to 1.3.21.0 where the Microsoft 365 portal does not reflect the updated version even though Microsoft Entra Connect upgraded successfully.

+> To resolve this issue, you need to import the **AdSync** module and then run the `Set-ADSyncDirSyncConfiguration` PowerShell cmdlet on the Microsoft Entra Connect server. You can use the following steps:

+- Fixed an elevation of privilege vulnerability that exists in Microsoft Entra Connect build 1.3.20.0. This vulnerability, under certain conditions, may allow an attacker to execute two PowerShell cmdlets in the context of a privileged account, and perform privileged actions. This security update addresses the issue by disabling these cmdlets. For more information, see [security update](https://portal.msrc.microsoft.com/security-guidance/advisory/CVE-2019-1000).

+- Added a new agent running as a Windows service. This agent, named ΓÇ£Admin AgentΓÇ¥, enables deeper remote diagnostics of the Microsoft Entra Connect server to help Microsoft Engineers troubleshoot when you open a support case. This agent is not installed and enabled by default. For more information on how to install and enable the agent, see [What is the Microsoft Entra Connect Admin Agent?](whatis-aadc-admin-agent.md).

+- Added auto upgrade support for deployments that use AD FS as their login type. This also removed the requirement of updating the AD FS Microsoft Entra ID Relying Party Trust as part of the upgrade process.

+- Added a Microsoft Entra ID trust management task that provides two options: analyze/update trust and reset trust.

+- Changed the AD FS Microsoft Entra ID Relying Party trust behavior so that it always uses the -SupportMultipleDomain switch (includes trust and Microsoft Entra domain updates).

+- Corrected an issue where installation of Azure AD PowerShell on a server could potentially cause an assembly conflict with Microsoft Entra Connect.

+This build updates the non-standard connectors (for example, Generic LDAP Connector and Generic SQL Connector) shipped with Microsoft Entra Connect. For more information on applicable connectors, see version 1.1.911.0 in [Connector Version Release History](/microsoft-identity-manager/reference/microsoft-identity-manager-2016-connector-version-history).

+- Changed the functionality of attribute write-back to ensure hosted voice-mail is working as expected. Under certain scenarios, Microsoft Entra ID was overwriting the msExchUcVoicemailSettings attribute during write-back with a null value. Microsoft Entra ID will now no longer clear the on-premises value of this attribute if the cloud value is not set.

+- Added diagnostics in the Microsoft Entra Connect wizard to investigate and identify Connectivity issues to Microsoft Entra ID. These same diagnostics can also be run directly through PowerShell using the Test- AdSyncAzureServiceConnectivity Cmdlet.

+- Added diagnostics in the Microsoft Entra Connect wizard to investigate and identify Connectivity issues to AD. These same diagnostics can also be run directly through PowerShell using the Start-ConnectivityValidation function in the ADConnectivityTools PowerShell module. For more information, see [What is the ADConnectivityTool PowerShell Module?](how-to-connect-adconnectivitytools.md)

+- Added an AD schema version pre-check for Microsoft Entra hybrid join and device write-back

+- Added full support for TLS 1.2. This release supports all other protocols being disabled and only TLS 1.2 being enabled on the machine where Microsoft Entra Connect is installed. For more information, see [TLS 1.2 enforcement for Microsoft Entra Connect](reference-connect-tls-enforcement.md)

+- Fixed a bug where Microsoft Entra Connect Upgrade would fail if SQL Always On was being used.

+- Fixed a bug where Microsoft Entra Connect would allow invalid partitions and container selection

+Microsoft Entra Connect Upgrade fails if SQL Always On Availability is configured for the ADSync DB. This hotfix addresses this issue and allows Upgrade to succeed.

+- The Ping Federate integration in Microsoft Entra Connect is now available for General Availability. [Learn more about how to federated Microsoft Entra ID with Ping Federate](./plan-connect-user-signin.md#federation-with-pingfederate)

+- Microsoft Entra Connect now creates the backup of Microsoft Entra ID trust in AD FS every time an update is made and stores it in a separate file for easy restore if required. [Learn more about the new functionality and Microsoft Entra ID trust management in Microsoft Entra Connect](./how-to-connect-azure-ad-trust.md).

+- Microsoft Entra Connect was updated to include the latest SQL Server 2012 Native Client

+- The Microsoft Entra Connect Health agent was updated to the latest version 3.1.7.0

+- Fixed a bug where the Microsoft Entra Connect server would show high CPU usage after upgrading to .NET 4.7.2

+- Fixed a bug where Microsoft Entra Connect can not get registry setting information

+- When Group Sync Filtering page encounters an LDAP error when resolving security groups, Microsoft Entra Connect now returns the exception with full fidelity. The root cause for the referral exception is still unknown and will be addressed by a different bug.

+- This release includes the public preview of the integration of PingFederate in Microsoft Entra Connect. With this release, customers can easily, and reliably configure their Microsoft Entra environment to leverage PingFederate as their federation provider. To learn more about how to use this new feature, please visit our [online documentation](plan-connect-user-signin.md#federation-with-pingfederate).

+- Updated the Microsoft Entra Connect Wizard Troubleshooting Utility, where it now analyzes more error scenarioΓÇÖs, such as Linked Mailboxes and AD Dynamic Groups. Read more about the troubleshooting utility [here](tshoot-connect-objectsync.md).

+- Device Writeback configuration is now managed solely within the Microsoft Entra Connect Wizard.

+ - **Microsoft Entra hybrid join**: If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Microsoft Entra ID, you can implement Microsoft Entra hybrid joined devices. These are devices that are both, joined to your on-premises Active Directory and your Microsoft Entra ID.

+- Microsoft Entra Connect Wizard: Error creating AD Connector account when Microsoft Entra Connect is in a workgroup

+- Microsoft Entra Connect Wizard: On the Microsoft Entra Sign-in page display the verification checkbox whenever there is any mismatch in AD domains and Microsoft Entra ID Verified domains

+- Microsoft Entra Connect Wizard: Updated telemetry to capture previously missing information

+- Microsoft Entra Connect Wizard: The following changes have been made when you use the **Change user sign-in** task to switch from AD FS to Pass-through Authentication:

+ - The Pass-through Authentication Agent is installed on the Microsoft Entra Connect server and the Pass-through Authentication feature is enabled, before we convert domain(s) from federated to managed.

+- Microsoft Entra Connect Wizard: AD FS Multi Domain Regex is not correct when user UPN has ' special character Regex update to support special characters

+- Microsoft Entra Connect Wizard: Remove spurious "Configure source anchor attribute" message when no change

+- Microsoft Entra Connect Wizard: AD FS support for the dual federation scenario

+- Microsoft Entra Connect Wizard: AD FS Claims aren't updated for added domain when converting a managed domain to federated

+- Microsoft Entra Connect Wizard: During detection of installed packages, we find stale Dirsync/Azure AD Sync/Azure AD Connect related products. We will now attempt to uninstall the stale products.

+- Microsoft Entra Connect Wizard: Correct Error Message Mapping when installation of passthrough authentication agent fails

+- Microsoft Entra Connect Wizard: Removed "Configuration" container from Domain OU Filtering page

+- Microsoft Entra Connect Wizard: Fix pop-up help text on Optional Features page for Password Hash Sync

+- Microsoft Entra Connect Wizard: Fix an issue resolving a custom Sync Service Account which has no AD Read privileges

+- Microsoft Entra Connect Wizard: Improve logging of Domain and OU filtering selections

+- Microsoft Entra Connect Wizard: AD FS Add default claims to federation trust created for MFA scenario

+- Microsoft Entra Connect Wizard: AD FS Deploy WAP: Adding server fails to use new certificate

+- Microsoft Entra Connect Wizard: DSSO exception when onPremCredentials aren't initialized for a domain

+>This release is a hotfix for Microsoft Entra Connect

+<a name='azure-ad-connect-sync'></a>

+### Microsoft Entra Connect Sync

+>When the upgrade to this new version completes, it will automatically trigger a full sync and full import for the Microsoft Entra connector and a full sync for the AD connector. Since this may take some time, depending on the size of your Microsoft Entra Connect environment, make sure that you've taken the necessary steps to support this or hold off on upgrading until you've found a convenient moment to do so.

+>ΓÇ£AutoUpgrade functionality was incorrectly disabled for some tenants who deployed builds later than 1.1.524.0. To ensure that your Microsoft Entra Connect instance is still eligible for AutoUpgrade, run the following PowerShell cmdlet:

+<a name='azure-ad-connect'></a>

+### Microsoft Entra Connect

+* Changed the **User Sign-in** page option "Password Synchronization" to "Password Hash Synchronization". Microsoft Entra Connect synchronizes password hashes, not passwords, so this aligns with what is actually occurring. For more information, see [Implement password hash synchronization with Microsoft Entra Connect Sync](how-to-connect-password-hash-synchronization.md)

+>When the upgrade to this new version completes, it will automatically trigger a full sync and full import for the Microsoft Entra connector and a full sync for the AD connector. Since this may take some time, depending on the size of your Microsoft Entra Connect environment, please make sure that you've taken the necessary steps to support this or hold off on upgrading until you've found a convenient moment to do so.

+<a name='azure-ad-connect'></a>

+### Microsoft Entra Connect

+* Fixed a bug which causes miiserver.exe to crash during a Microsoft Entra connector export.

+* Fixed a bug which bad password attempt logged on DC when running the Microsoft Entra Connect wizard to change configuration.

+* Microsoft Entra Health data - admin must visit the health portal to control their health settings.

+3. Changed the installer so it doesn't require SA privilege on clean install of Microsoft Entra Connect

+* Added a new utility to troubleshoot synchronization issues for a specific object. It is available under 'Troubleshoot Object Synchronization' option of Microsoft Entra Connect Wizard Troubleshoot Additional Task. Currently, the utility checks for the following:

+ * UserPrincipalName mismatch between synchronized user object and the user account in Microsoft Entra tenant.

+The utility does not require a password change. It is available under 'Troubleshoot Password Hash Synchronization' option of Microsoft Entra Connect Wizard Troubleshoot Additional Task.

+>This release is a security related hotfix for Microsoft Entra Connect

+<a name='azure-ad-connect'></a>

+### Microsoft Entra Connect

+An improvement has been added to Microsoft Entra Connect version 1.1.654.0 (and after) to ensure that the recommended permission changes described under section [Lock down access to the AD DS account](#lock) are automatically applied when Microsoft Entra Connect creates the AD DS account.

+- When setting up Microsoft Entra Connect, the installing administrator can either provide an existing AD DS account, or let Microsoft Entra Connect automatically create the account. The permission changes are automatically applied to the AD DS account that is created by Microsoft Entra Connect during setup. They aren't applied to existing AD DS account provided by the installing administrator.

+- For customers who have upgraded from an older version of Microsoft Entra Connect to 1.1.654.0 (or after), the permission changes will not be retroactively applied to existing AD DS accounts created prior to the upgrade. They will only be applied to new AD DS accounts created after the upgrade. This occurs when you are adding new AD forests to be synchronized to Microsoft Entra ID.

+>This release only removes the vulnerability for new installations of Microsoft Entra Connect where the service account is created by the installation process. For existing installations, or in cases where you provide the account yourself, you should ensure that this vulnerability does not exist.

+To use the PowerShell script, to apply these settings, to a pre-existing AD DS account, (ether provided by your organization or created by a previous installation of Microsoft Entra Connect, please download the script from the provided link above.

+To see if this vulnerability was used to compromise your Microsoft Entra Connect configuration you should verify the last password reset date of the service account. If the timestamp in unexpected, further investigation, via the event log, for that password reset event, should be undertaken.

+>This build is not available to customers through the Microsoft Entra Connect Auto Upgrade feature.

+<a name='azure-ad-connect'></a>

+### Microsoft Entra Connect

+* Fixed a version compatibility issue between Microsoft Entra Connect and Microsoft Entra Connect Health Agent (for sync). This issue affects customers who are performing Microsoft Entra Connect in-place upgrade to version 1.1.647.0, but currently has Health Agent version 3.0.127.0. After the upgrade, the Health Agent can no longer send health data about Microsoft Entra Connect Synchronization Service to Microsoft Entra Health Service. With this fix, Health Agent version 3.0.129.0 is installed during Microsoft Entra Connect in-place upgrade. Health Agent version 3.0.129.0 does not have compatibility issue with Microsoft Entra Connect version 1.1.649.0.

+> There is a known compatibility issue between Microsoft Entra Connect version 1.1.647.0 and Microsoft Entra Connect Health Agent (for sync) version 3.0.127.0. This issue prevents the Health Agent from sending health data about the Microsoft Entra Connect Synchronization Service (including object synchronization errors and run history data) to Microsoft Entra Health Service. Before manually upgrading your Microsoft Entra Connect deployment to version 1.1.647.0, please verify the current version of Microsoft Entra Connect Health Agent installed on your Microsoft Entra Connect server. You can do so by going to *Control Panel → Add Remove Programs* and look for application *Microsoft Entra Connect Health Agent for Sync*. If its version is 3.0.127.0, it's recommended that you wait for the next Microsoft Entra Connect version to be available before upgrade. If the Health Agent version isn't 3.0.127.0, it's fine to proceed with the manual, in-place upgrade. This issue does not affect swing upgrade or customers who are performing new installation of Microsoft Entra Connect.

+<a name='azure-ad-connect'></a>

+### Microsoft Entra Connect

+* Fixed an issue with the *Change user sign-in* task in Microsoft Entra Connect wizard:

+ * The issue occurs when you've an existing Microsoft Entra Connect deployment with Password Synchronization **enabled**, and you are trying to set the user sign-in method as *Pass-through Authentication*. Before the change is applied, the wizard incorrectly shows the "*Disable Password Synchronization*" prompt. However, Password Synchronization remains enabled after the change is applied. With this fix, the wizard no longer shows the prompt.

+ * Note that the same issue also occurs if you try to enable/disable Seamless Single Sign-On. Specifically, you've an existing Microsoft Entra Connect deployment with Password Synchronization enabled and the user sign-in method is already configured as *Pass-through Authentication*. Using the *Change user sign-in* task, you try to check/uncheck the *Enable Seamless Single Sign-On* option while the user sign-in method remains configured as "Pass-through Authentication". Before the change is applied, the wizard incorrectly shows the "*Disable Password Synchronization*" prompt. However, Password Synchronization remains enabled after the change is applied. With this fix, the wizard no longer shows the prompt.

+* Fixed an issue with the *Change user sign-in* task in Microsoft Entra Connect wizard:

+ * The issue occurs when you've an existing Microsoft Entra Connect deployment with Password Synchronization **disabled**, and you are trying to set the user sign-in method as *Pass-through Authentication*. When the change is applied, the wizard enables both Pass-through Authentication and Password Synchronization. With this fix, the wizard no longer enables Password Synchronization.

+ * Previously, Password Synchronization was a pre-requisite for enabling Pass-through Authentication. When you set the user sign-in method as *Pass-through Authentication*, the wizard would enable both Pass-through Authentication and Password Synchronization. Recently, Password Synchronization was removed as a pre-requisite. As part of Microsoft Entra Connect version 1.1.557.0, a change was made to Microsoft Entra Connect to not enable Password Synchronization when you set the user sign-in method as *Pass-through Authentication*. However, the change was only applied to Microsoft Entra Connect installation. With this fix, the same change is also applied to the *Change user sign-in* task.

+ * Note that the same issue also occurs if you try to enable/disable Seamless Single Sign-On. Specifically, you've an existing Microsoft Entra Connect deployment with Password Synchronization disabled and the user sign-in method is already configured as *Pass-through Authentication*. Using the *Change user sign-in* task, you try to check/uncheck the *Enable Seamless Single Sign-On* option while the user sign-in method remains configured as "Pass-through Authentication". When the change is applied, the wizard enables Password Synchronization. With this fix, the wizard no longer enables Password Synchronization.

+* Fixed an issue that caused Microsoft Entra Connect upgrade to fail with error "*Unable to upgrade the Synchronization Service*". Further, the Synchronization Service can no longer start with event error "*The service was unable to start because the version of the database is newer than the version of the binaries installed*". The issue occurs when the administrator performing the upgrade does not have sysadmin privilege to the SQL server that is being used by Microsoft Entra Connect. With this fix, Microsoft Entra Connect only requires the administrator to have db_owner privilege to the ADSync database during upgrade.

+* Fixed a Microsoft Entra Connect Upgrade issue that affected customers who have enabled [Seamless Single Sign-On](./how-to-connect-sso.md). After Microsoft Entra Connect is upgraded, Seamless Single Sign-On incorrectly appears as disabled in Microsoft Entra Connect wizard, even though the feature remains enabled and fully functional. With this fix, the feature now appears correctly as enabled in the wizard.

+* Fixed an issue that caused Microsoft Entra Connect wizard to always show the ΓÇ£*Configure Source Anchor*ΓÇ¥ prompt on the *Ready to Configure* page, even if no changes related to Source Anchor were made.

+* When performing manual in-place upgrade of Microsoft Entra Connect, the customer is required to provide the Global Administrator credentials of the corresponding Microsoft Entra tenant. Previously, upgrade could proceed even though the Global Administrator's credentials belonged to a different Microsoft Entra tenant. While upgrade appears to complete successfully, certain configurations aren't correctly persisted with the upgrade. With this change, the wizard prevents the upgrade from proceeding if the credentials provided don't match the Microsoft Entra tenant.

+* Removed redundant logic that unnecessarily restarted Microsoft Entra Connect Health service at the beginning of a manual upgrade.

+* Added logic to simplify the steps required to set up Microsoft Entra Connect with Microsoft Germany Cloud. Previously, you are required to update specific registry keys on the Microsoft Entra Connect server for it to work correctly with Microsoft Germany Cloud, as described in this article. Now, Microsoft Entra Connect can automatically detect if your tenant is in Microsoft Germany Cloud based on the Hybrid Identity Administrator credentials provided during setup.

+<a name='azure-ad-connect-sync'></a>

+### Microsoft Entra Connect Sync

+> Note: The Synchronization Service has a WMI interface that lets you develop your own custom scheduler. This interface is now deprecated and will be removed from future versions of Microsoft Entra Connect shipped after June 30, 2018. Customers who want to customize synchronization schedule should use the [built-in scheduler](./how-to-connect-sync-feature-scheduler.md).

+* When Microsoft Entra Connect wizard creates the AD Connector account required to synchronize changes from on-premises Active Directory, it does not correctly assign the account the permission required to read PublicFolder objects. This issue affects both Express installation and Custom installation. This change fixes the issue.

+* Fixed an issue that caused the Microsoft Entra Connect Wizard troubleshooting page to not render correctly for administrators running from Windows Server 2016.

+* When troubleshooting Password Synchronization using the Microsoft Entra Connect wizard troubleshooting page, the troubleshooting page now returns domain-specific status.

+* Previously, if you tried to enable Password Hash Synchronization, Microsoft Entra Connect does not verify whether the AD Connector account has required permissions to synchronize password hashes from on-premises AD. Now, Microsoft Entra Connect wizard will verify and warn you if the AD Connector account does not have sufficient permissions.

+* Fixed an issue related to the use of [ms-DS-ConsistencyGuid as Source Anchor](./plan-connect-design-concepts.md#using-ms-ds-consistencyguid-as-sourceanchor) feature. This issue affects customers who have configured *Federation with AD FS* as the user sign-in method. When you execute *Configure Source Anchor* task in the wizard, Microsoft Entra Connect switches to using *ms-DS-ConsistencyGuid as source attribute for immutableId. As part of this change, Microsoft Entra Connect attempts to update the claim rules for ImmutableId in AD FS. However, this step failed because Microsoft Entra Connect didn't have the administrator credentials required to configure AD FS. With this fix, Microsoft Entra Connect now prompts you to enter the administrator credentials for AD FS when you execute the *Configure Source Anchor* task.

+<a name='azure-ad-connect'></a>

+### Microsoft Entra Connect

+* There is a known issue that is causing Microsoft Entra Connect upgrade to fail with error "*Unable to upgrade the Synchronization Service*". Further, the Synchronization Service can no longer start with event error "*The service was unable to start because the version of the database is newer than the version of the binaries installed*". The issue occurs when the administrator performing the upgrade does not have sysadmin privilege to the SQL server that is being used by Microsoft Entra Connect. Dbo permissions aren't sufficient.

+* There is a known issue with Microsoft Entra Connect Upgrade that is affecting customers who have enabled [Seamless Single Sign-On](how-to-connect-sso.md). After Microsoft Entra Connect is upgraded, the feature appears as disabled in the wizard, even though the feature remains enabled. A fix for this issue will be provided in future release. Customers who are concerned about this display issue can manually fix it by enabling Seamless Single Sign-On in the wizard.

+* Fixed an issue that prevented Microsoft Entra Connect from updating the claims rules in on-premises AD FS while enabling the [ms-DS-ConsistencyGuid as Source Anchor](./plan-connect-design-concepts.md#using-ms-ds-consistencyguid-as-sourceanchor) feature. The issue occurs if you try to enable the feature for an existing Microsoft Entra Connect deployment that has AD FS configured as the sign-in method. The issue occurs because the wizard does not prompt for ADFS credentials before trying to update the claims rules in AD FS.

+* Fixed an issue that caused Microsoft Entra Connect to fail installation if the on-premises AD forest has NTLM disabled. The issue is due to Microsoft Entra Connect wizard not providing fully qualified credentials when creating the security contexts required for Kerberos authentication. This causes Kerberos authentication to fail and Microsoft Entra Connect wizard to fall back to using NTLM.

+<a name='azure-ad-connect-sync'></a>

+### Microsoft Entra Connect Sync

+* Fixed an issue that caused Microsoft Entra Connect to connect to on-premises AD for Password Synchronization using NTLM, even though Kerberos is available. This issue occurs if the on-premises AD topology has one or more domain controllers that were restored from a backup.

+* Fixed an issue that can cause the Microsoft Entra Connect server to not work correctly after Automatic Upgrade. This issue affects Microsoft Entra Connect servers with version 1.1.443.0 (or earlier). For details about the issue, refer to article [Microsoft Entra Connect is not working correctly after an automatic upgrade](https://support.microsoft.com/help/4038479/azure-ad-connect-is-not-working-correctly-after-an-automatic-upgrade).

+* Fixed an issue in the Microsoft Entra Connect wizard that allows Group writeback feature to be enabled without selecting an OU required for Group writeback.

+* Added a Troubleshoot task to Microsoft Entra Connect wizard under Additional Tasks. Customers can leverage this task to troubleshoot issues related to password synchronization and collect general diagnostics. In the future, the Troubleshoot task will be extended to include other directory synchronization-related issues.

+* Microsoft Entra Connect now supports a new installation mode called **Use Existing Database**. This installation mode allows customers to install Microsoft Entra Connect that specifies an existing ADSync database. For more information about this feature, refer to article [Use an existing database](how-to-connect-install-existing-database.md).

+* For improved security, Microsoft Entra Connect now defaults to using TLS1.2 to connect to Microsoft Entra ID for directory synchronization. Previously, the default was TLS1.0.

+* When Microsoft Entra Connect Password Synchronization Agent starts up, it tries to connect to Microsoft Entra well-known endpoint for password synchronization. Upon successful connection, it's redirected to a region-specific endpoint. Previously, the Password Synchronization Agent caches the region-specific endpoint until it's restarted. Now, the agent clears the cache and retries with the well-known endpoint if it encounters connection issue with the region-specific endpoint. This change ensures that password synchronization can failover to a different region-specific endpoint when the cached region-specific endpoint is no longer available.

+* To synchronize changes from an on-premises AD forest, an AD DS account is required. You can either (i) create the AD DS account yourself and provide its credential to Microsoft Entra Connect, or (ii) provide an Enterprise Admin's credentials and let Microsoft Entra Connect create the AD DS account for you. Previously, (i) is the default option in the Microsoft Entra Connect wizard. Now, (ii) is the default option.

+<a name='azure-ad-connect-health'></a>

+### Microsoft Entra Connect Health

+* The Microsoft Entra Connect Verify ADFS Login task was updated so that it verifies logins against Microsoft Online and not just token retrieval from ADFS.

+* When setting up a new ADFS farm using Microsoft Entra Connect, the page asking for ADFS credentials was moved so that it now occurs before the user is asked to provide ADFS and WAP servers. This allows Microsoft Entra Connect to check that the account specified has the correct permissions.

+* During Microsoft Entra Connect upgrade, we will no longer fail an upgrade if the ADFS Microsoft Entra ID Trust fails to update. If that happens, the user will be shown an appropriate warning message and should proceed to reset the trust via the Microsoft Entra Connect additional task.

+* Fixed an issue that caused Microsoft Entra Connect wizard to return an error if you try to enable [Seamless Single Sign-On](how-to-connect-sso.md). The error message is *ΓÇ£Configuration of Microsoft Entra Connect Authentication Agent failed.ΓÇ¥* This issue affects existing customers who had manually upgraded the preview version of the Authentication Agents for [Pass-through Authentication](how-to-connect-sso.md) based on the steps described in this [article](how-to-connect-pta-upgrade-preview-authentication-agents.md).

+<a name='azure-ad-connect'></a>

+### Microsoft Entra Connect

+ * The issue occurs when Microsoft Entra Connect is upgraded, or when the task option *Update Synchronization Configuration* in the Microsoft Entra Connect wizard is used to update Microsoft Entra Connect synchronization configuration.

+ * This synchronization rule is applicable to customers who have enabled the [ms-DS-ConsistencyGuid as Source Anchor feature](plan-connect-design-concepts.md#using-ms-ds-consistencyguid-as-sourceanchor). This feature was introduced in version 1.1.524.0 and after. When the synchronization rule is removed, Microsoft Entra Connect can no longer populate on-premises AD ms-DS-ConsistencyGuid attribute with the ObjectGuid attribute value. It does not prevent new users from being provisioned into Microsoft Entra ID.

+ * The fix ensures that the synchronization rule will no longer be removed during upgrade, or during configuration change, as long as the feature is enabled. For existing customers who have been affected by this issue, the fix also ensures that the synchronization rule is added back after upgrading to this version of Microsoft Entra Connect.

+* Fixed an issue where the [Domain and OU Filtering screen](how-to-connect-install-custom.md#domain-and-ou-filtering) in the Microsoft Entra Connect wizard is showing *Sync all domains and OUs* option as selected, even though OU-based filtering is enabled.

+* Fixed an issue that caused the [Configure Directory Partitions screen](how-to-connect-sync-configure-filtering.md#organizational-unitbased-filtering) in the Synchronization Service Manager to return an error if the *Refresh* button is clicked. The error message is *ΓÇ£An error was encountered while refreshing domains: Unable to cast object of type ΓÇÿSystem.Collections.ArrayListΓÇÖ to type ΓÇÿMicrosoft.DirectoryServices.MetadirectoryServices.UI.PropertySheetBase.MaPropertyPages.PartitionObject.ΓÇ¥* The error occurs when new AD domain has been added to an existing AD forest and you are trying to update Microsoft Entra Connect using the Refresh button.

+ >The scope expansion of the Automatic Upgrade feature affects customers with Microsoft Entra Connect build 1.1.105.0 and after. If you don't want your Microsoft Entra Connect server to be automatically upgraded, you must run following cmdlet on your Microsoft Entra Connect server: `Set-ADSyncAutoUpgrade -AutoUpgradeState disabled`. For more information about enabling/disabling Automatic Upgrade, refer to article [Microsoft Entra Connect: Automatic upgrade](how-to-connect-install-automatic-upgrade.md).

+<a name='azure-ad-connect'></a>

+### Microsoft Entra Connect

+* Fixed an issue where the [Domain and OU Filtering screen](how-to-connect-install-custom.md#domain-and-ou-filtering) in the Microsoft Entra Connect wizard is showing *Sync all domains and OUs* option as selected, even though OU-based filtering is enabled.

+* Fixed an issue that caused the [Configure Directory Partitions screen](how-to-connect-sync-configure-filtering.md#organizational-unitbased-filtering) in the Synchronization Service Manager to return an error if the *Refresh* button is clicked. The error message is *ΓÇ£An error was encountered while refreshing domains: Unable to cast object of type ΓÇÿSystem.Collections.ArrayListΓÇÖ to type ΓÇÿMicrosoft.DirectoryServices.MetadirectoryServices.UI.PropertySheetBase.MaPropertyPages.PartitionObject.ΓÇ¥* The error occurs when new AD domain has been added to an existing AD forest and you are trying to update Microsoft Entra Connect using the Refresh button.

+ >The scope expansion of the Automatic Upgrade feature affects customers with Microsoft Entra Connect build 1.1.105.0 and after. If you don't want your Microsoft Entra Connect server to be automatically upgraded, you must run following cmdlet on your Microsoft Entra Connect server: `Set-ADSyncAutoUpgrade -AutoUpgradeState disabled`. For more information about enabling/disabling Automatic Upgrade, refer to article [Microsoft Entra Connect: Automatic upgrade](how-to-connect-install-automatic-upgrade.md).

+>This build is not available to customers through the Microsoft Entra Connect Auto Upgrade feature.

+<a name='azure-ad-connect'></a>

+### Microsoft Entra Connect

+* Fixed an issue with the Initialize-ADSyncDomainJoinedComputerSync cmdlet that caused the verified domain configured on the existing service connection point object to be changed even if it's still a valid domain. This issue occurs when your Microsoft Entra tenant has more than one verified domains that can be used for configuring the service connection point.

+* Password writeback is now available for preview with Microsoft Azure Government cloud and Microsoft Cloud Germany. For more information about Microsoft Entra Connect support for the different service instances, refer to article [Microsoft Entra Connect: Special considerations for instances](reference-connect-instances.md).

+* The name of the agent required for Pass-through Authentication has been changed from *Microsoft Entra application proxy Connector* to *Microsoft Entra Connect Authentication Agent*.

+> There are schema and sync rule changes introduced in this build. Microsoft Entra Connect Synchronization Service will trigger Full Import and Full Synchronization steps after upgrade. Details of the changes are described below. To temporarily defer Full Import and Full Synchronization steps after upgrade, refer to article [How to defer full synchronization after upgrade](how-to-upgrade-previous-version.md#how-to-defer-full-synchronization-after-upgrade).

+<a name='azure-ad-connect-sync'></a>

+### Microsoft Entra Connect Sync

+* There is an issue that affects customers who are using [OU-based filtering](how-to-connect-sync-configure-filtering.md#organizational-unitbased-filtering) with Microsoft Entra Connect Sync. When you navigate to the [Domain and OU Filtering page](how-to-connect-install-custom.md#domain-and-ou-filtering) in the Microsoft Entra Connect wizard, the following behavior is expected:

+The issue that arises is that the **Sync all domains and OUs option** is always selected when you run the Wizard. This occurs even if OU-based filtering was previously configured. Before saving any Microsoft Entra Connect configuration changes, make sure the **Sync selected domains and OUs option is selected** and confirm that all OUs that need to synchronize are enabled again. Otherwise, OU-based filtering will be disabled.

+* Fixed an issue with Password writeback that allows a Microsoft Entra Administrator to reset the password of an on-premises AD privileged user account. The issue occurs when Microsoft Entra Connect is granted the Reset Password permission over the privileged account. The issue is addressed in this version of Microsoft Entra Connect by not allowing a Microsoft Entra Administrator to reset the password of an arbitrary on-premises AD privileged user account unless the administrator is the owner of that account. For more information, refer to [Security Advisory 4033453](/security-updates/SecurityAdvisories/2017/4033453).

+* Fixed an issue related to the [ms-DS-ConsistencyGuid as Source Anchor](./plan-connect-design-concepts.md#using-ms-ds-consistencyguid-as-sourceanchor) feature where Microsoft Entra Connect does not writeback to on-premises AD ms-DS-ConsistencyGuid attribute. The issue occurs when there are multiple on-premises AD forests added to Microsoft Entra Connect and the *User identities exist across multiple directories option* is selected. When such configuration is used, the resultant synchronization rules don't populate the sourceAnchorBinary attribute in the Metaverse. The sourceAnchorBinary attribute is used as the source attribute for ms-DS-ConsistencyGuid attribute. As a result, writeback to the ms-DSConsistencyGuid attribute does not occur. To fix the issue, following sync rules have been updated to ensure that the sourceAnchorBinary attribute in the Metaverse is always populated:

+* Previously, even if the [ms-DS-ConsistencyGuid as Source Anchor](./plan-connect-design-concepts.md#using-ms-ds-consistencyguid-as-sourceanchor) feature isnΓÇÖt enabled, the ΓÇ£Out to AD ΓÇô User ImmutableIdΓÇ¥ synchronization rule is still added to Microsoft Entra Connect. The effect is benign and does not cause writeback of ms-DS-ConsistencyGuid attribute to occur. To avoid confusion, logic has been added to ensure that the sync rule is only added when the feature is enabled.

+* Previously, even if Automatic Upgrade has been disabled using the Set-ADSyncAutoUpgrade cmdlet, the Automatic Upgrade process continues to check for upgrade periodically, and relies on the downloaded installer to honor disablement. With this fix, the Automatic Upgrade process no longer checks for upgrade periodically. The fix is automatically applied when upgrade installer for this Microsoft Entra Connect version is executed once.

+ * To access the feature, start the Microsoft Entra Connect wizard and choose the *Update Source Anchor* option.

+* Specific to **userCertificate** attribute on Device objects, Microsoft Entra Connect now looks for certificates values required for [Connecting domain-joined devices to Microsoft Entra ID for Windows 10 experience](../../devices/hybrid-join-plan.md) and filters out the rest before synchronizing to Microsoft Entra ID. To enable this behavior, the out-of-box sync rule ΓÇ£Out to Microsoft Entra ID - Device Join SOAInADΓÇ¥ has been updated.

+* Microsoft Entra Connect now supports writeback of Exchange Online **cloudPublicDelegates** attribute to on-premises AD **publicDelegates** attribute. This enables the scenario where an Exchange Online mailbox can be granted SendOnBehalfTo rights to users with on-premises Exchange mailbox. To support this feature, a new out-of-box sync rule ΓÇ£Out to AD ΓÇô User Exchange Hybrid PublicDelegates writebackΓÇ¥ has been added. This sync rule is only added to Microsoft Entra Connect when Exchange Hybrid feature is enabled.

+* Microsoft Entra Connect now supports synchronizing the **altRecipient** attribute from Microsoft Entra ID. To support this change, following out-of-box sync rules have been updated to include the required attribute flow:

+ * Out to Microsoft Entra ID ΓÇô User ExchangeOnline

+* The **cloudSOAExchMailbox** attribute in the Metaverse indicates whether a given user has Exchange Online mailbox or not. Its definition has been updated to include additional Exchange Online RecipientDisplayTypes as such Equipment and Conference Room mailboxes. To enable this change, the definition of the cloudSOAExchMailbox attribute, which is found under out-of-box sync rule ΓÇ£In from Microsoft Entra ID ΓÇô User Exchange HybridΓÇ¥, has been updated from:

+ * Following attributes have been added to Microsoft Entra Connector schema:

+* The ADSyncDomainJoinedComputerSync cmdlet script now has a new optional parameter named AzureEnvironment. The parameter is used to specify which region the corresponding Microsoft Entra tenant is hosted in. Valid values include:

+* Following URLs are new WS-Federation endpoints introduced by Microsoft Entra ID to improve resiliency against authentication outage and will be added to on-premises AD FS replying party trust configuration:

+* Fixed an issue that caused AD FS to generate incorrect claim value for IssuerID. The issue occurs if there are multiple verified domains in the Microsoft Entra tenant and the domain suffix of the userPrincipalName attribute used to generate the IssuerID claim is at least 3-levels deep (for example, johndoe@us.contoso.com). The issue is resolved by updating the regex used by the claim rules.

+* Previously, the ADFS Certificate Management feature provided by Microsoft Entra Connect can only be used with ADFS farms managed through Microsoft Entra Connect. Now, you can use the feature with ADFS farms that aren't managed using Microsoft Entra Connect.

+> There are schema and sync rule changes introduced in this build. Microsoft Entra Connect Synchronization Service will trigger Full Import and Full Sync steps after upgrade. Details of the changes are described below.

+Microsoft Entra Connect Sync

+* Fixed an issue that causes Automatic Upgrade to occur on the Microsoft Entra Connect server even if customer has disabled the feature using the Set-ADSyncAutoUpgrade cmdlet. With this fix, the Automatic Upgrade process on the server still checks for upgrade periodically, but the downloaded installer honors the Automatic Upgrade configuration.

+* During DirSync in-place upgrade, Microsoft Entra Connect creates a Microsoft Entra service account to be used by the Microsoft Entra connector for synchronizing with Microsoft Entra ID. After the account is created, Microsoft Entra Connect authenticates with Microsoft Entra ID using the account. Sometimes, authentication fails because of transient issues, which in turn causes DirSync in-place upgrade to fail with error *ΓÇ£An error has occurred executing Configure Azure AD Sync task: AADSTS50034: To sign into this application, the account must be added to the xxx.onmicrosoft.com directory.ΓÇ¥* To improve the resiliency of DirSync upgrade, Microsoft Entra Connect now retries the authentication step.

+* There was an issue with build 443 that causes DirSync in-place upgrade to succeed but run profiles required for directory synchronization aren't created. Healing logic is included in this build of Microsoft Entra Connect. When customer upgrades to this build, Microsoft Entra Connect detects missing run profiles and creates them.

+* During Express installation, Microsoft Entra Connect creates an on-premises AD DS account to be used by the AD connector to communicate with on-premises AD. Previously, the account is created with the PASSWD_NOTREQD flag set on the user-Account-Control attribute and a random password is set on the account. Now, Microsoft Entra Connect explicitly removes the PASSWD_NOTREQD flag after the password is set on the account.

+* Fixed an issue that causes Device writeback feature to automatically be disabled when an administrator is updating Microsoft Entra Connect sync configuration using Microsoft Entra Connect wizard. This issue is caused by the wizard performing a pre-requisite check for the existing Device writeback configuration in on-premises AD and the check fails. The fix is to skip the check if Device writeback is already enabled previously.

+* To configure OU filtering, you can either use the Microsoft Entra Connect wizard or the Synchronization Service Manager. Previously, if you use the Microsoft Entra Connect wizard to configure OU filtering, new OUs created afterwards are included for directory synchronization. If you don't want new OUs to be included, you must configure OU filtering using the Synchronization Service Manager. Now, you can achieve the same behavior using Microsoft Entra Connect wizard.

+* Fixed an issue that causes stored procedures required by Microsoft Entra Connect to be created under the schema of the installing admin, instead of under the dbo schema.

+* Fixed an issue that causes the TrackingId attribute returned by Microsoft Entra ID to be omitted in the Microsoft Entra Connect Server Event Logs. The issue occurs if Microsoft Entra Connect receives a redirection message from Microsoft Entra ID and Microsoft Entra Connect is unable to connect to the endpoint provided. The TrackingId is used by Support Engineers to correlate with service side logs during troubleshooting.

+* When Microsoft Entra Connect receives LargeObject error from Microsoft Entra ID, Microsoft Entra Connect generates an event with EventID 6941 and message *ΓÇ£The provisioned object is too large. Trim the number of attribute values on this object.ΓÇ¥* At the same time, Microsoft Entra Connect also generates a misleading event with EventID 6900 and message *ΓÇ£Microsoft.Online.Coexistence.ProvisionRetryException: Unable to communicate with the Windows Azure Active Directory service.ΓÇ¥* To minimize confusion, Microsoft Entra Connect no longer generates the latter event when LargeObject error is received.

+Microsoft Entra Connect Sync

+ * Added **preferredDataLocation** to the Metaverse schema and Microsoft Entra Connector schema. Customers who want to update either attributes in Microsoft Entra ID can implement custom sync rules to do so.

+ * Added **userType** to the Metaverse schema and Microsoft Entra Connector schema. Customers who want to update either attributes in Microsoft Entra ID can implement custom sync rules to do so.

+* Microsoft Entra Connect now automatically enables the use of ConsistencyGuid attribute as the Source Anchor attribute for on-premises AD objects. Further, Microsoft Entra Connect populates the ConsistencyGuid attribute with the objectGuid attribute value if it's empty. This feature is applicable to new deployment only. To find out more about this feature, refer to article section [Microsoft Entra Connect: Design concepts - Using ms-DS-ConsistencyGuid as sourceAnchor](plan-connect-design-concepts.md#using-ms-ds-consistencyguid-as-sourceanchor).

+* New troubleshooting cmdlet Invoke-ADSyncDiagnostics has been added to help diagnose Password Hash Synchronization related issues. For information about using the cmdlet, refer to article [Troubleshoot password hash synchronization with Microsoft Entra Connect Sync](tshoot-connect-password-hash-synchronization.md).

+* Microsoft Entra Connect now supports synchronizing Mail-Enabled Public Folder objects from on-premises AD to Microsoft Entra ID. You can enable the feature using Microsoft Entra Connect wizard under Optional Features. To find out more about this feature, refer to article [Office 365 Directory Based Edge Blocking support for on-premises Mail Enabled Public Folders](https://techcommunity.microsoft.com/t5/exchange/office-365-directory-based-edge-blocking-support-for-on-premises/m-p/74218).

+* Microsoft Entra Connect requires an AD DS account to synchronize from on-premises AD. Previously, if you installed Microsoft Entra Connect using the Express mode, you could provide the credentials of an Enterprise Admin account and Microsoft Entra Connect would create the AD DS account required. However, for a custom installation and adding forests to an existing deployment, you were required to provide the AD DS account instead. Now, you also have the option to provide the credentials of an Enterprise Admin account during a custom installation and let Microsoft Entra Connect create the AD DS account required.

+* Microsoft Entra Connect now supports SQL AOA. You must enable SQL AOA before installing Microsoft Entra Connect. During installation, Microsoft Entra Connect detects whether the SQL instance provided is enabled for SQL AOA or not. If SQL AOA is enabled, Microsoft Entra Connect further figures out if SQL AOA is configured to use synchronous replication or asynchronous replication. When setting up the Availability Group Listener, it's recommended that you set the RegisterAllProvidersIP property to 0. This recommendation is because Microsoft Entra Connect currently uses SQL Native Client to connect to SQL and SQL Native Client does not support the use of MultiSubNetFailover property.

+* If you are using LocalDB as the database for your Microsoft Entra Connect server and has reached its 10-GB size limit, the Synchronization Service no longer starts. Previously, you need to perform ShrinkDatabase operation on the LocalDB to reclaim enough DB space for the Synchronization Service to start. After which, you can use the Synchronization Service Manager to delete run history to reclaim more DB space. Now, you can use Start-ADSyncPurgeRunHistory cmdlet to purge run history data from LocalDB to reclaim DB space. Further, this cmdlet supports an offline mode (by specifying the -offline parameter) which can be used when the Synchronization Service is not running. Note: The offline mode can only be used if the Synchronization Service is not running and the database used is LocalDB.

+* To reduce the amount of storage space required, Microsoft Entra Connect now compresses sync error details before storing them in LocalDB/SQL databases. When upgrading from an older version of Microsoft Entra Connect to this version, Microsoft Entra Connect performs a one-time compression on existing sync error details.

+* Previously, after updating OU filtering configuration, you must manually run Full import to ensure existing objects are properly included/excluded from directory synchronization. Now, Microsoft Entra Connect automatically triggers Full import during the next sync cycle. Further, Full import is only be applied to the AD connectors affected by the update. Note: this improvement is applicable to OU filtering updates made using the Microsoft Entra Connect wizard only. It is not applicable to OU filtering update made using the Synchronization Service Manager.

+* Previously, you can delete Connector Space data without disabling Microsoft Entra Connect Sync scheduler. Now, the Synchronization Service Manager blocks the deletion of Connector Space data if it detects that the scheduler is enabled. Further, a warning is returned to inform customers about potential data loss if the Connector space data is deleted.

+* Previously, you must disable PowerShell transcription for Microsoft Entra Connect wizard to run correctly. This issue is partially resolved. You can enable PowerShell transcription if you are using Microsoft Entra Connect wizard to manage sync configuration. You must disable PowerShell transcription if you are using Microsoft Entra Connect wizard to manage ADFS configuration.

+* Fixed the issue where Microsoft Entra Connect will not install successfully on localized version of Windows Server.

+* This version of Microsoft Entra Connect will not install successfully if the following conditions are all true:

+ 1. You are performing either DirSync in-place upgrade or fresh installation of Microsoft Entra Connect.

+ 3. You are using the default SQL Server 2012 Express LocalDB installed with Microsoft Entra Connect instead of providing your own full SQL.

+Microsoft Entra Connect Sync

+* Fixed an issue that causes the Microsoft Entra Connector update to be skipped during Automatic Upgrade.

+* Fixed an issue that causes Microsoft Entra Connect to incorrectly determine whether the server is a domain controller during setup, which in turn causes DirSync upgrade to fail.

+* Fixed an issue that causes DirSync in-place upgrade to not create any run profile for the Microsoft Entra Connector.

+* Fixed an issue where the Microsoft Entra Connect wizard fails if the AD FS primary node has been moved to another server.

+* Fixed an issue in the Microsoft Entra Connect wizard where the Sign-In screen does not let you enable Desktop SSO feature if you chose Password Synchronization as your Sign-In option during new installation.

+Microsoft Entra Connect Sync

+* Microsoft Entra Connect Sync now supports the use of Virtual Service Account, Managed Service Account and Group Managed Service Account as its service account. This applies to new installation of Microsoft Entra Connect only. When installing Microsoft Entra Connect:

+ * By default, Microsoft Entra Connect wizard will create a Virtual Service Account and uses it as its service account.

+ * If you are installing on a domain controller, Microsoft Entra Connect falls back to previous behavior where it will create a domain user account and uses it as its service account instead.

+* Previously, if you upgrade to a new build of Microsoft Entra Connect containing connectors update or sync rule changes, Microsoft Entra Connect will trigger a full sync cycle. Now, Microsoft Entra Connect selectively triggers Full Import step only for connectors with update, and Full Synchronization step only for connectors with sync rule changes.

+* On your Microsoft Entra tenant, there is a service configuration which indicates whether Password Synchronization feature is enabled for your tenant or not. Previously, it's easy for the service configuration to be incorrectly configured by Microsoft Entra Connect when you've an active and a staging server. Now, Microsoft Entra Connect will attempt to keep the service configuration consistent with your active Microsoft Entra Connect server only.

+* Microsoft Entra Connect wizard now detects and returns a warning if on-premises AD does not have AD Recycle Bin enabled.

+* Previously, Export to Microsoft Entra ID times out and fails if the combined size of the objects in the batch exceeds certain threshold. Now, the Synchronization Service will reattempt to resend the objects in separate, smaller batches if the issue is encountered.

+* The Synchronization Service Key Management application has been removed from Windows Start Menu. Management of encryption key will continue to be supported through command-line interface using miiskmu.exe. For information about managing encryption key, refer to article [Abandoning the Microsoft Entra Connect Sync encryption key](./how-to-connect-sync-change-serviceacct-pass.md#abandoning-the-adsync-service-account-encryption-key).

+* Previously, if you change the Microsoft Entra Connect Sync service account password, the Synchronization Service will not be able start correctly until you've abandoned the encryption key and reinitialized the Microsoft Entra Connect Sync service account password. Now, this process is no longer required.

+* Microsoft Entra Connect wizard no longer requires port 9090 to be opened on the network when configuring Pass-through Authentication and Desktop SSO. Only port 443 is required.

+Microsoft Entra Connect Sync

+* Fixed an issue which causes Microsoft Entra Connect wizard to fail if the display name of the Microsoft Entra Connector does not contain the initial onmicrosoft.com domain assigned to the Microsoft Entra tenant.

+* Fixed an issue which causes Microsoft Entra Connect wizard to fail while making connection to SQL database when the password of the Sync Service Account contains special characters such as apostrophe, colon and space.

+* Fixed an issue which causes the error ΓÇ£The dimage has an anchor that is different than the imageΓÇ¥ to occur on a Microsoft Entra Connect server in staging mode, after you've temporarily excluded an on-premises AD object from syncing and then included it again for syncing.

+* Fixed an issue which causes the error ΓÇ£The object located by DN is a phantomΓÇ¥ to occur on a Microsoft Entra Connect server in staging mode, after you've temporarily excluded an on-premises AD object from syncing and then included it again for syncing.

+* Fixed an issue where Microsoft Entra Connect wizard does not update AD FS configuration and set the right claims on the relying party trust after Alternate Login ID is configured.

+* Fixed an issue where Microsoft Entra Connect wizard is unable to correctly handle AD FS servers whose service accounts are configured using userPrincipalName format instead of sAMAccountName format.

+* Fixed an issue which causes Microsoft Entra Connect wizard to fail if Pass Through Authentication is selected but registration of its connector fails.

+* Fixed an issue which causes Microsoft Entra Connect wizard to bypass validation checks on sign-in method selected when Desktop SSO feature is enabled.

+* Fixed an issue which may cause the Azure Microsoft Entra Connect server to not attempt to re-connect if the connection was killed by a firewall or proxy.

+Microsoft Entra Connect Sync

+* Destination folder for storing Microsoft Entra Connect installation and setup logs has been moved from %localappdata%\AADConnect to %programdata%\AADConnect to improve accessibility to the log files.

+* You can now configure SHA-256 as the signature hash algorithm for Microsoft Entra ID relying party trust.

+>This build is not available to customers through the Microsoft Entra Connect Auto Upgrade feature.

+* The issuerid claim rule for AD FS is missing in this build. The issuerid claim rule is required if you are federating multiple domains with Microsoft Entra ID. If you are using Microsoft Entra Connect to manage your on-premises AD FS deployment, upgrading to this build removes the existing issuerid claim rule from your AD FS configuration. You can work around the issue by adding the issuerid claim rule after the installation/upgrade. For details on adding the issuerid claim rule, refer to this article on [Multiple domain support for federating with Microsoft Entra ID](how-to-connect-install-multiple-domains.md).

+* If Port 9090 is not opened for the outbound connection, the Microsoft Entra Connect installation or upgrade fails.

+>This build is not available to customers through the Microsoft Entra Connect Auto Upgrade feature.

+* The issuerid claim rule for AD FS is missing in this build. The issuerid claim rule is required if you are federating multiple domains with Microsoft Entra ID. If you are using Microsoft Entra Connect to manage your on-premises AD FS deployment, upgrading to this build removes the existing issuerid claim rule from your AD FS configuration. You can work around the issue by adding the issuerid claim rule after installation/upgrade. For details on adding issuerid claim rule, refer to this article on [Multiple domain support for federating with Microsoft Entra ID](how-to-connect-install-multiple-domains.md).

+>This build is not available to customers through the Microsoft Entra Connect Auto Upgrade feature.

+* The issuerid claim rule for AD FS is missing in this build. The issuerid claim rule is required if you are federating multiple domains with Microsoft Entra ID. If you are using Microsoft Entra Connect to manage your on-premises AD FS deployment, upgrading to this build removes the existing issuerid claim rule from your AD FS configuration. You can work around the issue by adding the issuerid claim rule after installation/upgrade. For details on adding issuerid claim rule, refer to this article on [Multiple domain support for federating with Microsoft Entra ID](how-to-connect-install-multiple-domains.md).

+* Sometimes, installing Microsoft Entra Connect fails because it's unable to create a local service account whose password meets the level of complexity specified by the organization's password policy.

+* Fixed an issue where inbound synchronization rules (from Microsoft Entra ID), which don't contain join rules, aren't processed if they have lower precedence values than those containing join rules.

+* Added support for installing Microsoft Entra Connect on Windows Server 2016 Standard or higher.

+* Added support for using SQL Server 2016 as the remote database for Microsoft Entra Connect.

+* Microsoft Entra Connect wizard does not accept a Microsoft Entra account whose username starts with an underscore (\_).

+* Microsoft Entra Connect wizard fails to authenticate the Microsoft Entra account if the account password contains too many special characters. Error message "Unable to validate credentials. An unexpected error has occurred." is returned.

+* Uninstalling staging server disables password synchronization in Microsoft Entra tenant and causes password synchronization to fail with active server.

+* When Microsoft Entra Connect server is enabled for staging mode, password writeback is not temporarily disabled.

+* Microsoft Entra Connect wizard does not show the actual password synchronization and password writeback configuration when server is in staging mode. It always shows them as disabled.

+* Configuration changes to password synchronization and password writeback aren't persisted by Microsoft Entra Connect wizard when server is in staging mode.

+* When configuring [Directory extensions](how-to-connect-sync-feature-directory-extensions.md) in Microsoft Entra Connect wizard, the Microsoft Entra attribute of type "Teletex string" can now be selected.

+* Microsoft Entra Connect can now be installed on a FIPS-compliant server.

+* Warns and helps you verify domains if you didnΓÇÖt do it before running Microsoft Entra Connect.

+* If you installed an earlier release of Microsoft Entra Connect with AD FS as the sign-in option and upgrade, you cannot run the installation wizard again.

+* Support for the Hybrid Identity Administrator by using Microsoft Entra multifactor Authentication and Privileged Identity Management in the installation wizard.

+ * You need to allow your proxy to also allow traffic to ```https://secure.aadcdn.microsoftonline-p.com``` if you use multifactor authentication.

+ * You need to add ```https://secure.aadcdn.microsoftonline-p.com``` to your trusted sites list for multifactor authentication to properly work.

+* When you've a proxy server, authentication to Microsoft Entra ID might fail during installation, or if an upgrade is canceled on the configuration page.

+* Updating from a previous release of Microsoft Entra Connect with a full SQL Server instance fails if you aren't a SQL Server system administrator (SA).

+* Updating from a previous release of Microsoft Entra Connect with a remote SQL Server shows the ΓÇ£Unable to access the ADSync SQL databaseΓÇ¥ error.

+* Can reconfigure AD FS to Microsoft Entra ID trust.

+* [Microsoft Entra Connect Health for sync](how-to-connect-health-sync.md).

+* Support for [Microsoft Entra Domain Services](https://support.microsoft.com/account-billing/reset-your-work-or-school-password-using-security-info-23dde81f-08bb-4776-ba72-e6b72b9dda9e) password synchronization.

+* No longer creates a new user profile on the Microsoft Entra Connect server for every user doing a password change with password writeback enabled.

+* The Microsoft Entra Connect installation wizard is now localized to all Windows Server languages.

+* Added support for account unlock when using Microsoft Entra password management.

+* Microsoft Entra Connect installation wizard crashes if another user continues installation rather than the person who first started the installation.

+* If a previous uninstallation of Microsoft Entra Connect fails to uninstall Microsoft Entra Connect Sync cleanly, it's not possible to reinstall.

+* Cannot install Microsoft Entra Connect using Express installation if the user is not in the root domain of the forest or if a non-English version of Active Directory is used.

+* Microsoft Entra Connect sometimes fails to install on a domain controller.

+**Initial release of Microsoft Entra Connect.**

+Changed name from Azure AD Sync to Microsoft Entra Connect.

+* Password writeback from Microsoft Entra ID is failing with an Azure Service Bus connectivity error.

+* The performance of import operations has been improved for the Microsoft Entra Connector.

+* When a group has exceeded the membership limit (by default, the limit's set to 50,000 objects), the group was deleted in Microsoft Entra ID. With the new behavior, the group is not deleted, an error is thrown, and new membership changes aren't exported.

+* ΓÇ£Stopped-serverΓÇ¥ when importing from the Microsoft Entra Connector after device management has been enabled in Azure AD/Intune.

+* Password synchronization from multiple on-premises Active Directory to Microsoft Entra ID.

+Learn more about [Integrating your on-premises identities with Microsoft Entra ID](../whatis-hybrid-identity.md).

+ Title: 'Microsoft Entra Connect: Version release history'

+description: This article lists all releases of Microsoft Entra Connect and Azure AD Sync.

+# Microsoft Entra Connect: Version release history

+The Microsoft Entra team regularly updates Microsoft Entra Connect with new features and functionality. Not all additions apply to all audiences.

+You can upgrade your Microsoft Entra Connect server from all supported versions with the latest versions:

+You can download the latest version of Microsoft Entra Connect 2.0 from the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=47594). See the [release notes for the latest V2.0 release](reference-connect-version-history.md#21200).\

+Steps to upgrade from Microsoft Entra Connect | Different methods to [upgrade from a previous version to the latest](how-to-upgrade-previous-version.md) Microsoft Entra Connect release.

+Required permissions | For permissions required to apply an update, see [Microsoft Entra Connect: Accounts and permissions](reference-connect-accounts-permissions.md#upgrade).

+<a name='retiring-azure-ad-connect-1x-versions'></a>

+## Retiring Microsoft Entra Connect 1.x versions

+> Action required: Synchronization will stop working on October 1, 2023, for any customers still running Microsoft Entra Connect Sync V1. Customers using cloud sync or Microsoft Entra Connect V2 will remain fully operational with no action required. For more information and next step guidance, see [Decommission Azure AD Connect V1](https://aka.ms/DecommissionAADConnectV1) if an upgrade is required.

+<a name='retiring-azure-ad-connect-2x-versions'></a>

+## Retiring Microsoft Entra Connect 2.x versions

+> We will begin retiring past versions of Microsoft Entra Connect Sync 2.x 12 months from the date they are superseded by a newer version.

+> If you are not already using the latest release version of Microsoft Entra Connect Sync, you should upgrade your Microsoft Entra Connect Sync software before that date.

+If you run a retired version of Microsoft Entra Connect, it might unexpectedly stop working. You also might not have the latest security fixes, performance improvements, troubleshooting and diagnostic tools, and service enhancements. If you require support, we might not be able to provide you with the level of service your organization needs.

+To learn more about what has changed in V2.0 and how this change affects you, see [Microsoft Entra Connect V2.0](whatis-azure-ad-connect-v2.md).

+To learn more about how to upgrade Microsoft Entra Connect to the latest version, see [Microsoft Entra Connect: Upgrade from a previous version to the latest](./how-to-upgrade-previous-version.md).

+For version history information on retired versions, see [Microsoft Entra Connect: Version release history archive](reference-connect-version-history-archive.md).

+> Releasing a new version of Microsoft Entra Connect requires several quality-control steps to ensure the operation functionality of the service. While we go through this process, the version number of a new release and the release status are updated to reflect the most recent state.

+Not all releases of Microsoft Entra Connect are made available for autoupgrade. The release status indicates whether a release is made available for autoupgrade or for download only. If autoupgrade was enabled on your Microsoft Entra Connect server, that server automatically upgrades to the latest version of Microsoft Entra Connect that's released for autoupgrade. Not all Microsoft Entra Connect configurations are eligible for autoupgrade.

+To read more about autoupgrade, see [Microsoft Entra Connect: Automatic upgrade](how-to-connect-install-automatic-upgrade.md).

+ - We have added Microsoft Entra Connect Agent Updater service to the install. This new service will be used for future auto upgrades.

+ - We fixed a bug where the new employeeLeaveDateTime attribute wasn't syncing correctly in version 2.1.19.0. Note that if the incorrect attribute was already used in a rule, then the rule must be updated with the new attribute and any objects in the Microsoft Entra connector space that have the incorrect attribute must be removed with the "Remove-ADSyncCSObject" cmdlet, and then a full sync cycle must be run.

+ - We added a new attribute 'employeeLeaveDateTime' for syncing to Microsoft Entra ID. To learn more about how to use this attribute to manage your users' life cycles, please refer to [this article](../../governance/how-to-lifecycle-workflow-sync-attributes.md)

+ - we fixed a bug where Microsoft Entra Connect Password writeback stopped with error code "SSPR_0029 ERROR_ACCESS_DENIED"

+ - we fixed a bug where the Microsoft Entra Connect Configuration Wizard was sending incorrect credentials (username format) while validating if Enterprise Admin.

+> We have discovered a security vulnerability in the Microsoft Entra Connect Admin Agent. If you have installed the Admin Agent previously it is important that you update your Microsoft Entra Connect server(s) to this version to mitigate the vulnerability.

+ - We have removed the public preview functionality for the Admin Agent from Microsoft Entra Connect. We won't provide this functionality going forward.

+ - We added CertificateUserIds attribute to Microsoft Entra Connector static schema.

+ - The Microsoft Entra Connect wizard will now abort if write event logs permission is missing.

+ - We updated the expressions used in the "In from Microsoft Entra ID - Group SOAInAAD" rule to limit the description attribute to 448 characters.

+- We updated the Microsoft Entra Connect Health component in this release from version 3.1.110.0 to version 3.2.1823.12. This new version provides compliance of the Microsoft Entra Connect Health component with the [Federal Information Processing Standards (FIPS)](https://www.nist.gov/standardsgov/compliance-faqs-federal-information-processing-standards-fips) requirements.

+- We fixed an issue which causes upgrade to Microsoft Entra Connect version 2.x to fail, when using SQL localdb along with a VSA service account for ADSync.

+> This release requires Windows Server 2016 or newer. It fixes a vulnerability that's present in version 2.0 of Microsoft Entra Connect and other bug fixes and minor feature updates.

+ - We made the Microsoft Entra Connect wizard resizable to account for different zoom levels and screen resolutions.

+- We fixed a bug to ensure the desktop SSO value persists after upgrading Microsoft Entra Connect to a newer version.

+- Microsoft Entra Kerberos changes:

+ - We made a change to set an official brand name for the Microsoft Entra Kerberos feature.

+> This release is an update release of Microsoft Entra Connect. This version is intended to be used by customers who are running an older version of Windows Server and can't upgrade their server to Windows Server 2016 or newer at this time. You can't use this version to update a Microsoft Entra Connect V2.0 server.

+> Don't install this release on Windows Server 2016 or newer. This release includes SQL Server 2012 components and will be retired on August 31, 2022. Upgrade your Server OS and Microsoft Entra Connect version before that date.

+- We fixed a bug where the autoupgrade process attempted to upgrade Microsoft Entra Connect servers that are running older Windows OS version 2008 or 2008 R2 and failed. These versions of Windows Server are no longer supported. In this release, we only attempt autoupgrade on machines that run Windows Server 2012 or newer.

+> This release is a maintenance update release of Microsoft Entra Connect. It requires Windows Server 2016 or newer.

+> This release is an update release of Microsoft Entra Connect. This version is intended to be used by customers who are running an older version of Windows Server and can't upgrade their server to Windows Server 2016 or newer at this time. You can't use this version to update a Microsoft Entra Connect V2.0 server.

+- We added a configuration option to disable the Soft Matching feature in Microsoft Entra Connect. We recommend that you disable Soft Matching unless you need it to take over cloud-only accounts. To disable Soft Matching, see [this reference article](/powershell/module/msonline/set-msoldirsyncfeature#example-2--block-soft-matching-for-the-tenant).

+> This release is a hotfix update release of Microsoft Entra Connect. This release requires Windows Server 2016 or newer. It fixes a security issue that's present in version 2.0 of Microsoft Entra Connect and includes other bug fixes.

+- We fixed a security issue where an unquoted path was used to point to the Microsoft Entra Connect service. This path is now a quoted path.

+- We fixed an import configuration issue with writeback enabled when you use the existing Microsoft Entra Connector account.

+- We fixed an issue with the cmdlet we published in a previous release to set the TLS version. The cmdlet overwrote the keys, which destroyed any values that were in them. Now a new key is created only if one doesn't already exist. We added a warning to let users know the TLS registry changes aren't exclusive to Microsoft Entra Connect and might affect other applications on the same server.

+- We created new Microsoft Entra Kerberos PowerShell cmdlets (\*-AADKerberosServer) to add a Claims Transform rule to the Microsoft Entra service principal.

+- We added a configuration option to disable the Soft Matching feature in Microsoft Entra Connect. We recommend that you disable Soft Matching unless you need it to take over cloud-only accounts. To disable Soft Matching, see [this reference article](/powershell/module/msonline/set-msoldirsyncfeature#example-2--block-soft-matching-for-the-tenant).

+> This is a hotfix update release of Microsoft Entra Connect. This release requires Windows Server 2016 or newer. This hotfix addresses an issue that's present in version 2.0 and in Microsoft Entra Connect version 1.6. If you're running Microsoft Entra Connect on an older Windows server, install the [1.6.13.0](#16130) build instead.

+Under certain circumstances, the installer for this version displays an error that states TLS 1.2 isn't enabled and stops the installation. This issue occurs because of an error in the code that verifies the registry setting for TLS 1.2. We'll correct this issue in a future release. If you see this issue, follow the instructions to enable TLS 1.2 in [TLS 1.2 enforcement for Microsoft Entra Connect](reference-connect-tls-enforcement.md).

+> This release is a hotfix update release of Microsoft Entra Connect. It's intended to be used by customers who are running Microsoft Entra Connect on a server with Windows Server 2012 or 2012 R2.

+> This release is a hotfix update release of Microsoft Entra Connect. This release requires Windows Server 2016 or newer. It addresses an issue that's present in version 2.0.8.0. This issue isn't present in Microsoft Entra Connect version 1.6.

+> This release is a security update release of Microsoft Entra Connect. This release requires Windows Server 2016 or newer. If you're using an older version of Windows Server, use [version 1.6.11.3](#16113).

+To download the latest version of Microsoft Entra Connect 2.0, see the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=47594).

+> This release is a security update release of Microsoft Entra Connect. It's intended to be used by customers who are running an older version of Windows Server and can't upgrade their server to Windows Server 2016 or newer at this time. You can't use this version to update a Microsoft Entra Connect V2.0 server.

+> This release is a major release of Microsoft Entra Connect. For more information, see [Introduction to Microsoft Entra Connect V2.0](whatis-azure-ad-connect-v2.md).

+- This release requires Windows Server 2016 or newer because of the requirements of SQL Server 2019. An in-place upgrade of Windows Server on a Microsoft Entra Connect server isn't supported. For this reason, you might need to use a [swing migration](how-to-upgrade-previous-version.md#swing-migration).

+- We enforce the use of TLS 1.2 in this release. If you enabled your Windows Server for TLS 1.2, Microsoft Entra Connect uses this protocol. If TLS 1.2 isn't enabled on the server, you'll see an error message when you attempt to install Microsoft Entra Connect. The installation won't continue until you've enabled TLS 1.2. You can use the new Set-ADSyncToolsTls12 cmdlets to enable TLS 1.2 on your server.

+- We made a change so that with this release, you can use the Hybrid Identity Administrator role to authenticate when you install Microsoft Entra Connect. You no longer need to use the Global Administrator role.

+- We made a change so that passwords are now reevaluated when an expired password is "unexpired," no matter if the password itself is changed. If the password is set to "Must change password at next logon" for a user, and this flag is cleared (which "unexpires" the password), the unexpired status and the password hash are synced to Microsoft Entra ID. In Microsoft Entra ID, when the user attempts to sign in, they can use the unexpired password.

+To sync an expired password from Active Directory to Microsoft Entra ID, use the feature in Microsoft Entra Connect to [synchronize temporary passwords](how-to-connect-password-hash-synchronization.md#synchronizing-temporary-passwords-and-force-password-change-on-next-logon). Enable password writeback to use this feature so that the password the user updates is written back to Active Directory.

+You can use these cmdlets to retrieve the TLS 1.2 enablement status or set it as needed. TLS 1.2 must be enabled on the server for the installation or Microsoft Entra Connect to succeed.

+- We now use the V2 endpoint for import and export. We fixed an issue in the Get-ADSyncAADConnectorExportApiVersion cmdlet. To learn more about the V2 endpoint, see [Microsoft Entra Connect Sync V2 endpoint](how-to-connect-sync-endpoint-api-v2.md).

+- We added the following new user properties to sync from on-premises Active Directory to Microsoft Entra ID:

+- In the Microsoft 365 admin center, we now report the Microsoft Entra Connect client version whenever there's export activity to Microsoft Entra ID. This reporting ensures that the Microsoft 365 admin center always has the most up-to-date Microsoft Entra Connect client version, and that it can detect when you're using an outdated version.

+- We updated the Microsoft Entra Connect Health agent version to 3.1.110.0 to fix an installation failure.

+- We're seeing an issue with nondefault attributes from exported configurations where directory extension attributes are configured. In the process of importing these configurations to a new server or installation, the attribute inclusion list is overridden by the directory extension configuration step. As a result, after import, only default and directory extension attributes are selected in the sync service manager. Nondefault attributes aren't included in the installation, so the user must manually reenable them from the sync service manager if they want their imported sync rules to work. We now refresh the Microsoft Entra Connector before configuring the directory extension to keep existing attributes from the attribute inclusion list.

+- We fixed an accessibility issue where the active tab on Microsoft Entra Connect wizard wasn't showing the correct color on High Contrast theme. The selected color code was being overwritten because of a missing condition in the normal color code configuration.

+- We made some updates to the "migrate settings code" to check and fix backward compatibility issues when the script runs on an older version of Microsoft Entra Connect.

+- We fixed a bug where Microsoft Entra Connect can't read Application Proxy items by using Microsoft Graph because of a permissions issue with calling Microsoft Graph directly based on the Microsoft Entra Connect client identifier. To fix this issue, we removed the dependency on Microsoft Graph and instead use Azure AD PowerShell to work with the App Proxy Application objects.

+- We fixed a bug where a stopped-extension-dll-exception error on Microsoft Entra Connector exported after clean installing the Microsoft Entra Connect version 1.6.X.X, which defaulted to using DirSyncWebServices API V2, by using an existing database. Previously, the setting export version to V2 was only being done for upgrades. We changed it so that it's set on clean install.

+- The Microsoft Entra Connect wizard shows the **Import Synchronization Settings** option as **Preview**, although this feature is generally available.

+- The **User Sign In** options page in the Microsoft Entra Connect wizard mentions Company Administrator. This term is no longer used and needs to be replaced by Global Administrator.

+- While Microsoft Entra Connect can now be deployed by using the Hybrid Identity Administrator role, configuring Self-Service Password Reset, Passthru Authentication, or single sign-on still requires a user with the Global Administrator role.

+- When you import the Microsoft Entra Connect configuration while you deploy to connect with a different tenant than the original Microsoft Entra Connect configuration, directory extension attributes aren't configured correctly.

+> The Microsoft Entra Connect Sync V2 endpoint API is now available in these Azure environments:

+This release fixes a bug that occurred in version 1.6.2.4. After upgrade to that release, the Microsoft Entra Connect Health feature wasn't registered correctly and didn't work. If you deployed build 1.6.2.4, update your Microsoft Entra Connect server with this build to register the Health feature correctly.

+> If you already installed this build, you can manually register the Health services by using the cmdlet, as shown in [Microsoft Entra Connect Health agent installation](./how-to-connect-health-agent-install.md#manually-register-azure-ad-connect-health-for-sync).

+- This release defaults the Microsoft Entra Connect server to the new V2 endpoint.

+ - We added new default sync rules for limiting the membership count in group writeback (Out to AD - Group Writeback Member Limit) and group sync to Microsoft Entra ID (Out to Microsoft Entra ID - Group Writeup Member Limit) groups.

+ - If the In from Microsoft Entra ID - Group SOAInAAD rule is cloned and Microsoft Entra Connect is upgraded:

+ - Microsoft Entra Connect will write back all Cloud Groups (including Microsoft Entra Security Groups enabled for writeback) as Distribution Groups.

+ - If the Out to AD - Group SOAInAAD rule is cloned and Microsoft Entra Connect is upgraded:

+ - Depending on the Cloned Custom Sync Rule's precedence, Microsoft Entra Connect will flow the Mail and Exchange attributes.

+- We added the new [Single Object Sync cmdlet](./how-to-connect-single-object-sync.md). Use this cmdlet to troubleshoot your Microsoft Entra Connect Sync configuration.

+- Microsoft Entra Connect now supports the Hybrid Identity Administrator role for configuring the service.

+- We updated the Microsoft Entra Connect Health agent to 3.1.83.0.

+- We added the ability to set and get the Microsoft Entra DirSync feature group writeback V2 in the existing cmdlets:

+- We updated screen reader output for some items in the Microsoft Entra Connect wizard. We updated the button hover color to satisfy contrast requirements. We updated Synchronization Service Manager title color to satisfy contrast requirements.

+- We fixed an issue with installing Microsoft Entra Connect from exported configuration having custom extension attributes.

+- Fresh Microsoft Entra Connect installations will use the Export Deletion Threshold stored in the cloud if there's one available and if there isn't a different one passed in.

+- We fixed an issue where Microsoft Entra Connect wouldn't read Active Directory displayName changes of hybrid-joined devices.

+Learn more about how to [integrate your on-premises identities with Microsoft Entra ID](../whatis-hybrid-identity.md).

+# Understanding errors during Microsoft Entra synchronization

+# Introduction to Microsoft Entra Connect V2.0

+- Microsoft Graph PowerShell using a [Security Administrator](../roles/permissions-reference.md#security-administrator) role. The IdentityRiskEvent.Read.All, IdentityRiskyUser.ReadWrite.All Or IdentityRiskyUser.ReadWrite.All delegated permissions are required. To set the permissions to IdentityRiskEvent.Read.All and IdentityRiskyUser.ReadWrite.All, run:

+Microsoft Entra ID Protection marks some risk detections and the corresponding risky sign-ins as dismissed with risk state **Dismissed** and risk detail **Azure AD Identity Protection assessed sign-in safe**. It takes this action, because those events were no longer determined to be risky.

+You can allow users to self-remediate their sign-in risks and user risks by setting up [risk-based policies](howto-identity-protection-configure-risk-policies.md). If users pass the required access control, such as multifactor authentication or secure password change, then their risks are automatically remediated. The corresponding risk detections, risky sign-ins, and risky users are reported with the risk state **Remediated** instead of **At risk**.

+The prerequisites for users before risk-based policies can be applied to allow self-remediation of risks are:

+ - For hybrid users that are synced from on-premises to cloud, password writeback must be enabled.

+Risk-based policies are configured based on risk levels and only apply if the risk level of the sign-in or user matches the configured level. Some detections might not raise risk to the level where the policy applies, and administrators need to handle those risky users manually. Administrators can determine that extra measures are necessary like [blocking access from locations](../conditional-access/howto-conditional-access-policy-location.md) or lowering the acceptable risk in their policies.

+If a user has registered for self-service password reset (SSPR), then they can remediate their own user risk by performing a self-service password reset.

+If requiring a password reset using a user risk policy isn't an option, or time is of the essence, administrators can remediate a risky user by requiring a password reset.

+Administrators have options they can choose from:

+ - They can generate passwords for cloud and hybrid users in the Microsoft Entra admin center.

+ - They can generate passwords for hybrid users from an on-premises directory when password hash synchronization and the [Allow on-premises password change to reset user risk](#allow-on-premises-password-reset-to-remediate-user-risks-preview) setting is enabled.

+ > [!WARNING]

+ > Don't select the option **User must change password at next logon**. This is unsupported.

+- **Require the user to reset password** - Requiring the users to reset passwords enables self-recovery without contacting help desk or an administrator.

+ - Cloud and hybrid users can complete a secure password change. This method only applies to users that can perform MFA already. For users that haven't registered, this option isn't available.

+ - Hybrid users can complete a password change by pressing Ctrl+Alt+Del and changing their password from an on-premises or hybrid joined Windows device, when password hash synchronization and the [Allow on-premises password change to reset user risk](#allow-on-premises-password-reset-to-remediate-user-risks-preview) setting is enabled.

+#### Allow on-premises password reset to remediate user risks (Preview)

+Organizations who have enabled [password hash synchronization](../hybrid/connect/whatis-phs.md) can allow password changes on-premises to remediate user risk.

+This configuration provides organizations two new capabilities:

+- Risky hybrid users can self-remediate without administrators intervention. When a password is changed on-premises, user risk is now automatically remediated within Entra ID Protection, bringing the user to a safe state.

+- Organizations can proactively deploy [user risk policies that require password changes](howto-identity-protection-configure-risk-policies.md#user-risk-policy-in-conditional-access) to confidently protect their hybrid users. This option strengthens your organization's security posture and simplifies security management by ensuring that user risks are promptly addressed, even in complex hybrid environments.

+To configure this setting

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Security Operator](../roles/permissions-reference.md#security-operator).

+1. Browse to **Protection** > **Identity Protection** > **Settings**.

+1. Check the box to **Allow on-premises password change to reset user risk**.

+1. Select **Save**.

+Because this method doesn't affect the user's existing password, it doesn't bring their identity back into a safe state.

+An administrator can choose to block a sign-in based on their risk policy or investigations. A block can occur based on either sign-in or user risk.

+The `Invoke-AzureADIPDismissRiskyUser.ps1` script included in the repository allows organizations to dismiss all risky users in their directory.

+[Simulate a high user risk](howto-identity-protection-graph-api.md#confirm-users-compromised-using-powershell)

+There are several reasons why you should give Microsoft Entra risk feedback:

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

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

+5. Under **Select an identity provider**, select **Microsoft Entra ID**.

+ 

+Regarding SLO functionality, a SLO URI in Microsoft Entra ID ensures an IdP-initiated sign-out from the MyApps portal terminates the session between the client and the BIG-IP APM. The imported application federation metadata.xml provides the APM with the Microsoft Entra SAML sign-out endpoint, for SP initiated sign-out. Therefore, enable the APM to know when a user signs out.

+This tutorial covers the latest Guided Configuration 16.1 with an Easy Button template. With the Easy Button, Admins don't go back and forth between Microsoft Entra ID and a BIG-IP to enable services for SHA. The deployment and policy management is handled by the APM Guided Configuration wizard and Microsoft Graph. This integration between BIG-IP APM and Microsoft Entra ID ensures applications support identity federation, SSO, and Microsoft Entra Conditional Access, reducing administrative overhead.

+1. Navigate to **Access > Guided Configuration > Microsoft Integration** and select **Microsoft Entra Application**.

+ 

+This tutorial uses Guided Configuration 16.1 with an Easy Button template. With the Easy Button, admins don't go back and forth between Microsoft Entra ID and a BIG-IP to enable services for SHA. The deployment and policy management is handled between the APM Guided Configuration wizard and Microsoft Graph. This integration between BIG-IP APM and Microsoft Entra ID ensures applications support identity federation, SSO, and Microsoft Entra Conditional Access, reducing administrative overhead.

+1. Navigate to **Access > Guided Configuration > Microsoft Integration** and select **Microsoft Entra Application**.

+ 

+Guided Configuration version 16.x has the Easy Button feature: admins no longer go back and forth between Microsoft Entra ID and a BIG-IP to enable services for SHA. The end-to-end deployment and policy management is handled by the APM Guided Configuration wizard and Microsoft Graph. This integration between BIG-IP APM and Microsoft Entra ID ensures applications support identity federation, SSO, and Microsoft Entra Conditional Access, without the management overhead of doing so for each app.

+description: How to hide an Enterprise application from user's experience in Microsoft Entra ID access portals or Microsoft 365 launchers.

+- A Microsoft Entra ID P1 or P2 license is required for users to request to join a self-service app and for owners to approve or deny requests. Without a Microsoft Entra ID P1 or P2 license, users can't add self-service apps.

+- **Audit your app** using **Enterprise Applications, Audit**, or access the same information from the [Microsoft Entra reporting API](../reports-monitoring/howto-configure-prerequisites-for-reporting-api.md) to integrate into your favorite tools.

+- **Get sign-in insights** using **Enterprise Applications, Sign-Ins**. Access the same information from the [Microsoft Entra reporting API.](../reports-monitoring/howto-configure-prerequisites-for-reporting-api.md)

+ :::image type="content" source="media/migrate-adfs-represent-security-policies/permit-access-to-all-users-3.png" alt-text="Screenshot shows My SaaS Apps in Microsoft Entra ID.":::

+ 

+Learn more: [Assign or remove licenses in the Microsoft Entra admin center](/azure/active-directory/fundamentals/license-users-groups)

+- **Microsoft Entra ID licensing** - SSO for pre-integrated enterprise applications is free. However, the number of objects in your directory and the features you wish to deploy may require more licenses. For a full list of license requirements, see [Microsoft Entra pricing](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing).

+ Title: Secure hybrid access with Microsoft Entra integration

+# Secure hybrid access with Microsoft Entra integration

+When users sign in to applications, they use OIDC or SAML. If the applications need to interact with Microsoft Graph or Microsoft Entra protected API, we recommend you configure them to use OICD. This configuration ensures the JWT is applied to interact with Microsoft Graph. If there's no need for applications to interact with Microsoft Graph, or Microsoft Entra protected APIs, then use SAML.

+<a name='secure-hybrid-access-through-microsoft-entra-partner-integrations'></a>

+### Secure hybrid access through Microsoft Entra ID partner integrations

+- Microsoft Entra ID P1 or P2 licenses are required for use of tenant restrictions.

+ - For OpenID Connect, the application should be multitenant and [Microsoft Entra consent framework](../develop/application-consent-experience.md) must be correctly implemented. Refer to [this](../develop/howto-convert-app-to-be-multi-tenant.md) link to convert the application into multitenant.

+- Provisioning is optional yet highly recommended. To learn more about Microsoft Entra SCIM, see [build a SCIM endpoint and configure user provisioning with Microsoft Entra ID](../app-provisioning/use-scim-to-provision-users-and-groups.md).

+In Azure Active Directory, formerly known as Microsoft Entra ID, you can use Privileged Identity Management (PIM) to manage just-in-time membership in the group or just-in-time ownership of the group.

+- [Learn about the sign-in logs](concept-all-sign-ins.md)

+Other considerations for sending Microsoft Entra logs to Azure Monitor logs are covered in the following Azure Monitor cost details articles:

+Microsoft Entra logs all sign-ins into an Azure tenant for compliance purposes. As an IT administrator, you need to know what the values in the sign-in logs mean, so that you can interpret the log values correctly.

+This article explains the values on the Basic info tab of the sign-in log.

+Microsoft Entra logs all sign-ins into an Azure tenant, which includes your internal apps and resources. As an IT administrator, you need to know what the values in the sign-in logs mean, so that you can interpret the log values correctly.

+

+When Microsoft Entra logs multiple sign-ins that are identical other than time and date, those sign-ins are from the same entity and are aggregated into a single row. A row with multiple identical sign-ins (except for date and time issued) has a value greater than one in the *# sign-ins* column. These aggregated sign-ins may also appear to have the same time stamps. The **Time aggregate** filter can set to 1 hour, 6 hours, or 24 hours. You can expand the row to see all the different sign-ins and their different time stamps.

+

+

+* A Microsoft Entra ID P1 or P2 license to view the sign-in data

+| Provisioning | Same as audit and sign-ins, plus<br>Security Operator<br>Application Administrator<br>Cloud App Administrator<br>A custom role with `provisioningLogs` permission | Premium P1 or P2 |

+| Usage and insights | Security Reader<br>Reports Reader<br> Security Administrator | Premium P1 or P2 |

+| Identity Protection* | Security Administrator<br>Security Operator<br>Security Reader<br>Global Reader | Microsoft Entra ID Free/Microsoft 365 Apps<br>Microsoft Entra ID P1 or P2 |

+Audit logs are available for features that you've licensed. To access the sign-in logs using the Microsoft Graph API, your tenant must have a Microsoft Entra ID P1 or P2 license associated with it.

+This article describes the options for downloading the provisioning logs from the Microsoft Entra admin center as well as how to analyze the logs. Error codes and special considerations are also included.

+**Error: Neither tenant is B2C or tenant doesn't have premium license**: Accessing sign-in reports requires a Microsoft Entra ID P1 or P2 license. If you see this error message while accessing sign-ins, make sure that your tenant is licensed with a Microsoft Entra ID P1 license.

+| Provisioning | Same as audit and sign-ins, plus<br>Security Operator<br>Application Administrator<br>Cloud App Administrator<br>A custom role with `provisioningLogs` permission | Premium P1 or P2 |

+| Conditional Access data in the sign-in logs | Company Administrator<br>Global Reader<br>Security Administrator<br>Security Reader<br>Conditional Access Administrator | Premium P1 or P2 |

+| Provisioning | Same as audit and sign-ins, plus<br>Security Operator<br>Application Administrator<br>Cloud App Administrator<br>A custom role with `provisioningLogs` permission | P1 or P2 |

+<a name='integrate-microsoft-entra-id-logs-with-splunk'></a>

+### Integrate Microsoft Entra logs with Splunk

+<a name='integrate-microsoft-entra-id-logs-with-sumologic'></a>

+### Integrate Microsoft Entra logs with SumoLogic

+<a name='integrate-microsoft-entra-id-logs-with-arcsight'></a>

+## Integrate Microsoft Entra logs with ArcSight

+In addition, the sign-in logs can also help you troubleshoot sign-in failures for users in your organization. In this guide, you learn how to isolate a sign-in failure in the sign-ins report, and use it to understand the root cause of the failure. Some common sign-in errors are also described.

+* A Microsoft Entra tenant with a P1 or P2 license.

+- Help you identify opportunities to implement best practices for Microsoft Entra related features.

+ 

+As an IT admin, when a user failed to sign-in, you want to resolve the issue as soon as possible to unblock your user. Due to the amount of available data in the sign-in log, locating the right information can be a challenge.

+Flagged sign-ins give the user the ability to enable flagging when an error is seen on a sign-in page and then reproduce that error. The error event then appears as ΓÇ£Flagged for ReviewΓÇ¥ in the Microsoft Entra sign-in log.

+The sign-in logs enable you to find answers to questions such as:

+- Help you identify opportunities to implement best practices for Microsoft Entra related features.

+description: Learn how to access the sign-in log and analyze a single sign-in attempt using the Microsoft Graph API.

+With the information in the Microsoft Entra sign-in logs, you can figure out what happened if a sign-in of a user failed. This quickstart shows you how to access the sign-in log using the Microsoft Graph API.

+The goal of this step is to create a record of a failed sign-in in the Microsoft Entra sign-in log.

+2. Wait for 5 minutes to ensure that you can find a record of the sign-in in the sign-in log.

+description: In this quickstart, you learn how you can use the sign-in log to determine the reason for a failed sign-in to Microsoft Entra ID.

+#Customer intent: As an IT admin, you need to know how to use the sign-in log so that you can fix sign-in issues.

+# Quickstart: Analyze sign-ins with the Microsoft Entra sign-in log

+With the information in the Microsoft Entra sign-in log, you can figure out what happened if a sign-in of a user failed. This quickstart shows how to you can locate failed sign-in using the sign-in log.

+The goal of this step is to create a record of a failed sign-in in the Microsoft Entra sign-in log.

+2. Wait for 5 minutes to ensure that you can find the event in the sign-in log.

+This section provides you with the steps to analyze a failed sign-in. Filter the sign-in log to remove all records that aren't relevant to your analysis. For example, set a filter to display only the records of a specific user. Then you can review the error details. The log details provide helpful information. You can also look up the error using the [sign-in error lookup tool](https://login.microsoftonline.com/error). This tool might provide you with information to troubleshoot a sign-in error.

+ 

+ 

+- [Programmatic access to Microsoft Entra reports](./howto-configure-prerequisites-for-reporting-api.md)

+| authProcessingDetails | Azure Active Directory Authentication Library | Contains Family, Library, and Platform information in format: "Family: Microsoft Authentication Library: ADAL.JS 1.0.0 Platform: JS" |

+With Microsoft Entra reports, you can get details on activities around all the write operations in your direction (audit logs) and authentication data (sign-in logs). Although the information is available by using the MS Graph API, now you can retrieve the same data by using the Azure AD PowerShell cmdlets for reporting.

+

+You get access to the sign-in logs using the `Get-AzureADAuditSignInLogs` cmdlet.

+

+- [Microsoft Entra reports overview](overview-reports.md).

+- [Programmatic access to Microsoft Entra reports](./howto-configure-prerequisites-for-reporting-api.md)

+* [Microsoft Entra risk detections](../identity-protection/overview-identity-protection.md)

+description: Learn how to configure a log analytics workspace in Microsoft Entra ID and run Kusto queries on your identity data.

+ 

+> | [Permissions Management Administrator](#permissions-management-administrator) | Manage all aspects of Microsoft Entra Permissions Management. | af78dc32-cf4d-46f9-ba4e-4428526346b5 |

+> | microsoft.networkAccess/allEntities/allProperties/allTasks | Manage all aspects of Microsoft Entra Network Access |

+> | microsoft.permissionsManagement/allEntities/allProperties/allTasks | Manage all aspects of Microsoft Entra Permissions Management |

+> | microsoft.networkAccess/allEntities/allProperties/read | Read all aspects of Microsoft Entra Network Access |

+> | microsoft.permissionsManagement/allEntities/allProperties/read | Read all aspects of Microsoft Entra Permissions Management |

+> | microsoft.networkAccess/allEntities/allProperties/allTasks | Manage all aspects of Microsoft Entra Network Access |

+- Manage all aspects of Microsoft Entra Permissions Management, when the service is present

+> | microsoft.permissionsManagement/allEntities/allProperties/allTasks | Manage all aspects of Microsoft Entra Permissions Management |

+> | microsoft.networkAccess/allEntities/allProperties/allTasks | Manage all aspects of Microsoft Entra Network Access |

+> | microsoft.networkAccess/allEntities/allProperties/read | Read all aspects of Microsoft Entra Network Access |

+- [Azure AD PowerShell module](https://www.powershellgallery.com/packages/AzureAD) (current version)

+| propertySet | Specific properties or aspects of the entity for which access is being granted. For example, `microsoft.directory/applications/authentication/read` grants the ability to read the reply URL, logout URL, and implicit flow property on the application object in Microsoft Entra ID.<ul><li>`allProperties` designates all properties of the entity, including privileged properties.</li><li>`standard` designates common properties, but excludes privileged ones related to `read` action. For example, `microsoft.directory/user/standard/read` includes the ability to read standard properties like public phone number and email address, but not the private secondary phone number or email address used for multifactor authentication.</li><li>`basic` designates common properties, but excludes privileged ones related to the `update` action. The set of properties that you can read may be different from what you can update. ThatΓÇÖs why there are `standard` and `basic` keywords to reflect that.</li></ul> |

+In the below example we will publish an internal web server at `http://frp-app1.superdemo.live` and enable SSO using KCD.

+ >[!NOTE]

+ >You can grant permission to the role as needed. After creating the IdP and the corresponding role, we recommend that you save the ARNs of the IdP and the role for subsequent use. You can obtain the ARNs on the IdP information page and the role information page.

+ To associate the RAM role with the Microsoft Entra user, you must create a role in Microsoft Entra ID by following these steps:

+ 1. Sign in to the [Microsoft Graph Explorer](https://developer.microsoft.com/graph/graph-explorer).

+ 1. Click **modify permissions** to obtain required permissions for creating a role.

+ 

+ 1. Select the following permissions from the list and click **Modify Permissions**, as shown in the following figure.

+ 

+ > [!NOTE]

+ > After permissions are granted, sign in to the Graph Explorer again.

+ 1. On the Graph Explorer page, select **GET** from the first drop-down list and **beta** from the second drop-down list. Then enter `https://graph.microsoft.com/beta/servicePrincipals` in the field next to the drop-down lists, and click **Run Query**.

+ 

+ > [!NOTE]

+ > If you are using multiple directories, you can enter `https://graph.microsoft.com/beta/contoso.com/servicePrincipals` in the field of the query.

+ 1. In the **Response Preview** section, extract the appRoles property from the 'Service Principal' for subsequent use.

+ 

+ > [!NOTE]

+ > You can locate the appRoles property by entering `https://graph.microsoft.com/beta/servicePrincipals/<objectID>` in the field of the query. Note that the `objectID` is the object ID you have copied from the Microsoft Entra ID **Properties** page.

+ 1. Go back to the Graph Explorer, change the method from **GET** to **PATCH**, paste the following content into the **Request Body** section, and click **Run Query**:

+ ```json

+ {

+ "appRoles": [

+ {

+ "allowedMemberTypes": [

+ "User"

+ ],

+ "description": "msiam_access",

+ "displayName": "msiam_access",

+ "id": "41be2db8-48d9-4277-8e86-f6d22d35****",

+ "isEnabled": true,

+ "origin": "Application",

+ "value": null

+ },

+ {

+ "allowedMemberTypes": [

+ "User"

+ ],

+ "description": "Admin,AzureADProd",

+ "displayName": "Admin,AzureADProd",

+ "id": "68adae10-8b6b-47e6-9142-6476078cdbce",

+ "isEnabled": true,

+ "origin": "ServicePrincipal",

+ "value": "acs:ram::187125022722****:role/aadrole,acs:ram::187125022722****:saml-provider/AAD"

+ }

+ ]

+ }

+ ```

+ > [!NOTE]

+ > The `value` is the ARNs of the IdP and the role you created in the RAM console. Here, you can add multiple roles as needed. Microsoft Entra ID will send the value of these roles as the claim value in SAML response. However, you can only add new roles after the `msiam_access` part for the patch operation. To smooth the creation process, we recommend that you use an ID generator, such as GUID Generator, to generate IDs in real time.

+ 1. After the 'Service Principal' is patched with the required role, attach the role with the Microsoft Entra user (u2) by following the steps of **Assign the Microsoft Entra test user** section of the tutorial.

+1. Select **Organization** > **Edit Settings**.

+1. Sign in to the [Azure portal](https://portal.azure.com/), and then browse to **Groups**.

+ * Enter the **SAML Profile Name**, such as `Microsoft Entra SSO`.

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).

+1. Browse to **Identity** > **Applications** > **Enterprise applications** > **New application**.

+1. In the **Add from the gallery** section, type **Brivo Onair Identity Connector** in the search box.

+ In case the Login Option will be use on GWs who participate in MEP, in order to allow smooth user experience the Name should start with `SAMLVPN_` prefix.

+ 5. In the bottom pane, go to **realms_for_blades** > **vpn**.

+Alternatively, you can also use the [Enterprise App Configuration Wizard](https://portal.office.com/AdminPortal/home?Q=Docs#/azureadappintegration). In this wizard, you can add an application to your tenant, add users/groups to the app, assign roles, as well as walk through the SSO configuration as well. [Learn more about Microsoft 365 wizards.](/microsoft-365/admin/misc/azure-ad-setup-guides)

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).

+1. Browse to **Identity** > **Applications** > **Enterprise applications** > **New application**.

+1. In the **Add from the gallery** section, type **Corptax** in the search box.

+1. Select **Corptax** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.

+1. In Step **4 ΓÇô Data received from the SAML identity provider**, DSP supports both importing from a metadata URL and importing of a metadata XML provided by Microsoft Entra ID.

+ 1. Select **App federation metadata URL** radio button, and paste the **Metadata URL** in the field from Microsoft Entra ID, and then select **IMPORT**.

+1. Sign in to your [Druva Admin Console](https://console.druva.com). Navigate to **Druva** > **inSync**.

+ 

+ :::image type="content" source="media/druva-provisioning-tutorial/manage.png" alt-text="Screenshot of the Druva admin console. Manage is highlighted, and the Manage menu is visible. In that menu, under Deployments, Users is highlighted." border="false":::

+3. Navigate to **Settings**. Click **Generate Token**.

+ :::image type="content" source="media/druva-provisioning-tutorial/settings.png" alt-text="Screenshot of a page in the Druva admin console. Settings is highlighted, and the Settings tab is open. The Generate token button is highlighted." border="false":::

+4. Copy the **Auth token** value. This value will be entered in the **Secret Token** field in the Provisioning tab of your Druva application.

+ :::image type="content" source="media/druva-provisioning-tutorial/auth.png" alt-text="Screenshot of the Create token page in the Druva admin console. A link labeled Copy Token is available for copying the Auth token value." border="false":::

+ 

+ 

+ 

+ 

+ 

+5. Under the Admin Credentials section, input `https://apis.druva.com/insync/scim` in **Tenant URL**. Input the **Auth token** value in **Secret Token**. Click **Test Connection** to ensure Microsoft Entra ID can connect to Druva. If the connection fails, ensure your Druva account has Admin permissions and try again.

+ 

+ 

+ 

+ 

+ 

+ 

+ 

+ This operation starts the initial synchronization of all users and/or groups defined in **Scope** in the **Settings** section. The initial sync takes longer to perform than subsequent syncs, which occur approximately every 40 minutes as long as the Microsoft Entra provisioning service is running. You can use the **Synchronization Details** section to monitor progress and follow links to provisioning activity report, which describes all actions performed by the Microsoft Entra provisioning service on Druva.

+ For more information on how to read the Microsoft Entra provisioning logs, see [Reporting on automatic user account provisioning](../app-provisioning/check-status-user-account-provisioning.md).

+3. Under Manage, select **App registrations** > **New registration**.

+4. Enter a display name for your application, such as `F5 BIG-IP Easy Button`.

+1. Sign in to the [Azure portal](https://portal.azure.com/) using an account with Application Administrative rights.

+2. From the left navigation pane, select the **Microsoft Entra ID** service.

+3. Under Manage, select **App registrations** > **New registration**.

+4. Enter a display name for your application, such as `F5 BIG-IP Easy Button`.

+5. Specify who can use the application > **Accounts in this organizational directory only**.

+6. Select **Register** to complete the initial app registration.

+1. Sign in to the [Azure portal](https://portal.azure.com/) using an account with Application Administrative rights.

+2. From the left navigation pane, select the **Microsoft Entra ID** service.

+3. Under Manage, select **App registrations** > **New registration**.

+4. Enter a display name for your application, such as `F5 BIG-IP Easy Button`.

+5. Specify who can use the application > **Accounts in this organizational directory only**.

+6. Select **Register** to complete the initial app registration.

+1. Sign in to the [Azure portal](https://portal.azure.com/) using an account with Application Administrative rights.

+2. From the left navigation pane, select the **Microsoft Entra ID** service.

+3. Under Manage, select **App registrations** > **New registration**.

+4. Enter a display name for your application, such as `F5 BIG-IP Easy Button`.

+5. Specify who can use the application > **Accounts in this organizational directory only**.

+6. Select **Register** to complete the initial app registration.

+1. In the Microsoft Entra admin center, navigate to **Identity** > **Groups** > **New group**.

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).

+1. Browse to **Identity** > **Applications** > **Enterprise applications** > **New application**.

+1. In the **Add from the gallery** section, type **HighGear** in the search box.

+1. Select **HighGear** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).

+1. Browse to **Identity** > **Applications** > **Enterprise applications** > **New application**.

+1. In the **Add from the gallery** section, type **InsperityExpensAble** in the search box.

+1. Select **Insperity ExpensAble** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).

+1. Browse to **Identity** > **Users** > **All users**.

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).

+1. Browse to **Identity** > **Applications** > **Enterprise applications** > **New application**.

+1. In the **Add from the gallery** section, type **Jobscience** in the search box.

+1. Select **Jobscience** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.

+1. In the Microsoft Entra admin center, navigate to **Identity** > **Users** > **All users**.

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).

+1. Browse to **Identity** > **Applications** > **Enterprise applications** > **New application**.

+1. In the **Add from the gallery** section, type **Logz.io - Microsoft Entra Integration** in the search box.

+1. Select **Logz.io - Microsoft Entra Integration** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.

+1. Rename the integration with a relevant name and click **Create**. (In the steps that follow, we used the name **AD app for a logz.io resource**)

+In **AD app for a logz.io resource | Overview** > **Properties**, copy the **Application ID** property.

+To enable the login flow to Microsoft 365 / Microsoft Entra ID, refer to [this](https://success.mediusflow.com/documentation/administration_guide/user_login_and_transfer/office365userintegration/#user-login-setup) article.

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).

+1. Browse to **Identity** > **Applications** > **Enterprise applications** > **New application**.

+1. In the **Add from the gallery** section, type **MerchLogix** in the search box.

+1. Select **MerchLogix** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).

+1. Browse to **Identity** > **Applications** > **Enterprise applications** > **New application**.

+1. In the **Add from the gallery** section, type **Miro** in the search box.

+ 1. Select **SAML**, **_not Microsoft Entra ID_**, as the connection option.

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).

+1. Browse to **Identity** > **Applications** > **Enterprise applications** > **New application**.

+1. In the **Add from the gallery** section, type **SAP Cloud Identity Services** in the search box.

+1. Under the **Admin Credentials** section, input `https://<tenantID>.accounts.ondemand.com/service/scim` in **Tenant URL**. Input the **User ID** and **Password** values retrieved earlier in **Admin Username** and **Admin Password** respectively. Click **Test Connection** to ensure Microsoft Entra ID can connect to SAP Cloud Identity Services. If the connection fails, ensure your SAP Cloud Identity Services account has Admin permissions and try again.

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).

+1. Browse to **Identity** > **Applications** > **Enterprise applications** > **New application**.

+1. In the **Add from the gallery** section, type **SignalFx** in the search box.

+1. Select **SignalFx** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.

+1. Leave the Microsoft Entra admin center open, and then open a new browser tab.

+1. Return to the Microsoft Entra admin center, and on the **SignalFx** application integration page, locate the **Manage** section, and then select **Single sign-on**.

+ 

+1. If you have Microsoft Entra ID synchronized with your on-premises AD, change **Source attribute** to **sAMAccountName**. Otherwise, leave it as Group ID.

+1. In the Microsoft Entra admin center, navigate to **Identity** > **Users** > **All users**.

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).

+1. Browse to **Identity** > **Applications** > **Enterprise applications** > **New application**.

+1. In the **Add from the gallery** section, type **TurboRater** in the search box.

+1. Select **TurboRater** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.

+1. Sign in to the [Azure portal](https://portal.azure.com/).

+1. Sign in to the [Azure portal](https://portal.azure.com/).

+1. Sign in to [Zendesk Admin Center](https://support.zendesk.com/hc/en-us/articles/4581766374554#topic_hfg_dyz_1hb).

+1. Navigate to **Apps and integrations** > **APIs** > **Zendesk APIs**.

+ b. For **Sign-out page URL** value, in the Microsoft Entra admin center, navigate to **Identity** > **App registrations**> **Endpoints**.

+ 

+1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](../roles/permissions-reference.md#cloud-application-administrator).

+1. Browse to **Identity** > **Applications** > **Enterprise applications** > **New application**.

+1. In the **Add from the gallery** section, type **Zscaler Two** in the search box.

+1. Select **Zscaler Two** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.

+| AU.L2-3.3.8<br><br>**Practice statement:** Protect audit information and audit logging tools from unauthorized access, modification, and deletion.<br><br>**Objectives:**<br>Determine if:<br>[a.] audit information is protected from unauthorized access;<br>[b.] audit information is protected from unauthorized modification;<br>[c.] audit information is protected from unauthorized deletion;<br>[d.] audit logging tools are protected from unauthorized access;<br>[e.] audit logging tools are protected from unauthorized modification; and<br>[f.] audit logging tools are protected from unauthorized deletion.<br><br>AU.L2-3.3.9<br><br>**Practice statement:** Limit management of audit logging functionality to a subset of privileged users.<br><br>**Objectives:**<br>Determine if:<br>[a.] a subset of privileged users granted access to manage audit logging functionality is defined; and<br>[b.] management of audit logging functionality is limited to the defined subset of privileged users. | Microsoft Entra logs are retained by default for 30 days. These logs are unable to modified or deleted and are only accessible to limited set of privileged roles.<br>[Sign-in logs in Microsoft Entra ID](../reports-monitoring/concept-sign-ins.md)<br>[Audit logs in Microsoft Entra ID](../reports-monitoring/concept-audit-logs.md)

+| SI.L2-3.14.7<br><br>**Practice statement:**<br><br>**Objectives:** Identify unauthorized use of organizational systems.<br>Determine if:<br>[a.] authorized use of the system is defined; and<br>[b.] unauthorized use of the system is identified. | Consolidate telemetry: Microsoft Entra logs to stream to SIEM, such as Azure Sentinel Configure device management policies via MDM (such as Microsoft Intune), Configuration Manager, or group policy objects (GPO) to require Intrusion Detection/Protection (IDS/IPS) such as Microsoft Defender for Endpoint is installed and in use. Use telemetry provided by the IDS/IPS to identify unusual activities or conditions related to inbound and outbound communications traffic or unauthorized use.<br><br>Configure Conditional Access policies to enforce device compliance.<br><br>**Conditional Access**<br>[Require device to be marked as compliant](../conditional-access/concept-conditional-access-grant.md)<br>[Require Microsoft Entra hybrid joined device](../conditional-access/concept-conditional-access-grant.md)<br><br>**InTune**<br>[Device compliance policies in Microsoft Intune](/mem/intune/protect/device-compliance-get-started)<br><br>**Defender for Endpoint**<br>[Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint?view=o365-worldwide&preserve-view=true) |

+| **AC-2 ACCOUNT MANAGEMENT**<p><p>**The Organization**<br>**(a.)** Identifies and selects the following types of information system accounts to support organizational missions/business functions: [*Assignment: organization-defined information system account types*];<p><p>**(b.)** Assigns account managers for information system accounts;<p><p>**(c.)** Establishes conditions for group and role membership;<p><p>**(d.)** Specifies authorized users of the information system, group and role membership, and access authorizations (i.e., privileges) and other attributes (as required) for each account;<p><p>**(e.)** Requires approvals by [*Assignment: organization-defined personnel or roles*] for requests to create information system accounts;<p><p>**(f.)** Creates, enables, modifies, disables, and removes information system accounts in accordance with [*Assignment: organization-defined procedures or conditions*];<p><p>**(g.)** Monitors the use of information system accounts;<p><p>**(h.)** Notifies account managers:<br>(1.) When accounts are no longer required;<br>(2.) When users are terminated or transferred; and<br>(3.) When individual information system usage or need-to-know changes;<p><p>**(i.)** Authorizes access to the information system based on:<br>(1.) A valid access authorization;<br>(2.) Intended system usage; and<br>(3.) Other attributes as required by the organization or associated missions/business functions;<p><p>**(j.)** Reviews accounts for compliance with account management requirements [*FedRAMP Assignment: monthly for privileged accessed, every six (6) months for non-privileged access*]; and<p><p>**(k.)** Establishes a process for reissuing shared/group account credentials (if deployed) when individuals are removed from the group. | **Implement account lifecycle management for customer-controlled accounts. Monitor the use of accounts and notify account managers of account lifecycle events. Review accounts for compliance with account management requirements every month for privileged access and every six months for nonprivileged access.**<p>Use Microsoft Entra ID to provision accounts from external HR systems, on-premises Active Directory, or directly in the cloud. All account lifecycle operations are audited within the Microsoft Entra audit logs. You can collect and analyze logs by using a Security Information and Event Management (SIEM) solution such as Microsoft Sentinel. Alternatively, you can use Azure Event Hubs to integrate logs with third-party SIEM solutions to enable monitoring and notification. Use Microsoft Entra entitlement management with access reviews to ensure compliance status of accounts.<p>Provision accounts<br><li>[Plan cloud HR application to Microsoft Entra user provisioning](../app-provisioning/plan-cloud-hr-provision.md)<br><li>[Microsoft Entra Connect Sync: Understand and customize synchronization](../hybrid/connect/how-to-connect-sync-whatis.md)<br><li>[Add or delete users using Microsoft Entra ID](../fundamentals/add-users.md)<p>Monitor accounts<br><li>[Audit activity reports in the Microsoft Entra admin center](../reports-monitoring/concept-audit-logs.md)<br><li>[Connect Microsoft Entra data to Microsoft Sentinel](../../sentinel/connect-azure-active-directory.md) <br><li>[Tutorial: Stream logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md)<p>Review accounts<br><li>[What is Microsoft Entra entitlement management?](../governance/entitlement-management-overview.md)<br><li>[Create an access review of an access package in Microsoft Entra entitlement management](../governance/entitlement-management-access-reviews-create.md)<br><li>[Review access of an access package in Microsoft Entra entitlement management](../governance/entitlement-management-access-reviews-review-access.md)<p>Resources<br><li>[Administrator role permissions in Microsoft Entra ID](../roles/permissions-reference.md)<br><li>[Dynamic Groups in Microsoft Entra ID](../enterprise-users/groups-create-rule.md)<p>&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;<p> |

+| **AC-2(1)**<br>The organization employs automated mechanisms to support the management of information system accounts.| **Employ automated mechanisms to support management of customer-controlled accounts.**<p>Configure automated provisioning of customer-controlled accounts from external HR systems or on-premises Active Directory. For applications that support application provisioning, configure Microsoft Entra ID to automatically create user identities and roles in cloud software as a solution (SaaS) applications that users need access to. In addition to creating user identities, automatic provisioning includes the maintenance and removal of user identities as status or roles change. To ease monitoring of account usage, you can stream Microsoft Entra ID Protection logs, which show risky users, risky sign-ins, and risk detections, and audit logs directly into Microsoft Sentinel or Event Hubs.<p>Provision<br><li>[Plan cloud HR application to Microsoft Entra user provisioning](../app-provisioning/plan-cloud-hr-provision.md)<br><li>[Microsoft Entra Connect Sync: Understand and customize synchronization](../hybrid/connect/how-to-connect-sync-whatis.md)<br><li>[What is automated SaaS app user provisioning in Microsoft Entra ID?](../app-provisioning/user-provisioning.md)<br><li>[SaaS app integration tutorials for use with Microsoft Entra ID](../saas-apps/tutorial-list.md)<p>Monitor and audit<br><li>[Investigate risk](../identity-protection/howto-identity-protection-investigate-risk.md)<br><li>[Audit activity reports in the Microsoft Entra admin center](../reports-monitoring/concept-audit-logs.md)<br><li>[What is Microsoft Sentinel?](../../sentinel/overview.md)<br><li>[Microsoft Sentinel: Connect data from Microsoft Entra ID](../../sentinel/connect-azure-active-directory.md)<br><li>[Tutorial: Stream Microsoft Entra logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md)|

+| **AC-2(4)**<br>The information system automatically audits account creation, modification, enabling, disabling, and removal actions, and notifies [*FedRAMP Assignment: organization and/or service provider system owner*]. | **Implement an automated audit and notification system for the lifecycle of managing customer-controlled accounts.**<p>All account lifecycle operations, such as account creation, modification, enabling, disabling, and removal actions, are audited within the Azure audit logs. You can stream the logs directly into Microsoft Sentinel or Event Hubs to help with notification.<p>Audit<br><li>[Audit activity reports in the Microsoft Entra admin center](../reports-monitoring/concept-audit-logs.md)<br><li>[Microsoft Sentinel: Connect data from Microsoft Entra ID](../../sentinel/connect-azure-active-directory.md)<P>Notification<br><li>[What is Microsoft Sentinel?](../../sentinel/overview.md)<br><li>[Tutorial: Stream Microsoft Entra logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

+| **AC-2(7)**<p><p>**The organization:**<br>**(a.)** Establishes and administers privileged user accounts in accordance with a role-based access scheme that organizes allowed information system access and privileges into roles;<br>**(b)** Monitors privileged role assignments; and<br>**(c)** Takes [*FedRAMP Assignment: disables/revokes access within an organization-specified timeframe*] when privileged role assignments are no longer appropriate. | **Administer and monitor privileged role assignments by following a role-based access scheme for customer-controlled accounts. Disable or revoke privilege access for accounts when no longer appropriate.**<p>Implement Microsoft Entra Privileged Identity Management with access reviews for privileged roles in Microsoft Entra ID to monitor role assignments and remove role assignments when no longer appropriate. You can stream audit logs directly into Microsoft Sentinel or Event Hubs to help with monitoring.<p>Administer<br><li>[What is Microsoft Entra Privileged Identity Management?](../privileged-identity-management/pim-configure.md)<br><li>[Activation maximum duration](../privileged-identity-management/pim-how-to-change-default-settings.md?tabs=new)<p>Monitor<br><li>[Create an access review of Microsoft Entra roles in Privileged Identity Management](../privileged-identity-management/pim-create-roles-and-resource-roles-review.md)<br><li>[View audit history for Microsoft Entra roles in Privileged Identity Management](../privileged-identity-management/pim-how-to-use-audit-log.md?tabs=new)<br><li>[Audit activity reports in the Microsoft Entra admin center](../reports-monitoring/concept-audit-logs.md)<br><li>[What is Microsoft Sentinel?](../../sentinel/overview.md)<br><li>[Connect data from Microsoft Entra ID](../../sentinel/connect-azure-active-directory.md)<br><li>[Tutorial: Stream Microsoft Entra logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

+| **AC-2(12)**<p><p>**The organization:**<br>**(a)** Monitors information system accounts for [*Assignment: organization-defined atypical use*]; and<br>**(b)** Reports atypical usage of information system accounts to [*FedRAMP Assignment: at a minimum, the ISSO and/or similar role within the organization*].<p><p>**AC-2 (12) (a) and AC-2 (12) (b) Additional FedRAMP Requirements and Guidance:**<br> Required for privileged accounts. | **Monitor and report customer-controlled accounts with privileged access for atypical usage.**<p>For help with monitoring of atypical usage, you can stream Identity Protection logs, which show risky users, risky sign-ins, and risk detections, and audit logs, which help with correlation with privilege assignment, directly into a SIEM solution such as Microsoft Sentinel. You can also use Event Hubs to integrate logs with third-party SIEM solutions.<p>Identity protection<br><li>[What is Microsoft Entra ID Protection?](../identity-protection/overview-identity-protection.md)<br><li>[Investigate risk](../identity-protection/howto-identity-protection-investigate-risk.md)<br><li>[Microsoft Entra ID Protection notifications](../identity-protection/howto-identity-protection-configure-notifications.md)<p>Monitor accounts<br><li>[What is Microsoft Sentinel?](../../sentinel/overview.md)<br><li>[Audit activity reports in the Microsoft Entra admin center](../reports-monitoring/concept-audit-logs.md)<br><li>[Connect Microsoft Entra data to Microsoft Sentinel](../../sentinel/connect-azure-active-directory.md) <br><li>[Tutorial: Stream logs to an Azure event hub](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

+| **IA-2(12)*<br>The information system accepts and electronically verifies Personal Identity Verification (PIV) credentials.<br><br>**IA-2 (12) Additional FedRAMP Requirements and Guidance:**<br>**Guidance:** Include Common Access Card (CAC), that is, the DoD technical implementation of PIV/FIPS 201/HSPD-12. | **Accept and verify personal identity verification (PIV) credentials. This control isn't applicable if the customer doesn't deploy PIV credentials.**<p>Configure federated authentication by using Active Directory Federation Services (AD FS) to accept PIV (certificate authentication) as both primary and multifactor authentication methods and issue the multifactor authentication (MultipleAuthN) claim when PIV is used. Configure the federated domain in Microsoft Entra ID with setting **federatedIdpMfaBehavior** to `enforceMfaByFederatedIdp` (recommended) or SupportsMfa to `$True` to direct multifactor authentication requests originating at Microsoft Entra ID to Active Directory Federation Services. Alternatively, you can use PIV for sign-in on Windows devices and later use integrated Windows authentication along with seamless single sign-on. Windows Server and client verify certificates by default when used for authentication. <p>Resources<br><li>[What is federation with Microsoft Entra ID?](../hybrid/connect/whatis-fed.md)<br> <li>[Configure AD FS support for user certificate authentication](/windows-server/identity/ad-fs/operations/configure-user-certificate-authentication)<br> <li>[Configure authentication policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies)<br> <li>[Secure resources with Microsoft Entra multifactor authentication and AD FS](../authentication/howto-mfa-adfs.md)<br><li>[New-MgDomainFederationConfiguration](/powershell/module/microsoft.graph.identity.directorymanagement/new-mgdomainfederationconfiguration)<br> <li>[Microsoft Entra Connect: Seamless single sign-on](../hybrid/connect/how-to-connect-sso.md) |

+| **AU-2 Audit Events**<br>**The organization:**<br>**(a.)** Determines that the information system is capable of auditing the following events: [*FedRAMP Assignment: [Successful and unsuccessful account logon events, account management events, object access, policy change, privilege functions, process tracking, and system events. For Web applications: all administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and permission changes*];<br>**(b.)** Coordinates the security audit function with other organizational entities requiring audit-related information to enhance mutual support and to help guide the selection of auditable events;<br>**(c.)** Provides a rationale for why the auditable events are deemed to be adequate to support after-the-fact investigations of security incidents; and<br>**(d.)** Determines that the following events are to be audited in the information system: [*FedRAMP Assignment: organization-defined subset of the auditable events defined in AU-2 a. to be audited continually for each identified event*].<br><br>**AU-2 Additional FedRAMP Requirements and Guidance:**<br>**Requirement:** Coordination between service provider and consumer shall be documented and accepted by the JAB/AO.<br><br>**AU-3 Content and Audit Records**<br>The information system generates audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event.<br><br>**AU-3(1)**<br>The information system generates audit records containing the following additional information: [*FedRAMP Assignment: organization-defined additional, more detailed information*].<br><br>**AU-3 (1) Additional FedRAMP Requirements and Guidance:**<br>**Requirement:** The service provider defines audit record types [*FedRAMP Assignment: session, connection, transaction, or activity duration; for client-server transactions, the number of bytes received and bytes sent; additional informational messages to diagnose or identify the event; characteristics that describe or identify the object or resource being acted upon; individual identities of group account users; full-text of privileged commands*]. The audit record types are approved and accepted by the JAB/AO.<br>**Guidance:** For client-server transactions, the number of bytes sent and received gives bidirectional transfer information that can be helpful during an investigation or inquiry.<br><br>**AU-3(2)**<br>The information system provides centralized management and configuration of the content to be captured in audit records generated by [*FedRAMP Assignment: all network, data storage, and computing devices*]. | Ensure the system is capable of auditing events defined in AU-2 Part a. Coordinate with other entities within the organization's subset of auditable events to support after-the-fact investigations. Implement centralized management of audit records.<p>All account lifecycle operations (account creation, modification, enabling, disabling, and removal actions) are audited within the Microsoft Entra audit logs. All authentication and authorization events are audited within Microsoft Entra sign-in logs, and any detected risks are audited in the Identity Protection logs. You can stream each of these logs directly into a security information and event management (SIEM) solution such as Microsoft Sentinel. Alternatively, use Azure Event Hubs to integrate logs with third-party SIEM solutions.<p>Audit events<li> [Audit activity reports in the Microsoft Entra admin center](../reports-monitoring/concept-audit-logs.md)<li> [Sign-in activity reports in the Microsoft Entra admin center](../reports-monitoring/concept-sign-ins.md)<li>[How To: Investigate risk](../identity-protection/howto-identity-protection-investigate-risk.md)<p>SIEM integrations<li> [Microsoft Sentinel : Connect data from Microsoft Entra ID](../../sentinel/connect-azure-active-directory.md)<li>[Stream to Azure event hub and other SIEMs](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

+| **IR-4 Incident Handling**<br>**The organization:**<br>**(a.)** Implements an incident handling capability for security incidents that includes preparation, detection and analysis, containment, eradication, and recovery;<br>**(b.)** Coordinates incident handling activities with contingency planning activities; and<br>**(c.)** Incorporates lessons learned from ongoing incident handling activities into incident response procedures, training, and testing/exercises, and implements the resulting changes accordingly.<br>**IR-4 Additional FedRAMP Requirements and Guidance:**<br>**Requirement:** The service provider ensures that individuals conducting incident handling meet personnel security requirements commensurate with the criticality/sensitivity of the information being processed, stored, and transmitted by the information system.<br><br>**IR-04(1)**<br>The organization employs automated mechanisms to support the incident handling process.<br><br>**IR-04(2)**<br>The organization includes dynamic reconfiguration of [*FedRAMP Assignment: all network, data storage, and computing devices*] as part of the incident response capability.<br><br>**IR-04(3)**<br>The organization identifies [*Assignment: organization-defined classes of incidents*] and [*Assignment: organization-defined actions to take in response to classes of incident*] to ensure continuation of organizational missions and business functions.<br><br>**IR-04(4)**<br>The organization correlates incident information and individual incident responses to achieve an organization-wide perspective on incident awareness and response.<br><br>**IR-04(6)**<br>The organization implements incident handling capability for insider threats.<br><br>**IR-04(8)**<br>The organization implements incident handling capability for insider threats.<br>The organization coordinates with [*FedRAMP Assignment: external organizations including consumer incident responders and network defenders and the appropriate consumer incident response team (CIRT)/ Computer Emergency Response Team (CERT) (such as US-CERT, DoD CERT, IC CERT)*] to correlate and share [*Assignment: organization-defined incident information*] to achieve a cross- organization perspective on incident awareness and more effective incident responses.<br><br>**IR-05 Incident Monitoring**<br>The organization tracks and documents information system security incidents.<br><br>**IR-05(1)**<br>The organization employs automated mechanisms to assist in the tracking of security incidents and in the collection and analysis of incident information. | Implement incident handling and monitoring capabilities. This includes Automated Incident Handling, Dynamic Reconfiguration, Continuity of Operations, Information Correlation, Insider Threats, Correlation with External Organizations, and Incident Monitoring and Automated Tracking. <p>The audit logs record all configuration changes. Authentication and authorization events are audited within the sign-in logs, and any detected risks are audited in the Identity Protection logs. You can stream each of these logs directly into a SIEM solution, such as Microsoft Sentinel. Alternatively, use Azure Event Hubs to integrate logs with third-party SIEM solutions. Automate dynamic reconfiguration based on events in the SIEM by using Microsoft Graph PowerShell.<p>Audit events<br><li>[Audit activity reports in the Microsoft Entra admin center](../reports-monitoring/concept-audit-logs.md)<li>[Sign-in activity reports in the Microsoft Entra admin center](../reports-monitoring/concept-sign-ins.md)<li>[How To: Investigate risk](../identity-protection/howto-identity-protection-investigate-risk.md)<p>SIEM integrations<li>[Microsoft Sentinel : Connect data from Microsoft Entra ID](../../sentinel/connect-azure-active-directory.md)<li>[Stream to Azure event hub and other SIEMs](../reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md)|

+| **SI-4 Information System Monitoring**<br>**The organization:**<br>**(a.)** Monitors the information system to detect:<br>**(1.)** Attacks and indicators of potential attacks in accordance with [*Assignment: organization-defined monitoring objectives*]; and<br>**(2.)** Unauthorized local, network, and remote connections;<br>**(b.)** Identifies unauthorized use of the information system through [*Assignment: organization-defined techniques and methods*];<br>**(c.)** Deploys monitoring devices (i) strategically within the information system to collect organization-determined essential information; and (ii) at ad hoc locations within the system to track specific types of transactions of interest to the organization;<br>**(d.)** Protects information obtained from intrusion-monitoring tools from unauthorized access, modification, and deletion;<br>**(e.)** Heightens the level of information system monitoring activity whenever there is an indication of increased risk to organizational operations and assets, individuals, other organizations, or the Nation based on law enforcement information, intelligence information, or other credible sources of information;<br>**(f.)** Obtains legal opinion with regard to information system monitoring activities in accordance with applicable federal laws, Executive Orders, directives, policies, or regulations; and<br>**(d.)** Provides [*Assignment: organization-defined information system monitoring information*] to [*Assignment: organization-defined personnel or roles] [Selection (one or more): as needed; [Assignment: organization-defined frequency]*].<br>**SI-4 Additional FedRAMP Requirements and Guidance:**<br>**Guidance:** See US-CERT Incident Response Reporting Guidelines.<br><br>**SI-04(1)**<br> The organization connects and configures individual intrusion detection tools into an information system-wide intrusion detection system. | Implement information system-wide monitoring, and the intrusion detection system. <p>Include all Microsoft Entra logs (Audit, Sign-in, Identity Protection) within the information system monitoring solution. <p>Stream Microsoft Entra logs into a SIEM solution (see IA-04). &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|

+| Set up hybrid to utilize Microsoft Entra ID | [Microsoft Entra Connect](../hybrid/how-to-connect-install-express.md) integrates on-premises directories with Microsoft Entra ID, supporting the use of single identities to access on-premises applications and cloud services such as Microsoft 365. It orchestrates synchronization between Active Directory (AD) and Microsoft Entra ID. To get started with Microsoft Entra Connect review the prerequisites, making note of the server requirements and how to prepare your Microsoft Entra tenant for management.</br>[Microsoft Entra Connect sync](../cloud-sync/tutorial-pilot-aadc-aadccp.md) is a provisioning agent that is managed on the cloud. The provisioning agent supports synchronizing to Microsoft Entra ID from a multi-forest disconnected AD environment. Lightweight agents are installed and can be used with Microsoft Entra Connect.</br>We recommend you use **Password Hash Sync** to help reduce the number of passwords and protect against leaked credential detection.|

+| Provision user accounts |[Microsoft Entra ID](../fundamentals/add-users-azure-active-directory.md) is a cloud-based identity and access management service that provides single sign-on, multi-factor authentication and Conditional Access to guard against security attacks. To create a user account, sign in into the Microsoft Entra admin center as a **User Admin** and create a new account by navigating to [All users](../fundamentals/add-users-azure-active-directory.md) in the menu. </br> Microsoft Entra ID provides support for automated user provisioning for systems and applications. Capabilities include creating, updating, and deleting a user account. Automated provisioning creates new accounts in the right systems for new people when they join a team in an organization, and automated deprovisioning deactivates accounts when people leave the team. Configure provisioning by navigating to the Microsoft Entra admin center and selecting [enterprise applications](../app-provisioning/configure-automatic-user-provisioning-portal.md) to add and manage the app settings. |

+|HR-driven provisioning | [Integrating Microsoft Entra account provisioning](../app-provisioning/plan-cloud-hr-provision.md) within a Human Resources (HR) system reduces the risk of excessive access and access no longer required. The HR system becomes the start-of-authority, for newly created accounts, extending the capabilities to account deprovisioning. Automation manages the identity lifecycle and reduces the risk of over-provisioning. This approach follows the security best practice of providing least privilege access. |

+| Create lifecycle workflows | [Lifecycle workflows](../governance/understanding-lifecycle-workflows.md) provide identity governance for automating the joiner/mover/leaver (JML) lifecycle. Lifecycle workflows centralize the workflow process by either using the [built-in templates](../governance/lifecycle-workflow-templates.md) or creating your own custom workflows. this practice helps reduce or potentially remove manual tasks for organizational JML strategy requirements. Within the Azure portal, navigate to **Identity Governance** in the Microsoft Entra menu to review or configure tasks that fit within your organizational requirements. |

+| Manage privileged identities | [Microsoft Entra Privileged Identity Management (PIM)](../privileged-identity-management/pim-configure.md) enables management, control, and the ability to monitor access. You provide access when it's needed, on a time-based and approval-based role activation. This approach limits the risk of excessive, unnecessary, or misused access permissions. |

+| Monitoring and alerting | [Identity Protection](../identity-protection/overview-identity-protection.md) provides a consolidated view into risk events and potential vulnerabilities that could affect an organizationΓÇÖs identities. Enabling the protection applies the existing Microsoft Entra anomaly detection capabilities and introduces risk event types that detect anomalies in real-time. Through the Microsoft Entra admin center, you can sign-in, audit, and review provisioning logs.</br>The logs can be [downloaded, archived, and streamed](../reports-monitoring/howto-download-logs.md) to your security information and event management (SIEM) tool. Microsoft Entra logs can be located in the monitoring section of the Microsoft Entra menu. The logs can also be sent to [Azure Monitor](../reports-monitoring/concept-activity-logs-azure-monitor.md) using an Azure log analytics workspace where you can set up alerting on the connected data. </br> Microsoft Entra ID uniquely identifies users via the [ID property](/graph/api/resources/user?view=graph-rest-1.0&preserve-view=true) on the respective directory object. This approach enables you to filter for specific identities in the log files. |

+| Ensure resiliency | [Resiliency](/azure/architecture/framework/resiliency/overview) helps to maintain service levels when there's disruption to business operations and core IT services. The capability spans services, data, Microsoft Entra ID, and Active Directory considerations. Determining a strategic [resiliency plan](/azure/architecture/checklist/resiliency-per-service) to include what systems and data rely on Microsoft Entra and hybrid environments. [Microsoft 365 resiliency](/compliance/assurance/assurance-sharepoint-onedrive-data-resiliency) covering the core services, which include Exchange, SharePoint, and OneDrive to protect against data corruption and applying resiliency data points to protect ePHI content. |

+| Enable logging and monitoring | </br>[Logging and monitoring](/security/benchmark/azure/security-control-logging-monitoring) are essential to securing an environment. The data supports investigations and helps detect potential threats by identifying unusual patterns. Enable logging and monitoring of services to reduce the risk of unauthorized access.</br>We recommend you monitor [Microsoft Entra activity logs](../reports-monitoring/howto-access-activity-logs.md). |

+Microsoft Entra ID meets identity-related practice requirements for implementing HIPAA safeguards. To be HIPAA compliant, implement the safeguards using this guidance along with any other configurations or processes needed.

+We recommend you integrate Microsoft Entra logs with Microsoft Sentinel. Configure a connector to ingest Microsoft Entra tenant logs.

+* [What is Microsoft Entra monitoring?](../reports-monitoring/overview-monitoring.md)

+ * Use analytics rule templates to hunt for threats and alerts in your Microsoft Entra logs. Your security or operation analyst can triage and remediate threats.

+* Archive Microsoft Entra logs in security information and event management (SIEM) systems

+|**10.4.1** The following audit logs are reviewed at least once daily: </br> All security events. </br> Logs of all system components that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD). Logs of all critical system components. </br> Logs of all servers and system components that perform security functions (for example, network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers).|Include Microsoft Entra logs in this process.|

+|**10.4.1.1** Automated mechanisms are used to perform audit log reviews.|Include Microsoft Entra logs in this process. Configure automated actions and alerting when Microsoft Entra logs are integrated with Azure Monitor. [Deploy Azure Monitor: Alerts and automated actions](/azure/azure-monitor/best-practices-alerts)|

+|**10.5.1** Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis.|Integrate with Azure Monitor and export the logs for long term archival. [Integrate Microsoft Entra logs with Azure Monitor logs](../reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md) </br> Learn about Microsoft Entra logs data retention policy. [Microsoft Entra data retention](../reports-monitoring/reference-reports-data-retention.md)|

+|**11.3.1** Internal vulnerability scans are performed as follows: </br> At least once every three months. </br> High-risk and critical vulnerabilities (per the entityΓÇÖs vulnerability risk rankings defined at Requirement 6.3.1) are resolved. </br> Rescans are performed that confirm all high-risk and critical vulnerabilities (as noted) have been resolved. </br> Scan tool is kept up to date with latest vulnerability information. </br> Scans are performed by qualified personnel and organizational independence of the tester exists.|Include servers that support Microsoft Entra hybrid capabilities. For example, Microsoft Entra Connect, Application proxy connectors, etc. as part of internal vulnerability scans. </br> Organizations using federated authentication: review and address federation system infrastructure vulnerabilities. [What is federation with Microsoft Entra ID?](../hybrid/connect/whatis-fed.md) </br> Review and mitigate risk detections reported by Microsoft Entra ID Protection. Integrate the signals with a SIEM solution to integrate more with remediation workflows or automation. [Risk types and detection](../identity-protection/concept-identity-protection-risks.md) </br> Run the Microsoft Entra assessment tool regularly and address findings. [`AzureADAssessment`](https://github.com/AzureAD/AzureADAssessment) </br> [Security operations for infrastructure](../architecture/security-operations-infrastructure.md) </br> [Integrate Microsoft Entra logs with Azure Monitor logs](../reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md)|

+|**11.3.1.1** All other applicable vulnerabilities (those not ranked as high-risk or critical per the entityΓÇÖs vulnerability risk rankings defined at Requirement 6.3.1) are managed as follows: </br> Addressed based on the risk defined in the entityΓÇÖs targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. </br> Rescans are conducted as needed.|Include servers that support Microsoft Entra hybrid capabilities. For example, Microsoft Entra Connect, Application proxy connectors, etc. as part of internal vulnerability scans. </br> Organizations using federated authentication: review and address federation system infrastructure vulnerabilities. [What is federation with Microsoft Entra ID?](../hybrid/connect/whatis-fed.md) </br> Review and mitigate risk detections reported by Microsoft Entra ID Protection. Integrate the signals with a SIEM solution to integrate more with remediation workflows or automation. [Risk types and detection](../identity-protection/concept-identity-protection-risks.md) </br> Run the Microsoft Entra assessment tool regularly and address findings. [`AzureAD/AzureADAssessment`](https://github.com/AzureAD/AzureADAssessment) </br> [Security operations for infrastructure](../architecture/security-operations-infrastructure.md) </br> [Integrate Microsoft Entra logs with Azure Monitor logs](../reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md)|

+|**11.3.1.2** Internal vulnerability scans are performed via authenticated scanning as follows: </br> Systems that are unable to accept credentials for authenticated scanning are documented. </br> Sufficient privileges are used for those systems that accept credentials for scanning. </br> If accounts used for authenticated scanning can be used for interactive login, they're managed in accordance with Requirement 8.2.2.|Include servers that support Microsoft Entra hybrid capabilities. For example, Microsoft Entra Connect, Application proxy connectors, etc. as part of internal vulnerability scans. </br> Organizations using federated authentication: review and address federation system infrastructure vulnerabilities. [What is federation with Microsoft Entra ID?](../hybrid/connect/whatis-fed.md) </br> Review and mitigate risk detections reported by Microsoft Entra ID Protection. Integrate the signals with a SIEM solution to integrate more with remediation workflows or automation. [Risk types and detection](../identity-protection/concept-identity-protection-risks.md) </br> Run the Microsoft Entra assessment tool regularly and address findings. [`AzureADAssessment`](https://github.com/AzureAD/AzureADAssessment) </br> [Security operations for infrastructure](../architecture/security-operations-infrastructure.md) </br> [Integrate Microsoft Entra logs with Azure Monitor logs](../reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md)|

+|**11.3.1.3** Internal vulnerability scans are performed after any significant change as follows: </br> High-risk and critical vulnerabilities (per the entityΓÇÖs vulnerability risk rankings defined at Requirement 6.3.1) are resolved. </br> Rescans are conducted as needed. </br> Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV)).|Include servers that support Microsoft Entra hybrid capabilities. For example, Microsoft Entra Connect, Application proxy connectors, etc. as part of internal vulnerability scans. </br> Organizations using federated authentication: review and address federation system infrastructure vulnerabilities. [What is federation with Microsoft Entra ID?](../hybrid/connect/whatis-fed.md) </br> Review and mitigate risk detections reported by Microsoft Entra ID Protection. Integrate the signals with a SIEM solution to integrate more with remediation workflows or automation. [Risk types and detection](../identity-protection/concept-identity-protection-risks.md) </br> Run the Microsoft Entra assessment tool regularly and address findings. [`AzureADAssessment`](https://github.com/AzureAD/AzureADAssessment) </br> [Security operations for infrastructure](../architecture/security-operations-infrastructure.md) </br> [Integrate Microsoft Entra logs with Azure Monitor logs](../reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md)|

+| Workload identity federation | Use workloads tested by external Identity Providers (IdPs) to access Microsoft Entra protected resources | Yes | Yes |

+#Customer intent: As a developer, I want workload identities so I can authenticate with Microsoft Entra ID and access Microsoft Entra protected resources.

+- Access Microsoft Entra protected resources without needing to manage secrets for workloads that run on Azure using [managed identities](../managed-identities-azure-resources/overview.md?toc=/azure/active-directory/workload-identities?toc=/azure/active-directory/workload-identities/toc.json&bc=/azure/active-directory/workload-identities/breadcrumb/toc.json).

+- Access Microsoft Entra protected resources without needing to manage secrets using [workload identity federation](workload-identity-federation.md) for supported scenarios such as GitHub Actions, workloads running on Kubernetes, or workloads running in compute platforms outside of Azure.

+description: Learn how to use a built-in Azure Policy to block workload identity federation on user-assigned managed identities. Govern the use of federated identity credentials on managed identities so that no one can access Microsoft Entra protected resources from external workloads.

+This article describes how to block the creation of federated identity credentials on user-assigned managed identities by using Azure Policy. By blocking the creation of federated identity credentials, you can block everyone from using [workload identity federation](workload-identity-federation.md) to access Microsoft Entra protected resources. [Azure Policy](../../governance/policy/overview.md) helps enforce certain business rules on your Azure resources and assess compliance of those resources.

+description: Set up a trust relationship between a user-assigned managed identity in Microsoft Entra ID and an external identity provider. This allows a software workload outside of Azure to access Microsoft Entra protected resources without using secrets or certificates.

+#Customer intent: As an application developer, I want to configure a federated credential on a user-assigned managed identity so I can create a trust relationship with an external identity provider and use workload identity federation to access Microsoft Entra protected resources without managing secrets.

+After you configure your user-assigned managed identity to trust an external IdP, configure your external software workload to exchange a token from the external IdP for an access token from Microsoft identity platform. The external workload uses the access token to access Microsoft Entra protected resources without needing to manage secrets (in supported scenarios). To learn more about the token exchange workflow, read about [workload identity federation](workload-identity-federation.md).

+description: Set up a trust relationship between an app in Microsoft Entra ID and an external identity provider. This allows a software workload outside of Azure to access Microsoft Entra protected resources without using secrets or certificates.

+#Customer intent: As an application developer, I want to configure a federated credential on an app registration so I can create a trust relationship with an external identity provider and use workload identity federation to access Microsoft Entra protected resources without managing secrets.

+You can then configure an external software workload to exchange a token from the external IdP for an access token from Microsoft identity platform. The external workload can access Microsoft Entra protected resources without needing to manage secrets (in supported scenarios). To learn more about the token exchange workflow, read about [workload identity federation](workload-identity-federation.md).

+description: Use workload identity federation to grant workloads running outside of Azure access to Microsoft Entra protected resources without using secrets or certificates. This eliminates the need for developers to store and maintain long-lived secrets or certificates outside of Azure.

+#Customer intent: As a developer, I want to learn about workload identity federation so that I can securely access Microsoft Entra protected resources from external apps and services without needing to manage secrets.

+This article provides an overview of workload identity federation for software workloads. Using workload identity federation allows you to access Microsoft Entra protected resources without needing to manage secrets (for supported scenarios).

+Typically, a software workload (such as an application, service, script, or container-based application) needs an identity in order to authenticate and access resources or communicate with other services. When these workloads run on Azure, you can use [managed identities](../managed-identities-azure-resources/overview.md) and the Azure platform manages the credentials for you. You can only use managed identities, however, for software workloads running in Azure. For a software workload running outside of Azure, you need to use application credentials (a secret or certificate) to access Microsoft Entra protected resources (such as Azure, Microsoft Graph, Microsoft 365, or third-party resources). These credentials pose a security risk and have to be stored securely and rotated regularly. You also run the risk of service downtime if the credentials expire.

+You use workload identity federation to configure a [user-assigned managed identity](../managed-identities-azure-resources/how-manage-user-assigned-managed-identities.md) or [app registration](../develop/app-objects-and-service-principals.md) in Microsoft Entra ID to trust tokens from an external identity provider (IdP), such as GitHub or Google. The user-assigned managed identity or app registration in Microsoft Entra ID becomes an identity for software workloads running, for example, in on-premises Kubernetes or GitHub Actions workflows. Once that trust relationship is created, your external software workload exchanges trusted tokens from the external IdP for access tokens from Microsoft identity platform. Your software workload uses that access token to access the Microsoft Entra protected resources to which the workload has been granted access. You eliminate the maintenance burden of manually managing credentials and eliminates the risk of leaking secrets or having certificates expire.

+The following scenarios are supported for accessing Microsoft Entra protected resources using workload identity federation:

+- Google Cloud. First, configure a trust relationship between your user-assigned managed identity or app in Microsoft Entra ID and an identity in Google Cloud. Then configure your software workload running in Google Cloud to get an access token from Microsoft identity provider and access Microsoft Entra protected resources. See [Access Microsoft Entra protected resources from an app in Google Cloud](https://blog.identitydigest.com/azuread-federate-gcp/).

+- Workloads running in Amazon Web Services (AWS). First, configure a trust relationship between your user-assigned managed identity or app in Microsoft Entra ID and an identity in Amazon Cognito. Then configure your software workload running in AWS to get an access token from Microsoft identity provider and access Microsoft Entra protected resources. See [Workload identity federation with AWS](https://blog.identitydigest.com/azuread-federate-aws/).

+- SPIFFE and SPIRE are a set of platform agnostic, open-source standards for providing identities to your software workloads deployed across platforms and cloud vendors. First, configure a trust relationship between your user-assigned managed identity or app in Microsoft Entra ID and a SPIFFE ID for an external workload. Then configure your external software workload to get an access token from Microsoft identity provider and access Microsoft Entra protected resources. See [Workload identity federation with SPIFFE and SPIRE](https://blog.identitydigest.com/azuread-federate-spiffe/).

+- On a user-assigned managed identity through the [Microsoft Entra admin center](https://entra.microsoft.com), Azure CLI, Azure PowerShell, Azure SDK, and Azure Resource Manager (ARM) templates. The external workload uses the access token to access Microsoft Entra protected resources without needing to manage secrets (in supported scenarios). The [steps for configuring the trust relationship](workload-identity-federation-create-trust-user-assigned-managed-identity.md) will differ, depending on the scenario and external IdP.

+The workflow for exchanging an external token for an access token is the same, however, for all scenarios. The following diagram shows the general workflow of a workload exchanging an external token for an access token and then accessing Microsoft Entra protected resources.

+1. The external workload accesses Microsoft Entra protected resources using the access token from Microsoft identity platform. A GitHub Actions workflow, for example, uses the access token to publish a web app to Azure App Service.

+- Read the [workload identity overview](../../aks/workload-identity-overview.md) to learn how to configure a Kubernetes workload to get an access token from Microsoft identity provider and access Microsoft Entra protected resources.

+- Read the [GitHub Actions documentation](https://docs.github.com/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure) to learn more about configuring your GitHub Actions workflow to get an access token from Microsoft identity provider and access Microsoft Entra protected resources.

+This guide shows you how to scale up from existing PersonGroup and FaceList objects to LargePersonGroup and LargeFaceList objects, respectively. PersonGroups can hold up to 1000 persons in the free tier and 10,000 in the paid tier, while LargePersonGroups can hold up to one million persons in the paid tier.

+> [!IMPORTANT]

+> The newer data structure **PersonDirectory** is recommended for new development. It can hold up to 75 million identities and does not require manual training. For more information, see the [PersonDirectory guide](./use-persondirectory.md).

+> [Try Vision Studio for Face](https://portal.vision.cognitive.azure.com/gallery/face)

+You can try out Face detection quickly and easily in your browser using Vision Studio.

+> [!div class="nextstepaction"]

+> [Try Vision Studio for Face](https://portal.vision.cognitive.azure.com/gallery/face)

+Quota increase requests can be submitted from the [Quotas](./how-to/quota.md) page of Azure OpenAI Studio. Please note that due to overwhelming demand, quota increase requests are being accepted and will be filled in the order they are received. Priority will be given to customers who generate traffic that consumes the existing quota allocation, and your request may be denied if this condition is not met.

+ <voice name='\''en-US-JennyNeural'\''>

+ "<speak version='1.0' xml:lang='en-US'>\n\t\t\t\t<voice name='en-US-JennyNeural'>\n\t\t\t\t\tThe rainbow has seven colors.\n\t\t\t\t</voice>\n\t\t\t</speak>"

+Azure AI services provide each container with a common configuration framework. You can easily configure your Translator containers to build Translator application architecture optimized for robust cloud capabilities and edge locality.

+* Azure portal: **Translator** Overview page labeled `Endpoint`

+Translator containers support the following logging providers:

+|Provider|Purpose|

+|--|--|

+|[Console](/aspnet/core/fundamentals/logging/#console-provider)|The ASP.NET Core `Console` logging provider. All of the ASP.NET Core configuration settings and default values for this logging provider are supported.|

+|[Debug](/aspnet/core/fundamentals/logging/#debug-provider)|The ASP.NET Core `Debug` logging provider. All of the ASP.NET Core configuration settings and default values for this logging provider are supported.|

+|[Disk](#disk-logging)|The JSON logging provider. This logging provider writes log data to the output mount.|

+* The `Logging` settings manage ASP.NET Core logging support for your container. You can use the same configuration settings and values for your container that you use for an ASP.NET Core application.

+* The `Logging.LogLevel` specifies the minimum level to log. The severity of the `LogLevel` ranges from 0 to 6. When a `LogLevel` is specified, logging is enabled for messages at the specified level and higher: Trace = 0, Debug = 1, Information = 2, Warning = 3, Error = 4, Critical = 5, None = 6.

+* Currently, Translator containers have the ability to restrict logs at the **Warning** LogLevel or higher.

+The general command syntax for logging is as follows:

+```bash

+ -Logging:LogLevel:{Provider}={FilterSpecs}

+```

+The following command starts the Docker container with the `LogLevel` set to **Warning** and logging provider set to **Console**. This command prints anomalous or unexpected events during the application flow to the console:

+```bash

+docker run --rm -it -p 5000:5000

+-v /mnt/d/TranslatorContainer:/usr/local/models \

+-e apikey={API_KEY} \

+-e eula=accept \

+-e billing={ENDPOINT_URI} \

+-e Languages=en,fr,es,ar,ru \

+-e Logging:LogLevel:Console="Warning"

+mcr.microsoft.com/azure-cognitive-services/translator/text-translation:latest

+```

+### Disk logging

+The `Disk` logging provider supports the following configuration settings:

+| Name | Data type | Description |

+||--|-|

+| `Format` | String | The output format for log files.<br/> **Note:** This value must be set to `json` to enable the logging provider. If this value is specified without also specifying an output mount while instantiating a container, an error occurs. |

+| `MaxFileSize` | Integer | The maximum size, in megabytes (MB), of a log file. When the size of the current log file meets or exceeds this value, the logging provider starts a new log file. If -1 is specified, the size of the log file is limited only by the maximum file size, if any, for the output mount. The default value is 1. |

+#### Disk provider example

+```bash

+docker run --rm -it -p 5000:5000 \

+--memory 2g --cpus 1 \

+--mount type=bind,src=/home/azureuser/output,target=/output \

+-e apikey={API_KEY} \

+-e eula=accept \

+-e billing={ENDPOINT_URI} \

+-e Languages=en,fr,es,ar,ru \

+Eula=accept \

+Billing=<endpoint> \

+ApiKey=<api-key> \

+Logging:Disk:Format=json \

+Mounts:Output=/output

+```

+For more information about configuring ASP.NET Core logging support, see [Settings file configuration](/aspnet/core/fundamentals/logging/).

+Sign in to the [Azure portal](https://portal.azure.com/), and then select the [Cloud Shell](../cloud-shell/overview.md) button in the upper-right corner. Use Azure CLI or PowerShell to create an AKS cluster.

+#### [Azure CLI](#tab/cli)

+#### [PowerShell](#tab/powershell)

+```powershell

+# Install Azure PowerShell

+Install-Module -Name Az -Repository PSGallery -Force

+# The Microsoft.OperationsManagement resource provider must be registered. This is a one-time activity per subscription.

+Register-AzResourceProvider -ProviderNamespace Microsoft.OperationsManagement

+# Create a resource group

+New-AzResourceGroup -Name myapp-rg -Location eastus

+# Create a container registry

+New-AzContainerRegistry -ResourceGroupName myapp-rg -Name myContainerRegistry -Sku Basic -Location eastus

+# Create a log analytics workspace (or use an existing one)

+New-AzOperationalInsightsWorkspace -ResourceGroupName myapp-rg -Name myWorkspace -Location eastus

+# Create an AKS cluster with monitoring add-on enabled

+$aksParameters = @{

+ ResourceGroupName = 'myapp-rg'

+ Name = 'myapp'

+ NodeCount = 1

+ AddOnNameToBeEnabled = 'Monitoring'

+ GenerateSshKey = $true

+ WorkspaceResourceId = '/subscriptions/<subscription-id>/resourceGroups/myapp-rg/providers/Microsoft.OperationalInsights/workspaces/myWorkspace'

+}

+New-AzAksCluster @aksParameters

+```

+

+Sign in to the [Azure portal](https://portal.azure.com/), and then select the [Cloud Shell](../cloud-shell/overview.md) button in the upper-right corner. Use Azure CLI or PowerShell to create an AKS cluster.

+#### [Azure CLI](#tab/cli)

+az acr create --resource-group myapp-rg --name mycontainerregistry --sku Basic

+#### [PowerShell](#tab/powershell)

+```powershell

+# Install Azure PowerShell

+Install-Module -Name Az -Repository PSGallery -Force

+# The Microsoft.OperationsManagement resource provider must be registered. This is a one-time activity per subscription.

+Register-AzResourceProvider -ProviderNamespace Microsoft.OperationsManagement

+# Create a resource group

+New-AzResourceGroup -Name myapp-rg -Location eastus

+# Create a container registry

+New-AzContainerRegistry -ResourceGroupName myapp-rg -Name myContainerRegistry -Sku Basic -Location eastus

+# Create a log analytics workspace (or use an existing one)

+New-AzOperationalInsightsWorkspace -ResourceGroupName myapp-rg -Name myWorkspace -Location eastus

+# Create an AKS cluster with monitoring add-on enabled

+$aksParameters = @{

+ ResourceGroupName = 'myapp-rg'

+ Name = 'myapp'

+ NodeCount = 1

+ AddOnNameToBeEnabled = 'Monitoring'

+ GenerateSshKey = $true

+ WorkspaceResourceId = '/subscriptions/<subscription-id>/resourceGroups/myapp-rg/providers/Microsoft.OperationalInsights/workspaces/myWorkspace'

+}

+New-AzAksCluster @aksParameters

+```

+| 1.27 | Azure policy 1.1.0<br>Metrics-Server 0.6.3<br>KEDA 2.10.0<br>Open Service Mesh 1.2.3<br>Core DNS V1.9.4<br>0.12.0</br>Overlay VPA 0.11.0<br>Azure-Keyvault-SecretsProvider 1.4.1<br>Ingress AppGateway 1.2.1<br>Eraser v1.1.1<br>Azure Workload identity v1.0.0<br>ASC Defender 1.0.56<br>Azure Active Directory Pod Identity 1.8.13.6<br>GitOps 1.7.0<br>KMS 0.5.0|Cilium 1.12.8<br>CNI 1.4.44<br> Cluster Autoscaler 1.8.5.3<br> | OS Image Ubuntu 22.04 Cgroups V2 <br>ContainerD 1.7 for Linux and 1.6 for Windows<br>|Keda 2.10.0 |Because of Ubuntu 22.04 FIPS certification status, we'll switch AKS FIPS nodes from 18.04 to 20.04 from 1.27 onwards.

+ - JavaScript: 8.0.1

+ - Java: 1.0.0-beta3

+ ## More information

+ - The network must be deployed in the same region and subscription as your API Management instance

+| config.service.integration.timeout | Defines the timeout for interacting with the Configuration API. | No | `00:01:40` | v2.3.5+ |

+> This tutorial doesn't include guidance for [Azure Cosmos DB](../cosmos-db/index.yml), which supports Microsoft Entra authentication differently. For more information, see the Azure Cosmos DB documentation, such as [Use system-assigned managed identities to access Azure Cosmos DB data](../cosmos-db/managed-identity-based-authentication.md).

+> * Configure a Microsoft Entra user as an administrator for your Azure database.

+> * Connect to your database as the Microsoft Entra user.

+> * Connect to the Azure database from your development environment using the Microsoft Entra user.

+<a name='1-grant-database-access-to-azure-ad-user'></a>

+## 1. Grant database access to Microsoft Entra user

+First, enable Microsoft Entra authentication to the Azure database by assigning a Microsoft Entra user as the administrator of the server. For the scenario in the tutorial, you'll use this user to connect to your Azure database from the local development environment. Later, you set up the managed identity for your App Service app to connect from within Azure.

+> This user is different from the Microsoft account you used to sign up for your Azure subscription. It must be a user that you created, imported, synced, or invited into Microsoft Entra ID. For more information on allowed Microsoft Entra users, see [Microsoft Entra features and limitations in SQL Database](/azure/azure-sql/database/authentication-aad-overview#azure-ad-features-and-limitations).

+1. If your Microsoft Entra tenant doesn't have a user yet, create one by following the steps at [Add or delete users using Microsoft Entra ID](../active-directory/fundamentals/add-users-azure-active-directory.md).

+1. Find the object ID of the Microsoft Entra user using the [`az ad user list`](/cli/azure/ad/user#az-ad-user-list) and replace *\<user-principal-name>*. The result is saved to a variable.

+3. Add this Microsoft Entra user as an Active Directory administrator using [`az sql server ad-admin create`](/cli/azure/sql/server/ad-admin#az-sql-server-ad-admin-create) command in the Cloud Shell. In the following command, replace *\<group-name>* and *\<server-name>* with your own parameters.

+ For more information on adding an Active Directory administrator, see [Provision a Microsoft Entra administrator for your server](/azure/azure-sql/database/authentication-aad-configure#provision-azure-ad-admin-sql-managed-instance)

+3. Add this Microsoft Entra user as an Active Directory administrator using [`az mysql server ad-admin create`](/cli/azure/mysql/server/ad-admin#az-mysql-server-ad-admin-create) command in the Cloud Shell. In the following command, replace *\<group-name>* and *\<server-name>* with your own parameters.

+3. Add this Microsoft Entra user as an Active Directory administrator using [`az postgres server ad-admin create`](/cli/azure/postgres/server/ad-admin#az-postgres-server-ad-admin-create) command in the Cloud Shell. In the following command, replace *\<group-name>* and *\<server-name>* with your own parameters.

+1. The identity needs to be granted permissions to access the database. In the Cloud Shell, sign in to your database with the following command. Replace _\<server-name>_ with your server name, _\<database-name>_ with the database name your app uses, and _\<aad-user-name>_ and _\<aad-password>_ with your Microsoft Entra user's credentials from [1. Grant database access to Microsoft Entra user]().

+ [Microsoft.Data.SqlClient](/sql/connect/ado-net/sql/azure-active-directory-authentication?view=azuresqldb-current&preserve-view=true) provides integrated support of Microsoft Entra authentication. In this case, the [Active Directory Default](/sql/connect/ado-net/sql/azure-active-directory-authentication?view=azuresqldb-current&preserve-view=true#using-active-directory-default-authentication) uses `DefaultAzureCredential` to retrieve the required token for you and adds it to the database connection directly.

+ The `LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN` environment variable enables the [Cleartext plugin](https://dev.mysql.com/doc/refman/8.0/en/cleartext-pluggable-authentication.html) in the MySQL Connector (see [Use Microsoft Entra ID for authentication with MySQL](../mysql/howto-configure-sign-in-azure-ad-authentication.md#compatibility-with-application-drivers)).

+ Whatever database driver you use, make sure it can send the token as clear text (see [Use Microsoft Entra ID for authentication with MySQL](../mysql/howto-configure-sign-in-azure-ad-authentication.md#compatibility-with-application-drivers)).

+ This sample code uses `DefaultAzureCredential` to get a useable token for your Azure database from Microsoft Entra ID and then adds it to the database connection. While you can customize `DefaultAzureCredential`, it's already versatile by default. It gets a token from the signed-in Microsoft Entra user or from a managed identity, depending on whether you run it locally in your development environment or in App Service.

+Without any further changes, your code is ready to be run in Azure. To debug your code locally, however, your develop environment needs a signed-in Microsoft Entra user. In this step, you configure your environment of choice by signing in [with your Microsoft Entra user](#1-grant-database-access-to-azure-ad-user).

+1. Visual Studio for Windows is integrated with Microsoft Entra authentication. To enable development and debugging in Visual Studio, add your Microsoft Entra user in Visual Studio by selecting **File** > **Account Settings** from the menu, and select **Sign in** or **Add**.

+1. To set the Microsoft Entra user for Azure service authentication, select **Tools** > **Options** from the menu, then select **Azure Service Authentication** > **Account Selection**. Select the Microsoft Entra user you added and select **OK**.

+1. Visual Studio for Mac is *not* integrated with Microsoft Entra authentication. However, the Azure Identity client library that you'll use later can also retrieve tokens from Azure CLI. To enable development and debugging in Visual Studio, [install Azure CLI](/cli/azure/install-azure-cli) on your local machine.

+1. Sign in to Azure CLI with the following command using your Microsoft Entra user:

+1. Visual Studio Code is integrated with Microsoft Entra authentication through the Azure extension. Install the <a href="https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-node-azure-pack" target="_blank">Azure Tools</a> extension in Visual Studio Code.

+1. Sign in to Azure with the following command using your Microsoft Entra user:

+1. Sign in to Azure CLI with the following cmdlet using your Microsoft Entra user:

+For more information about setting up your dev environment for Microsoft Entra authentication, see [Azure Identity client library for .NET](/dotnet/api/overview/azure/Identity-readme).

+You're now ready to develop and debug your app with the SQL Database as the back end, using Microsoft Entra authentication.

+1. Run your code in your dev environment. Your code uses the [signed-in Microsoft Entra user](#1-grant-database-access-to-azure-ad-user)) in your environment to connect to the back-end database. The user can access the database because it's configured as a Microsoft Entra administrator for the database.

+- [How do I add the managed identity to a Microsoft Entra group?](#how-do-i-add-the-managed-identity-to-an-azure-ad-group)

+Microsoft Entra ID and managed identities aren't supported for on-premises SQL Server.

+<a name='how-do-i-add-the-managed-identity-to-an-azure-ad-group'></a>

+#### How do I add the managed identity to a Microsoft Entra group?

+If you want, you can add the identity to an [Microsoft Entra group](../active-directory/fundamentals/active-directory-manage-groups.md), then grant access to the Microsoft Entra group instead of the identity. For example, the following commands add the managed identity from the previous step to a new group called _myAzureSQLDBAccessGroup_:

+To grant database permissions for a Microsoft Entra group, see documentation for the respective database type.

+> * Configure a Microsoft Entra user as an administrator for your Azure database.

+> * Connect to your database as the Microsoft Entra user.

+> * Connect to the Azure database from your development environment using the Microsoft Entra user.

+> * Configure Entity Framework to use Microsoft Entra authentication with SQL Database

+> * Connect to SQL Database from Visual Studio using Microsoft Entra authentication

+>Microsoft Entra authentication is _different_ from [Integrated Windows authentication](/previous-versions/windows/it-pro/windows-server-2003/cc758557(v=ws.10)) in on-premises Active Directory (AD DS). AD DS and Microsoft Entra ID use completely different authentication protocols. For more information, see [Microsoft Entra Domain Services documentation](../active-directory-domain-services/index.yml).

+<a name='1-grant-database-access-to-azure-ad-user'></a>

+## 1. Grant database access to Microsoft Entra user

+First, enable Microsoft Entra authentication to SQL Database by assigning a Microsoft Entra user as the admin of the server. This user is different from the Microsoft account you used to sign up for your Azure subscription. It must be a user that you created, imported, synced, or invited into Microsoft Entra ID. For more information on allowed Microsoft Entra users, see [Microsoft Entra features and limitations in SQL Database](/azure/azure-sql/database/authentication-aad-overview#azure-ad-features-and-limitations).

+1. If your Microsoft Entra tenant doesn't have a user yet, create one by following the steps at [Add or delete users using Microsoft Entra ID](../active-directory/fundamentals/add-users-azure-active-directory.md).

+1. Find the object ID of the Microsoft Entra user using the [`az ad user list`](/cli/azure/ad/user#az-ad-user-list) and replace *\<user-principal-name>*. The result is saved to a variable.

+ > To see the list of all user principal names in Microsoft Entra ID, run `az ad user list --query '[].userPrincipalName'`.

+1. Add this Microsoft Entra user as an Active Directory admin using [`az sql server ad-admin create`](/cli/azure/sql/server/ad-admin#az-sql-server-ad-admin-create) command in the Cloud Shell. In the following command, replace *\<server-name>* with the server name (without the `.database.windows.net` suffix).

+For more information on adding an Active Directory admin, see [Provision a Microsoft Entra administrator for your server](/azure/azure-sql/database/authentication-aad-configure#provision-azure-ad-admin-sql-managed-instance)

+1. Visual Studio for Windows is integrated with Microsoft Entra authentication. To enable development and debugging in Visual Studio, add your Microsoft Entra user in Visual Studio by selecting **File** > **Account Settings** from the menu, and select **Sign in** or **Add**.

+1. To set the Microsoft Entra user for Azure service authentication, select **Tools** > **Options** from the menu, then select **Azure Service Authentication** > **Account Selection**. Select the Microsoft Entra user you added and select **OK**.

+1. Visual Studio for Mac is *not* integrated with Microsoft Entra authentication. However, the Azure Identity client library that you'll use later can use tokens from Azure CLI. To enable development and debugging in Visual Studio, [install Azure CLI](/cli/azure/install-azure-cli) on your local machine.

+1. Sign in to Azure CLI with the following command using your Microsoft Entra user:

+1. Visual Studio Code is integrated with Microsoft Entra authentication through the Azure extension. Install the <a href="https://marketplace.visualstudio.com/items?itemName=ms-vscode.vscode-node-azure-pack" target="_blank">Azure Tools</a> extension in Visual Studio Code.

+1. Sign in to Azure with the following command using your Microsoft Entra user:

+1. Sign in to Azure CLI with the following cmdlet using your Microsoft Entra user:

+For more information about setting up your dev environment for Microsoft Entra authentication, see [Azure Identity client library for .NET](/dotnet/api/overview/azure/Identity-readme).

+You're now ready to develop and debug your app with the SQL Database as the back end, using Microsoft Entra authentication.

+ > The [Active Directory Default](/sql/connect/ado-net/sql/azure-active-directory-authentication#using-active-directory-default-authentication) authentication type can be used both on your local machine and in Azure App Service. The driver attempts to acquire a token from Microsoft Entra ID using various means. If the app is deployed, it gets a token from the app's managed identity. If the app is running locally, it tries to get a token from Visual Studio, Visual Studio Code, and Azure CLI.

+ That's everything you need to connect to SQL Database. When you debug in Visual Studio, your code uses the Microsoft Entra user you configured in [2. Set up your dev environment](#2-set-up-your-dev-environment). You'll set up SQL Database later to allow connection from the managed identity of your App Service app. The `DefaultAzureCredential` class caches the token in memory and retrieves it from Microsoft Entra ID just before expiration. You don't need any custom code to refresh the token.

+1. Type `Ctrl+F5` to run the app again. The same CRUD app in your browser is now connecting to the Azure SQL Database directly, using Microsoft Entra authentication. This setup lets you run database migrations from Visual Studio.

+ This code uses [Azure.Identity.DefaultAzureCredential](/dotnet/api/azure.identity.defaultazurecredential) to get a useable token for SQL Database from Microsoft Entra ID and then adds it to the database connection. While you can customize `DefaultAzureCredential`, by default it's already versatile. When it runs in App Service, it uses app's system-assigned managed identity. When it runs locally, it can get a token using the logged-in identity of Visual Studio, Visual Studio Code, Azure CLI, and Azure PowerShell.

+ That's every thing you need to connect to SQL Database. When you debug in Visual Studio, your code uses the Microsoft Entra user you configured in [2. Set up your dev environment](#2-set-up-your-dev-environment). You'll set up SQL Database later to allow connection from the managed identity of your App Service app.

+1. Type `Ctrl+F5` to run the app again. The same CRUD app in your browser is now connecting to the Azure SQL Database directly, using Microsoft Entra authentication. This setup lets you run database migrations from Visual Studio.

+> If you want, you can add the identity to an [Microsoft Entra group](../active-directory/fundamentals/active-directory-manage-groups.md), then grant SQL Database access to the Microsoft Entra group instead of the identity. For example, the following commands add the managed identity from the previous step to a new group called _myAzureSQLDBAccessGroup_:

+1. In the Cloud Shell, sign in to SQL Database by using the SQLCMD command. Replace _\<server-name>_ with your server name, _\<db-name>_ with the database name your app uses, and _\<aad-user-name>_ and _\<aad-password>_ with your Microsoft Entra user's credentials.

+ *\<identity-name>* is the name of the managed identity in Microsoft Entra ID. If the identity is system-assigned, the name is always the same as the name of your App Service app. For a [deployment slot](deploy-staging-slots.md), the name of its system-assigned identity is *\<app-name>/slots/\<slot-name>*. To grant permissions for a Microsoft Entra group, use the group's display name instead (for example, *myAzureSQLDBAccessGroup*).

+ > Microsoft Entra ID and managed identities are not supported for on-premises SQL Server.

+> * Configure Entity Framework to use Microsoft Entra authentication with SQL Database

+> * Connect to SQL Database from Visual Studio using Microsoft Entra authentication

+|[Direct connection from App Service managed identity](#connect-to-azure-services-with-managed-identity)|Dependent service [supports managed identity](../active-directory/managed-identities-azure-resources/managed-identities-status.md)<br><br>* Best for enterprise-level security.<br>* Connection to dependent service is secured with managed identity.<br>* Large team or automated connection string and secret management.<br>* Don't manage credentials manually.<br>* Credentials arenΓÇÖt accessible to you.<br>* a Microsoft Entra identity is required to access. Services include Microsoft Graph or Azure management SDKs.|

+* You can use managed identities to authenticate to any resource that supports Microsoft Entra authentication including your own applications.

+> * Configure a Tomcat web application to use Microsoft Entra authentication with PostgreSQL Database.

+Follow these steps to create an Azure Database for Postgres in your subscription. The Tomcat app connects to this database and store its data when running, persisting the application state no matter where you run the application.

+1. Create an Azure Database for PostgreSQL server. The server is created with an administrator account, but it isn't used because we're going to use the Microsoft Entra admin account to perform administrative tasks.

+Consider [disabling basic auth on App Service](https://azure.github.io/AppService/2020/08/10/securing-data-plane-access.html), which limits access to the FTP and SCM endpoints to users that are backed by Microsoft Entra ID. If using a continuous deployment tool to deploy your application source code, disabling basic auth will require [extra steps to configure continuous deployment](deploy-github-actions.md). For example, you won't be able to use a publish profile since that authentication mechanism doesn't use Microsoft Entra backed credentials. Instead, you'll need to use either a [service principal or OpenID Connect](deploy-github-actions.md#generate-deployment-credentials).

+[Disabling basic auth on App Service](https://azure.github.io/AppService/2020/08/10/securing-data-plane-access.html) limits access to the FTP and SCM endpoints to users that are backed by Microsoft Entra ID, which further secures your apps. For more information on disabling basic auth including how to test and monitor logins, see [Disabling basic auth on App Service](https://azure.github.io/AppService/2020/08/10/securing-data-plane-access.html).

+When you [lock down FTP and SCM access](#5-lock-down-ftp-and-scm-access), it ensures that only Microsoft Entra backed principals can access the SCM endpoint even though it's publicly accessible. This setting should reassure you that your backend web app is still secure.

+* **Access log**: You can use this log to view Application Gateway for Containers access patterns and analyze important information. This includes the caller's IP, requested URL, response latency, return code, and bytes in and out. An access log is collected every 60 seconds. The data may be stored in a storage account that is specified at time of enable logging.

+### Limitations

+- Although it's possible to configure logging to log analytics, logs are currently not emitted to a log analytics workspace or event hub. Log analytics and event hub streaming will be supported in a future update.

+ > Assignment of the managed identity immediately after creation may result in an error that the principalId does not exist. Allow about a minute of time to elapse for the identity to replicate in Microsoft Entra ID prior to delegating the identity.

+1. First, create a Microsoft Entra service principal and assign it `Monitoring Reader` access over Application Gateway's resource group.

+1. Now, deploy the [`Azure Kubernetes Metric Adapter`](https://github.com/Azure/azure-k8s-metrics-adapter) using the Microsoft Entra service principal created previously.

+ - Option 1: [Set up Microsoft Entra Workload ID](#set-up-azure-ad-workload-identity) and create Azure Identity on ARMs

+- [Microsoft Entra Workload ID](../aks/workload-identity-overview.md) configured for your AKS cluster

+<a name='set-up-azure-ad-workload-identity'></a>

+## Set up Microsoft Entra Workload ID

+[Microsoft Entra Workload ID](../aks/workload-identity-overview.md) is an identity you assign to a software workload, to authenticate and access other services and resources. This identity enables your AKS pod to use this identity and authenticate with other Azure resources. For this configuration, we need authorization

+ > The `<identity-client-id>` is a property of the Microsoft Entra Workload ID you setup in the previous section. You can retrieve this information by running the following command: `az identity show -g <resourcegroup> -n <identity-name>`, where `<resourcegroup>` is the resource group hosting the infrastructure resources related to the AKS cluster, Application Gateway and managed identity.

+Follow the steps below to create a Microsoft Entra [service principal object](../active-directory/develop/app-objects-and-service-principals.md#service-principal-object). Record the `appId`, `password`, and `objectId` values - these values will be used in the following steps.

+- [Managed Identity](../active-directory/managed-identities-azure-resources/overview.md), which will be used by [Microsoft Entra Pod Identity](https://github.com/Azure/aad-pod-identity/blob/master/README.md)

+<a name='install-azure-ad-pod-identity'></a>

+### Install Microsoft Entra Pod Identity

+ Microsoft Entra Pod Identity provides token-based access to

+ [Microsoft Entra Pod Identity](https://github.com/Azure/aad-pod-identity) will add the following components to your Kubernetes cluster:

+To install Microsoft Entra Pod Identity to your cluster:

+1. Within your **Application Gateways** properties blade, obtain and make a note of the **Resource ID**, this is required if you are setting up a Private Endpoint within a different Microsoft Entra tenant.

+- VNet in the same or different subscription and the same or different Microsoft Entra tenant from Application Gateway

+- Azure portal: Go to **Microsoft Entra ID** and search for your Automanage Account by name. Under **Enterprise Applications**, select the Automanage Account name when it appears.

+* Runbooks taking dependency on internal file paths such as `C:\modules` might fail due to changes in service backend infrastructure. Change runbook code to ensure there are no dependencies on internal file paths and use [Get-ChildItem](/powershell/module/microsoft.powershell.management/get-childitem?view=powershell-7.3) to get the required directory.

+## October 10, 2023

+### Image tag

+`v1.24.0_2023-10-10`

+For complete release version information, review [Version log](version-log.md#october-10-2023).

+## October 10, 2023

+|Component|Value|

+|--|--|

+|Container images tag |`v1.24.0_2023-10-10`|

+|**CRD names and version:**| |

+|`activedirectoryconnectors.arcdata.microsoft.com`| v1beta1, v1beta2, v1, v2|

+|`datacontrollers.arcdata.microsoft.com`| v1beta1, v1 through v5|

+|`exporttasks.tasks.arcdata.microsoft.com`| v1beta1, v1, v2|

+|`failovergroups.sql.arcdata.microsoft.com`| v1beta1, v1beta2, v1, v2|

+|`kafkas.arcdata.microsoft.com`| v1beta1 through v1beta4|

+|`monitors.arcdata.microsoft.com`| v1beta1, v1, v3|

+|`postgresqls.arcdata.microsoft.com`| v1beta1 through v1beta6|

+|`postgresqlrestoretasks.tasks.postgresql.arcdata.microsoft.com`| v1beta1|

+|`sqlmanagedinstances.sql.arcdata.microsoft.com`| v1beta1, v1 through v13|

+|`sqlmanagedinstancemonitoringprofiles.arcdata.microsoft.com`| v1beta1, v1beta2|

+|`sqlmanagedinstancereprovisionreplicatasks.tasks.sql.arcdata.microsoft.com`| v1beta1|

+|`sqlmanagedinstancerestoretasks.tasks.sql.arcdata.microsoft.com`| v1beta1, v1|

+|`telemetrycollectors.arcdata.microsoft.com`| v1beta1 through v1beta5|

+|`telemetryrouters.arcdata.microsoft.com`| v1beta1 through v1beta5|

+|Azure Resource Manager (ARM) API version|2023-01-15-preview|

+|`arcdata` Azure CLI extension version|1.5.6 ([Download](https://aka.ms/az-cli-arcdata-ext))|

+|Arc-enabled Kubernetes helm chart extension version|1.24.0|

+|Azure Arc Extension for Azure Data Studio<br/>`arc`<br/>`azcli`|<br/>1.8.0 ([Download](https://aka.ms/ads-arcdata-ext))</br>1.8.0 ([Download](https://aka.ms/ads-azcli-ext))|

+|SQL Database version | 957 |

+### 1.8.0 (October 2023)

+> [!NOTE]

+> We have started to roll out this release across regions. We'll remove this note once version 1.8.0 is available to all supported regions.

+Flux version: [Release v2.1.1](https://github.com/fluxcd/flux2/releases/tag/v2.1.1)

+- source-controller: v1.1.1

+- kustomize-controller: v1.1.0

+- helm-controller: v0.36.1

+- notification-controller: v1.1.0

+- image-automation-controller: v0.36.1

+- image-reflector-controller: v0.30.0

+Changes made for this version:

+- Upgrades Flux to [v2.1.1](https://github.com/fluxcd/flux2/releases/tag/v2.1.1)

+- Adds support for [AKS clusters with workload identity](tutorial-use-gitops-flux2.md#workload-identity-in-aks-clusters)

+### Workload identity in AKS clusters

+Starting with [`microsoft.flux` v1.8.0](extensions-release.md#flux-gitops), you can create Flux configurations in [AKS clusters with workload identity enabled](/azure/aks/workload-identity-deploy-cluster). To do so, modify the flux extension as shown in the following steps.

+1. Retrieve the [OIDC issuer URL](/azure/aks/workload-identity-deploy-cluster#retrieve-the-oidc-issuer-url) for your cluster.

+1. Create a [managed identity](/azure/aks/workload-identity-deploy-cluster#create-a-managed-identity) and note its client ID.

+1. Create the flux extension on the cluster, using the following command:

+ ```azurecli

+ az k8s-extension create --resource-group <resource_group_name> --cluster-name <aks_cluster_name> --cluster-type managedClusters --name flux --extension-type microsoft.flux --config workloadIdentity.enable=true workloadIdentity.azureClientId=<user_assigned_client_id>

+ ```

+1. Establish a [federated identity credential](/azure/aks/workload-identity-deploy-cluster#establish-federated-identity-credential). For example:

+ ```azurecli

+ # For source-controller

+ az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --issuer "${AKS_OIDC_ISSUER}" --subject system:serviceaccount:"flux-system":"source-controller" --audience api://AzureADTokenExchange

+

+ # For image-reflector controller if you plan to enable it during extension creation, it is not deployed by default

+ az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --issuer "${AKS_OIDC_ISSUER}" --subject system:serviceaccount:"flux-system":"image-reflector-controller" --audience api://AzureADTokenExchange

+ ```

+1. Make sure the custom resource that needs to use workload identity has set `.spec.provider` value to `azure` in the manifest. For example:

+ ```json

+ apiVersion: source.toolkit.fluxcd.io/v1beta2

+ kind: HelmRepository

+ metadata:

+ name: acrrepo

+ spec:

+ interval: 10m0s

+ type: <helm_repository_type>

+ url: <helm_repository_link>

+ provider: azure

+ ```

+1. Be sure to provide proper permissions for workload identity for the resource that you want source-controller or image-reflector controller to pull. For example, if using Azure Container Registry, `AcrPull` permissions are required.

+Arc resource bridge communicates outbound securely to Azure Arc over TCP port 443. If the appliance needs to connect through a firewall or proxy server to communicate over the internet, it communicates outbound using the HTTPS protocol.

+## Required Azure permissions

+- To onboard Arc resource bridge, you must have the [Contributor](/azure/role-based-access-control/built-in-roles) role for the resource group.

+- To read, modify, and delete Arc resource bridge, you must have the [Contributor](/azure/role-based-access-control/built-in-roles) role for the resource group.

+- if applicable, communication over port 443 to the private cloud management console (ex: VMware vCenter host machine)

+When you deploy Arc resource bridge with AKS on Azure Stack HCI (AKS-HCI), the following configurations must be applied:

+### Scenario 8: An insurance customer is running a 16 node VMware cluster with 1024 physical cores on-premises. 44 of the VMs on the cluster are running Windows Server 2012 R2. Those 44 VMs consume 506 virtual cores, which was calculated by summing up the maximum of 8 or the actual number of cores assigned to each VM.

+In this scenario, you could either license the entire cluster with 1024 Windows Server 2012 Datacenter ESU physical cores or license each VM individually with a total of 506 standard edition virtual cores. In this case, it's cheaper to purchase an Arc ESU Windows Server 2012 Standard edition license associated with 506 virtual cores. You'll need to onboard each of the 44 VMs to Azure Arc and then link the license to the Arc machines. If you migrate the VMs to Azure VMware Solution (AVS), these servers become eligible for free WS2012 ESUs and do not need to be licensed for ESUs through Azure Arc.

+ Title: Connect Windows Server machines to Azure through Azure Arc Setup

+description: In this article, you learn how to connect Windows Server machines to Azure Arc using the built-in Windows Server Azure Arc Setup wizard.

+# Connect Windows Server machines to Azure through Azure Arc Setup

+Windows Server machines can be onboarded directly to Azure Arc through a graphical wizard included in Windows Server. The wizard automates the onboarding process by checking the necessary prerequisites for successful Azure Arc onboarding and fetching and installing the latest version of the Azure Connected Machine (AzCM) agent. Once the wizard process completes, you're directed to your Window Server machine in the Azure portal, where it can be viewed and managed like any other Azure Arc-enabled resource.

+> [!NOTE]

+> This feature only applies to Windows Server 2022 and later. It was released in the [Cumulative Update of 10/10/2023](https://support.microsoft.com/en-us/topic/october-10-2023-kb5031364-os-build-20348-2031-7f1d69e7-c468-4566-887a-1902af791bbc).

+>

+## Prerequisites

+* Azure Arc-enabled servers - Review the [prerequisites](prerequisites.md) and verify that your subscription, your Azure account, and resources meet the requirements.

+* An Azure subscription. If you don't have one, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

+* Modern browser (Microsoft Edge) for authentication to Microsoft Azure. Configuration of the Azure Connected Machine agent requires authentication to your Azure account, either through interactive authentication on a modern browser or device code log-in on a separate device (if the machine doesn't have a modern browser).

+## Launch Azure Arc Setup and connect to Azure Arc

+The Azure Arc Setup wizard is launched from a system tray icon at the bottom of the Windows Server machine when the Azure Arc Setup feature is enabled. This feature is enabled by default. Alternatively, you can launch the wizard from a pop-up window in the Server Manager or from the Windows Server Start menu.

+1. Select the Azure Arc system tray icon, then select **Launch Azure Arc Setup**.

+ :::image type="content" source="media/onboard-windows-server/system-tray-icon.png" alt-text="Screenshot showing Azure Arc system tray icon and window to launch Azure Arc setup process.":::

+

+1. The introduction window of the Azure Arc Setup wizard explains the benefits of onboarding your machine to Azure Arc. When you're ready to proceed, click **Next**.

+ :::image type="content" source="media/onboard-windows-server/get-started-with-arc.png" alt-text="Screenshot of the Getting Started page of the wizard.":::

+1. The wizard automatically checks for the prerequisites necessary to install the Azure Connected Machine agent on your Windows Server machine. Once this process completes and the agent is installed, select **Configure**.

+1. The configuration window details the steps required to configure the Azure Connected Machine agent. When you're ready to begin configuration, select **Next**.

+1. Sign-in to Azure by selecting the applicable Azure cloud, and then selecting **Sign in to Azure**. You'll be asked to provide your sign-in credentials.

+1. Provide the resource details of how your machine will work within Azure Arc, such as the **Subscription** and **Resource group**, and then select **Next**.

+ :::image type="content" source="media/onboard-windows-server/resource-details.png" alt-text="Screenshot of resource details window with fields.":::

+1. Select an option for enabling Azure Automanage on your machine, and then click **Next**.

+ Azure Automanage machine best practices help enhance reliability, security, and management for virtual machines. To learn more, see [Azure Automanage machine best practices](/azure/automanage/overview-about).

+1. Once the configuration completes and your machine is onboarded to Azure Arc, select **Finish**.

+1. Go to the Server Manager and select **Local Server** to view the status of the machine in the **Azure Arc Management** field. A successfully onboarded machine has a status of **Enabled**.

+ :::image type="content" source="media/onboard-windows-server/server-manager-enabled.png" alt-text="Screenshot of Server Manager local server pane showing machine status is enabled.":::

+## Server Manager functions

+You can select the **Enabled/Disabled** link in the **Azure Arc Management** field of the Server Manager to launch different functions based on the status of the machine:

+- If Azure Arc Setup isn't installed, selecting **Enabled/Disabled** launches the **Add Roles and Features Wizard**.

+- If Azure Arc Setup is installed and the Azure Connected Machine agent hasn't been installed, selecting **Disabled** launches `AzureArcSetup.exe`, the executable file for the Azure Arc Setup wizard.

+- If Azure Arc Setup is installed and the Azure Connected Machine agent is already installed, selecting **Enabled/Disabled** launches `AzureArcConfiguration.exe`, the executable file for configuring the Azure Connected Machine agent to work with your machine.

+

+## Viewing the connected machine

+The Azure Arc system tray icon at the bottom of your Windows Server machine indicates if the machine is connected to Azure Arc; a red symbol means the machine does not have the Azure Connected Machine agent installed. To view a connected machine in Azure Arc, select the icon and then select **View Machine in Azure**. You can then view the machine in the [Azure portal](https://portal.azure.com/), just as you would other Azure Arc-enabled resources.

+## Uninstalling Azure Arc Setup

+To uninstall Azure Arc Setup, follow these steps:

+1. In the Server Manager, navigate to the **Remove Roles and Features Wizard**. (See [Remove roles, role services, and features by using the remove Roles and Features Wizard](/windows-server/administration/server-manager/install-or-uninstall-roles-role-services-or-features#remove-roles-role-services-and-features-by-using-the-remove-roles-and-features-wizard) for more information.)

+1. On the Features page, uncheck the box for **Azure Arc Setup**.

+1. On the confirmation page, select **Restart the destination server automatically if required**, then select **Remove**.

+> [!NOTE]

+> Uninstalling Azure Arc Setup does not uninstall the Azure Connected Machine agent from the machine. For instructions on uninstalling the agent, see [Managing and maintaining the Connected Machine agent](manage-agent.md).

+>

+## Next steps

+* Troubleshooting information can be found in the [Troubleshoot Azure Connected Machine agent guide](troubleshoot-agent-onboard.md).

+* Review the [Planning and deployment guide](plan-at-scale-deployment.md) to plan for deploying Azure Arc-enabled servers at any scale and implement centralized management and monitoring.

+* Learn how to manage your machine using [Azure Policy](../../governance/policy/overview.md), for such things as VM [guest configuration](../../governance/machine-configuration/overview.md), verifying the machine is reporting to the expected Log Analytics workspace, enable monitoring with [VM insights](../../azure-monitor/vm/vminsights-enable-policy.md), and much more.

+- **Azure billed:** You can draw down from your existing [Microsoft Azure Consumption Commitment](/marketplace/azure-consumption-commitment-benefit) (MACC) and analyze your costs using [Microsoft Cost Management and Billing](../../cost-management-billing/cost-management-billing-overview.md).

+ "value": "[server-name].azurecr.io"

+ "value": "[username]"

+ "value": "DOCKER|[server-name].azurecr.io/package:20190827195524"

+ - Make sure that both the source and resource subscriptions exist within the same Microsoft Entra tenant.

+One simple option for user authentication would be to simply use an [Azure Function](../../azure-functions/index.yml) as your token provider, and enforce user authentication as a condition of obtaining a token. If an application tries to call the Function it would fail unless authenticated with your auth system. If you're using Microsoft Entra ID, for example, you might create a Microsoft Entra application for your Azure Function, and tie it to your organization's auth system.

+In this case the user would sign into your application using Microsoft Entra ID, through which you would obtain a token to use to call your Azure Function. The Azure Function itself behaves the same, but it's now only accessible to people who have also authenticated with Microsoft Entra ID.

+- Azure Key Vault, user assigned identity, and the Fluid Relay resource must be in the same region and in the same Microsoft Entra tenant.

+| Windows | .NET 8 RC1 |

+| Linux | .NET 8 RC2 |

+ Title: Data-driven style expressions in the Azure Maps Web SDK | Microsoft Azure Maps

+# Data-driven style expressions (Web SDK)

+Expressions enable you to apply business logic to styling options that observe the properties defined in each shape in a data source. Expressions can filter data in a data source or a layer. Expressions might consist of conditional logic, like if-statements. And, they can be used to manipulate data using: string operators, logical operators, and mathematical operators.

+| `['distance', Point \| MultiPoint \| LineString \| MultiLineString \| Polygon \| MultiPolygon \| Feature \| FeatureCollection]` | number | Calculates the shortest distance in meters between the evaluated feature and the input geometry. Distance values returned might vary in precision due to loss in precision from encoding geometries, particularly below zoom level 13. |

+A `zoom` expression is used to retrieve the current zoom level of the map at render time and is defined as `['zoom']`. This expression returns a number between the minimum and maximum zoom level range of the map. The Azure Maps interactive map controls for web and Android support 25 zoom levels, numbered 0 through 24. Using the `zoom` expression allows styles to be modified dynamically as the zoom level of the map is changed. The `zoom` expression can only be used with `interpolate` and `step` expressions.

+ <!DOCTYPE html>

+ <body onload='GetMap()'>

+ <div id="myMap" style="position:relative;width:100%;min-width:290px;height:600px;"></div>

+ :::image type="content" source="./media/how-to-use-spatial-io-module/spatial-data-example.png" alt-text="Screenshot of an indoor map demonstrating Spatial Data.":::

+[How to use the Azure Maps map control npm package]: how-to-use-npm-package.md

+* Bing maps require an account key specified in the script reference of the API or as a map option. Authentication credentials for Azure Maps are specified as options of the map class as either [Shared Key authentication] or [Microsoft Entra ID].

+Bing Maps provides basic key-based authentication. Azure Maps provides both basic key-based authentication and highly secure, Microsoft Entra authentication.

+1. Setup authentication using an Azure Maps [subscription key] or [Microsoft Entra authentication].

+4. Get your Azure Maps [subscription key] or setup [Microsoft Entra authentication] for enhanced security.

+* Google Maps requires an account key to be specified in the script reference of the API. Authentication credentials for Azure Maps are specified as options of the map class. This credential can be a subscription key or Microsoft Entra information.

+Google Maps provides basic key-based authentication. Azure Maps provides both basic key-based authentication and Microsoft Entra authentication. Microsoft Entra authentication provides more security features, compared to the basic key-based authentication.

+3. Create an [Azure Maps account] and [subscription key] or [Microsoft Entra authentication].

+4. Get your Azure Maps [subscription key] or [Microsoft Entra authentication] for enhanced security.

+| [Azure Maps & Microsoft Entra ID Samples] | A collection of samples that show how to use Microsoft Entra ID with Azure Maps. |

+> This quickstart uses the [Shared Key] authentication approach for demonstration purposes, but the preferred approach for any production environment is to use [Microsoft Entra ID] authentication.

+ 1. Comment out all of the code in the `authOptions` function, this code is used for Microsoft Entra authentication.

+> This quickstart uses [Shared Key authentication] for demonstration purposes, but the preferred approach for any production environment is to use [Microsoft Entra authentication].

+To enhance security, more authentication methods are included in the Web SDK starting in version 2. The new methods include [Microsoft Entra authentication] and [Shared Key Authentication]. For more information about Azure Maps web application security, see [Manage Authentication in Azure Maps].

+ - Enhanced security through Managed Identity and Microsoft Entra tokens (for clients).

+ - **System-assigned**: This managed identity is suited for initial testing or small deployments. When used at scale, for example, for all VMs in a subscription, it results in a substantial number of identities created (and deleted) in Microsoft Entra ID. To avoid this churn of identities, use user-assigned managed identities instead. *For Azure Arc-enabled servers, system-assigned managed identity is enabled automatically* as soon as you install the Azure Arc agent. It's the only supported type for Azure Arc-enabled servers.

+| Authentication | Using Managed Identity | Using Microsoft Entra device token |

+| Associating config rules to agents | DCRs associates directly to individual VM resources | DCRs associate to Monitored Object (MO), which maps to all devices within the Microsoft Entra tenant |

+1. The Windows client installer supports latest Windows machines only that are **Microsoft Entra joined** or Microsoft Entra hybrid joined. More information under [prerequisites](#prerequisites) below

+2. The Data Collection rules can only target the Microsoft Entra tenant scope, i.e. all DCRs associated to the tenant (via Monitored Object) will apply to all Windows client machines within that tenant with the agent installed using this client installer. **Granular targeting using DCRs is not supported** for Windows client devices yet

+3. The machine must be domain joined to a Microsoft Entra tenant (AADj or Hybrid AADj machines), which enables the agent to fetch Microsoft Entra device tokens used to authenticate and fetch data collection rules from Azure.

+4. You may need tenant admin permissions on the Microsoft Entra tenant.

+You need to create a 'Monitored Object' (MO) that creates a representation for the Microsoft Entra tenant within Azure Resource Manager (ARM). This ARM entity is what Data Collection Rules are then associated with. **This Monitored Object needs to be created only once for any number of machines in a single Microsoft Entra tenant**.

+Currently this association is only **limited** to the Microsoft Entra tenant scope, which means configuration applied to the Microsoft Entra tenant will be applied to all devices that are part of the tenant and running the agent installed via the client installer. Agents installed as virtual machine extension will not be impacted by this.

+Since MO is a tenant level resource, the scope of the permission would be higher than a subscription scope. Therefore, an Azure tenant admin may be needed to perform this step. [Follow these steps to elevate Microsoft Entra tenant admin as Azure Tenant Admin](../../role-based-access-control/elevate-access-global-admin.md). It will give the Microsoft Entra admin 'owner' permissions at the root scope. This is needed for all methods described below in this section.

+This step creates the Monitored Object for the Microsoft Entra tenant scope. It will be used to represent client devices that are signed with that Microsoft Entra tenant identity.

+| `AADTenantId` | path | string | ID of the Microsoft Entra tenant that the device(s) belong to. The MO will be created with the same ID |

+<a name='not-aad-joined'></a>

+#### Not Microsoft Entra joined

+1. Run the command `dsregcmd /status`. This should produce the output as `AzureAdJoined : YES` in the 'Device State' section. If not, join the device with a Microsoft Entra tenant and try installation again.

+ |Email Azure Resource Manager role|Send an email to the subscription members, based on their role.<br>A notification email is sent only to the primary email address configured for the Microsoft Entra user.<br>The email is only sent to Microsoft Entra ID **user** members of the selected role, not to Microsoft Entra groups or service principals.<br> See [Email](#email-azure-resource-manager).|Enter the primary email address configured for the Microsoft Entra user. See [Email](#email-azure-resource-manager).|

+ |Secure webhook|When you use a secure webhook action, you must use Microsoft Entra ID to secure the connection between your action group and your endpoint, which is a protected web API. See [Configure authentication for Secure webhook](#configure-authentication-for-secure-webhook). Secure webhook doesn't support basic authentication. If you're using basic authentication, use the Webhook action.|

+When you use Azure Resource Manager for email notifications, you can send email to the members of a subscription's role. Email is only sent to Microsoft Entra ID **user** members of the role. Email isn't sent to Microsoft Entra groups or service principals.

+1. Make sure an email address is configured for the user in their **Microsoft Entra profile**.

+The secure webhook action authenticates to the protected API by using a Service Principal instance in the Microsoft Entra tenant of the "AZNS Microsoft Entra Webhook" Microsoft Entra application. To make the action group work, this Microsoft Entra Webhook Service Principal must be added as a member of a role on the target Microsoft Entra application that grants access to the target endpoint.

+For an overview of Microsoft Entra applications and service principals, see [Microsoft identity platform (v2.0) overview](../../active-directory/develop/v2-overview.md). Follow these steps to take advantage of the secure webhook functionality.

+1. Create a Microsoft Entra application for your protected web API. For more information, see [Protected web API: App registration](../../active-directory/develop/scenario-protected-web-api-app-registration.md). Configure your protected API to be called by a daemon app and expose application permissions, not delegated permissions. For more information about these permissions, see [If your web API is called by a service or daemon app](../../active-directory/develop/scenario-protected-web-api-app-registration.md#if-your-web-api-is-called-by-a-service-or-daemon-app).

+ > Configure your protected web API to accept V2.0 access tokens. For more information about this setting, see [Microsoft Entra app manifest](../../active-directory/develop/reference-app-manifest.md#accesstokenacceptedversion-attribute).

+1. To enable the action group to use your Microsoft Entra application, use the PowerShell script that follows this procedure.

+ > You must be assigned the [Microsoft Entra Application Administrator role](../../active-directory/roles/permissions-reference.md#all-roles) to run this script.

+ 1. Modify the PowerShell script's `Connect-AzureAD` call to use your Microsoft Entra tenant ID.

+ 1. Modify the PowerShell script's `$myAzureADApplicationObjectId` variable to use the object ID of your Microsoft Entra application.

+ > The service principal must be assigned an **owner role** of the Microsoft Entra application to be able to create or modify the secure webhook action in the action group.

+|caller|The email address or Microsoft Entra identifier of the user who performed the operation of the activity log event. |

+- **Secure webhook**: Integrate ITSM with Microsoft Entra authentication.

+ITSMC uses username and password credentials. Secure Webhook has stronger authentication because it uses Microsoft Entra ID. Microsoft Entra ID is Microsoft's cloud-based identity and access management service. It helps users sign in and access internal or external resources. Using Microsoft Entra ID with ITSM helps to identify Azure alerts (through the Microsoft Entra application ID) that were sent to the external system.

+* **Microsoft Entra authentication**: Authentication occurs through Microsoft Entra ID instead of username and password credentials.

+1. The ITSM application checks with Microsoft Entra ID to determine if the alert is authorized to enter the ITSM tool.

+

+* **Better authentication**: Microsoft Entra ID provides more secure authentication without the timeouts that commonly occur in ITSMC.

+<a name='register-with-azure-active-directory'></a>

+## Register with Microsoft Entra ID

+To register the application with Microsoft Entra ID:

+1. In Microsoft Entra ID, select **Expose application**.

+The action group service is a first-party application. It has permission to acquire authentication tokens from your Microsoft Entra application to authenticate with ServiceNow.

+After your application is registered with Microsoft Entra ID, you can create work items in your ITSM tool based on Azure alerts by using the Secure Webhook action in action groups.

+ 1. Select the object ID of the Microsoft Entra instance that you registered.

+ 1. [Register your app with Microsoft Entra ID](./itsm-connector-secure-webhook-connections-azure-configuration.md#register-with-azure-active-directory).

+* Microsoft Entra ID is registered.

+* Microsoft Entra ID is registered.

+|HTTP 400: The \<action\> could not be triggered because Microsoft Entra auth is enabled but no auth context provided in the request. | 1. Check your Secure Webhook action settings.</br>2. Check your Microsoft Entra configuration. For more information, see [action groups](action-groups.md). |

+|</br>HTTP 403: The \<action\> returned a "Forbidden" response.</br>HTTP 403: Couldn't trigger the \<action\>. Make sure you have the required authorization.</br>HTTP 403: The \<action\> returned a 'Forbidden' response. Make sure you have the proper permissions to access it.</br>HTTP 403: The \<action\> is "Forbidden".</br>HTTP 403: Could not access the ITSM system. Make sure you have the required authorization. | 1. Check if the credential in the request is present, and valid.</br>2. Check if your endpoint correctly validates the credentials.</br>3. If it's Secure Webhook, make sure the Microsoft Entra authentication is set up correctly. For more information, see [action groups](action-groups.md).|

+- [Connect ServiceNow with IT Service Management Connector](./itsmc-connections-servicenow.md)

+ Title: Application Insights API Access with Microsoft Entra authentication

+description: Learn how to authenticate and access the Azure Monitor Application Insights APIs using Microsoft Entra ID

+# Application Insights API Access with Microsoft Entra authentication

+You can submit a query request by using the Azure Monitor Application Insights endpoint `https://api.applicationinsights.io`. To access the endpoint, you must authenticate through Microsoft Entra ID.

+To access the API, you register a client app with Microsoft Entra ID and request a token.

+1. [Register an app in Microsoft Entra ID](../logs/api/register-app-for-token.md).

+- Your Microsoft Entra tenant ID.

+- Your Microsoft Entra client ID for the app.

+- A Microsoft Entra client secret for the app.

+The Application Insights API supports Microsoft Entra authentication with three different [Microsoft Entra ID OAuth2](/azure/active-directory/develop/active-directory-protocols-oauth-code) flows:

+In the client credentials flow, the token is used with the Application Insights endpoint. A single request is made to receive a token by using the credentials provided for your app in the previous step when you [register an app in Microsoft Entra ID](../logs/api/register-app-for-token.md).

+When a request is made to the authorize URL, the client\_id is the application ID from your Microsoft Entra app, copied from the app's properties menu. The redirect\_uri is the homepage/login URL from the same Microsoft Entra app. When a request is successful, this endpoint redirects you to the sign-in page you provided at sign-up with the authorization code appended to the URL. See the following example:

+All values are the same as before, with some additions. The authorization code is the same code you received in the previous request after a successful redirect. The code is combined with the key obtained from the Microsoft Entra app. If you didn't save the key, you can delete it and create a new one from the keys tab of the Microsoft Entra app menu. The response is a JSON string that contains the token with the following schema. Types are indicated for the token values.

+ Title: Microsoft Entra authentication for Application Insights

+description: Learn how to enable Microsoft Entra authentication to ensure that only authenticated telemetry is ingested in your Application Insights resources.

+# Microsoft Entra authentication for Application Insights

+Application Insights now supports [Microsoft Entra authentication](../../active-directory/authentication/overview-authentication.md). By using Microsoft Entra ID, you can ensure that only authenticated telemetry is ingested in your Application Insights resources.

+Using various authentication systems can be cumbersome and risky because it's difficult to manage credentials at scale. You can now choose to [opt out of local authentication](#disable-local-authentication) to ensure only telemetry exclusively authenticated by using [managed identities](../../active-directory/managed-identities-azure-resources/overview.md) and [Microsoft Entra ID](../../active-directory/fundamentals/active-directory-whatis.md) is ingested in your resource. This feature is a step to enhance the security and reliability of the telemetry used to make critical operational ([alerting](../alerts/alerts-overview.md#what-are-azure-monitor-alerts)and [autoscale](../autoscale/autoscale-overview.md#overview-of-autoscale-in-azure)) and business decisions.

+> This document covers data ingestion into Application Insights using Microsoft Entra ID. authentication. For information on querying data within Application Insights, see [Query Application Insights using Microsoft Entra authentication](./app-insights-azure-ad-api.md).

+The following prerequisites enable Microsoft Entra authenticated ingestion. You need to:

+The following SDKs and features are unsupported for use with Microsoft Entra authenticated ingestion:

+ Microsoft Entra authentication is only available for Application Insights Java Agent greater than or equal to 3.2.0.

+- [Certificate/secret-based Microsoft Entra ID](../../active-directory/authentication/active-directory-certificate-based-authentication-get-started.md) isn't recommended for production. Use managed identities instead.

+<a name='configure-and-enable-azure-ad-based-authentication'></a>

+## Configure and enable Microsoft Entra ID-based authentication

+ For more information on how to create a Microsoft Entra application and service principal that can access resources, see [Create a service principal](../../active-directory/develop/howto-create-service-principal-portal.md).

+> Support for Microsoft Entra ID in the Application Insights .NET SDK is included starting with [version 2.18-Beta3](https://www.nuget.org/packages/Microsoft.ApplicationInsights/2.18.0-beta3).

+> Support for Microsoft Entra ID in the Application Insights Node.JS is included starting with [version 2.1.0-beta.1](https://www.npmjs.com/package/applicationinsights/v/2.1.0-beta.1).

+> Support for Microsoft Entra ID in the Application Insights Java agent is included starting with [Java 3.2.0-BETA](https://github.com/microsoft/ApplicationInsights-Java/releases/tag/3.2.0-BETA).

+The following example shows how to configure the Java agent to use system-assigned managed identity for authentication with Microsoft Entra ID.

+The following example shows how to configure the Java agent to use user-assigned managed identity for authentication with Microsoft Entra ID.

+The following example shows how to configure the Java agent to use a service principal for authentication with Microsoft Entra ID. We recommend using this type of authentication only during development. The ultimate goal of adding the authentication feature is to eliminate secrets.

+The `APPLICATIONINSIGHTS_AUTHENTICATION_STRING` environment variable lets Application Insights authenticate to Microsoft Entra ID and send telemetry.

+After setting it, restart your application. It now sends telemetry to Application Insights using Microsoft Entra authentication.

+> Microsoft Entra authentication is only available for Python v2.7, v3.6, and v3.7. Support for Microsoft Entra ID in the Application Insights Opencensus Python SDK

+After the Microsoft Entra authentication is enabled, you can choose to disable local authentication. This configuration allows you to ingest telemetry authenticated exclusively by Microsoft Entra ID and affects data access (for example, through API keys).

+The property `DisableLocalAuth` is used to disable any local authentication on your Application Insights resource. When this property is set to `true`, it enforces that Microsoft Entra authentication must be used for all access.

+When developing a custom client to obtain an access token from Microsoft Entra ID for submitting telemetry to Application Insights, refer to the following table to determine the appropriate audience string for your particular host environment.

+This error indicates that the resource is configured for Microsoft Entra-only. The SDK hasn't been correctly configured and is sending to the incorrect API.

+> "v2/track" doesn't support Microsoft Entra ID. When the SDK is correctly configured, telemetry will be sent to "v2.1/track".

+This error indicates that the SDK is correctly configured but it's unable to acquire a valid token. This error might indicate an issue with Microsoft Entra ID.

+Internal logs could be turned on by using the following setup. After they're enabled, error logs will be shown in the console, including any error related to Microsoft Entra integration. Examples include failure to generate the token when the wrong credentials are supplied or errors when the ingestion endpoint fails to authenticate by using the provided credentials.

+If Microsoft Entra ID is enabled in the agent, outbound traffic includes the HTTP header `Authorization`.

+If the following WARN message is seen in the log file `WARN c.m.a.TelemetryChannel - Failed to send telemetry with status code: 401, please check your credentials`, it indicates the agent wasn't successful in sending telemetry. You probably haven't enabled Microsoft Entra authentication on the agent, but your Application Insights resource is configured with `DisableLocalAuth: true`. Make sure you're passing in a valid credential and that it has permission to access your Application Insights resource.

+* [Query Application Insights using Microsoft Entra authentication](./app-insights-azure-ad-api.md)

+- Enabled support for Microsoft Entra authentication.

+- Node.js extension: Updated AI SDK to [2.1.8](https://github.com/microsoft/ApplicationInsights-node.js/releases/tag/2.1.8) from 2.1.7. Added support for User and System assigned Microsoft Entra managed identities.

+|Azure App Service on Windows - Publish as Code | [ :white_check_mark: :link: ](azure-web-apps-net.md) ┬╣ | :x: |

+|Azure App Service on Windows - Publish as Docker | [ :white_check_mark: ](https://azure.github.io/AppService/2022/04/11/windows-containers-app-insights-preview.html) ┬▓ | :x: | :x: |

+|Azure App Service on Linux - Publish as Code | :x: | [ :white_check_mark: :link: ](azure-web-apps-net-core.md?tabs=linux) ┬╣ | [ :white_check_mark: :link: ](azure-web-apps-nodejs.md?tabs=linux) | :x: |

+|Azure Functions - basic | [ :white_check_mark: :link: ](monitor-functions.md) ┬╣ |

+|Azure VMs Windows | [ :white_check_mark: :link: ](azure-vm-vmss-apps.md) ┬▓ | [ :white_check_mark: :link: ](opentelemetry-enable.md?tabs=java) | :x: | :x: |

+|On-premises VMs Windows | [ :white_check_mark: :link: ](application-insights-asp-net-agent.md) ┬│ | [ :white_check_mark: :link: ](opentelemetry-enable.md?tabs=java) | :x: | :x: |

+- ┬╣: Application Insights is on by default and enabled automatically.

+- ┬▓: This feature is in public preview. See [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

+- ┬│: An agent must be deployed and configured.

+1. Select the Log Analytics workspace where you want all future ingested Application Insights telemetry to be stored. It can either be a Log Analytics workspace in the same subscription or a different subscription that shares the same Microsoft Entra tenant. The Log Analytics workspace doesn't have to be in the same resource group as the Application Insights resource.

+You can use authentication to configure the agent to generate [token credentials](/java/api/overview/azure/identity-readme#credentials) that are required for Microsoft Entra authentication.

+* [HTTP](https://github.com/open-telemetry/semantic-conventions/blob/main/docs//http.md)

+* [Messaging](https://github.com/open-telemetry/semantic-conventions/blob/main/docs//messaging.md)

+* [Database](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/database/README.md)

+* [RPC](https://github.com/open-telemetry/semantic-conventions/blob/main/docs//rpc.md)

+| `db.system` | string | Identifier for the database management system (DBMS) product being used. See [list of identifiers](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/database/README.md). |

+- **Recommended:** Secure the Live Metrics channel by using [Microsoft Entra authentication](./azure-ad-authentication.md#configure-and-enable-azure-ad-based-authentication).

+> On September 30, 2025, API keys used to stream Live Metrics telemetry into Application Insights will be retired. After that date, applications that use API keys won't be able to send Live Metrics data to your Application Insights resource. Authenticated telemetry ingestion for Live Metrics streaming to Application Insights will need to be done with [Microsoft Entra authentication for Application Insights](./azure-ad-authentication.md).

+- **Security**: Connection strings allow authenticated telemetry ingestion by using [Microsoft Entra authentication for Application Insights](azure-ad-authentication.md).

+<a name='can-i-use-azure-ad-authentication-with-autoinstrumentation'></a>

+### Can I use Microsoft Entra authentication with autoinstrumentation?

+You can't enable [Microsoft Entra authentication](azure-ad-authentication.md) for [autoinstrumentation](codeless-overview.md) scenarios. We have plans to address this limitation in the future.

+ Core](https://github.com/open-telemetry/opentelemetry-dotnet/blob/1.0.0-rc9.14/src/OpenTelemetry.Instrumentation.AspNetCore/README.md) ┬╣

+- [HttpClient](https://github.com/open-telemetry/opentelemetry-dotnet/blob/1.0.0-rc9.14/src/OpenTelemetry.Instrumentation.Http/README.md) ┬╣

+- [SqlClient](https://github.com/open-telemetry/opentelemetry-dotnet/blob/1.0.0-rc9.14/src/OpenTelemetry.Instrumentation.SqlClient/README.md) ┬╣

+* Logback (including MDC properties) ┬╣ ┬│

+* Log4j (including MDC/Thread Context properties) ┬╣ ┬│

+* JBoss Logging (including MDC properties) ┬╣ ┬│

+* java.util.logging ┬╣ ┬│

+- [HTTP/HTTPS](https://github.com/open-telemetry/opentelemetry-js/tree/main/experimental/packages/opentelemetry-instrumentation-http) ┬▓

+- [Django](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation/opentelemetry-instrumentation-django) ┬╣

+- [FastApi](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation/opentelemetry-instrumentation-fastapi) ┬╣

+- [Flask](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation/opentelemetry-instrumentation-flask) ┬╣

+- [Requests](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation/opentelemetry-instrumentation-requests) ┬╣

+- [`Urllib`](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation/opentelemetry-instrumentation-urllib) ┬╣

+- [`Urllib3`](https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation/opentelemetry-instrumentation-urllib3) ┬╣

+- [Python logging library](https://docs.python.org/3/howto/logging.html) ⁴

+- ┬╣: Supports automatic reporting of *unhandled/uncaught* exceptions

+- ┬▓: Supports OpenTelemetry Metrics

+- ┬│: By default, logging is only collected at INFO level or higher. To change this setting, see the [configuration options](./java-standalone-config.md#autocollected-logging).

+- ⁴: By default, logging is only collected when that logging is performed at the WARNING level or higher.

+Set the Cloud Role Name and the Cloud Role Instance via [Resource](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md#resource-sdk) attributes. Cloud Role Name uses `service.namespace` and `service.name` attributes, although it falls back to `service.name` if `service.namespace` isn't set. Cloud Role Instance uses the `service.instance.id` attribute value. For information on standard attributes for resources, see [Resource Semantic Conventions](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/README.md).

+Set the Cloud Role Name and the Cloud Role Instance via [Resource](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md#resource-sdk) attributes. Cloud Role Name uses `service.namespace` and `service.name` attributes, although it falls back to `service.name` if `service.namespace` isn't set. Cloud Role Instance uses the `service.instance.id` attribute value. For information on standard attributes for resources, see [Resource Semantic Conventions](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/README.md).

+Set the Cloud Role Name and the Cloud Role Instance via [Resource](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md#resource-sdk) attributes. Cloud Role Name uses `service.namespace` and `service.name` attributes, although it falls back to `service.name` if `service.namespace` isn't set. Cloud Role Instance uses the `service.instance.id` attribute value. For information on standard attributes for resources, see [Resource Semantic Conventions](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/README.md).

+Set the Cloud Role Name and the Cloud Role Instance via [Resource](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md#resource-sdk) attributes. Cloud Role Name uses `service.namespace` and `service.name` attributes, although it falls back to `service.name` if `service.namespace` isn't set. Cloud Role Instance uses the `service.instance.id` attribute value. For information on standard attributes for resources, see [Resource Semantic Conventions](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/README.md).

+<a name='enable-entra-id-formerly-azure-ad-authentication'></a>

+## Enable Microsoft Entra ID (formerly Azure AD) authentication

+You might want to enable Microsoft Entra authentication for a more secure connection to Azure, which prevents unauthorized telemetry from being ingested into your subscription.

+|.NET (Exporter) | :white_check_mark: ┬╣ |

+|Java | :white_check_mark: ┬╣ |

+|Node.js | :white_check_mark: ┬╣ |

+|Python | :white_check_mark: ┬╣ |

+|ASP.NET Core | :warning: ┬▓ |

+- ┬╣ :white_check_mark: : OpenTelemetry is available to all customers with formal support.

+- ┬▓ :warning: : OpenTelemetry is available as a public preview. [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/)

+Set the Cloud Role Name and the Cloud Role Instance via [Resource](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md#resource-sdk) attributes. Cloud Role Name uses `service.namespace` and `service.name` attributes, although it falls back to `service.name` if `service.namespace` isn't set. Cloud Role Instance uses the `service.instance.id` attribute value. For information on standard attributes for resources, see [Resource Semantic Conventions](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/README.md).

+> Currently, [Microsoft Entra authentication](azure-ad-authentication.md) is not available with autoinstrumentation. If you require Microsoft Entra auth, you'll need to use manual instrumentation.

+The user must have a [Microsoft account][account] or access to their [organizational Microsoft account](../../active-directory/fundamentals/sign-up-organization.md). You can provide access to individuals and also to user groups defined in Microsoft Entra ID.

+The connection string contains an ikey, which is a unique identifier used by the ingestion service to associate telemetry to a specific Application Insights resource. It's not considered a security token or key. If you want to protect your AI resource from misuse, the ingestion endpoint provides authenticated telemetry ingestion options based on Microsoft Entra ID.

+> The Application Insights JavaScript SDK requires the connection string to be passed in during initialization and configuration. It's viewable in plain text in client browsers. There's no easy way to use the Microsoft Entra ID-based authentication for browser telemetry. We recommend that you consider creating a separate Application Insights resource for browser telemetry if you need to secure the service telemetry.

+ | customEvents ┬╣ | parentId | Name of feature |

+ | customEvents ┬╣ | pageName | Name of page |

+ | customEvents ┬╣ | actionType | Category of Click Analytics record |

+┬╣: To emit these attributes, use the [Click Analytics Autocollection plug-in](javascript-feature-extensions.md) via npm.

+The [Microsoft Entra logs](../active-directory/reports-monitoring/overview-reports.md) for your tenant and the [activity log](essentials/platform-logs-overview.md) for your subscription are collected automatically. When you send them to a Log Analytics workspace, you can analyze these events with other log data by using log queries in Log Analytics. You can also create log query alerts, which are the only way to alert on Microsoft Entra logs and provide more complex logic than activity log alerts.

+There's no cost for sending the activity log to a workspace, but there's a data ingestion and retention charge for Microsoft Entra logs.

+See [Integrate Microsoft Entra logs with Azure Monitor logs](../active-directory/reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md) and [Create diagnostic settings to send platform logs and metrics to different destinations](essentials/diagnostic-settings.md) to create a diagnostic setting for your tenant and subscription to send log entries to your Log Analytics workspace.

+1. Select an object from the performance grid. In the **Properties** pane on the right side, select the **Live Logs** tab. If the AKS cluster is configured with single sign-on by using Microsoft Entra ID, you're prompted to authenticate on first use during that browser session. Select your account and finish authentication with Azure.

+1. Select an object from the performance grid. In the **Properties** pane on the right side, select the **Live Events** tab. If the AKS cluster is configured with single sign-on by using Microsoft Entra ID, you're prompted to authenticate on first use during that browser session. Select your account and finish authentication with Azure.

+1. Select a **Pod** object from the performance grid. In the **Properties** pane on the right side, select the **Live Metrics** tab. If the AKS cluster is configured with single sign-on by using Microsoft Entra ID, you're prompted to authenticate on first use during that browser session. Select your account and finish authentication with Azure.

+- To see predefined queries and examples to create alerts and visualizations or perform further analysis of your clusters, see [How to query logs from Container insights](container-insights-log-query.md).

+- AKS enabled with Microsoft Entra SAML-based single sign-on

+These instructions require administrative access to your Kubernetes cluster. If you're configuring to use Microsoft Entra ID for user authentication, you also need administrative access to Microsoft Entra ID.

+- Microsoft Entra integrated AKS cluster

+The Azure portal prompts you to validate your sign-in credentials for a Microsoft Entra ID cluster. It redirects you to the client registration setup during cluster creation (and reconfigured in this article). This behavior is similar to the authentication process required by `kubectl`.

+>This configuration file contains the authorization and authentication token for the *Azure Kubernetes Service Cluster User Role*, in the case of Azure RBAC enabled and AKS clusters without Kubernetes RBAC authorization enabled. It contains information about Microsoft Entra ID and client registration details when AKS is enabled with Microsoft Entra SAML-based single sign-on.

+If you have a Kubernetes cluster that isn't configured with Kubernetes RBAC authorization or integrated with Microsoft Entra single sign-on, you don't need to follow these steps. You already have administrative permissions by default in a non-RBAC configuration.

+<a name='configure-azure-ad-integrated-authentication'></a>

+## Configure Microsoft Entra integrated authentication

+An AKS cluster configured to use Microsoft Entra ID for user authentication uses the sign-in credentials of the person accessing this feature. In this configuration, you can sign in to an AKS cluster by using your Microsoft Entra authentication token.

+Microsoft Entra client registration must be reconfigured to allow the Azure portal to redirect authorization pages as a trusted redirect URL. Users from Microsoft Entra ID are then granted access directly to the same Kubernetes API endpoints through **ClusterRoles** and **ClusterRoleBindings**.

+>If you're creating a new Kubernetes RBAC-enabled cluster, see [Integrate Microsoft Entra ID with Azure Kubernetes Service](../../aks/azure-ad-integration-cli.md) and follow the steps to configure Microsoft Entra authentication. During the steps to create the client application, a note in that section highlights the two redirect URLs you need to create for Container insights matching those specified in step 3.

+1. Locate the client registration for your Kubernetes cluster in Microsoft Entra ID under **Microsoft Entra ID** > **App registrations** in the Azure portal.

+You can configure authentication with Microsoft Entra ID for single sign-on only during initial deployment of a new AKS cluster. You can't configure single sign-on for an AKS cluster that's already deployed.

+>If you reconfigured Microsoft Entra ID for user authentication by using the updated URI, clear your browser's cache to ensure the updated authentication token is downloaded and applied.

+Each Microsoft Entra account must be granted permission to the appropriate APIs in Kubernetes to access the Live Data feature. The steps to grant the Microsoft Entra account are similar to the steps described in the [Kubernetes RBAC authentication](#configure-kubernetes-rbac-authorization) section. Before you apply the YAML configuration template to your cluster, replace **clusterUser** under **ClusterRoleBinding** with the desired user.

+>If the user you grant the Kubernetes RBAC binding for is in the same Microsoft Entra tenant, assign permissions based on `userPrincipalName`. If the user is in a different Microsoft Entra tenant, query for and use the `objectId` property.

+ You can attach an AKS cluster to a Log Analytics workspace in a different Azure subscription in the same Microsoft Entra tenant. Currently, you can't do it with the Azure portal, but you can use the Azure CLI or an Azure Resource Manager template.

+1. For clusters with Microsoft Entra pod identity enabled and using MSI:

+> We recommend using Microsoft Entra Workload ID. This authentication method replaces pod-managed identity (preview), which integrates with the Kubernetes native capabilities to federate with any external identity providers on behalf of the application.

+> The open source Microsoft Entra pod-managed identity (preview) in Azure Kubernetes Service has been deprecated as of 10/24/2022, and the project will be archived in Sept. 2023. For more information, see the deprecation notice. The AKS Managed add-on begins deprecation in Sept. 2023.

+ + `USER_ASSIGNED_IDENTITY_NAME` is the name of the Microsoft Entra identity that's created for KEDA.

+| guard | Enable if Microsoft Entra ID is enabled | Log Analytics workspace |

+ Title: Microsoft Entra authorization proxy

+description: Microsoft Entra authorization proxy

+# Microsoft Entra authorization proxy

+The Microsoft Entra authorization proxy is a reverse proxy, which can be used to authenticate requests using Microsoft Entra ID. This proxy can be used to authenticate requests to any service that supports Microsoft Entra authentication. Use this proxy to authenticate requests to Azure Monitor managed service for Prometheus.

+For for more information, see [Microsoft Entra authentication proxy](https://github.com/Azure/aad-auth-proxy) project.

+ Title: Remote-write in Azure Monitor Managed Service for Prometheus using Microsoft Entra ID

+description: Describes how to configure remote-write to send data from self-managed Prometheus running in your Kubernetes cluster running on-premises or in another cloud using Microsoft Entra authentication.

+# Configure remote write for Azure Monitor managed service for Prometheus using Microsoft Entra authentication

+This article describes how to configure [remote-write](prometheus-remote-write.md) to send data from self-managed Prometheus running in your AKS cluster or Azure Arc-enabled Kubernetes cluster using Microsoft Entra authentication.

+<a name='create-azure-active-directory-application'></a>

+## Create Microsoft Entra application

+Follow the procedure at [Register an application with Microsoft Entra ID and create a service principal](../../active-directory/develop/howto-create-service-principal-portal.md#register-an-application-with-azure-ad-and-create-a-service-principal) to register an application for Prometheus remote-write and create a service principal.

+<a name='get-the-client-id-of-the-azure-active-directory-application'></a>

+## Get the client ID of the Microsoft Entra application.

+1. From the **Microsoft Entra ID** menu in the Azure Portal, select **App registrations**.

+ :::image type="content" source="media/prometheus-remote-write-active-directory/application-client-id.png" alt-text="Screenshot showing client ID of Microsoft Entra application." lightbox="media/prometheus-remote-write-active-directory/application-client-id.png":::

+<a name='add-certificate-to-the-azure-active-directory-application'></a>

+## Add certificate to the Microsoft Entra application

+1. From the menu for your Microsoft Entra application, select **Certificates & secrets**.

+ :::image type="content" source="media/prometheus-remote-write-active-directory/upload-certificate.png" alt-text="Screenshot showing upload of certificate for Microsoft Entra application." lightbox="media/prometheus-remote-write-active-directory/upload-certificate.png":::

+ # Required only for Microsoft Entra ID based auth

+ # Required only for Microsoft Entra ID based auth

+ | `<TENANT-ID> ` | Tenant ID of the Microsoft Entra application |

+- [Configure remote write for Azure Monitor managed service for Prometheus using Microsoft Entra pod identity (preview)](./prometheus-remote-write-azure-ad-pod-identity.md)

+ Title: Configure remote write for Azure Monitor managed service for Prometheus using Microsoft Entra pod identity (preview)

+description: Configure remote write for Azure Monitor managed service for Prometheus using Microsoft Entra pod identity (preview)

+# Configure remote write for Azure Monitor managed service for Prometheus using Microsoft Entra pod identity (preview)

+> The remote write sidecar should only be configured via the following steps only if the AKS cluster already has the Microsoft Entra pod enabled. This approach is not recommended as Microsoft Entra pod identity has been deprecated to be replace by [Azure Workload Identity](/azure/active-directory/workload-identities/workload-identities-overview)

+To configure remote write for Azure Monitor managed service for Prometheus using Microsoft Entra pod identity, follow the steps below.

+- [Remote-write in Azure Monitor Managed Service for Prometheus using Microsoft Entra ID](./prometheus-remote-write-active-directory.md)

+ Title: Configure remote write for Azure managed service for Prometheus using Microsoft Entra Workload ID (preview)

+description: Configure remote write for Azure Monitor managed service for Prometheus using Microsoft Entra Workload ID (preview)

+# Configure remote write for Azure managed service for Prometheus using Microsoft Entra Workload ID (preview)

+This article describes how to configure [remote-write](prometheus-remote-write.md) to send data from your Azure managed Prometheus cluster using Microsoft Entra Workload ID.

+ * For managed clusters (AKS/EKS/GKE), see [Managed Clusters - Microsoft Entra Workload ID](https://azure.github.io/azure-workload-identity/docs/installation/managed-clusters.html)

+ * For self-managed clusters, see [Self-Managed Clusters - Microsoft Entra Workload ID](https://azure.github.io/azure-workload-identity/docs/installation/self-managed-clusters.html)

+* Installed mutating admission webhook. For more information, see [Mutating Admission Webhook - Microsoft Entra Workload ID](https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html)

+1. Create a Microsoft Entra app or user assigned managed identity and grant permission to publish metrics to Azure Monitor workspace.

+ Assign the *Monitoring Metrics Publisher* role to the Microsoft Entra app or user-assigned managed identity. For more information, see [Assign Monitoring Metrics Publisher role on the data collection rule to the managed identity](prometheus-remote-write-managed-identity.md#assign-monitoring-metrics-publisher-role-on-the-data-collection-rule-to-the-managed-identity).

+ If your Microsoft Entra app or user assigned managed identity isn't in the same tenant as your cluster, add the following annotation to your service account:

+ * Microsoft Entra ID

+ # Get the ObjectID of the Microsoft Entra app.

+* [Remote-write in Azure Monitor Managed Service for Prometheus using Microsoft Entra ID](./prometheus-remote-write-active-directory.md)

+* [Configure remote write for Azure Monitor managed service for Prometheus using Microsoft Entra pod identity (preview)](./prometheus-remote-write-azure-ad-pod-identity.md)

+> For a Kubernetes cluster running in another cloud or on-premises, see [Azure Monitor managed service for Prometheus remote write - Microsoft Entra ID](prometheus-remote-write-active-directory.md).

+- [Remote-write in Azure Monitor Managed Service for Prometheus using Microsoft Entra ID](./prometheus-remote-write-active-directory.md)

+- [Configure remote write for Azure Monitor managed service for Prometheus using Microsoft Entra pod identity (preview)](./prometheus-remote-write-azure-ad-pod-identity.md)

+Azure Monitor provides a reverse proxy container (Azure Monitor [side car container](/azure/architecture/patterns/sidecar)) that provides an abstraction for ingesting Prometheus remote write metrics and helps in authenticating packets. The Azure Monitor side car container currently supports User Assigned Identity and Microsoft Entra ID based authentication to ingest Prometheus remote write metrics to Azure Monitor workspace.

+- **Microsoft Entra ID** can be used for Azure Kubernetes service (AKS) and Azure Arc-enabled Kubernetes cluster and is required for Kubernetes cluster running in another cloud or on-premises. See [Azure Monitor managed service for Prometheus remote write - Microsoft Entra ID](prometheus-remote-write-active-directory.md)

+> Whether you use Managed Identity or Microsoft Entra ID to enable permissions for ingesting data, these settings take some time to take effect. When following the steps below to verify that the setup is working please allow up to 10-15 minutes for the authorization settings needed to ingest data to complete.

+- [Remote-write in Azure Monitor Managed Service for Prometheus using Microsoft Entra ID](./prometheus-remote-write-active-directory.md)

+- [Configure remote write for Azure Monitor managed service for Prometheus using Microsoft Entra pod identity (preview)](./prometheus-remote-write-azure-ad-pod-identity.md)

+| [Azure Tenant](#azure-tenant) | Data about the operation of tenant-level Azure services, such as Microsoft Entra ID. | View Microsoft Entra data in portal or configure collection to Azure Monitor using a tenant diagnostic setting. |

+Telemetry related to your Azure tenant is collected from tenant-wide services such as Microsoft Entra ID.

+<a name='azure-active-directory-audit-logs'></a>

+### Microsoft Entra audit logs

+[Microsoft Entra ID reporting](../active-directory/reports-monitoring/overview-reports.md) contains the history of sign-in activity and audit trail of changes made within a particular tenant.

+| Azure Monitor Logs | Configure Microsoft Entra logs to be collected in Azure Monitor to analyze them with other monitoring data. | [Integrate Microsoft Entra logs with Azure Monitor logs](../active-directory/reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md) |

+| Azure Storage | Export Microsoft Entra logs to Azure Storage for archiving. | [Tutorial: Archive Microsoft Entra logs to an Azure storage account](../active-directory/reports-monitoring/quickstart-azure-monitor-route-logs-to-storage-account.md) |

+| Event Hubs | Stream Microsoft Entra logs to other locations using Event Hubs. | [Tutorial: Stream Microsoft Entra logs to an Azure event hub](../active-directory/reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md). |

+Create a service principal in your Microsoft Entra tenant by using the instructions at [Create a service principal](../../active-directory/develop/howto-create-service-principal-portal.md). Note the following while going through this process:

+- Learn more about [custom metrics](./metrics-custom-overview.md).

+Create a service principal in your Microsoft Entra tenant by using the instructions at [Use portal to create a Microsoft Entra application and service principal that can access resources](../../active-directory/develop/howto-create-service-principal-portal.md). Note the following while you're going through this process:

+Any destinations for the diagnostic setting must be created before you create the diagnostic settings. The destination doesn't have to be in the same subscription as the resource sending logs if the user who configures the setting has appropriate Azure role-based access control access to both subscriptions. By using Azure Lighthouse, it's also possible to have diagnostic settings sent to a workspace, storage account, or event hub in another Microsoft Entra tenant.

+To submit custom metrics to Azure Monitor, the entity that submits the metric needs a valid Microsoft Entra token in the **Bearer** header of the request. Supported ways to acquire a valid bearer token include:

+- [Microsoft Entra service principal](../../active-directory/develop/app-objects-and-service-principals.md). In this scenario, a Microsoft Entra application, or service, can be assigned permissions to emit metrics about an Azure resource. To authenticate the request, Azure Monitor validates the application token by using Microsoft Entra public keys. The existing **Monitoring Metrics Publisher** role already has this permission. It's available in the Azure portal.

+> When you request a Microsoft Entra token to emit custom metrics, ensure that the audience or resource that the token is requested for is `https://monitoring.azure.com/`. Be sure to include the trailing slash.

+A service principal is an application whose tokens can be used to authenticate and grant access to specific Azure resources by using Microsoft Entra ID. Resources include user apps, services, or automation tools.

+1. [Register an application with Microsoft Entra ID](../logs/api/register-app-for-token.md) to create a service principal.

+| [Microsoft Entra logs](../../active-directory/reports-monitoring/overview-reports.md) | Azure Tenant | Microsoft Entra logs contain the history of sign-in activity and an audit trail of changes made in Microsoft Entra ID for a particular tenant. |

+- View Microsoft Entra security and activity reports in the Azure portal. See [What are Microsoft Entra reports?](../../active-directory/reports-monitoring/overview-reports.md) for details.

+- For details on how to create a diagnostic setting for Microsoft Entra logs, see the following articles:

+ - [Integrate Microsoft Entra logs with Azure Monitor logs](../../active-directory/reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md)

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

+ - [Tutorial: Archive Microsoft Entra logs to an Azure Storage account](../../active-directory/reports-monitoring/quickstart-azure-monitor-route-logs-to-storage-account.md)

+To query your Azure Monitor workspace, authenticate using Microsoft Entra ID.

+The API supports Microsoft Entra authentication using client credentials. Register a client app with Microsoft Entra ID and request a token.

+To set up Microsoft Entra authentication, follow the steps below:

+1. Register an app with Microsoft Entra ID.

+<a name='register-an-app-with-azure-active-directory'></a>

+### Register an app with Microsoft Entra ID

+For information on using Grafana with Active Directory, see [Configure self-managed Grafana to use Azure Monitor managed Prometheus with Microsoft Entra ID](./prometheus-self-managed-grafana-azure-active-directory.md).

+- [Configure self-managed Grafana to use Azure-managed Prometheus with Microsoft Entra ID](./prometheus-self-managed-grafana-azure-active-directory.md).

+ Title: Configure self-hosted Grafana to use Azure Monitor managed service for Prometheus as data source using Microsoft Entra ID.

+description: How to configure Azure Monitor managed service for Prometheus as data source for both Azure Managed Grafana and self-hosted Grafana using Microsoft Entra ID.

+# Configure self-managed Grafana to use Azure Monitor managed service for Prometheus with Microsoft Entra ID.

+[Azure Monitor managed service for Prometheus](prometheus-metrics-overview.md) allows you to collect and analyze metrics at scale using a [Prometheus](https://aka.ms/azureprometheus-promio)-compatible monitoring solution. The most common way to analyze and present Prometheus data is with a Grafana dashboard. This article explains how to configure Prometheus as a data source for [self-hosted Grafana](https://grafana.com/) using Microsoft Entra ID.

+<a name='azure-active-directory-authentication'></a>

+## Microsoft Entra authentication

+To set up Microsoft Entra authentication, follow the steps below:

+1. Register an app with Microsoft Entra ID.

+<a name='register-an-app-with-azure-active-directory'></a>

+## Register an app with Microsoft Entra ID

+1. Search for the app that you registered in the [Register an app with Microsoft Entra ID](#register-an-app-with-azure-active-directory) section and select it.

+1. Enter the **Direct(tenant) ID**, **Application (client) ID**, and the **Client secret** from the [Register an app with Microsoft Entra ID](#register-an-app-with-azure-active-directory) section.

+| Microsoft Entra ID | [Overview](../../active-directory/reports-monitoring/concept-activity-logs-azure-monitor.md), [Audit log schema](../../active-directory/reports-monitoring/overview-reports.md), [Sign-ins schema](../../active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema.md) |

+Request submitted using the Azure Monitor API use the Azure Resource Manager authentication model. All requests are authenticated with Microsoft Entra ID. One approach to authenticating the client application is to create a Microsoft Entra service principal and retrieve an authentication token. You can create a Microsoft Entra service principal using the Azure portal, CLI, or PowerShell. For more information, see [Register an App to request authorization tokens and work with APIs](../logs/api/register-app-for-token.md)

+| [Azure tenant](../data-sources.md#azure-tenant) | Microsoft Entra audit logs | Configure a tenant diagnostic setting on your Microsoft Entra tenant. For more information, see [Tutorial: Stream Microsoft Entra logs to an Azure event hub](../../active-directory/reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md). |

+| [Azure Monitor Workbooks for Microsoft Entra ID](../../active-directory/reports-monitoring/howto-use-azure-monitor-workbooks.md) | General availability (GA) | [Yes](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Workbooks) | Microsoft Entra ID provides workbooks to understand the effect of your Conditional Access policies, troubleshoot sign-in failures, and identify legacy authentications. |

+You can submit a query request to a workspace by using the Azure Monitor Log Analytics endpoint `https://api.loganalytics.azure.com`. To access the endpoint, you must authenticate through Microsoft Entra ID.

+To quickly explore the API without Microsoft Entra authentication, use the demonstration workspace with sample data, which supports API key authentication.

+To access the API, you register a client app with Microsoft Entra ID and request a token.

+1. [Register an app in Microsoft Entra ID](./register-app-for-token.md).

+- Your Microsoft Entra tenant ID.

+- Your Microsoft Entra client ID for the app.

+- A Microsoft Entra client secret for the app.

+The Log Analytics API supports Microsoft Entra authentication with three different [Microsoft Entra ID OAuth2](/azure/active-directory/develop/active-directory-protocols-oauth-code) flows:

+In the client credentials flow, the token is used with the Log Analytics endpoint. A single request is made to receive a token by using the credentials provided for your app in the previous step when you [register an app in Microsoft Entra ID](./register-app-for-token.md).

+When a request is made to the authorize URL, the client\_id is the application ID from your Microsoft Entra app, copied from the app's properties menu. The redirect\_uri is the homepage/login URL from the same Microsoft Entra app. When a request is successful, this endpoint redirects you to the sign-in page you provided at sign-up with the authorization code appended to the URL. See the following example:

+All values are the same as before, with some additions. The authorization code is the same code you received in the previous request after a successful redirect. The code is combined with the key obtained from the Microsoft Entra app. If you didn't save the key, you can delete it and create a new one from the keys tab of the Microsoft Entra app menu. The response is a JSON string that contains the token with the following schema. Types are indicated for the token values.

+You can find documentation about OAuth2 with Microsoft Entra here:

+ - [Microsoft Entra authorization code flow](/azure/active-directory/develop/active-directory-protocols-oauth-code)

+ - [Microsoft Entra implicit grant flow](/azure/active-directory/develop/active-directory-dev-understanding-oauth2-implicit-grant)

+ - [Microsoft Entra S2S client credentials flow](/azure/active-directory/develop/active-directory-protocols-oauth-service-to-service)

+The Azure Monitor Log Analytics API supports batching queries together. Batch queries currently require Microsoft Entra authentication.

+- 403 - Forbidden. The token provided does not have access to the resource you are trying to access. Make sure that your token request has the correct resource, and you have granted permissions for your Microsoft Entra application.

+The token is malformed or otherwise invalid. This error can occur if you manually copy and paste the token and add or cut characters to the payload. Verify that the token is exactly as received from Microsoft Entra ID.

+The token you've presented for authorization belongs to a user who doesn't have sufficient access to this privilege. Verify that your workspace GUID and your token request are correct. If necessary, grant IAM privileges in your workspace to the Microsoft Entra application you created as Contributor.

+> When you use Microsoft Entra authentication, it might take up to 60 minutes for the Application Insights REST API to recognize new role-based access control permissions. While permissions are propagating, REST API calls might fail with error code 403.

+The authorization code submitted in the token request was either stale or previously used. Reauthorize via the Microsoft Entra authorize endpoint to get a new code.

+- To query your workspaces, you must use [Microsoft Entra authentication](../../../active-directory/fundamentals/active-directory-whatis.md).

+- To quickly explore the API without using Microsoft Entra authentication, you can use an API key to query sample data in a non-production environment.

+<a name='azure-ad-authentication-for-workspace-data'></a>

+### Microsoft Entra authentication for workspace data

+The Log Analytics API supports Microsoft Entra authentication with three different [Microsoft Entra ID OAuth2](/azure/active-directory/develop/active-directory-protocols-oauth-code) flows:

+To quickly explore the API without using Microsoft Entra authentication, we provide a demonstration workspace with sample data. You can [authenticate by using an API key](./access-api.md#authenticate-with-a-demo-api-key).

+> When you use Microsoft Entra authentication, it might take up to 60 minutes for the Application Insights REST API to recognize new role-based access control permissions. While permissions are propagating, REST API calls might fail with [error code 403](./errors.md#insufficient-permissions).

+The following sample script demonstrates creating a Microsoft Entra service principal via PowerShell. For a more detailed walkthrough, see [using Azure PowerShell to create a service principal to access resources](../../../active-directory/develop/howto-authenticate-service-principal-powershell.md)

+> When using Microsoft Entra authentication, it may take up to 60 minutes for the Azure Application Insights REST API to recognize new role-based access control (RBAC) permissions. While permissions are propagating, REST API calls may fail with error code 403.

+While the URLs are different, the query parameters are the same for each endpoint. Both endpoints require authorization through Microsoft Entra ID.

+```

+ Title: Microsoft Entra authentication for Azure Monitor Logs

+description: Learn how to enable Microsoft Entra authentication for Log Analytics in Azure Monitor.

+# Microsoft Entra authentication for Azure Monitor Logs

+These options might be cumbersome and pose a risk because it's difficult to manage credentials, specifically workspace keys, at a large scale. You can opt out of local authentication and ensure that only telemetry that's exclusively authenticated by using Managed Identities and Microsoft Entra ID is ingested into Azure Monitor. This feature enhances the security and reliability of the telemetry used to make critical operational and business decisions.

+To enable Microsoft Entra integration for Azure Monitor Logs and remove reliance on these shared secrets:

+1. Ensure that only authenticated telemetry is ingested in your Application Insights resources with [Microsoft Entra authentication for Application Insights (preview)](../app/azure-ad-authentication.md).

+- The Data Collector API (preview) won't support Microsoft Entra authentication and won't be available to ingest data.

+The `DisableLocalAuth` property is used to disable any local authentication on your Log Analytics workspace. When set to `true`, this property enforces that Microsoft Entra authentication must be used for all access.

+The `DisableLocalAuth` property is used to disable any local authentication on your Log Analytics workspace. When set to `true`, this property enforces that Microsoft Entra authentication must be used for all access.

+The `DisableLocalAuth` property is used to disable any local authentication on your Log Analytics workspace. When set to `true`, this property enforces that Microsoft Entra authentication must be used for all access.

+See [Microsoft Entra authentication for Application Insights (preview)](../app/azure-ad-authentication.md).

+If you manage subscriptions in other Microsoft Entra tenants through [Azure Lighthouse](../../lighthouse/overview.md), you can include [Log Analytics workspaces created in those customer tenants](../../lighthouse/how-to/monitor-at-scale.md) in your queries.

+- [A Microsoft Entra application to authenticate API calls](../logs/tutorial-logs-ingestion-portal.md#create-azure-ad-application) or any other Resource Manager authentication scheme.

+Azure Monitor uses managed identity to grant access to your Azure Key Vault. The identity of the Log Analytics cluster is supported at the cluster level. To allow Customer-managed key on multiple workspaces, a Log Analytics Cluster resource performs as an intermediate identity connection between your Key Vault and your Log Analytics workspaces. The cluster's storage uses the managed identity that\'s associated with the Cluster resource to authenticate to your Azure Key Vault via Microsoft Entra ID.

+- Azure Storage uses managed identity that's associated with the *Cluster* resource for authentication. It accesses Azure Key Vault via Microsoft Entra ID.

+- Your Azure Key Vault, cluster and workspaces must be in the same region and in the same Microsoft Entra tenant, but they can be in different subscriptions.

+- If you transfer a subscription between Microsoft Entra directories, you need to follow the steps described in [Known issues with managed identities for Azure resources](/azure/active-directory/managed-identities-azure-resources/known-issues#transferring-a-subscription-between-azure-ad-directories) to continue ingesting data.

+The data export destination must be available before you create export rules in your workspace. Destinations don't have to be in the same subscription as your workspace. When you use Azure Lighthouse, it's also possible to send data to destinations in another Microsoft Entra tenant.

+When developing a custom client to obtain an access token from Microsoft Entra ID for the purpose of submitting telemetry to Log Ingestion API in Azure Monitor, refer to the table provided below to determine the appropriate audience string for your particular host environment.

+**Example 5: Grant a user permission to read log data from their resources and all Microsoft Entra sign-in and read Update Management solution log data in the Log Analytics workspace.**

+ - `Microsoft.OperationalInsights/workspaces/query/SigninLogs/read`: To be able to read Microsoft Entra sign-in logs

+| **Azure** | [Diagnostic settings](../essentials/diagnostic-settings.md) | | **Azure tenant** - Microsoft Entra audit logs provide sign-in activity history and audit trail of changes made within a tenant.<br/>**Azure resources** - Logs and performance counters.<br/>**Azure subscription** - Service health records along with records on any configuration changes made to the resources in your Azure subscription. |

+"Access to the subscription was lost. Ensure that the \<**subscription id**\> subscription is in the \<**tenant id**\> Microsoft Entra tenant. If the subscription is transferred to another tenant, there's no impact to the services, but information for the tenant could take up to an hour to propagate."

+| Verify the Microsoft Entra tenant. | `Microsoft.AzureActiveDirectory/b2cDirectories/read` permissions, as provided by the [Log Analytics Reader built-in role](./manage-access.md#log-analytics-reader), for example. |

+<a name='verify-the-azure-active-directory-tenant'></a>

+## Verify the Microsoft Entra tenant

+The workspace source and destination subscriptions must exist within the same Microsoft Entra tenant. Use Azure PowerShell to verify that both subscriptions have the same tenant ID.

+[Find your Microsoft Entra tenant](../../azure-portal/get-subscription-tenant-id.md#find-your-azure-ad-tenant) for the source and destination subscriptions.

+|[Azure Identity client library](/python/api/overview/azure/identity-readme)|Enables Azure SDK clients to authenticate with Microsoft Entra ID.|

+ `LogsQueryClient` typically only supports authentication with Microsoft Entra token credentials. However, we can pass a custom authentication policy to enable the use of API keys. This allows the client to [query the demo workspace](../logs/api/access-api.md#authenticate-with-a-demo-api-key). The availability and access to this demo workspace is subject to change, so we recommend using your own Log Analytics workspace.

+1. To send data to your Log Analytics workspace, you need a custom table, data collection endpoint, data collection rule, and a registered Microsoft Entra application with permission to use the data collection rule, as explained in [Tutorial: Send data to Azure Monitor Logs with Logs ingestion API (Azure portal)](../logs/tutorial-logs-ingestion-portal.md).

+* **User IDs**: By default, Application Insights uses randomly generated IDs for user and session tracking in fields such as *session_Id*, *user_Id*, *user_AuthenticatedId*, *user_AccountId*, and *customDimensions*. However, it's common to override these fields with an ID that's more relevant to the application, such as usernames or Microsoft Entra GUIDs. These IDs are often considered to be personal data. We recommend obfuscating or anonymizing these IDs.

+| AADObjectId | Microsoft Entra ID of the user account that started the query. |

+- A Microsoft Entra application to authenticate against the API and:

+ - A service principal on the Microsoft Entra application

+ - A secret for the Microsoft Entra application

+1. [Create a Microsoft Entra application](#create-azure-ad-application) to authenticate against the API.

+<a name='create-azure-ad-application'></a>

+## Create Microsoft Entra application

+Start by registering a Microsoft Entra application to authenticate against the API. Any Resource Manager authentication scheme is supported, but this tutorial follows the [Client Credential Grant Flow scheme](../../active-directory/develop/v2-oauth2-client-creds-grant-flow.md).

+1. On the **Microsoft Entra ID** menu in the Azure portal, select **App registrations** > **New registration**.

+3. Create the following environment variables with values for your Microsoft Entra application. These values are used by `DefaultAzureCredential` in the Azure Identity library.

+1. Create the following environment variables with values for your Microsoft Entra application. These values are used by `DefaultAzureCredential` in the Azure Identity module.

+1. Create the following environment variables with values for your Microsoft Entra application. These values are used by `DefaultAzureCredential` in the Azure Identity library.

+1. Create the following environment variables with values for your Microsoft Entra application. These values are used by `DefaultAzureCredential` in the Azure Identity library.

+1. Create the following environment variables with values for your Microsoft Entra application. These values are used by `DefaultAzureCredential` in the Azure Identity library.

+1. [Create a Microsoft Entra application](#create-azure-ad-application) to authenticate against the API.

+<a name='create-azure-ad-application'></a>

+## Create Microsoft Entra application

+Start by registering a Microsoft Entra application to authenticate against the API. Any Resource Manager authentication scheme is supported, but this tutorial will follow the [Client Credential Grant Flow scheme](../../active-directory/develop/v2-oauth2-client-creds-grant-flow.md).

+1. On the **Microsoft Entra ID** menu in the Azure portal, select **App registrations** > **New registration**.

+- Use [Azure Lighthouse](../../lighthouse/overview.md) to access each customer tenant. The service provider administrators are included in a Microsoft Entra user group in the service provider's tenant. This group is granted access during the onboarding process for each customer. The administrators can then access each customer's workspaces from within their own service provider tenant instead of having to sign in to each customer's tenant individually. For more information, see [Monitor customer resources at scale](../../lighthouse/how-to/monitor-at-scale.md).

+- Add individual users from the service provider as [Microsoft Entra guest users (B2B)](../../active-directory/external-identities/what-is-b2b.md). The customer tenant administrators manage individual access for each service provider administrator. The service provider administrators must sign in to the directory for each tenant in the Azure portal to access these workspaces.

+|Azure Platform|**Azure resource** - Data about the operation of an Azure resource from inside the resource, including changes. Resource Logs are one example. <br><br>**Azure subscription** - The operation and management of an Azure subscription, and data about the health and operation of Azure itself. The activity log is one example.<br><br>**Azure tenant** - Data about the operation of tenant-level Azure services, such as Microsoft Entra ID.<br> |

+- Single sign-on: You can easily enable SSO through Microsoft Entra ID.

+A BYOS storage account is linked to an Application Insights resource. Start by granting the `Storage Blob Data Contributor` role to the Microsoft Entra application named `Diagnostic Services Trusted Storage Access` via the [Access Control (IAM)](../../role-based-access-control/role-assignments-portal.md) page in your storage account.

+- [Learn more about Snapshot Debugger](../snapshot-debugger/snapshot-debugger.md)

+<a name='enable-azure-active-directory-authentication-for-profile-ingestion'></a>

+## Enable Microsoft Entra authentication for profile ingestion

+Application Insights Profiler supports Microsoft Entra authentication for profile ingestion. For all profiles of your application to be ingested, your application must be authenticated and provide the required application settings to the Profiler agent.

+Profiler only supports Microsoft Entra authentication when you reference and configure Microsoft Entra ID by using the [Application Insights SDK](../app/asp-net-core.md#configure-the-application-insights-sdk) in your application.

+To enable Microsoft Entra ID for profile ingestion:

+1. [Configure and enable Microsoft Entra ID](../app/azure-ad-authentication.md?tabs=net#configure-and-enable-azure-ad-based-authentication) in your Application Insights resource.

+<a name='enable-azure-active-directory-authentication-for-snapshot-ingestion'></a>

+## Enable Microsoft Entra authentication for snapshot ingestion

+Application Insights Snapshot Debugger supports Microsoft Entra authentication for snapshot ingestion. This means, for all snapshots of your application to be ingested, your application must be authenticated and provide the required application settings to the Snapshot Debugger agent.

+As of today, Snapshot Debugger only supports Microsoft Entra authentication when you reference and configure Microsoft Entra ID using the Application Insights SDK in your application.

+To turn-on Microsoft Entra ID for snapshot ingestion:

+1. Configure and turn on Microsoft Entra ID in your Application Insights resource. For more information, see the following [documentation](../app/azure-ad-authentication.md?tabs=net#configure-and-enable-azure-ad-based-authentication)

+Addressed multiple improvements and added support for Microsoft Entra authentication for Application Insights ingestion.

+Added Microsoft Entra authentication to `SnapshotCollector`. To learn more about Microsoft Entra authentication in Application Insights, see [Microsoft Entra authentication for Application Insights](../app/azure-ad-authentication.md).

+- Manage user authentication and access control by using Microsoft Entra identities.

+1. Create a service principal. Grafana uses a Microsoft Entra service principal to connect to Azure Monitor APIs and collect data. You must create, or use an existing service principal, to manage access to your Azure resources:

+ * See [Create a Microsoft Entra app and service principal in the portal](../../active-directory/develop/howto-create-service-principal-portal.md) to create a service principal. Copy and save your tenant ID (Directory ID), client ID (Application ID), and client secret (Application key value).

+ * View [Assign application to role](../../active-directory/develop/howto-create-service-principal-portal.md) to assign the [Monitoring Reader role](../roles-permissions-security.md) to the Microsoft Entra application on the subscription, resource group, or resource you want to monitor.

+ > * Client ID is the Microsoft Entra Application ID.

+ > * Client Secret is the Microsoft Entra Application key value.

+| Workbooks in Microsoft Entra ID | `microsoft.aadiam/tenant` | `workbook` |

+## September 2023

+|Subservice | Article | Description |

+||||

+Agents|[Define Azure Monitor Agent network settings](agents/azure-monitor-agent-data-collection-endpoint.md)|Added an example of Azure Monitor Agent deployment with an Azure Resource Manager policy template.|

+Agents|[Migrate to Azure Monitor Agent from Log Analytics agent](agents/azure-monitor-agent-migration.md)|VM Insights with Azure Monitor Agent is now generally available.|

+Alerts|[Manage your alert instances](alerts/alerts-manage-alert-instances.md)|Updated documentation to clarify that Azure Monitor alerts are stored for 30 days and are deleted after the 30-day retention period. For stateful alerts, while the alert itself is deleted after 30 days, and isn't viewable on the alerts page, the alert condition is stored until the alert is resolved, to prevent firing another alert, and so that notifications can be sent when the alert is resolved.|

+Alerts|[Troubleshooting problems in Azure Monitor alerts](alerts/alerts-troubleshoot.md)|Added a new article describing the process for migrating from the alertsSummary API, which is being deprecated in September 2026. You can use Azure Resource Graph's functionality to get the same information returned by the alertsSummary API.|

+Alerts|[Troubleshoot log alerts in Azure Monitor](alerts/alerts-troubleshoot-log.md)|Added clarification about the limitations of the override time query setting when creating a new alert rule. The alert time range is limited to a maximum of two days, no matter what override time is set in the query.|

+Application-Insights|[Migrate availability tests](app/availability-test-migration.md)|Updated PowerShell script for quick migration of URL Ping Tests to Standard Tests.|

+Application-Insights|[Application Insights overview](app/app-insights-overview.md)|We've updated the Supported Languages section to provide more information about the OpenTelemetry Distro.|

+Application-Insights|[Migrating from OpenCensus Python SDK and Azure Monitor OpenCensus exporter for Python to Azure Monitor OpenTelemetry Python Distro](app/opentelemetry-python-opencensus-migrate.md)|Follow this guide to migrate Python apps from OpenCensus solutions to the OpenTelemetry Distro.|

+Application-Insights|[Enable Azure Monitor OpenTelemetry for .NET, Node.js, Python and Java applications](app/opentelemetry-enable.md)|The OpenTelemetry Distro is fully released and generally available for Node.js, Python, and Java. An OpenTelemetry Exporter is also released and generally available for .NET and .NET Core.|

+Application-Insights|[What is autoinstrumentation for Azure Monitor Application Insights?](app/codeless-overview.md)|Automatic instrumentation, which enables Application Insights without code changes, is now released and generally available for App Service on Linux - Publish as Docker.|

+Containers|[Migrate from ContainerLog to ContainerLogV2](containers/container-insights-v2-migration.md)|New article.|

+Containers|[Configure remote write for Azure managed service for Prometheus using Azure Active Directory workload identity (preview)](containers/prometheus-remote-write-azure-workload-identity.md)|New article Configure remote write for Azure Monitor managed service …|

+Essentials|[Migrate from diagnostic settings storage retention to Azure Storage lifecycle management](essentials/migrate-to-azure-storage-lifecycle-policy.md)|Added CLI and template tabs showing storage lifecycle setting.|

+General|[Plan your alerts and automated actions](alerts/alerts-plan.md)|Add alerts best practices article|

+General|[Azure Monitor cost and usage](usage-estimated-costs.md)|Updated information about the Cost Analysis usage report which contains both the cost for your usage, and the number of units of usage. You can use this export to see the amount of benefit you're receiving from various offers such as the [Defender for Servers data allowance](logs/cost-logs.md#workspaces-with-microsoft-defender-for-cloud) and the [Microsoft Sentinel benefit for Microsoft 365 E5, A5, F5, and G5 customers](https://azure.microsoft.com/offers/sentinel-microsoft-365-offer/). |

+Logs|[Send log data to Azure Monitor by using the HTTP Data Collector API (deprecated)](logs/data-collector-api.md)|Added deprecation notice.|

+Logs|[Azure Monitor Logs overview](logs/data-platform-logs.md)|Added code samples for the Azure Monitor Ingestion client module for Go.|

+Logs|[Set a table's log data plan to Basic or Analytics](logs/basic-logs-configure.md)|Added new Virtual Network Manager, Dev Center, and Communication Services tables that now support Basic logs.|

+You can add a decorator to a resource or module definition. The supported decorators are `batchSize(int) and description. You can only apply it to a resource or module definition that uses a `for` expression.

+The Microsoft Entra auth method is used when `AuthType` is set to `azure`, `azure.app` or `azure.msi`.

+The Microsoft Entra middleware has built-in capabilities for validating access tokens. You can browse through our [samples](../active-directory/develop/sample-v2-code.md) to find one in the language of your choice.

+1. Select **Microsoft** in the identity provider dropdown. The option to create a new registration is selected by default. You can change the name of the registration. For more information on enabling Microsoft Entra provider, see [Configure your App Service or Azure Functions app to login with Microsoft Entra ID](../app-service/configure-authentication-provider-aad.md)

+| | Microsoft Entra authentication |

+1. Sign in using your Microsoft Entra account.

+* A Microsoft Entra domain.

+ If you don't have a Microsoft Entra domain, create this domain with your Azure subscription. For more information, see [Managing custom domain names in your Microsoft Entra ID](../active-directory/enterprise-users/domains-manage.md)

+* A user in your Microsoft Entra domain with an **Application administrator** role. You'll use this member when connecting your Azure AI Video Indexer account to Azure.

+ This user should be a Microsoft Entra user with a work or school account. Don't use a personal account, such as outlook.com, live.com, or hotmail.com.