+ Title: Microsoft Entra SSPR technical profiles in custom policies

+description: Custom policy reference for Microsoft Entra SSPR technical profiles in Azure AD B2C.

+# Define a Microsoft Entra SSPR technical profile in an Azure AD B2C custom policy

+Azure Active Directory B2C (Azure AD B2C) provides support for verifying an email address for self-service password reset (SSPR). Use the Microsoft Entra SSPR technical profile to generate and send a code to an email address, and then verify the code. The Microsoft Entra SSPR technical profile may also return an error message. The validation technical profile validates the user-provided data before the user journey continues. With the validation technical profile, an error message displays on a self-asserted page.

+- Uses the Microsoft Entra SSPR service to generate and send a code to an email address, and then verifies the code.

+The following example shows a Microsoft Entra SSPR technical profile:

+The **InputClaims** element contains a list of claims to send to Microsoft Entra SSPR. You can also map the name of your claim to the name defined in the SSPR technical profile.

+The **InputClaimsTransformations** element may contain a collection of **InputClaimsTransformation** elements that are used to modify the input claims or generate new ones before sending to the Microsoft Entra SSPR service.

+The Microsoft Entra SSPR protocol provider does not return any **OutputClaims**, thus there is no need to specify output claims. You can, however, include claims that aren't returned by the Microsoft Entra SSPR protocol provider as long as you set the `DefaultValue` attribute.

+The following example shows a Microsoft Entra SSPR technical profile that is used to send a code via email.

+The **InputClaims** element contains a list of claims to send to Microsoft Entra SSPR. You can also map the name of your claim to the name defined in the SSPR technical profile.

+The **InputClaimsTransformations** element may contain a collection of **InputClaimsTransformation** elements that are used to modify the input claims or generate new ones before calling the Microsoft Entra SSPR service.

+The Microsoft Entra SSPR protocol provider does not return any **OutputClaims**, thus there is no need to specify output claims. You can, however, include claims that aren't returned by the Microsoft Entra SSPR protocol provider as long as you set the `DefaultValue` attribute.

+The following example shows a Microsoft Entra SSPR technical profile used to verify the code.

+> **Web API chains (On-Behalf-Of) is not supported by Azure AD B2C** - Many architectures include a web API that needs to call another downstream web API, both secured by Azure AD B2C. This scenario is common in clients that have a web API back end, which in turn calls a another service. This chained web API scenario can be supported by using the OAuth 2.0 JWT Bearer Credential grant, otherwise known as the On-Behalf-Of flow. However, the On-Behalf-Of flow is not currently implemented in Azure AD B2C. Although On-Behalf-Of works for applications registered in Microsoft Entra ID, it does not work for applications registered in Azure AD B2C, regardless of the tenant (Microsoft Entra ID or Azure AD B2C) that is issuing the tokens.

+ Title: Define a Microsoft Entra technical profile in a custom policy

+description: Define a Microsoft Entra technical profile in a custom policy in Azure Active Directory B2C.

+# Define a Microsoft Entra technical profile in an Azure Active Directory B2C custom policy

+Azure Active Directory B2C (Azure AD B2C) provides support for the Microsoft Entra user management. This article describes the specifics of a technical profile for interacting with a claims provider that supports this standardized protocol.

+Following [custom policy starter pack](tutorial-create-user-flows.md?pivots=b2c-custom-policy#custom-policy-starter-pack) Microsoft Entra technical profiles include the **AAD-Common** technical profile. The Microsoft Entra technical profiles don't specify the protocol because the protocol is configured in the **AAD-Common** technical profile:

+The InputClaims element contains a claim, which is used to look up an account in the directory, or create a new one. There must be exactly one InputClaim element in the input claims collection for all Microsoft Entra technical profiles. You may need to map the name of the claim defined in your policy to the name defined in Microsoft Entra ID.

+To read, update, or delete an existing user account, the input claim is a key that uniquely identifies the account in Microsoft Entra directory. For example, **objectId**, **userPrincipalName**, **signInNames.emailAddress**, **signInNames.userName**, or **alternativeSecurityId**.

+The **OutputClaims** element contains a list of claims returned by the Microsoft Entra technical profile. You may need to map the name of the claim defined in your policy to the name defined in Microsoft Entra ID. You can also include claims that aren't returned by the Microsoft Entra ID, as long as you set the `DefaultValue` attribute.

+The **PersistedClaims** element contains all of the values that should be persisted by Microsoft Entra ID with possible mapping information between a claim type already defined in the [ClaimsSchema](claimsschema.md) section in the policy and the Microsoft Entra attribute name.

+The name of the claim is the name of the Microsoft Entra attribute unless the **PartnerClaimType** attribute is specified, which contains the Microsoft Entra attribute name.

+- There must be exactly one **InputClaim** element in the claims bag for all Microsoft Entra technical profiles.

+<a name='azure-ad-technical-profile-operations'></a>

+## Microsoft Entra technical profile operations

+See the following article, for example of using Microsoft Entra technical profile:

+When the web API receives an HTTP request from Microsoft Entra ID during a user flow, it can return a "continuation response."

+1. Make sure you're using the directory that contains your Microsoft Entra tenant by selecting the **Directories + subscriptions** icon in the portal toolbar.

+1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch**.

+An API connector at this step in the sign-up process is invoked immediately after the user authenticates with an identity provider (like Google, Facebook, and Microsoft Entra ID). This step precedes the ***attribute collection page***, which is the form presented to the user to collect user attributes. This step is not invoked if a user is registering with a local account.

+When the web API receives an HTTP request from Microsoft Entra ID during a user flow, it can return these responses:

+When the web API receives an HTTP request from Microsoft Entra ID during a user flow, it can return these responses:

+When the web API receives an HTTP request from Microsoft Entra ID during a user flow, it can return these responses:

+1. Make sure you're using the directory that contains your Microsoft Entra tenant by selecting the **Directories + subscriptions** icon in the portal toolbar.

+1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch**.

+* [Microsoft Entra ID (Single-tenant)](identity-provider-azure-ad-single-tenant.md)

+* [Microsoft Entra ID (Multi-tenant)](identity-provider-azure-ad-multi-tenant.md)

+1. Make sure you're using the directory that contains your Azure AD B2C tenant by selecting the **Directories + subscriptions** icon in the portal toolbar.

+1. On the **Portal settings | Directories + subscriptions** page, find your Azure AD B2C directory in the **Directory name** list, and then select **Switch**.

+1. Make sure you're using the directory that has your Microsoft Entra subscription, and not your Azure AD B2C directory. Select the **Directories + subscriptions** icon in the portal toolbar.

+1. On the **Portal settings | Directories + subscriptions** page, find the Microsoft Entra directory that has your subscription in the **Directory name** list, and then select **Switch**

+1. Open the **Application Insights** resource in your Microsoft Entra tenant.

+description: Use Microsoft Entra API connectors to customize and extend your user flows and custom policies by using REST APIs or outbound webhooks to external identity data sources.

+An API connector at this step in the sign-up process is invoked immediately after the user authenticates with an identity provider (like Google, Facebook, and Microsoft Entra ID). This step precedes the ***attribute collection page***, which is the form presented to the user to collect user attributes. This step isn't invoked if a user is registering with a local account. The following are examples of API connector scenarios you might enable at this step:

+- Query external systems for existing data about the user to return it in the application token or store it in Microsoft Entra ID.

+- **Dynamically enrich user data by further integrating with corporate line-of-business applications**. Your RESTful service can receive the user's email address, query the customer's database, and return the user's loyalty number to Azure AD B2C. Then return claims can be stored in the user's Microsoft Entra account, evaluated in the next orchestration steps, or included in the access token.

+The new experience shows all Azure AD B2C app registrations and Microsoft Entra app registrations in one place and provides a consistent way to manage them. From creating a customer-facing app to managing an app with Microsoft Graph permissions for resource management, you only need to learn one way to do things.

+You can reach the new experience by navigating to **App registrations** in an Azure AD B2C tenant from both the **Azure AD B2C** or the **Microsoft Entra ID** services in the Azure portal.

+The Azure AD B2C App registrations experience is based on the general [App Registration experience](https://devblogs.microsoft.com/microsoft365dev/new-app-registrations-experience-is-now-generally-available/) for any Microsoft Entra tenant, but is tailored for Azure AD B2C tenants.

+> To view all your previously created applications, navigate to the **App registrations** blade and select the **All applications** tab. This will display apps created in the legacy experience, the new experience, and those created in the Microsoft Entra service.

+- A **unified app list** shows all your applications that authenticate with Azure AD B2C and Microsoft Entra ID in one convenient place. In addition, you can take advantage of features already available for Microsoft Entra applications, including the **Created on** date, **Certificates & secrets** status, search bar, and much more.

+- Accounts in any organizational directory (Any Microsoft Entra directory ΓÇô Multitenant)

+In the new experience, instead of **Keys**, you use the **Certificates & secrets** blade to manage certificates and secrets. Certificates & secrets enable applications to identify themselves to the authentication service when receiving tokens at a web addressable location (using an HTTPS scheme). We recommend using a certificate instead of a client secret for client credential scenarios when authenticating against Microsoft Entra ID. Certificates can't be used to authenticate against Azure AD B2C.

+The following Microsoft Entra app registrations capabilities are not applicable to or available in Azure AD B2C tenants:

+- Changing the value for supported accounts isn't supported in the UI. You'll need to use the app manifest, unless you're switching between Microsoft Entra single-tenant and multi-tenant.

+For web applications (including .NET, PHP, Java, Ruby, Python, and Node.js) that are hosted on a web server and accessed through a browser, Azure AD B2C supports [OpenID Connect](protocols-overview.md) for all user experiences. In the Azure AD B2C implementation of OpenID Connect, your web application initiates user experiences by issuing authentication requests to Microsoft Entra ID. The result of the request is an `id_token`. This security token represents the user's identity. It also provides information about the user in the form of claims:

+Validation of the `id_token` by using a public signing key that is received from Microsoft Entra ID is sufficient to verify the identity of the user. This process also sets a session cookie that can be used to identify the user on subsequent page requests.

+In this flow, the application executes [policies](user-flow-overview.md) and receives an `authorization_code` from Microsoft Entra ID after the user completes the policy. The `authorization_code` represents the application's permission to call back-end services on behalf of the user who is currently signed in. The application can then exchange the `authorization_code` in the background for an `access_token` and a `refresh_token`. The application can use the `access_token` to authenticate to a back-end web API in HTTP requests. It can also use the `refresh_token` to get a new `access_token` when an older one expires.

+For Azure AD B2C, the [OAuth 2.0 client credentials flow](./client-credentials-grant-flow.md) is currently in public preview. However, you can set up client credential flow using Microsoft Entra ID and the Microsoft identity platform `/token` endpoint (`https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token`) for a [Microsoft Graph application](microsoft-graph-get-started.md) or your own application. For more information, check out the [Microsoft Entra token reference](../active-directory/develop/id-tokens.md) article.

+Azure AD B2C extends the standard OAuth 2.0 flows to do more than simple authentication and authorization. It introduces the [user flow](user-flow-overview.md). With user flows, you can use OAuth 2.0 to add user experiences to your application, such as sign-up, sign-in, and profile management. Identity providers that use the OAuth 2.0 protocol include [Amazon](identity-provider-amazon.md), [Microsoft Entra ID](identity-provider-azure-ad-single-tenant.md), [Facebook](identity-provider-facebook.md), [GitHub](identity-provider-github.md), [Google](identity-provider-google.md), and [LinkedIn](identity-provider-linkedin.md).

+After the user completes the user flow, Microsoft Entra ID returns a response to your app at the value you used for `redirect_uri`. It uses the method specified in the `response_mode` parameter. The response is exactly the same for each of the user action scenarios, independent of the user flow that was executed.

+| scope |Recommended |A space-separated list of scopes. A single scope value indicates to Microsoft Entra ID both of the permissions that are being requested. Using the client ID as the scope indicates that your app needs an access token that can be used against your own service or web API, represented by the same client ID. The `offline_access` scope indicates that your app needs a refresh token for long-lived access to resources. You also can use the `openid` scope to request an ID token from Azure AD B2C. |

+| token_type |The token type value. The only type that Microsoft Entra ID supports is Bearer. |

+| scope |Recommended |A space-separated list of scopes. A single scope value indicates to Microsoft Entra ID both of the permissions that are being requested. Using the client ID as the scope indicates that your app needs an access token that can be used against your own service or web API, represented by the same client ID. The `offline_access` scope indicates that your app will need a refresh token for long-lived access to resources. You also can use the `openid` scope to request an ID token from Azure AD B2C. |

+| token_type |The token type value. The only type that Microsoft Entra ID supports is Bearer. |

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

+To enable _Diagnostic settings_ in Microsoft Entra ID within your Azure AD B2C tenant, you use [Azure Lighthouse](../lighthouse/overview.md) to [delegate a resource](../lighthouse/concepts/architecture.md), which allows your Azure AD B2C (the **Service Provider**) to manage a Microsoft Entra ID (the **Customer**) resource.

+> Azure Lighthouse is typically used to manage resources for multiple customers. However, it can also be used to manage resources **within an enterprise that has multiple Microsoft Entra tenants of its own**, which is what we are doing here, except that we are only delegating the management of single resource group.

+The following diagram depicts the components you'll configure in your Microsoft Entra ID and Azure AD B2C tenants.

+During this deployment, you'll configure your Azure AD B2C tenant where logs are generated. You'll also configure Microsoft Entra tenant where the Log Analytics workspace will be hosted. The Azure AD B2C accounts used (such as your admin account) should be assigned the [Global Administrator](../active-directory/roles/permissions-reference.md#global-administrator) role on the Azure AD B2C tenant. The Microsoft Entra account you'll use to run the deployment must be assigned the [Owner](../role-based-access-control/built-in-roles.md#owner) role in the Microsoft Entra subscription. It's also important to make sure you're signed in to the correct directory as you complete each step as described.

+In summary, you'll use Azure Lighthouse to allow a user or group in your Azure AD B2C tenant to manage a resource group in a subscription associated with a different tenant (the Microsoft Entra tenant). After this authorization is completed, the subscription and log analytics workspace can be selected as a target in the Diagnostic settings in Azure AD B2C.

+- A Microsoft Entra account with the [Owner](../role-based-access-control/built-in-roles.md#owner) role in the Microsoft Entra subscription. See how to [Assign a user as an administrator of an Azure subscription](../role-based-access-control/role-assignments-portal-subscription-admin.md).

+1. Make sure you're using the directory that contains your *Microsoft Entra ID* tenant. Select the **Directories + subscriptions** icon in the portal toolbar.

+1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch**.

+1. Make sure you're using the directory that contains your *Microsoft Entra ID* tenant. Select the **Directories + subscriptions** icon in the portal toolbar.

+1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch**.

+In this step, you choose your Azure AD B2C tenant as a **service provider**. You also define the authorizations you need to assign the appropriate Azure built-in roles to groups in your Microsoft Entra tenant.

+1. Select **Microsoft Entra ID**, select **Overview**.

+To make management easier, we recommend using Microsoft Entra user _groups_ for each role, allowing you to add or remove individual users to the group rather than assigning permissions directly to that user. In this walkthrough, we'll add a security group.

+> In order to add permissions for a Microsoft Entra group, the **Group type** must be set to **Security**. This option is selected when the group is created. For more information, see [Create a basic group and add members using Microsoft Entra ID](../active-directory/fundamentals/how-to-manage-groups.md).

+1. With **Microsoft Entra ID** still selected in your **Azure AD B2C** directory, select **Groups**, and then select a group. If you don't have an existing group, create a **Security** group, then add members. For more information, follow the procedure [Create a basic group and add members using Microsoft Entra ID](../active-directory/fundamentals/how-to-manage-groups.md).

+To create the custom authorization and delegation in Azure Lighthouse, we use an Azure Resource Manager template. This template grants Azure AD B2C access to the Microsoft Entra resource group, which you created earlier, for example, _azure-ad-b2c-monitor_. Deploy the template from the GitHub sample by using the **Deploy to Azure** button, which opens the Azure portal and lets you configure and deploy the template directly in the portal. For these steps, make sure you're signed in to your Microsoft Entra tenant (not the Azure AD B2C tenant).

+1. Make sure you're using the directory that contains your *Microsoft Entra tenant*. Select the **Directories + subscriptions** icon in the portal toolbar.

+1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch**.

+ | Msp Offer Name | A name describing this definition. For example, _Azure AD B2C Monitoring_. It's the name that will be displayed in Azure Lighthouse. The **MSP Offer Name** must be unique in your Microsoft Entra ID. To monitor multiple Azure AD B2C tenants, use different names. |

+ | Authorizations | Specify a JSON array of objects that include the Microsoft Entra ID `principalId`, `principalIdDisplayName`, and Azure `roleDefinitionId`. The `principalId` is the **Object ID** of the B2C group or user that will have access to resources in this Azure subscription. For this walkthrough, specify the group's Object ID that you recorded earlier. For the `roleDefinitionId`, use the [built-in role](../role-based-access-control/built-in-roles.md) value for the _Contributor role_, `b24988ac-6180-42a0-ab88-20f7382dd24c`. |

+ | Rg Name | The name of the resource group you create earlier in your Microsoft Entra tenant. For example, _azure-ad-b2c-monitor_. |

+After you deploy the template, it can take a few minutes (typically no more than five) for the resource projection to complete. You can verify the deployment in your Microsoft Entra tenant and get the details of the resource projection. For more information, see [View and manage service providers](../lighthouse/how-to/view-manage-service-providers.md).

+> On the **Portal settings | Directories + subscriptions** page, ensure that your Azure AD B2C and Microsoft Entra tenants are selected under **Current + delegated directories**.

+1. On the **Portal settings | Directories + subscriptions** page, in the **Directory name** list, find your Microsoft Entra directory that contains the Azure subscription and the _azure-ad-b2c-monitor_ resource group you created, and then select **Switch**.

+1. Select **Microsoft Entra ID**

+Now you can configure your Log Analytics workspace to visualize your data and configure alerts. These configurations can be made in both your Microsoft Entra tenant and your Azure AD B2C tenant.

+1. Make sure you're using the directory that contains your *Microsoft Entra ID* tenant. Select the **Directories + subscriptions** icon in the portal toolbar.

+1. Make sure you're using the directory that contains your *Microsoft Entra ID* tenant. Select the **Directories + subscriptions** icon in the portal toolbar.

+1. Make sure you're using the directory that contains your *Microsoft Entra ID* tenant. Select the **Directories + subscriptions** icon in the portal toolbar.

+1. Make sure you're using the directory that contains your *Microsoft Entra ID* tenant:

+ 1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch** button next to it.

+- For information about streaming Microsoft Entra ID logs to an event hub, see [Tutorial: Stream Microsoft Entra ID logs to an Azure event hub](../active-directory/reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md).

+1. The EMEA Azure AD B2C tenant performs a Microsoft Entra ROPC flow against the NOAM Azure AD B2C tenant to verify credentials.

+ * Follow the documentation [here](secure-rest-api.md?tabs=windows&pivots=b2c-custom-policy#using-oauth2-bearer) to obtain and protect your API using a Microsoft Entra bearer token.

+ * Follow the documentation [here](secure-rest-api.md?tabs=windows&pivots=b2c-custom-policy#using-oauth2-bearer) to obtain and protect your API using a Microsoft Entra bearer token.

+1. The EMEA Azure AD B2C tenant performs a Microsoft Entra ROPC flow against the NOAM Azure AD B2C tenant to verify credentials.

+Azure Active Directory B2C (Azure AD B2C) is a separate service from [Microsoft Entra ID](../active-directory/fundamentals/whatis.md). It's built on the same technology as Microsoft Entra ID but for a different purpose. It allows businesses to build customer facing applications, and then allows self-service sign-up to applications.

+Some customers use the shared capabilities of Microsoft Entra enterprise tenants. For example, acquiring an access token to call the [MS Graph API](microsoft-graph-operations.md#code-discussion) of the Azure AD B2C tenant.

+All endpoints, which don't contain a policy parameter aren't affected by the change. They're accessed only with the Microsoft Entra ID's login.microsoftonline.com endpoints, and can't be used with the *b2clogin.com*, or custom domains. The following example shows a valid token endpoint of the Microsoft identity platform:

+Azure Active Directory B2C (Azure AD B2C) pricing is based on monthly active users (MAU), which is the count of unique users with authentication activity within a calendar month. This billing model applies to both Azure AD B2C tenants and [Microsoft Entra guest user collaboration (B2B)](../active-directory/external-identities/external-identities-pricing.md). MAU billing helps you reduce costs by offering a free tier and flexible, predictable pricing.

+| An Azure AD B2C tenant and you want to use premium features (like risk-based Conditional Access policies) | [Change to a Microsoft Entra pricing tier](#change-your-azure-ad-pricing-tier) that supports the features you want to use. |

+> Your first 50,000 MAUs per month are free for both Premium P1 and Premium P2 features, but the **free tier doesnΓÇÖt apply to free trial, credit-based, or sponsorship subscriptions**. Once the free trial period or credits expire for these types of subscriptions, you'll begin to be charged for Azure AD B2C MAUs. To determine the total number of MAUs, we combine MAUs from all your tenants (both Microsoft Entra ID and Azure AD B2C) that are linked to the same subscription.

+Usage charges for Azure AD B2C are billed to an Azure subscription. You need to explicitly link an Azure AD B2C tenant to an Azure subscription by creating an Azure AD B2C *resource* within the target Azure subscription. Several Azure AD B2C resources can be created in a single Azure subscription, along with other Azure resources like virtual machines, and storage accounts. You can see all of the resources within a subscription by going to the Microsoft Entra tenant that the subscription is associated with.

+1. Make sure you're using the directory that has your Microsoft Entra subscription, and not the directory containing your Azure AD B2C tenant. Select the **Directories + subscriptions** icon in the portal toolbar.

+1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch**.

+<a name='change-your-azure-ad-pricing-tier'></a>

+## Change your Microsoft Entra pricing tier

+1. Make sure you're using the Microsoft Entra directory that contains the subscription your Azure B2C tenant and not the Azure AD B2C tenant itself:

+ 1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch** button next to it.

+Learn about the [Microsoft Entra features, which are supported in Azure AD B2C](supported-azure-ad-features.md).

+1. On the **Overview** page of the Azure AD B2C tenant, select the link under **Resource name**. You're directed to the Azure AD B2C resource in your Microsoft Entra tenant.<br/>

+Azure AD B2C tenants can be moved to another subscription using Azure Resource Manager if the source and destination subscriptions exist within the same Microsoft Entra tenant.

+If the source and destination subscriptions are associated with different Microsoft Entra tenants, you can't perform the move via Azure Resource Manager as explained above. However, you can still achieve the same result by unlinking the Azure AD B2C tenant from the source subscription and relinking it to the destination subscription. This method is safe because the only object you delete is the *billing link*, not the Azure AD B2C tenant itself. None of the users, apps, user flows, etc. will be affected.

+1. In the Azure AD B2C directory itself, [invite a guest user](user-overview.md#guest-user) from the destination Microsoft Entra tenant (the one that the destination Azure subscription is linked to) and ensure this user has the **Global administrator** role in Azure AD B2C.

+1. Sign in to the Azure portal with the user account that was added as an administrator in Azure AD B2C in step 1. Then navigate to the destination Azure subscription, which is linked to the destination Microsoft Entra tenant.

+1. Your Azure AD B2C resource has now moved to the destination Azure subscription (linked to the target Microsoft Entra ID) and will be billed through this subscription from now on.

+|[Microsoft Entra](active-directory-technical-profile.md) technical profile| `InputClaim`, `OutputClaim`| 1, 2|

+**ClaimsProvider** organizes how your technical profiles relate to the claims provider. The following example shows the Microsoft Entra claims provider with the Microsoft Entra technical profiles:

+## Step 1: Register the web API app

+## Step 2: Register an application

+## Step 3: Obtain an access token

+## Step 4: Customize the token

+Enhance the security of Azure Active Directory B2C (Azure AD B2C) with Microsoft Entra ID Protection and Conditional Access. The Identity Protection risk-detection features, including risky users and risky sign-ins, are automatically detected and displayed in your Azure AD B2C tenant. You can create Conditional Access policies that use these risk detections to determine actions and enforce organizational policies. Together, these capabilities give Azure AD B2C application owners greater control over risky authentications and access policies.

+If you're already familiar with [Identity Protection](../active-directory/identity-protection/overview-identity-protection.md) and [Conditional Access](../active-directory/conditional-access/overview.md) in Microsoft Entra ID, using these capabilities with Azure AD B2C will be a familiar experience, with the minor differences discussed in this article.

+- **Gain a new level of visibility into the authentication risks for your apps and your customer base**. With signals from billions of monthly authentications across Microsoft Entra ID and Microsoft Account, the risk detection algorithms will now flag authentications as low, medium, or high risk for your local consumer or citizen authentications.

+Identity Protection and Conditional Access in Azure AD B2C generally work the same way as in Microsoft Entra ID, with the following exceptions:

+- [Learn about Identity Protection in Microsoft Entra ID](../active-directory/identity-protection/overview-identity-protection.md)

+Microsoft Entra Conditional Access is the tool used by Azure AD B2C to bring signals together, make decisions, and enforce organizational policies. Automating risk assessment with policy conditions means risky sign-ins are at once identified and remediated or blocked.

+Conditional Access can be added to your Azure Active Directory B2C (Azure AD B2C) user flows or custom policies to manage risky sign-ins to your applications. Microsoft Entra Conditional Access is the tool used by Azure AD B2C to bring signals together, make decisions, and enforce organizational policies.

+- **Conditional Access policy** that brings signals together to make decisions and enforce organizational policies. When a user signs into your application via an Azure AD B2C policy, the Conditional Access policy uses Microsoft Entra ID Protection signals to identify risky sign-ins and presents the appropriate remediation action.

+When using the Microsoft Entra Conditional Access, consider the following:

+- In Azure AD B2C tenants, only a subset of [Microsoft Entra Conditional Access](../active-directory/conditional-access/overview.md) policies are available.

+1. Under **Azure services**, select **Microsoft Entra ID**. Or use the search box to find and select **Microsoft Entra ID**.

+Most users have a normal behavior that can be tracked, when they fall outside of this norm it could be risky to allow them to just sign in. You may want to block that user or maybe just ask them to perform multifactor authentication to prove that they are really who they say they are. A sign-in risk represents the probability that a given authentication request isn't authorized by the identity owner. Azure AD B2C tenants with P2 licenses can create Conditional Access policies incorporating Microsoft Entra ID Protection sign-in risk detections.

+After you've added the Microsoft Entra Conditional Access policy, enable Conditional Access in your user flow or custom policy. When you enable Conditional Access, you don't need to specify a policy name.

+1. Make sure you're using the directory that contains your Microsoft Entra tenant (not the Azure AD B2C tenant). Select the **Directories + subscriptions** icon in the portal toolbar.

+1. On the **Portal settings | Directories + subscriptions** page, find the Microsoft Entra directory in the **Directory name** list, and then select **Switch**.

+* Learn how to [Work with OAuth tokens in Azure App Service authentication](../app-service/configure-authentication-oauth-tokens.md).

+1. Enable **Diagnostic settings** in Microsoft Entra ID, in your Azure AD B2C tenant.

+The following technical profiles are [Active Directory technical profiles](active-directory-technical-profile.md), which read and write data to Microsoft Entra ID.

+The Azure B2C service is compatible with SameSite browser configurations, including support for `SameSite=None` with the `Secure` attribute.

+- You can set up multiple custom domains. For the maximum number of supported custom domains, see [Microsoft Entra service limits and restrictions](../active-directory/enterprise-users/directory-service-limits-restrictions.md) for Azure AD B2C and [Azure subscription and service limits, quotas, and constraints](../azure-resource-manager/management/azure-subscription-service-limits.md#azure-front-door-classic-limits) for Azure Front Door.

+## Step 1: Add a custom domain name to your Azure AD B2C tenant

+1. [Add your custom domain name to Microsoft Entra ID](../active-directory/fundamentals/add-custom-domain.md#add-your-custom-domain-name).

+ > For these steps, be sure to sign in to your **Azure AD B2C** tenant and select the **Microsoft Entra ID** service.

+1. [Add your DNS information to the domain registrar](../active-directory/fundamentals/add-custom-domain.md#add-your-dns-information-to-the-domain-registrar). After you add your custom domain name to Microsoft Entra ID, create a DNS `TXT`, or `MX` record for your domain. Creating this DNS record for your domain verifies ownership of your domain name.

+ The TXT record must be associated with the subdomain, or hostname of the domain. For example, the *login* part of the *contoso.com* domain. If the hostname is empty or `@`, Microsoft Entra ID won't be able to verify the custom domain you added. In the following examples, both records are configured incorrectly.

+## Step 2: Create a new Azure Front Door instance

+ 1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch** button next to the directory.

+## Step 3: Set up your custom domain on Azure Front Door

+## Step 4: Configure CORS

+- **Possible causes** - This issue could be related to the Microsoft Entra custom domain verification.

+|[Create and read a user account by using Azure Active Directory B2C custom policy](custom-policies-series-store-user.md)| Learn how to store into and read user details from Microsoft Entra storage by using Azure AD B2C custom policy. You use the Microsoft Entra technical profile.|

+- [Write your first Azure Active Directory B2C custom policy - Hello World!](custom-policies-series-hello-world.md)

+- Define more claims transformations to help with claims manipulations such as creating `AlternativeSecurityId`.

+- Configure Microsoft Entra technical profiles to read and write the social account from and to the Microsoft Entra database.

+In the `ContosoCustomPolicy.XML` file, locate the `ClaimsSchema` section, and then declare more claims by using the following code:

+In the `ContosoCustomPolicy.XML` file, locate the `ClaimsTransformations` element, and add claims transformations by using the following code:

+We've defined three Claims Transformations, which we use to generate values for `alternativeSecurityId` and `userPrincipalName` claims. These ClaimsTransformations are invoked in the OAuth2 technical profile in [step 3.3](#step-33configure-facebook-claims-provider).

+In the `ContosoCustomPolicy.XML` file, locate `ClaimsProviders` element, add a new claims provider by using the following code:

+- `facebook-app-id` with the value of Facebook `appID` you obtained in [step 1](#step-1create-facebook-application).

+Notice the claims transformations we defined in [step 3.2](#step-32define-claims-transformations) in the `OutputClaimsTransformations` collection.

+<a name='step-34create-azure-ad-technical-profiles'></a>

+### Step 3.4 - Create Microsoft Entra technical profiles

+Just like in sign-in with a local account, you need to configure the [Microsoft Entra Technical Profiles](active-directory-technical-profile.md), which you use to connect to Microsoft Entra storage, to store or read a user social account.

+1. In the `ContosoCustomPolicy.XML` file, locate the `AAD-UserUpdate` technical profile and then add a new technical profile by using the following code:

+ We've added a new Microsoft Entra Technical Profile `AAD-UserWriteUsingAlternativeSecurityId` that writes a new social account into Microsoft Entra ID.

+1. In the `ContosoCustomPolicy.XML` file, add another Microsoft Entra technical profile after the `AAD-UserWriteUsingAlternativeSecurityId` Technical Profile by using the following code:

+ We've added a new Microsoft Entra Technical Profile `AAD-UserReadUsingAlternativeSecurityId` that reads a new social account from Microsoft Entra ID. It uses `alternativeSecurityId` as a unique identifier for the social account.

+In the `ContosoCustomPolicy.XML` file, locate the `ContentDefinitions` element, and then add a new content definition in the `ContentDefinitions` collection by using the following code:

+In the `ContosoCustomPolicy.XML` file, locate the `ClaimsProviders` section, and then add a new claims provider by using the following code:

+The claims provider we've added contains a self-asserted technical profile, `SelfAsserted-Social`. The self-asserted technical profile uses the `AAD-UserWriteUsingAlternativeSecurityId` Technical Profile as a validation technical profile. So, the `AAD-UserWriteUsingAlternativeSecurityId` Technical Profile executes when the user selects the **Continue** button (see screenshot in [step 7](#step-7test-policy)).

+Also, notice that we've added the content definition, `socialAccountsignupContentDefinition`, that we configured in [step 3.5](#step-35configure-content-definition) in the metadata section.

+- **Orchestration Step 1** - This step includes a `ClaimsProviderSelections` element, which lists the available sign-in options a user can choose from. In this case, we've only have one option, `FacebookExchange`, so when the policy runs, users are taken directly to Facebook.com in step 2 as shown by the `TargetClaimsExchangeId` attribute.

+- **Orchestration Step 2** - The `Facebook-OAUTH` technical profile executes, so the user is redirected to Facebook to sign in.

+- **Orchestration Step 3** - In step 3, the `AAD-UserReadUsingAlternativeSecurityId` technical profile executes to try to read the user social account from Microsoft Entra storage. If the social account is found, `objectId` is returned as an output claim.

+- **Orchestration Step 5** - This step runs if the user doesn't already exist (`objectId` doesn't exist), so the `AAD-UserWriteUsingAlternativeSecurityId` Technical Profile executes to write the social account into Microsoft Entra ID.

+In the `ContosoCustomPolicy.XML` file, locate the `RelyingParty` element, and then replace all the output claims collection with the following code:

+If it's the first time running this policy (social account doesn't already exist in Microsoft Entra storage), you see a screenshot such as the one shown below. You won't see this screen in subsequent policy executions as the social account already exist in Microsoft Entra storage.

+1. In the `UserJourneys` section, add a new user journey, `LocalAndSocialSignInAndSignUp` by using the following code:

+1. In the user journey you've created, `LocalAndSocialSignInAndSignUp`, add orchestration steps by using the following code:

+- Learn more about how to [Define an OAuth2 technical profile in an Azure Active Directory B2C custom policy](oauth2-technical-profile.md).

+Azure AD B2C uses OpenID Connect authentication protocol to verify user credentials. In Azure AD B2C, you send the user credentials alongside other information to a secure endpoint, which then determines if the credentials are valid or not. In a nutshell, when you use Azure AD B2C's implementation of OpenID Connect, you can outsource sign-up, sign in, and other identity management experiences in your web applications to Microsoft Entra ID.

+- **Orchestration Step 5** - This step reads account information from Microsoft Entra ID (we invoke *AAD-UserRead* Microsoft Entra technical profile), so it runs whether a user signs up or signs in.

+Azure Active Directory B2C (Azure AD B2C) is built on Microsoft Entra ID, and so it uses Microsoft Entra storage to store user accounts. Azure AD B2C directory user profile comes with a built-in set of attributes, such as given name, surname, city, postal code, and phone number, but you can [extend the user profile with your own custom attributes](user-flow-custom-attributes.md) without requiring an external data store.

+Your custom policy can connect to Microsoft Entra storage by using [Microsoft Entra technical profile](active-directory-technical-profile.md) to store, update or delete user information. In this article, you'll learn how to configure a set of Microsoft Entra technical profiles to store and read a user account before a JWT token is returned.

+<a name='step-2create-azure-ad-technical-profiles'></a>

+## Step 2 - Create Microsoft Entra technical profiles

+You need to configure two [Microsoft Entra Technical Profile](active-directory-technical-profile.md). One technical profile writes user details into Microsoft Entra storage, and the other reads a user account from Microsoft Entra storage.

+1. In the `ContosoCustomPolicy.XML` file, locate the *ClaimsProviders* element, and add a new claims provider by using the code below. This claims provider holds the Microsoft Entra technical profiles:

+1. In the claims provider you just created, add a Microsoft Entra technical profile by using the following code:

+ We've added a new Microsoft Entra technical profile, `AAD-UserWrite`. You need to take note of the following important parts of the technical profile:

+ - *Operation*: The operation specifies the action to be performed, in this case, *Write*. Learn more about other [operations in a Microsoft Entra technical provider](active-directory-technical-profile.md#azure-ad-technical-profile-operations).

+ - *Persisted claims*: The *PersistedClaims* element contains all of the values that should be stored into Microsoft Entra storage.

+ - *InputClaims*: The *InputClaims* element contains a claim, which is used to look up an account in the directory, or create a new one. There must be exactly one input claim element in the input claims collection for all Microsoft Entra technical profiles. This technical profile uses the *email* claim, as the key identifier for the user account. Learn more about [other key identifiers you can use uniquely identify a user account](active-directory-technical-profile.md#inputclaims).

+ We've added a new Microsoft Entra technical profile, `AAD-UserRead`. We've configured this technical profile to perform a read operation, and to return `objectId`, `userPrincipalName`, `givenName`, `surname` and `displayName` claims if a user account with the `email` in the `InputClaim` section is found.

+<a name='step-3use-the-azure-ad-technical-profile'></a>

+## Step 3 - Use the Microsoft Entra technical profile

+After we collect user details by using the `UserInformationCollector` self-asserted technical profile, we need to write a user account into Microsoft Entra storage by using the `AAD-UserWrite` technical profile. To do so, use the `AAD-UserWrite` technical profile as a validation technical profile in the `UserInformationCollector` self-asserted technical profile.

+ We've broken the technical profile into two separate technical profiles. The *UserInputMessageClaimGenerator* technical profile generates the message sent as claim in the JWT token. The *UserInputDisplayNameGenerator* technical profile generates the `displayName` claim. The `displayName` claim value must be available before the `AAD-UserWrite` technical profile writes the user record into Microsoft Entra storage. In the new code, we remove the *GenerateRandomObjectIdTransformation* as the `objectId` is created and returned by Microsoft Entra ID after an account is created, so we don't need to generate it ourselves within the policy.

+ You must add the validation technical profile before `AAD-UserWrite` as the `displayName` claim value must be available before the `AAD-UserWrite` technical profile writes the user record into Microsoft Entra storage.

+In our `AAD-UserWrite` Microsoft Entra Technical Profile, we specify that if the user already exists, we raise an error message.

+Azure AD B2C uses [Microsoft Entra SSPR technical profile](aad-sspr-technical-profile.md) to verify an email address. This technical profile can generate and send a code to an email address or verifies the code depending on how you configure it.

+<a name='update-user-account-by-using-azure-ad-technical-profile'></a>

+## Update user account by using Microsoft Entra technical profile

+You can configure a Microsoft Entra technical profile to update a user account instead of attempting to create a new one. To do so, set the Microsoft Entra technical profile to throw an error if the specified user account doesn't already exist in the `Metadata` collection by using the following code. The *Operation* needs to be set to *Write*:

+- Learn more about [Microsoft Entra Technical Profile](active-directory-technical-profile.md).

+|[Microsoft Entra ID (Single-tenant)](identity-provider-azure-ad-single-tenant.md) | GA | GA | |

+|[Microsoft Entra ID (Multi-tenant)](identity-provider-azure-ad-multi-tenant.md) | NA | GA | |

+|[OpenID Connect](openid-connect-technical-profile.md) | GA | GA | For example, [Microsoft Entra ID](identity-provider-azure-ad-single-tenant.md). |

+| [Microsoft Entra multifactor authentication authentication](multi-factor-auth-technical-profile.md) | GA | |

+| [Microsoft Entra ID](active-directory-technical-profile.md) as local directory | GA | |

+- Avoid writing to the Microsoft Entra directory during sign-in, which may lead to throttling issues.

+|[DefaultSSOSessionProvider](#defaultssosessionprovider) | [Self-asserted](self-asserted-technical-profile.md), [Microsoft Entra ID](active-directory-technical-profile.md), [Microsoft Entra multifactor authentication](multi-factor-auth-technical-profile.md), [Claims transformation](claims-transformation-technical-profile.md)| Skips technical profile execution.| Yes | Yes |

+The `ExternalLoginSSOSessionProvider` session provider is used to skip the "identity provider selection" screen and sign-out from a federated identity provider. ItΓÇÖs typically referenced in a technical profile configured for a federated identity provider, such as Facebook or Microsoft Entra ID.

+- [Phonefactor](phone-factor-technical-profile.md) - Force the user to perform multifactor authentication as part of a "step up authentication" even during subsequent logons (single sign-on).

+> In an Azure AD B2C tenant, you can't provision Blob storage. You must create this resource in your Microsoft Entra tenant.

+1. Make sure you're using the directory that contains your Microsoft Entra tenant, and which has a subscription:

+ 1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the Directory name list, and then select **Switch**.

+1. Select **Review + create** and wait a few seconds for Microsoft Entra ID to run a validation.

+You can customize your Azure AD B2C pages with a banner logo, background image, and background color by using Microsoft Entra ID [Company branding](../active-directory/fundamentals/how-to-customize-branding.md). The company branding includes signing up, signing in, profile editing, and password resetting.

+To customize your user flow pages, you first configure company branding in Microsoft Entra ID, then you enable it in your user flows in Azure AD B2C.

+1. Follow the steps in [Add branding to your organization's Microsoft Entra sign-in page](../active-directory/fundamentals/how-to-customize-branding.md).

+Azure Active Directory B2C (Azure AD B2C) stores customer data in a geographic location based on how a tenant was created and provisioned. For the Azure portal or Microsoft Entra API, the location is defined when a customer selects a location from the pre-defined list.

+To find the exact location where your data is located per country/region, refer to [where Microsoft Entra data is located](https://aka.ms/aaddatamap)service.

+The following script acquires an access token from Microsoft Entra ID. With the token, the script calls the MS Graph API to upload the policies in the *B2CAssets* folder. You can also change the content of the policy before uploading it. For example, replace the `tenant-name.onmicrosoft.com` with your tenant name.

+1. Make sure you're using the directory that contains your Microsoft Entra tenant. Select the **Directories + Subscriptions** icon in the portal toolbar.

+1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch**.

+Use time-based one-time password (TOTP) [display controls](display-controls.md) to enable multifactor authentication using the TOTP method. End users need to use an authenticator app that generates TOTP codes, such as the [Microsoft Authenticator app](https://www.microsoft.com/security/mobile-authenticator-app) or any other authenticator app that supports TOTP verification.

+The verification TOTP code is done by another self-asserted technical profile that uses display claims and a validation technical profile. For more information, see [Define a Microsoft Entra multifactor authentication technical profile in an Azure AD B2C custom policy](multi-factor-auth-technical-profile.md).

+- Learn how to validate a TOTP code in [Define a Microsoft Entra multifactor authentication technical profile](multi-factor-auth-technical-profile.md).

+- Explore a sample [Azure AD B2C MFA with TOTP using any Authenticator app custom policy in GitHub](https://github.com/azure-ad-b2c/samples/tree/master/policies/totp).

+The following example sends and verifies the email address using [Microsoft Entra SSPR technical profile](aad-sspr-technical-profile.md).

+- Imports the passport Microsoft Entra library

+- Instantiate the passport Microsoft Entra library with the Azure AD B2C options

+ - clears the web app session is and makes an http call to the Azure AD B2C logout endpoint.

+Learn the basics of External Identities - Azure Active Directory B2C (Azure AD B2C) and Microsoft Entra B2B in the Microsoft identity platform.

+|[Monitoring and reporting Azure AD B2C using Azure Monitor](https://www.youtube.com/watch?v=Mu9GQy-CbXI&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=1) 6:57|[:::image type="icon" source="./media/external-identities-videos/monitoring-reporting.png" border="false":::](https://www.youtube.com/watch?v=Mu9GQy-CbXI&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=2)|[Azure AD B2C user migration using Microsoft Graph API](https://www.youtube.com/watch?v=9BRXBtkBzL4&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=5) 7:09| [:::image type="icon" source="./media/external-identities-videos/user-migration-msgraph-api.png" border="false":::](https://www.youtube.com/watch?v=9BRXBtkBzL4&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=6)|

+1. Make sure you're using the Microsoft Entra tenant that contains your Azure subscription:

+ 1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch** button next to it.

+1. In the Azure portal, search for and select **Microsoft Entra ID**.

+1. Sign in to the [Azure portal](https://portal.azure.com) as a user administrator or a password administrator. For more information about the available roles, see [Assigning administrator roles in Microsoft Entra ID](../active-directory/roles/permissions-reference.md#all-roles).

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

+#### Step 1: Create a shared key

+#### Step 2: Add the signing key to Azure AD B2C

+#### Step 3: Add the ID token hint technical profile

+#### Step 4: Prepare your policy

+#### Step 5: Prepare the code

+With an asymmetric key, the token is signed using RSA certificates. This application hosts an OpenID Connect metadata endpoint and JSON Web Keys (JWKs) endpoint that is used by Azure AD B2C to validate the signature of the ID token.

+#### Step 1: Prepare a self-signed certificate

+#### Step 2: Add the ID token hint technical profile

+#### Step 3: Prepare your policy

+#### Step 4: Prepare the code

+- In Azure AD B2C tenants, only a subset of the [Microsoft Entra ID Protection risk detections](../active-directory/identity-protection/overview-identity-protection.md) is available. The following risk detections are supported by Azure AD B2C:

+|Microsoft Entra threat intelligence | Microsoft's internal and external threat intelligence sources have identified a known attack pattern. |

+- [Add Conditional Access to a user flow](conditional-access-user-flow.md).

+As of November 2020, new application registrations show up as unverified in the user consent prompt unless [the application's publisher domain is verified](../active-directory/develop/howto-configure-publisher-domain.md) ***and*** the companyΓÇÖs identity has been verified with the Microsoft Partner Network and associated with the application. ([Learn more](../active-directory/develop/publisher-verification-overview.md) about this change.) Note that for Azure AD B2C user flows, the publisherΓÇÖs domain appears only when using a [Microsoft account](../active-directory-b2c/identity-provider-microsoft-account.md) or other Microsoft Entra tenant as the identity provider. To meet these new requirements, do the following:

+ - If the app registration for the Microsoft account identity provider is in a Microsoft Entra tenant, [verify your app in the App Registration portal](../active-directory/develop/mark-app-as-publisher-verified.md).

+Learn how to [pass the other Azure AD B2C token to your application](idp-pass-through-user-flow.md).

+ Title: Set up sign-in for multi-tenant Microsoft Entra ID by custom policies

+description: Add a multi-tenant Microsoft Entra identity provider using custom policies in Azure Active Directory B2C.

+# Set up sign-in for multi-tenant Microsoft Entra ID using custom policies in Azure Active Directory B2C

+This article shows you how to enable sign-in for users using the multi-tenant endpoint for Microsoft Entra ID. Allowing users from multiple Microsoft Entra tenants to sign in using Azure AD B2C, without you having to configure an identity provider for each tenant. However, guest members in any of these tenants **will not** be able to sign in. For that, you need to [individually configure each tenant](identity-provider-azure-ad-single-tenant.md).

+<a name='register-an-azure-ad-app'></a>

+## Register a Microsoft Entra app

+To enable sign-in for users with a Microsoft Entra account in Azure Active Directory B2C (Azure AD B2C), you need to create an application in the [Azure portal](https://portal.azure.com). For more information, see [Register an application with the Microsoft identity platform](../active-directory/develop/quickstart-register-app.md).

+1. Make sure you're using the directory that contains your organizational Microsoft Entra tenant (for example, Contoso). Select the **Directories + subscriptions** icon in the portal toolbar.

+1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch**.

+1. Select **Accounts in any organizational directory (Any Microsoft Entra directory ΓÇô Multitenant)** for this application.

+If you want to get the `family_name`, and `given_name` claims from Microsoft Entra ID, you can configure optional claims for your application in the Azure portal UI or application manifest. For more information, see [How to provide optional claims to your Microsoft Entra app](../active-directory/develop/optional-claims.md).

+1. Sign in to the [Azure portal](https://portal.azure.com). Search for and select **Microsoft Entra ID**.

+<a name='configure-azure-ad-as-an-identity-provider'></a>

+## Configure Microsoft Entra ID as an identity provider

+To enable users to sign in using a Microsoft Entra account, you need to define Microsoft Entra ID as a claims provider that Azure AD B2C can communicate with through an endpoint. The endpoint provides a set of claims that are used by Azure AD B2C to verify that a specific user has authenticated.

+You can define Microsoft Entra ID as a claims provider by adding Microsoft Entra ID to the **ClaimsProvider** element in the extension file of your policy.

+1. Set **client_id** to the application ID of the Microsoft Entra multi-tenant application that you registered earlier.

+Using `https://login.microsoftonline.com/` as the value for **ValidTokenIssuerPrefixes** allows all Microsoft Entra users to sign in to your application. Update the list of valid token issuers and restrict access to a specific list of Microsoft Entra tenant users who can sign in.

+To obtain the values, look at the OpenID Connect discovery metadata for each of the Microsoft Entra tenants that you would like to have users sign in from. The format of the metadata URL is similar to `https://login.microsoftonline.com/your-tenant/v2.0/.well-known/openid-configuration`, where `your-tenant` is your Microsoft Entra tenant name. For example:

+Perform these steps for each Microsoft Entra tenant that should be used to sign in:

+1. From the sign-up or sign-in page, select **Common Microsoft Entra ID** to sign in with Microsoft Entra account.

+To test the multi-tenant sign-in capability, perform the last two steps using the credentials for a user that exists another Microsoft Entra tenant. Copy the **Run now endpoint** and open it in a private browser window, for example, Incognito Mode in Google Chrome or an InPrivate window in Microsoft Edge. Opening in a private browser window allows you to test the full user journey by not using any currently cached Microsoft Entra credentials.

+- Learn how to [pass the Microsoft Entra token to your application](idp-pass-through-user-flow.md).

+- Check out the Microsoft Entra multi-tenant federation [Live demo](https://github.com/azure-ad-b2c/unit-tests/tree/main/Identity-providers#azure-active-directory), and how to pass Microsoft Entra access token [Live demo](https://github.com/azure-ad-b2c/unit-tests/tree/main/Identity-providers#azure-active-directory-with-access-token)

+ Title: Set up sign-in for a Microsoft Entra organization

+description: Set up sign-in for a specific Microsoft Entra organization in Azure Active Directory B2C.

+# Set up sign-in for a specific Microsoft Entra organization in Azure Active Directory B2C

+This article shows you how to enable sign-in for users from a specific Microsoft Entra organization using a user flow in Azure AD B2C.

+As of November 2020, new application registrations show up as unverified in the user consent prompt unless [the application's publisher domain is verified](../active-directory/develop/howto-configure-publisher-domain.md) ***and*** the companyΓÇÖs identity has been verified with the Microsoft Partner Network and associated with the application. ([Learn more](../active-directory/develop/publisher-verification-overview.md) about this change.) Note that for Azure AD B2C user flows, the publisherΓÇÖs domain appears only when using a [Microsoft account](../active-directory-b2c/identity-provider-microsoft-account.md) or other Microsoft Entra tenant as the identity provider. To meet these new requirements, do the following:

+ - If the app registration for the Microsoft account identity provider is in a Microsoft Entra tenant, [verify your app in the App Registration portal](../active-directory/develop/mark-app-as-publisher-verified.md).

+<a name='register-an-azure-ad-app'></a>

+## Register a Microsoft Entra app

+To enable sign-in for users with a Microsoft Entra account from a specific Microsoft Entra organization, in Azure Active Directory B2C (Azure AD B2C), you need to create an application in the [Azure portal](https://portal.azure.com). For more information, see [Register an application with the Microsoft identity platform](../active-directory/develop/quickstart-register-app.md).

+1. Make sure you're using the directory that contains your organizational Microsoft Entra tenant (for example, Contoso):

+ 2. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch**.

+1. In the Azure portal, search for and select **Microsoft Entra ID**.

+<a name='configure-azure-ad-as-an-identity-provider'></a>

+## Configure Microsoft Entra ID as an identity provider

+1. Enter a **Name**. For example, enter *Contoso Microsoft Entra ID*.

+1. For **Metadata url**, enter the following URL replacing `{tenant}` with the domain name of your Microsoft Entra tenant:

+<a name='add-azure-ad-identity-provider-to-a-user-flow-'></a>

+## Add Microsoft Entra identity provider to a user flow

+At this point, the Microsoft Entra identity provider has been set up, but it's not yet available in any of the sign-in pages. To add the Microsoft Entra identity provider to a user flow:

+1. Click the user flow that you want to add the Microsoft Entra identity provider.

+1. Under **Custom identity providers**, select **Contoso Microsoft Entra ID**.

+1. From the sign-up or sign-in page, select **Contoso Microsoft Entra ID** to sign in with Microsoft Entra Contoso account.

+<a name='configure-azure-ad-as-an-identity-provider'></a>

+## Configure Microsoft Entra ID as an identity provider

+To enable users to sign in using a Microsoft Entra account, you need to define Microsoft Entra ID as a claims provider that Azure AD B2C can communicate with through an endpoint. The endpoint provides a set of claims that are used by Azure AD B2C to verify that a specific user has authenticated.

+You can define Microsoft Entra ID as a claims provider by adding Microsoft Entra ID to the **ClaimsProvider** element in the extension file of your policy.

+To get a token from the Microsoft Entra endpoint, you need to define the protocols that Azure AD B2C should use to communicate with Microsoft Entra ID. This is done inside the **TechnicalProfile** element of **ClaimsProvider**.

+1. Microsoft Entra ID uses the OpenID Connect protocol, so make sure that the value for **Protocol** is `OpenIdConnect`.

+1. Set value of the **METADATA** to `https://login.microsoftonline.com/tenant-name.onmicrosoft.com/v2.0/.well-known/openid-configuration`, where `tenant-name` is your Microsoft Entra tenant name. For example, `https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration`

+1. From the sign-up or sign-in page, select **Contoso Employee** to sign in with Microsoft Entra Contoso account.

+If you want to get the `family_name` and `given_name` claims from Microsoft Entra ID, you can configure optional claims for your application in the Azure portal UI or application manifest. For more information, see [How to provide optional claims to your Microsoft Entra app](../active-directory/develop/optional-claims.md).

+1. Sign in to the [Azure portal](https://portal.azure.com) using your organizational Microsoft Entra tenant. Or if you're already signed in, make sure you're using the directory that contains your organizational Microsoft Entra tenant (for example, Contoso):

+ 2. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch**.

+1. In the Azure portal, search for and select **Microsoft Entra ID**.

+Learn how to [pass the Microsoft Entra token to your application](idp-pass-through-user-flow.md).

+The following XML is an example of a Microsoft Entra metadata single sign-on service with two bindings. The `HTTP-Redirect` takes precedence over the `HTTP-POST` because it appears first in the SAML identity provider metadata.

+When the identity provider indicates that Azure AD B2C binding is set to `HTTP-POST`, Azure AD B2C includes the signature and the algorithm in the body of the SAML request. You can also configure Microsoft Entra ID to include the public key of the certificate when the binding is set to `HTTP-POST`. Use the **IncludeKeyInfo** metadata to `true`, or `false`. In the following example, Microsoft Entra ID doesn't include the public key of the certificate.

+1. Make sure you're using the directory that contains your Microsoft Entra tenant. Select the **Directories + subscriptions** icon in the portal toolbar.

+1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch**.

+1. For the **Client ID**, enter the Application (client) ID of the Microsoft Entra application that you created earlier.

+If you want to get the `family_name` and `given_name` claims from Microsoft Entra ID, you can configure optional claims for your application in the Azure portal UI or application manifest. For more information, see [How to provide optional claims to your Microsoft Entra app](../active-directory/develop/optional-claims.md).

+1. Sign in to the [Azure portal](https://portal.azure.com). Search for and select **Microsoft Entra ID**.

+Now that you've created the application in your Microsoft Entra tenant, you need to store that application's client secret in your Azure AD B2C tenant.

+You can define Microsoft Entra ID as a claims provider by adding the **ClaimsProvider** element in the extension file of your policy.

+1. Replace the value of **client_id** with the Microsoft Entra application's *Application (client) ID* that you recorded earlier.

+You've now configured your policy so that Azure AD B2C knows how to communicate with your Microsoft account application in Microsoft Entra ID.

+| scope | Yes | A space-separated list of scopes. A single scope value indicates to Microsoft Entra ID both of the permissions that are being requested. The `openid` scope indicates a permission to sign in the user and get data about the user in the form of ID tokens. The `offline_access` scope is optional for web apps. It indicates that your app needs a refresh token for long-lived access to resources. |

+* Ensuring that a certain strength of authentication has occurred, such as by using Microsoft Entra multifactor authentication.

+Now that you've signed the user into your SPA, you can get access tokens for calling web APIs that are secured by Microsoft Entra ID. Even if you've already received a token by using the `token` response type, you can use this method to acquire tokens for additional resources without redirecting the user to sign in again.

+Azure AD B2C includes support for the following languages by using ISO 639-1 codes. User flow languages are provided by Azure AD B2C. The multifactor authentication notification languages are provided by [Microsoft Entra multifactor authentication](../active-directory/authentication/concept-mfa-howitworks.md).

+| `cancel_message` | The user has canceled multifactor authentication | `All` |

+<a name='azure-ad-mfa-error-messages'></a>

+## Microsoft Entra multifactor authentication error messages

+The following IDs are used for an [Microsoft Entra multifactor authentication technical profile](multi-factor-auth-technical-profile.md) error message:

+<a name='azure-ad-mfa-example'></a>

+### Microsoft Entra multifactor authentication example

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

+## Microsoft Entra SSPR

+The following IDs are used for [Microsoft Entra SSPR technical profile](aad-sspr-technical-profile.md) error messages:

+<a name='azure-ad-sspr-example'></a>

+### Microsoft Entra SSPR example

+- **Data stored in the Microsoft Entra ID**: You can retrieve data in an Azure AD B2C authentication user journey by using the object ID or any sign-in name, such as an email address or username.

+1. The user signs in to the application. Azure AD B2C enforces authentication with Microsoft Entra multifactor authentication if needed.

+To learn how to manage how users access your application, see [Manage user access](manage-user-access.md).

+This article focuses on working with **consumer accounts** in the Azure portal. For information about creating and deleting Work and Guest accounts, see [Add or delete users using Microsoft Entra ID](../active-directory/fundamentals/add-users.md).

+1. In the left menu, select **Microsoft Entra ID**. Or, select **All services** and search for and select **Microsoft Entra ID**.

+For details about restoring a user within the first 30 days after deletion, or for permanently deleting a user, see [Restore or remove a recently deleted user using Microsoft Entra ID](../active-directory/fundamentals/users-restore.md).

+1. In your Azure AD B2C directory, search for **Microsoft Entra ID**.

+Azure AD B2C authentication service directly supports OAuth 2.0 client credentials grant flow (**currently in public preview**), but you can't use it to manage your Azure AD B2C resources via Microsoft Graph API. However, you can set up [client credential flow](../active-directory/develop/v2-oauth2-client-creds-grant-flow.md) using Microsoft Entra ID and the Microsoft identity platform `/token` endpoint for an application in your Azure AD B2C tenant.

+* [Get an access token from Microsoft Entra ID](/graph/auth-v2-service#4-get-an-access-token)

+* [Get audit logs with the Microsoft Entra reporting API](view-audit-logs.md#get-audit-logs-with-the-azure-ad-reporting-api)

+[ms-graph-api]: /graph/api/overview

+A phone number that can be used by a user to sign-in using [SMS or voice calls](sign-in-options.md#phone-sign-in), or [multifactor authentication](multi-factor-authentication.md). For more information, see [Microsoft Entra authentication methods API](/graph/api/resources/phoneauthenticationmethod).

+An email address that can be used by a [username sign-in account](sign-in-options.md#username-sign-in) to reset the password. For more information, see [Microsoft Entra authentication methods API](/graph/api/resources/emailauthenticationmethod).

+Choose a mechanism for letting users register via local accounts. Local accounts are the accounts where Azure AD B2C does the identity assertion. For more information, see [b2cAuthenticationMethodsPolicy resource type](/graph/api/resources/b2cauthenticationmethodspolicy).

+Application extension properties are also known as directory or Microsoft Entra extensions. To manage them in Azure AD B2C, use the [identityUserFlowAttribute resource type](/graph/api/resources/identityuserflowattribute) and its associated methods.

+> In Microsoft Entra ID, directory extensions are managed through the [extensionProperty resource type](/graph/api/resources/extensionproperty) and its associated methods. However, because they are used in B2C through the `b2c-extensions-app` app which should not be updated, they are managed in Azure AD B2C using the [identityUserFlowAttribute resource type](/graph/api/resources/identityuserflowattribute) and its associated methods.

+ Title: Microsoft Entra multifactor authentication technical profiles in custom policies

+description: Custom policy reference for Microsoft Entra multifactor authentication technical profiles in Azure AD B2C.

+# Define a Microsoft Entra multifactor authentication technical profile in an Azure AD B2C custom policy

+The following example shows a Microsoft Entra multifactor authentication technical profile:

+In the verify phone mode, the technical profile generates and sends a code to a phone number, and then verifies the code. The Microsoft Entra multifactor authentication technical profile may also return an error message. The validation technical profile validates the user-provided data before the user journey continues. With the validation technical profile, an error message displays on a self-asserted page. The technical profile:

+- Uses the Microsoft Entra multifactor authentication service to generate and send a code to a phone number, and then verifies the code.

+The **InputClaims** element contains a list of claims to send to Microsoft Entra multifactor authentication. You can also map the name of your claim to the name defined in the MFA technical profile.

+The Microsoft Entra multifactor authentication protocol provider doesn't return any output claims, so there's no need to specify output claims.

+The following example shows a Microsoft Entra multifactor authentication technical profile that is used to send a code via SMS.

+The **InputClaims** element contains a list of claims to send to Microsoft Entra multifactor authentication. You can also map the name of your claim to the name defined in the MFA technical profile.

+The Microsoft Entra multifactor authentication protocol provider doesn't return any output claims, so there's no need to specify output claims.

+The following example shows a Microsoft Entra multifactor authentication technical profile used to verify the code.

+- Uses the Microsoft Entra multifactor authentication service to validate the TOTP code.

+The **InputClaims** element contains a list of claims to send to Microsoft Entra multifactor authentication. You can also map the name of your claim to the name defined in the MFA technical profile.

+The output claims element contains a list of claims to return from Microsoft Entra multifactor authentication. You can also map the name of your claim to the name defined in the MFA technical profile.

+The following example shows a Microsoft Entra multifactor authentication technical profile used to get the number of available devices.

+The **InputClaims** element contains a list of claims to send to Microsoft Entra multifactor authentication. You can also map the name of your claim to the name defined in the MFA technical profile.

+The Microsoft Entra multifactor authentication protocol provider doesn't return any output claims, so there's no need to specify output claims.

+The following example shows a Microsoft Entra multifactor authentication technical profile used to begin the TOTP verification process.

+The **InputClaims** element contains a list of claims to send to Microsoft Entra multifactor authentication. You can also map the name of your claim to the name defined in the MFA technical profile.

+The Microsoft Entra multifactor authentication protocol provider doesn't return any output claims, so there's no need to specify output claims.

+The following example shows a Microsoft Entra multifactor authentication technical profile used to verify a TOTP code.

+- [Enable multifactor authentication in Azure Active Directory B2C](multi-factor-authentication.md)

+Azure Active Directory B2C (Azure AD B2C) integrates directly with [Microsoft Entra multifactor authentication](../active-directory/authentication/concept-mfa-howitworks.md) so that you can add a second layer of security to sign-up and sign-in experiences in your applications. You enable multifactor authentication without writing a single line of code. If you already created sign up and sign-in user flows, you can still enable multifactor authentication.

+> Authenticator app - TOTP provides stronger security than SMS/Phone and email is the least secure. [SMS/Phone-based multifactor authentication incurs separate charges from the normal Azure AD B2C MAU's pricing model](https://azure.microsoft.com/pricing/details/active-directory/external-identities/).

+ > - Multifactor authentication is disabled by default for sign-up user flows. You can enable MFA in user flows with phone sign-up, but because a phone number is used as the primary identifier, email one-time passcode is the only option available for the second authentication factor.

+- Learn about the [TOTP display control](display-control-time-based-one-time-password.md) and [Microsoft Entra multifactor authentication technical profile](multi-factor-auth-technical-profile.md)

+Azure Active Directory B2C (Azure AD B2C) provides support for the [OpenID Connect](https://openid.net/certification/) protocol identity provider. OpenID Connect 1.0 defines an identity layer on top of OAuth 2.0 and represents the state of the art in modern authentication protocols. With an OpenID Connect technical profile, you can federate with an OpenID Connect based identity provider, such as Microsoft Entra ID. Federating with an identity provider allows users to sign in with their existing social or enterprise identities.

+| ValidTokenIssuerPrefixes | No | A key that can be used to sign in to each of the tenants when using a multi-tenant identity provider such as Microsoft Entra ID. |

+- [Sign in by using Microsoft Entra accounts](identity-provider-azure-ad-single-tenant.md)

+- [Allow users to sign in to a multi-tenant Microsoft Entra identity provider using custom policies](identity-provider-azure-ad-multi-tenant.md)

+OpenID Connect is an authentication protocol, built on top of OAuth 2.0, that can be used to securely sign users in to web applications. By using the Azure Active Directory B2C (Azure AD B2C) implementation of OpenID Connect, you can outsource sign-up, sign in, and other identity management experiences in your web applications to Microsoft Entra ID. This guide shows you how to do so in a language-independent manner. It describes how to send and receive HTTP messages without using any of our open-source libraries.

+- Ensuring that a certain strength of authentication has occurred, such as Microsoft Entra multifactor authentication.

+Azure AD B2C is a separate service from [Microsoft Entra ID](../active-directory/fundamentals/whatis.md). It is built on the same technology as Microsoft Entra ID but for a different purpose. It allows businesses to build customer facing applications, and then allow anyone to sign-up and into those applications with no restrictions on user account.

+1. Configure the OIDC to SAML bridging in the **Azure AD B2C SAML IdP** created with the previous steps.

+Learn to integrate Microsoft Entra ID (Azure AD B2C) authentication with [Asignio](https://www.web.asignio.com/). With this integration, provide passwordless, soft biometric, and multifactor authentication experience to customers. Asignio uses patented Asignio Signature and live facial verification for user authentication. The changeable biometric signature helps to reduce passwords, fraud, phishing, and credential reuse through omni-channel authentication.

+* An Azure subscription.

+For the following instructions, use the Microsoft Entra tenant with the Azure subscription.

+3. On **Portal settings | Directories + subscriptions**, in the **Directory name** list, locate your Microsoft Entra directory.

+* A Microsoft Entra subscription

+* An Azure subscription

+- A Microsoft Entra subscription

+1. Learn how to register your web application in an Azure AD B2C tenant, and configure a sign up-and sign-in user flow. For more info, see [Azure AD B2C](https://docs.datawiza.com/idp/azureb2c.html#microsoft-azure-ad-b2c-configuration).

+4. At the prompt, enter your credentials. If necessary, include a Microsoft Entra multifactor authentication token.

+- **Microsoft DFP API endpoints**: Provides the decision result and accepts a final status reflecting the operation undertaken by the client application. Azure AD B2C communicates with the Microsoft DFP endpoints using REST API connectors. API authentication occurs with a client_credentials grant to the Microsoft Entra tenant in which Microsoft DFP is licensed and installed to obtain a bearer token.

+[Set up your Microsoft Entra tenant](/dynamics365/fraud-protection/integrate-real-time-api) to use Microsoft DFP.

+1. In the Microsoft Entra tenant where Microsoft DFP is set up, create an [Microsoft Entra application and grant admin consent](/dynamics365/fraud-protection/integrate-real-time-api#create-azure-active-directory-applications).

+|{Settings:DfpTenantId}|The ID of the Microsoft Entra tenant (not B2C) where DFP is licensed and installed|`01234567-89ab-cdef-0123-456789abcdef` or `consoto.onmicrosoft.com` |

+*You can set up application insights in a Microsoft Entra tenant or subscription. This value is optional but [recommended to assist with debugging](./troubleshoot-with-application-insights.md).

+- A Microsoft Entra subscription

+>Use the deployed service URL to configure Microsoft Entra ID with the required settings.

+Go to f5.com resources and white papers for: [Easily Configure Secure Access to All Your Applications via Microsoft Entra ID](https://www.f5.com/resources/white-papers/easily-configure-secure-access-to-all-your-applications-via-azure-active-directory)

+* **Azure AD B2C** - identity provider (IdP) and OpenID Connect (OIDC) authorization server that verifies user credentials, multifactor authentication, and SSO to the BIG-IP APM

+To improve the user sign-in experience, suppress the OAuth user sign-in prompt that appears before Microsoft Entra preauthentication.

+If you see a BIG-IP error message after Azure AD B2C authentication, the issue might relate to SSO from Microsoft Entra ID to the BIG-IP.

+ 5. Determine if the APM receives the expected Microsoft Entra claims.

+- Enables users to use modern authentication experiences such as multifactor authentication, biometrics, and password-less resulting in enhanced security.

+3. At the prompt, enter your credentials. If necessary, include a Microsoft Entra multifactor authentication token.

+- A Microsoft Entra subscription. If you don't have one, you can get an [Azure free account](https://azure.microsoft.com/free/).

+- A Microsoft Entra subscription. If you don't have one, you can create a [free Azure account](https://azure.microsoft.com/free/).

+- **Azure AD B2C Identity Experience Framework (IEF)**: An engine that executes user journeys, which can include validating credentials, performing MFA, checking user access. It's aided by the Microsoft Entra database and the API layer, which's configured using XML.

+- **Grit API layer**: This layer exposes user profile data and metadata about organizations and applications. The data is stored in Microsoft Entra ID and Cosmos DB.

+* **Web and mobile applications** - OpenID Connect (OIDC) mobile or web applications protected by Authenticate and Azure AD B2C

+* An Azure subscription

+* An Azure subscription

+* An Azure subscription

+|`loa-2`| Crypto-based Microsoft Entra multifactor authentication only|

+* An Azure subscription. If you don't have a subscription, you can get a [free account](https://azure.microsoft.com/free/).

+- Custom REST API ΓÇô This API implements the integration between Microsoft Entra ID and the IDology service.

+You'll need the URL of the deployed service to configure Microsoft Entra ID with the required settings.

+* An Azure subscription. If you don't have a subscription, you can get a [free account](https://azure.microsoft.com/free/).

+* An Azure subscription

+>To configure Microsoft Entra ID, you'll need the deployed service URL.

+15. Add user attributes Microsoft Entra ID collects with claims Azure AD B2C returns to the client application.

+* An Azure subscription

+>You'll need deployed service URL to configure Microsoft Entra ID.

+* An Azure subscription

+2. Go to **Microsoft Entra ID** > **Users**.

+Create a CSR or Helpdesk user who accesses TheAccessHub Admin Tool with enterprise Microsoft Entra credentials.

+6. For **Login ID/Azure AD User Name**, enter the user principal name from the user Microsoft Entra account.

+Create a CSR or Helpdesk user to access TheAccessHub Admin Tool with a new local credential. This user is for organizations that don't use Microsoft Entra ID.

+* An Azure subscription

+The following diagram illustrates the Nok Nok solution as IdP for Azure AD B2C using OpenID Connect (OIDC) for passwordless authentication.

+ 

+12. Add user attributes for Microsoft Entra ID to collect, with claims that Azure AD B2C returns to the client application.

+* An Azure subscription

+>You'll need the deployed service URL to configure Microsoft Entra ID.

+Generally, configurations include an authentication translation layer that externalizes the authentication from the web application. Reverse proxies provide the authenticated user context to the web applications, such as a header value in clear or digest form. The applications aren't using industry standard tokens such as Security Assertion Markup Language (SAML), OAuth, or OpenID Connect (OIDC). Instead, the proxy provides authentication context and maintains the session with the end-user agent such as browser or native application. As a service running as a man-in-the-middle, proxies provide significant session control. The proxy service is efficient and scalable, not a bottleneck for applications behind the proxy service. The diagram is a reverse-proxy implementation and communications flow.

+6. For **Client ID**, enter the **Microsoft Entra Application ID**.

+7. For **Client Secret**, enter the **Key** you generated for the application in Microsoft Entra ID.

+8. (Optional) Create and use custom claims with the Microsoft Graph API: Select **Advanced**. Deselect **Request Profile** and **Refresh User Attributes**. Learn more about custom claims: [Header-based single sign-on for on-premises apps with Microsoft Entra application proxy](../active-directory/app-proxy/application-proxy-configure-single-sign-on-with-headers.md).

+* An Azure subscription

+<a name='create-an-azure-ad-application-for-saviynt'></a>

+### Create a Microsoft Entra application for Saviynt

+Learn more: [Application and service principal objects in Microsoft Entra ID](../active-directory/develop/app-objects-and-service-principals.md)

+* An Azure subscription

+- **Network egress**: From the server hosting Maverics Identity Orchestrator that can reach your Microsoft Entra tenant

+In this sample tutorial, you'll learn how to integrate Azure AD B2C authentication with [Trusona Authentication Cloud](https://www.trusona.com/customers/authentication-cloud). It's a cloud-based service enabling users to authenticate with a **tap-and-go** experience, without the need for any kind of mobile authenticator app.

+- An Azure subscription. If you don't have a subscription, you can get a [free account](https://azure.microsoft.com/free/).

+ >2. Microsoft Entra IDΓÇÖs initial domain name is used as the client redirect host.

+* An Azure subscription. If you don't have a subscription, you can get a [free account](https://azure.microsoft.com/free/).

+- [Custom policies in Azure AD B2C](custom-policy-overview.md)

+- [Get started with custom policies in Azure AD B2C](tutorial-create-user-flows.md?pivots=b2c-custom-policy)

+description: Learn how to integrate Azure AD B2C authentication with TypingDNA to help with Identity verification and proofing based on user typing pattern, provides ID verification solutions forcing multifactor authentication and helps to comply with SCA requirements for Payment Services Directive 2 (PSD2).

+ Azure AD B2C uses TypingDNA's technologies to capture the users typing characteristics and have them recorded and analyzed for familiarity on each authentication. This adds a layer of protection related to the riskiness of an authentication and evaluates the risk levels. Azure AD B2C can invoke other mechanisms to provide further confidence the user is who they claim to be by invoking Microsoft Entra multifactor authentication, forcing email verification, or any other custom logic for your scenario.

+- The `promptMFA` claim is used within a pre-condition to conditionally execute Microsoft Entra multifactor authentication.

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

+- [Custom policies in Azure AD B2C](./custom-policy-overview.md)

+- [Get started with custom policies in Azure AD B2C](tutorial-create-user-flows.md?pivots=b2c-custom-policy)

+* An Azure subscription

+* **a Microsoft Entra tenant** - the Azure AD B2C tenant stores users and manages access (and scope) in Rampart

+* An Azure subscription

+ * [Microsoft Entra ID](https://azure.microsoft.com/services/active-directory/): Authenticate administrative users for the portal

+* An Azure subscription

+The following technical profiles are [Active Directory technical profiles](active-directory-technical-profile.md), which read and write data to Microsoft Entra ID. Override these technical profiles in the extension file. Use `PersistedClaims` to disable the strong password policy. Find the **ClaimsProviders** element. Add the following claim providers as follows:

+description: Learn tips for securing phone-based multifactor authentication in your Azure AD B2C tenant by using Azure Monitor Log Analytics reports and alerts. Use our workbook to identify fraudulent phone authentications and mitigate fraudulent sign-ups. =

+# Securing phone-based multifactor authentication

+With Microsoft Entra multifactor authentication, users can choose to receive an automated voice call at a phone number they register for verification. Malicious users could take advantage of this method by creating multiple accounts and placing phone calls without completing the MFA registration process. These numerous failed sign-ups could exhaust the allowed sign-up attempts, preventing other users from signing up for new accounts in your Azure AD B2C tenant. To help protect against these attacks, you can use Azure Monitor to monitor phone authentication failures and mitigate fraudulent sign-ups.

+> Authenticator app (TOTP) provides stronger security than SMS/Phone multifactor authentication. To set this up please read our instructions for [enabling multifactor authentication in Azure Active Directory B2C](multi-factor-authentication.md).

+ Title: Publish your Azure Active Directory B2C app to the Microsoft Entra app gallery

+description: Learn how to list an Azure AD B2C app that supports single sign-on in the Microsoft Entra app gallery.

+# Publish your Azure Active Directory B2C app to the Microsoft Entra app gallery

+The Microsoft Entra app gallery is a catalog of thousands of apps. The app gallery makes it easy to deploy and configure single sign-on (SSO) and automate user setup. You can find popular cloud apps in the gallery, such as Workday, ServiceNow, and Zoom.

+This article describes how to publish your Azure Active Directory B2C (Azure AD B2C) app in the Microsoft Entra app gallery. When you publish your app, it's listed among the options that customers can choose from when they're adding apps to their Microsoft Entra tenant.

+- SSO access is enabled between your app and Microsoft Entra apps.

+1. Users choose to sign in with their Microsoft Entra ID "Corporate" account. Azure AD B2C takes them to the Microsoft Entra authorization endpoint, where they sign in with their work account.

+1. If the Microsoft Entra SSO session is active, Microsoft Entra ID issues an access token without prompting users to sign in again. Otherwise, users are prompted to sign in again.

+Depending on the users' SSO session and Microsoft Entra identity settings, they might be prompted to:

+Upon successful sign-in, Microsoft Entra ID returns a token to Azure AD B2C. Azure AD B2C validates and reads the token claims, and then returns a token to your application.

+<a name='step-2-set-up-sign-in-for-multitenant-azure-ad'></a>

+## Step 2: Set up sign-in for multitenant Microsoft Entra ID

+To allow employees and consumers from any Microsoft Entra tenant to sign in by using Azure AD B2C, follow the guidance for [setting up sign in for multitenant Microsoft Entra ID](identity-provider-azure-ad-multi-tenant.md?pivots=b2c-custom-policy).

+In your app, copy the URL of the sign-in endpoint. If you use the [web application sample](configure-authentication-sample-web-app.md), the sign-in URL is `https://localhost:5001/MicrosoftIdentity/Account/SignIn?`. This URL is where the Microsoft Entra app gallery takes users to sign in to your app.

+Finally, add the multitenant app to the Microsoft Entra app gallery. Follow the instructions in [Publish your app to the Microsoft Entra app gallery](../active-directory/manage-apps/v2-howto-app-gallery-listing.md). To add your app to the app gallery, use the following steps:

+- Learn how to [Publish your Microsoft Entra app to the Microsoft Entra app gallery](../active-directory/manage-apps/v2-howto-app-gallery-listing.md).

+The application includes the Microsoft Entra access token in the request to the protected web API resource. The web API sends back the display name contained in the access token.

+ The ASP.NET web application includes a Microsoft Entra access token in the request to the protected web API resource to perform operations on the user's to-do list items.

+- [Publish app in Microsoft Entra app gallery](publish-app-to-azure-ad-app-gallery.md)

+

+|Tenant Creator| Create new Microsoft Entra ID or Azure AD B2C tenants.| [Tenant Creator](../active-directory/roles/permissions-reference.md#tenant-creator)|

+| AuthenticationRequestExtensions | No | Optional protocol message extension elements that are agreed on between Azure AD B2C and the identity provider. The extension is presented in XML format. You add the XML data inside the CDATA element `<![CDATA[Your IDP metadata]]>`. Check your identity providerΓÇÖs documentation to see if the extensions element is supported. |

+<a name='acquiring-an-azure-ad-access-token-'></a>

+#### Acquiring a Microsoft Entra access token

+The following example uses a REST API technical profile to make a request to the Microsoft Entra token endpoint using the client credentials passed as HTTP basic authentication. For more information, see [Microsoft identity platform and the OAuth 2.0 client credentials flow](../active-directory/develop/v2-oauth2-client-creds-grant-flow.md).

+Before the technical profile can interact with Microsoft Entra ID to obtain an access token, you need to register an application. Azure AD B2C relies the Microsoft Entra platform. You can create the app in your Azure AD B2C tenant, or in any Microsoft Entra tenant you manage. To register an application:

+1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra ID or Azure AD B2C directory in the **Directory name** list, and then select **Switch**.

+1. In the left menu, select **Microsoft Entra ID**. Or, select **All services** and search for and select **Microsoft Entra ID**.

+1. In the **Microsoft Entra ID - App registrations** page, select the application you created, for example *Client_Credentials_Auth_app*.

+For the ServiceUrl, replace your-tenant-name with the name of your Microsoft Entra tenant. See the [RESTful technical profile](restful-technical-profile.md) reference for all options available.

+To call the `REST-GetProfile` technical profile, you first need to acquire a Microsoft Entra access token using the `REST-AcquireAccessToken` technical profile. The following example shows how to call the `REST-GetProfile` technical profile from a [validation technical profile](validation-technical-profile.md):

+- Multifactor authentication controls

+|Multifactor authentication|MFA adds a second layer of security to the sign-up and sign-in process and is an essential component of improving the security posture of user authentication in Azure AD B2C. The Authenticator app - TOTP is the recommended MFA method in Azure AD B2C. | <ul><li>[Enable multifactor authentication](./multi-factor-authentication.md)</li></ul> |

+- Microsoft Entra multifactor authentication using SMS or phone call

+- Microsoft Entra multifactor authentication using SMS or phone call

+- [Securing phone-based multifactor authentication](./phone-based-mfa.md) to protect your phone based multifactor authentication.

+The validation technical profile can be any technical profile in the policy, such as [Microsoft Entra ID](active-directory-technical-profile.md) or a [REST API](restful-technical-profile.md) technical profiles. In the previous example, the `LocalAccountSignUpWithLogonEmail` technical profile validates that the signinName does not exist in the directory. If not, the validation technical profile creates a local account and returns the objectId, authenticationSource, newUser. The `SelfAsserted-LocalAccountSignin-Email` technical profile calls the `login-NonInteractive` validation technical profile to validate the user credentials.

+|Microsoft Entra multifactor authentication |2 |

+¹ See also [Microsoft Entra service limits and restrictions](../active-directory/enterprise-users/directory-service-limits-restrictions.md).

+1. In the `AAD-UserReadUsingAlternativeSecurityId` and `AAD-UserReadUsingObjectId` technical profiles, output the user's `alternativeSecurityIds` claim.

+Creates a JSON representation of the userΓÇÖs alternativeSecurityId property that can be used in the calls to Microsoft Entra ID. Check out the [Live demo](https://github.com/azure-ad-b2c/unit-tests/tree/main/claims-transformation/social#createalternativesecurityid) of this claims transformation. For more information, see the [AlternativeSecurityId](/graph/api/resources/alternativesecurityid) schema.

+Use this claims transformation to generate a `alternativeSecurityId` claim. It's used by all social identity provider technical profiles, such as `Facebook-OAUTH`. The following claims transformation receives the user social account ID and the identity provider name. The output of this technical profile is a JSON string format that can be used in Microsoft Entra directory services.

+1. In the `AAD-UserReadUsingAlternativeSecurityId` and `AAD-UserReadUsingObjectId` technical profiles, output the user's `alternativeSecurityIds` claim.

+| [Enabling partners, Suppliers, and Customers to Access Applications with Microsoft Entra ID](https://aka.ms/aadexternalidentities) | PDF | Every organizationΓÇÖs success, regardless of its size, industry, or compliance and security posture, relies on organizational ability to collaborate with other organizations and connect with customers.<br><br>Bringing together Microsoft Entra ID, Azure AD B2C, and Microsoft Entra B2B Collaboration, this guide details the business value and the mechanics of building an application or web experience that provides a consolidated authentication experience tailored to the contexts of your employees, business partners and suppliers, and customers. |

+The following example takes a string collection of user roles, and converts it to a comma delimiter string. You can use this method to store a string collection in an Azure AD B2C user account. Later, when you read the account from the directory, use the `StringSplit` to convert the comma delimiter string back to string collection.

+- Find more [claims transformation samples](https://github.com/azure-ad-b2c/unit-tests/tree/main/claims-transformation/stringCollection) on the Azure AD B2C community GitHub repo

+ Title: Supported Microsoft Entra features

+description: Learn about Microsoft Entra features, which are still supported in Azure AD B2C.

+# Supported Microsoft Entra features

+An Azure Active Directory B2C (Azure AD B2C) tenant is different than a Microsoft Entra tenant, which you may already have, but it relies on it. The following Microsoft Entra features can be used in your Azure AD B2C tenant.

+|Feature |Microsoft Entra ID | Azure AD B2C |

+| [Inviting External Identities guests](../active-directory//external-identities/add-users-administrator.md)| You can invite guest users and configure External Identities features such as federation and sign-in with Facebook and Google accounts. | You can invite only a Microsoft account or a Microsoft Entra user as a guest to your Microsoft Entra tenant for accessing applications or managing tenants. For [consumer accounts](user-overview.md#consumer-user), you use Azure AD B2C user flows and custom policies to manage users and sign-up or sign-in with external identity providers, such as Google or Facebook. |

+| [Custom domain names](../active-directory/fundamentals/add-custom-domain.md) | You can use Microsoft Entra custom domains for administrative accounts only. | [Consumer accounts](user-overview.md#consumer-user) can sign in with a username, phone number, or any email address. You can use [custom domains](custom-domain.md) in your redirect URLs.|

+| [Conditional Access](../active-directory/conditional-access/overview.md) | Fully supported for administrative and user accounts. | A subset of Microsoft Entra Conditional Access features is supported with [consumer accounts](user-overview.md#consumer-user) Learn how to configure Azure AD B2C [conditional access](conditional-access-user-flow.md).|

+| [Premium P1](https://azure.microsoft.com/pricing/details/active-directory) | Fully supported for Microsoft Entra ID P1 features. For example, [Password Protection](../active-directory/authentication/concept-password-ban-bad.md), [Hybrid Identities](../active-directory/hybrid/whatis-hybrid-identity.md), [Conditional Access](../active-directory/roles/permissions-reference.md#), [Dynamic groups](../active-directory/enterprise-users/groups-create-rule.md), and more. | Azure AD B2C uses [Azure AD B2C Premium P1 license](https://azure.microsoft.com/pricing/details/active-directory/external-identities/), which is different from Microsoft Entra ID P1. A subset of Microsoft Entra Conditional Access features is supported with [consumer accounts](user-overview.md#consumer-user). Learn how to configure Azure AD B2C [Conditional Access](conditional-access-user-flow.md).|

+| [Premium P2](https://azure.microsoft.com/pricing/details/active-directory/) | Fully supported for Microsoft Entra ID P2 features. For example, [Identity Protection](../active-directory/identity-protection/overview-identity-protection.md), and [Identity Governance](../active-directory/governance/identity-governance-overview.md). | Azure AD B2C uses [Azure AD B2C Premium P2 license](https://azure.microsoft.com/pricing/details/active-directory/external-identities/), which is different from Microsoft Entra ID P2. A subset of Microsoft Entra ID Protection features is supported with [consumer accounts](user-overview.md#consumer-user). Learn how to [Investigate risk with Identity Protection](identity-protection-investigate-risk.md) and configure Azure AD B2C [Conditional Access](conditional-access-user-flow.md). |

+|[Data retention policy](../active-directory/reports-monitoring/reference-reports-data-retention.md#how-long-does-azure-ad-store-the-data)|Data retention period for both audit and sign in logs depend on your subscription. Learn more about [How long Microsoft Entra ID store reporting data](../active-directory/reports-monitoring/reference-reports-data-retention.md#how-long-does-azure-ad-store-the-data).|Sign in and audit logs are only retained for **seven (7) days**. If you require a longer retention period, use the [Azure monitor](azure-monitor.md).|

+| [Go-Local add-on](data-residency.md#go-local-add-on) | Microsoft Entra Go-Local add-on enables you to store data in the country/region you choose when your Microsoft Entra tenant.| Just like Microsoft Entra ID, Azure AD B2C supports [Go-Local add-on](data-residency.md#go-local-add-on). |

+> **Other Azure resources in your tenant:** <br>In an Azure AD B2C tenant, you can't provision other Azure resources such as virtual machines, Azure web apps, or Azure functions. You must create these resources in your Microsoft Entra tenant.

+In Azure Active Directory B2C (Azure AD B2C), a *tenant* represents your organization and is a directory of users. Each Azure AD B2C tenant is distinct and separate from other Azure AD B2C tenants. An Azure AD B2C tenant is different than a Microsoft Entra tenant, which you may already have.

+Azure AD B2C defines several types of user accounts. Microsoft Entra ID, Microsoft Entra B2B, and Azure Active Directory B2C share these account types.

+You can also extend the Microsoft Entra schema to store additional information about your users. For example, their country/region of residency, preferred language, and preferences like whether they want to subscribe to a newsletter or enable multifactor authentication. For more information, see:

+Microsoft Entra ID Protection risk-detection features, including risky users and risky sign-ins, are automatically detected and displayed in your Azure AD B2C tenant. You can create Conditional Access policies that use these risk detections to determine remediation actions and enforce organizational policies.

+Azure AD B2C tenants share many characteristics with enterprise Microsoft Entra tenants used for employees and partners. Shared aspects include mechanisms for viewing administrative roles, assigning roles, and auditing activities.

+For more information about Microsoft Entra roles, including Azure AD B2C administration role support, see [Administrator role permissions in Microsoft Entra ID](../active-directory/roles/permissions-reference.md).

+- [Microsoft Entra ID](active-directory-technical-profile.md): Provides support for the Azure AD B2C user management.

+- [Microsoft Entra multifactor authentication](multi-factor-auth-technical-profile.md): Provides support for verifying a phone number by using Microsoft Entra multifactor authentication.

+All types of technical profiles share the same concept. They start by reading the input claims and run claims transformations. Then they communicate with the configured party, such as an identity provider, REST API, or Microsoft Entra directory services. After the process is completed, the technical profile returns the output claims and might run output claims transformations. The following diagram shows how the transformations and mappings referenced in the technical profile are processed. After the claims transformation is executed, the output claims are immediately stored in the claims bag, regardless of the party the technical profile interacts with.

+The **InputClaims** element picks up claims from the claims bag that are used for the technical profile. For example, a [self-asserted technical profile](self-asserted-technical-profile.md) uses the input claims to prepopulate the output claims that the user provides. A REST API technical profile uses the input claims to send input parameters to the REST API endpoint. Azure AD B2C uses an input claim as a unique identifier to read, update, or delete an account.

+The **PersistedClaims** element contains all of the values that should be persisted by an [Microsoft Entra technical profile](active-directory-technical-profile.md) with possible mapping information between a claim type already defined in the [ClaimsSchema](claimsschema.md) section in the policy and the Microsoft Entra attribute name.

+The name of the claim is the name of the [Microsoft Entra attribute](user-profile-attributes.md) unless the **PartnerClaimType** attribute is specified, which contains the Microsoft Entra attribute name.

+A validation technical profile is used for validating output claims in a [self-asserted technical profile](self-asserted-technical-profile.md#validation-technical-profiles). A validation technical profile is an ordinary technical profile from any protocol, such as [Microsoft Entra ID](active-directory-technical-profile.md) or a [REST API](restful-technical-profile.md). The validation technical profile returns output claims or returns error code. The error message is rendered to the user on the screen, which allows the user to retry.

+1. In the Azure portal, search for and select **Microsoft Entra ID**.

+1. In the Azure portal, search for and select **Microsoft Entra ID**.

+It's important that you monitor how you use your Azure AD B2C directory quota. Directory quota has a given size that is expressed in number of objects. These objects include user accounts, app registrations, groups, etc. When the number of objects in your tenant reach quota size, the directory will generate an error when trying to create a new object.

+1. Sign in to the [Azure portal](https://portal.azure.com) as an existing Global Administrator. If you use your Microsoft Entra account, make sure you're using the directory that contains your Azure AD B2C tenant:

+ - **Directory role**: If you require Microsoft Entra administrative permissions for the user, you can add them to a Microsoft Entra role. You can assign the user to be a Global administrator or one or more of the limited administrator roles in Microsoft Entra ID. For more information about assigning roles, see [Use roles to control resource access](roles-resource-access-control.md).

+You can also invite a new guest user to manage your tenant. The guest account is the preferred option when your organization also has Microsoft Entra ID because the lifecycle of this identity can be managed externally.

+ - **Directory role**: If you require Microsoft Entra administrative permissions for the user, you can add them to a Microsoft Entra role. You can assign the user to be a Global administrator or one or more of the limited administrator roles in Microsoft Entra ID. For more information about assigning roles, see [Use roles to control resource access](roles-resource-access-control.md).

+The user is deleted and no longer appears on the **Users - All users** page. The user can be seen on the **Deleted users** page for the next 30 days and can be restored during that time. For more information about restoring a user, see [Restore or remove a recently deleted user using Microsoft Entra ID](../active-directory/fundamentals/users-restore.md).

+If you're not using [Conditional Access](conditional-access-user-flow.md), you can enable [Microsoft Entra security defaults](../active-directory/fundamentals/security-defaults.md) to force all administrative accounts to use MFA.

+1. In the Azure portal, search for and select **Microsoft Entra ID**.

+- [Clean up resources and delete tenant](tutorial-delete-tenant.md)

+ 

+> When you test smart lockout, your sign-in requests might be handled by different datacenters due to the geo-distributed and load-balanced nature of the Microsoft Entra authentication service. In that scenario, because each Microsoft Entra datacenter tracks lockout independently, it might take more than your defined lockout threshold number of attempts to cause a lockout. A user has a maximum of (threshold_limit * datacenter_count) number of bad attempts before being completely locked out. For more information, see [Azure global infrastructure](https://azure.microsoft.com/global-infrastructure/).

+

+To learn about viewing the sign-in activity report in Microsoft Entra ID, see [Sign-in activity report error codes](../active-directory/reports-monitoring/concept-sign-ins.md).

+1. Make sure you're using the Microsoft Entra directory that has your Azure subscription, and not your Azure AD B2C directory. Select the **Directories + subscriptions** icon in the portal toolbar.

+1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch**.

+1. Make sure you're using the Microsoft Entra directory that has your Azure subscription, and not your Azure AD B2C directory. Select the **Directories + subscriptions** icon in the portal toolbar.

+1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory in the **Directory name** list, and then select **Switch**.

+ - Use recommended [self service password reset (SSPR) experience](add-password-reset-policy.md#self-service-password-reset-recommended).

+- A user policy uses the recommended [self service password reset (SSPR) experience](add-password-reset-policy.md#self-service-password-reset-recommended) with a consumer local account. The user selects the **Forgot your password?** link , and then selects **Cancel** button before the user flow experience completes. In this case, Azure AD B2C service returns error code `AADB2C90091` to your application.

+1. Make sure you're using the Microsoft Entra tenant that contains your subscription:

+ 1. On the **Portal settings | Directories + subscriptions** page, find your Microsoft Entra directory that contains your subscription in the **Directory name** list, and then select **Switch** button next to it.

+ - For **Location**, select your country/region from the list. If the country/region you select has a [Go-Local add-on](data-residency.md#go-local-add-on) option, such as Japan or Australia, and you want to store your data exclusively within that country/region, select the **Store Microsoft Entra Core Store data and Microsoft Entra components and service data in the location selected above** checkbox. Go-Local add-on is a paid add-on whose charge is added to your Azure AD B2C Premium P1 or P2 licenses charges, see [Billing model](billing.md#about-go-local-add-on). You can't change the data residency region after you create your Azure AD B2C tenant.

+1. On the **Data residency** pane that appears, select the **Store my directory and Microsoft Entra data in \<Country\>** checkbox, then select **Save** button.

+1. In the Azure portal, search for and select the **Microsoft Entra ID** service.

+1. In the Azure portal, search for and select the **Microsoft Entra ID** service

+1. In the Azure portal, search for and select the **Microsoft Entra ID** service.

+ 1. Sign out of the Azure portal and then sign back in to refresh your access, and select the **Microsoft Entra ID** service.

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

+> The first time the Microsoft Entra technical profile persists the claim to the directory, it checks whether the custom attribute exists. If it doesn't, it creates the custom attribute.

+You can use Microsoft Graph to create and manage the custom attributes then set the values for a user. Extension attributes are also called directory or Microsoft Entra extensions.

+* Microsoft Entra multifactor authentication

+* First- and third-party multifactor authentication challenges

+| Identity Providers | [Predefined local](identity-provider-local.md) or [social provider](add-identity-provider.md), such as federation with Microsoft Entra tenants. | Standards-based OIDC, OAUTH, and SAML. Authentication is also possible by using integration with REST APIs. |

+| Identity Tasks | [Sign-up or sign-in](add-sign-up-and-sign-in-policy.md) with local or many social accounts.<br><br>[Self-service password reset](add-password-reset-policy.md).<br><br>[Profile edit](add-profile-editing-policy.md).<br><br>Multifactor authentication.<br><br>Access token flows. | Complete the same tasks as user flows using custom identity providers or use custom scopes.<br><br>Provision a user account in another system at the time of registration.<br><br>Send a welcome email using your own email service provider.<br><br>Use a user store outside Azure AD B2C.<br><br>Validate user provided information with a trusted system by using an API. |

+1. Create a new user flow policy by following the steps in [Tutorial: Create user flows in Azure AD B2C](tutorial-create-user-flows.md). While creating the user flow, select the **Recommended** version.

+In the public cloud, all legacy preview user flows (V1.1 and V2) are deprecated. *These changes apply to the Azure public cloud only. Other environments will continue to use [legacy user flow versioning](user-flow-versions-legacy.md).*

+In Azure Active Directory B2C (Azure AD B2C), there are several types of accounts that can be created. Microsoft Entra ID, Microsoft Entra B2B, and Azure Active Directory B2C (Azure AD B2C) share in the types of user accounts that can be used.

+- **Guest account** - A guest account can only be a Microsoft account or a Microsoft Entra user that can be used to share administration responsibilities such as [managing a tenant](tenant-management-manage-administrator.md).

+A work account is created the same way for all tenants based on Microsoft Entra ID. To create a work account, you can use the information in [Quickstart: Add new users to Microsoft Entra ID](../active-directory/fundamentals/add-users.md). A work account is created using the **New user** choice in the Azure portal.

+ - **Limited administrator** - Select the administrative role or roles for the user. For more information about the roles that can be selected, see [Assigning administrator roles in Microsoft Entra ID](../active-directory/roles/permissions-reference.md).

+You can invite external users to your tenant as a guest user. A typical scenario for inviting a guest user to your Azure AD B2C tenant is to share administration responsibilities. For an example of using a guest account, see [Properties of a Microsoft Entra B2B collaboration user](../active-directory/external-identities/user-properties.md).

+<a name='azure-ad-user-resource-type'></a>

+## Microsoft Entra user resource type

+- Whether the attribute can be used in a custom policy [Microsoft Entra technical profile](active-directory-technical-profile.md) and in which section (&lt;InputClaims&gt;, &lt;OutputClaims&gt;, or &lt;PersistedClaims&gt;)

+|userState (externalUserState)³|String|For Microsoft Entra B2B account only, and it indicates whether the invitation is PendingAcceptance or Accepted.|No|No|Persisted, Output|

+The Azure AD B2C password policy (for local accounts) is based on the Microsoft Entra ID [strong password strength](../active-directory/authentication/concept-sspr-policy.md) policy. The Azure AD B2C sign-up or sign-in and password reset policies require this strong password strength, and don't expire passwords.

+Extension attributes [extend the schema](/graph/extensibility-overview#schema-extensions) of the user objects in the directory. The extension attributes can only be registered on an application object, even though they might contain data for a user. The extension attribute is attached to the application called `b2c-extensions-app`. Do not modify this application, as it's used by Azure AD B2C for storing user data. You can find this application under Microsoft Entra App registrations. [Learn more about Azure AD B2C](extensions-app.md) `b2c-extensions-app`.

+ - An orchestration step is used to gather information about the user. Based on the claims within the incoming access token, the user journey invokes a [Microsoft Entra technical profile](active-directory-technical-profile.md) to retrieve data about the user, for example, reading the user by the objectId.

+A validation technical profile is an ordinary technical profile from any protocol, such as [Microsoft Entra ID](active-directory-technical-profile.md) or a [REST API](restful-technical-profile.md). The validation technical profile returns output claims, or returns 4xx HTTP status code, with the following data. For more information, see [returning error message](restful-technical-profile.md#returning-validation-error-message)

+> You can't see user sign-ins for individual Azure AD B2C applications under the **Users** section of the **Microsoft Entra ID** or **Azure AD B2C** pages in the Azure portal. The sign-in events there show user activity, but can't be correlated back to the B2C application that the user signed in to. You must use the audit logs for that, as explained further in this article.

+<a name='get-audit-logs-with-the-azure-ad-reporting-api'></a>

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

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

+To allow script- or application-based access to the Microsoft Entra reporting API, you need an application registered in your Azure AD B2C tenant with the following API permissions. You can enable these permissions on an existing application registration within your B2C tenant, or create a new one specifically for use with audit log automation.

+To download Azure AD B2C audit log events via the API, filter the logs on the `B2C` category. To filter by category, use the `filter` query string parameter when you call the Microsoft Entra reporting API endpoint.

+The following PowerShell script shows an example of how to query the Microsoft Entra reporting API. After querying the API, it prints the logged events to standard output, then writes the JSON output to a file.

+ Title: Management concepts for Microsoft Entra Domain Services | Microsoft Docs

+description: Learn about how to administer a Microsoft Entra Domain Services managed domain and the behavior of user accounts and passwords

+# Management concepts for user accounts, passwords, and administration in Microsoft Entra Domain Services

+When you create and run a Microsoft Entra Domain Services (AD DS) managed domain, there are some differences in behavior compared to a traditional on-premises AD DS environment. You use the same administrative tools in Microsoft Entra DS as a self-managed domain, but you can't directly access the domain controllers (DC). There's also some differences in behavior for password policies and password hashes depending on the source of the user account creation.

+User accounts can be created in a managed domain in multiple ways. Most user accounts are synchronized in from Microsoft Entra ID, which can also include user account synchronized from an on-premises AD DS environment. You can also manually create accounts directly in the managed domain. Some features, like initial password synchronization or password policy, behave differently depending on how and where user accounts are created.

+* The user account can be synchronized in from Microsoft Entra ID. This includes cloud-only user accounts created directly in Microsoft Entra ID, and hybrid user accounts synchronized from an on-premises AD DS environment using Microsoft Entra Connect.

+ * The majority of user accounts in a managed domain are created through the synchronization process from Microsoft Entra ID.

+* The user account can be manually created in a managed domain, and doesn't exist in Microsoft Entra ID.

+ * If you need to create service accounts for applications that only run in the managed domain, you can manually create them in the managed domain. As synchronization is one way from Microsoft Entra ID, user accounts created in the managed domain aren't synchronized back to Microsoft Entra ID.

+Microsoft Entra DS includes a default password policy that defines settings for things like account lockout, maximum password age, and password complexity. Settings like account lockout policy apply to all users in a managed domain, regardless of how the user was created as outlined in the previous section. A few settings, like minimum password length and password complexity, only apply to users created directly in a managed domain.

+To authenticate users on the managed domain, Microsoft Entra DS needs password hashes in a format that's suitable for NT LAN Manager (NTLM) and Kerberos authentication. Microsoft Entra ID doesn't generate or store password hashes in the format that's required for NTLM or Kerberos authentication until you enable Microsoft Entra DS for your tenant. For security reasons, Microsoft Entra ID also doesn't store any password credentials in clear-text form. Therefore, Microsoft Entra ID can't automatically generate these NTLM or Kerberos password hashes based on users' existing credentials.

+For cloud-only user accounts, users must change their passwords before they can use the managed domain. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Microsoft Entra ID. The account isn't synchronized from Microsoft Entra ID to Microsoft Entra DS until the password is changed.

+For users synchronized from an on-premises AD DS environment using Microsoft Entra Connect, [enable synchronization of password hashes][hybrid-phs].

+> Microsoft Entra Connect only synchronizes legacy password hashes when you enable Microsoft Entra DS for your Microsoft Entra tenant. Legacy password hashes aren't used if you only use Microsoft Entra Connect to synchronize an on-premises AD DS environment with Microsoft Entra ID.

+> If your legacy applications don't use NTLM authentication or LDAP simple binds, we recommend that you disable NTLM password hash synchronization for Microsoft Entra DS. For more information, see [Disable weak cipher suites and NTLM credential hash synchronization][secure-domain].

+Once appropriately configured, the usable password hashes are stored in the managed domain. If you delete the managed domain, any password hashes stored at that point are also deleted. Synchronized credential information in Microsoft Entra ID can't be reused if you later create another managed domain - you must reconfigure the password hash synchronization to store the password hashes again. Previously domain-joined VMs or users won't be able to immediately authenticate - Microsoft Entra ID needs to generate and store the password hashes in the new managed domain. For more information, see [Password hash sync process for Microsoft Entra DS and Microsoft Entra Connect][azure-ad-password-sync].

+> Microsoft Entra Connect should only be installed and configured for synchronization with on-premises AD DS environments. It's not supported to install Microsoft Entra Connect in a managed domain to synchronize objects back to Microsoft Entra ID.

+In Microsoft Entra DS, the forest only contains one domain. On-premises AD DS forests often contain many domains. In large organizations, especially after mergers and acquisitions, you may end up with multiple on-premises forests that each then contain multiple domains.

+By default, a managed domain is created as a *user* forest. This type of forest synchronizes all objects from Microsoft Entra ID, including any user accounts created in an on-premises AD DS environment. User accounts can directly authenticate against the managed domain, such as to sign in to a domain-joined VM. A user forest works when the password hashes can be synchronized and users aren't using exclusive sign-in methods like smart card authentication.

+In a Microsoft Entra DS *resource* forest, users authenticate over a one-way forest *trust* from their on-premises AD DS. With this approach, the user objects and password hashes aren't synchronized to Microsoft Entra DS. The user objects and credentials only exist in the on-premises AD DS. This approach lets enterprises host resources and application platforms in Azure that depend on classic authentication such LDAPS, Kerberos, or NTLM, but any authentication issues or concerns are removed.

+<a name='azure-ad-ds-skus'></a>

+## Microsoft Entra DS SKUs

+In Microsoft Entra DS, the available performance and features are based on the SKU. You select a SKU when you create the managed domain, and you can switch SKUs as your business requirements change after the managed domain has been deployed. The following table outlines the available SKUs and the differences between them:

+Before these Microsoft Entra DS SKUs, a billing model based on the number of objects (user and computer accounts) in the managed domain was used. There is no longer variable pricing based on the number of objects in the managed domain.

+For more information, see the [Microsoft Entra DS pricing page][pricing].

+The backup frequency determines how often a snapshot of the managed domain is taken. Backups are an automated process managed by the Azure platform. In the event of an issue with your managed domain, Azure support can assist you in restoring from backup. As synchronization only occurs one way *from* Microsoft Entra ID, any issues in a managed domain won't impact Microsoft Entra ID or on-premises AD DS environments and functionality.

+To get started, [create a Microsoft Entra DS managed domain][create-instance].

+ Title: Resolve secure LDAP alerts in Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to troubleshoot and resolve common alerts with secure LDAP for Microsoft Entra Domain Services.

+# Known issues: Secure LDAP alerts in Microsoft Entra Domain Services

+Applications and services that use lightweight directory access protocol (LDAP) to communicate with Microsoft Entra Domain Services (Microsoft Entra DS) can be [configured to use secure LDAP](tutorial-configure-ldaps.md). An appropriate certificate and required network ports must be open for secure LDAP to work correctly.

+This article helps you understand and resolve common alerts with secure LDAP access in Microsoft Entra DS.

+> TCP port 636 isn't the only rule needed for Microsoft Entra DS to run smoothly. To learn more, see the [Microsoft Entra DS Network security groups and required ports](network-considerations.md#network-security-groups-and-required-ports).

+Create a replacement secure LDAP certificate by following the steps to [create a certificate for secure LDAP](tutorial-configure-ldaps.md#create-a-certificate-for-secure-ldap). Apply the replacement certificate to Microsoft Entra DS, and distribute the certificate to any clients that connect using secure LDAP.

+ Title: Resolve network security group alerts in Microsoft Entra DS | Microsoft Docs

+description: Learn how to troubleshoot and resolve network security group configuration alerts for Microsoft Entra Domain Services

+# Known issues: Network configuration alerts in Microsoft Entra Domain Services

+To let applications and services correctly communicate with a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain, specific network ports must be open to allow traffic to flow. In Azure, you control the flow of traffic using network security groups. The health status of a Microsoft Entra DS managed domain shows an alert if the required network security group rules aren't in place.

+Invalid network security group rules are the most common cause of network errors for Microsoft Entra DS. The network security group for the virtual network must allow access to specific ports and protocols. If these ports are blocked, the Azure platform can't monitor or update the managed domain. The synchronization between the Microsoft Entra directory and Microsoft Entra DS is also impacted. Make sure you keep the default ports open to avoid interruption in service.

+The following default inbound and outbound security rules are applied to the network security group for a managed domain. These rules keep Microsoft Entra DS secure and allow the Azure platform to monitor, manage, and update the managed domain.

+> Microsoft Entra DS needs unrestricted outbound access from the virtual network. We don't recommend that you create any additional rules that restrict outbound access for the virtual network.

+ Title: Resolve service principal alerts in Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to troubleshoot service principal configuration alerts for Microsoft Entra Domain Services

+# Known issues: Service principal alerts in Microsoft Entra Domain Services

+[Service principals](../active-directory/develop/app-objects-and-service-principals.md) are applications that the Azure platform uses to manage, update, and maintain a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain. If a service principal is deleted, functionality in the managed domain is impacted.

+*A Service Principal required for Microsoft Entra Domain Services to function properly has been deleted from your Microsoft Entra directory. This configuration impacts Microsoft's ability to monitor, manage, patch, and synchronize your managed domain.*

+If application ID *2565bd9d-da50-47d4-8b85-4c97f669dc36* is missing from your Microsoft Entra directory in Azure Global, use Azure AD PowerShell to complete the following steps. For other Azure clouds, use AppId value *6ba9a5d4-8456-4118-b521-9c5ca10cdf84*. For more information, see [Azure AD PowerShell](/powershell/azure/active-directory/install-adv2).

+<a name='re-register-the-microsoft-aad-namespace'></a>

+### Re-register the Microsoft Entra namespace

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

+*The service principal with the application ID "d87dcbc6-a371-462e-88e3-28ad15ec4e64" was deleted and then recreated. The recreation leaves behind inconsistent permissions on Microsoft Entra Domain Services resources needed to service your managed domain. Synchronization of passwords on your managed domain could be affected.*

+Microsoft Entra DS automatically synchronizes user accounts and credentials from Microsoft Entra ID. If there's a problem with the Microsoft Entra application used for this process, credential synchronization between Microsoft Entra DS and Microsoft Entra ID fails.

+To recreate the Microsoft Entra application used for credential synchronization, use Azure AD PowerShell to complete the following steps. For more information, see [install Azure AD PowerShell](/powershell/azure/active-directory/install-adv2).

+ Title: Change the SKU for a Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to the SKU tier for a Microsoft Entra Domain Services managed domain if your business requirements change

+#Customer intent: As an identity administrator, I want to change the SKU for my Microsoft Entra Domain Services managed domain to use different features as my business requirements change.

+# Change the SKU for an existing Microsoft Entra Domain Services managed domain

+In Microsoft Entra Domain Services (Microsoft Entra DS), the available performance and features are based on the SKU type. These feature differences include the backup frequency or maximum number of one-way outbound forest trusts.

+You select a SKU when you create the managed domain, and you can switch SKUs up or down as your business needs change after the managed domain has been deployed. Changes in business requirements could include the need for more frequent backups or to create additional forest trusts. For more information on the limits and pricing of the different SKUs, see [Microsoft Entra DS SKU concepts][concepts-sku] and [Microsoft Entra DS pricing][pricing] pages.

+This article shows you how to change the SKU for an existing Microsoft Entra DS managed domain using the [Microsoft Entra admin center](https://entra.microsoft.com).

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+For more information on these limits, see [Microsoft Entra DS SKU features and limits][concepts-sku].

+1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Microsoft Entra Domain Services**. Choose your managed domain from the list, such as *aaddscontoso.com*.

+1. In the menu on the left-hand side of the Microsoft Entra DS page, select **Settings > SKU**.

+ 

+If you have a resource forest and want to create additional trusts after the SKU change, see [Create an outbound forest trust to an on-premises domain in Microsoft Entra DS][create-trust].

+ Title: Check the health of Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to check the health of a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain and understand status messages.

+# Check the health of a Microsoft Entra Domain Services managed domain

+Microsoft Entra Domain Services (Microsoft Entra DS) runs some background tasks to keep the managed domain healthy and up-to-date. These tasks include taking backups, applying security updates, and synchronizing data from Microsoft Entra ID. If there are issues with the Microsoft Entra DS managed domain, these tasks may not successfully complete. To review and resolve any issues, you can check the health status of a managed domain using the Microsoft Entra admin center.

+This article shows you how to view the Microsoft Entra DS health status and understand the information or alerts shown.

+The health status for a managed domain is viewed using the Microsoft Entra admin center. Information on the last backup time and synchronization with Microsoft Entra ID can be seen, along with any alerts that indicate a problem with the managed domain's health. To view the health status for a managed domain, complete the following steps:

+1. Search for and select **Microsoft Entra Domain Services**.

+1. On the left-hand side of the Microsoft Entra DS resource window, select **Health**. The following example screenshot shows a healthy managed domain and the status of the last backup and Azure AD synchronization:

+ 

+Monitors are areas of a managed domain that are checked on a regular basis. If there are any active alerts for the managed domain, it may cause one of the monitors to report an issue. Microsoft Entra DS currently has monitors for the following areas:

+* Synchronization with Microsoft Entra ID

+<a name='synchronization-with-azure-ad-monitor'></a>

+#### Synchronization with Microsoft Entra ID monitor

+A managed domain regularly synchronizes with Microsoft Entra ID. The number of users and group objects, and the number of changes made in the Microsoft Entra directory since the last sync, affects how long it takes to synchronize. If the managed domain was last synchronized over three days ago, check for and resolve any active alerts. If the synchronization monitor doesn't update the status to show a recent sync after you address any active alerts, [open an Azure support request][azure-support].

+description: In this overview, you compare the different identity offerings for Active Directory Domain Services, Microsoft Entra ID, and Microsoft Entra Domain Services.

+#Customer intent: As an IT administrator or decision maker, I want to understand the differences between Active Directory Domain Services (AD DS), Microsoft Entra ID, and Microsoft Entra DS so I can choose the most appropriate identity solution for my organization.

+# Compare self-managed Active Directory Domain Services, Microsoft Entra ID, and managed Microsoft Entra Domain Services

+To provide applications, services, or devices access to a central identity, there are three common ways to use Active Directory-based services in Azure. This choice in identity solutions gives you the flexibility to use the most appropriate directory for your organization's needs. For example, if you mostly manage cloud-only users that run mobile devices, it may not make sense to build and run your own Active Directory Domain Services (AD DS) identity solution. Instead, you could just use Microsoft Entra ID.

+* **Microsoft Entra ID** - Cloud-based identity and mobile device management that provides user account and authentication services for resources such as Microsoft 365, the Microsoft Entra admin center, or SaaS applications.

+ * Microsoft Entra ID can be synchronized with an on-premises AD DS environment to provide a single identity to users that works natively in the cloud.

+ * For more information about Microsoft Entra ID, see [What is Microsoft Entra ID?][whatis-azuread]

+* **Microsoft Entra Domain Services (Microsoft Entra DS)** - Provides managed domain services with a subset of fully compatible traditional AD DS features such as domain join, group policy, LDAP, and Kerberos / NTLM authentication.

+ * Microsoft Entra DS integrates with Microsoft Entra ID, which itself can synchronize with an on-premises AD DS environment. This ability extends central identity use cases to traditional web applications that run in Azure as part of a lift-and-shift strategy.

+ * To learn more about synchronization with Microsoft Entra ID and on-premises, see [How objects and credentials are synchronized in a managed domain][synchronization].

+> [To get started, create a Microsoft Entra DS managed domain using the Microsoft Entra admin center][tutorial-create]

+<a name='azure-ad-ds-and-self-managed-ad-ds'></a>

+## Microsoft Entra DS and self-managed AD DS

+* A *managed domain* that you create using Microsoft Entra Domain Services (Microsoft Entra DS). Microsoft creates and manages the required resources.

+With Microsoft Entra DS, the core service components are deployed and maintained for you by Microsoft as a *managed* domain experience. You don't deploy, manage, patch, and secure the AD DS infrastructure for components like the VMs, Windows Server OS, or domain controllers (DCs).

+Microsoft Entra DS provides a smaller subset of features to traditional self-managed AD DS environment, which reduces some of the design and management complexity. For example, there are no AD forests, domain, sites, and replication links to design and maintain. You can still [create forest trusts between Microsoft Entra DS and on-premises environments][create-forest-trust].

+For applications and services that run in the cloud and need access to traditional authentication mechanisms such as Kerberos or NTLM, Microsoft Entra DS provides a managed domain experience with the minimal amount of administrative overhead. For more information, see [Management concepts for user accounts, passwords, and administration in Microsoft Entra DS][administration-concepts].

+The following table outlines some of the features you may need for your organization, and the differences between a managed Microsoft Entra DS domain or a self-managed AD DS domain:

+| **Feature** | **Microsoft Entra DS** | **Self-managed AD DS** |

+<a name='azure-ad-ds-and-azure-ad'></a>

+## Microsoft Entra DS and Microsoft Entra ID

+Microsoft Entra ID lets you manage the identity of devices used by the organization and control access to corporate resources from those devices. Users can also register their personal device (a bring-your-own (BYO) model) with Microsoft Entra ID, which provides the device with an identity. Microsoft Entra ID then authenticates the device when a user signs in to Microsoft Entra ID and uses the device to access secured resources. The device can be managed using Mobile Device Management (MDM) software like Microsoft Intune. This management ability lets you restrict access to sensitive resources to managed and policy-compliant devices.

+Traditional computers and laptops can also join to Microsoft Entra ID. This mechanism offers the same benefits of registering a personal device with Microsoft Entra ID, such as to allow users to sign in to the device using their corporate credentials.

+Microsoft Entra joined devices give you the following benefits:

+* Single-sign-on (SSO) to applications secured by Microsoft Entra ID.

+Devices can be joined to Microsoft Entra ID with or without a hybrid deployment that includes an on-premises AD DS environment. The following table outlines common device ownership models and how they would typically be joined to a domain:

+| Personal devices | Windows 10, iOS, Android, macOS | Microsoft Entra registered |

+| Organization-owned device not joined to on-premises AD DS | Windows 10 | Microsoft Entra joined |

+| Organization-owned device joined to an on-premises AD DS | Windows 10 | Microsoft Entra hybrid joined |

+On a Microsoft Entra joined or registered device, user authentication happens using modern OAuth / OpenID Connect based protocols. These protocols are designed to work over the internet, so are great for mobile scenarios where users access corporate resources from anywhere.

+With Microsoft Entra DS-joined devices, applications can use the Kerberos and NTLM protocols for authentication, so can support legacy applications migrated to run on Azure VMs as part of a lift-and-shift strategy. The following table outlines differences in how the devices are represented and can authenticate themselves against the directory:

+| **Aspect** | **Microsoft Entra joined** | **Microsoft Entra DS-joined** |

+| Device controlled by | Microsoft Entra ID | Microsoft Entra DS managed domain |

+| Representation in the directory | Device objects in the Microsoft Entra directory | Computer objects in the Microsoft Entra DS managed domain |

+If on-premises AD DS and Microsoft Entra ID are configured for federated authentication using AD FS, then there's no (current/valid) password hash available in Azure DS. Microsoft Entra user accounts created before fed auth was implemented might have an old password hash but this likely doesn't match a hash of their on-premises password. Hence Microsoft Entra DS won't be able to validate the users credentials

+To get started with using Microsoft Entra DS, [create a Microsoft Entra DS managed domain using the Microsoft Entra admin center][tutorial-create].

+[management concepts for user accounts, passwords, and administration in Microsoft Entra DS][administration-concepts] and [how objects and credentials are synchronized in a managed domain][synchronization].

+ Title: Create and manage custom attributes for Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to create and manage custom attributes in a Microsoft Entra DS managed domain.

+# Custom attributes for Microsoft Entra Domain Services

+Microsoft Entra ID supports adding custom data to resources using [extensions](/graph/extensibility-overview). Microsoft Entra Domain Services (Microsoft Entra DS) can synchronize the following types of extensions from Microsoft Entra ID, so you can also use apps that depend on custom attributes with Microsoft Entra DS:

+Both types of extensions can be configured by using Microsoft Entra Connect for users who are managed on-premises, or Microsoft Graph APIs for cloud-only users.

+>- Custom security attributes in Microsoft Entra ID (Preview)

+The minimum SKU supported for custom attributes is the Enterprise SKU. If you use Standard, you need to [upgrade](change-sku.md) the managed domain to Enterprise or Premium. For more information, see [Microsoft Entra Domain Pricing](https://azure.microsoft.com/pricing/details/active-directory-ds/).

+<a name='synchronize-azure-ad-directory-extension-attributes-'></a>

+## Synchronize Microsoft Entra directory extension attributes

+These are the extended user or group attributes defined in your Microsoft Entra tenant.

+>If you would like to see directory extensions synchronized by Microsoft Entra Connect, click **Enterprise App** and look for the Application ID of the **Tenant Schema Extension App**. For more information, see [Microsoft Entra Connect Sync: Directory extensions](../active-directory/hybrid/connect/how-to-connect-sync-feature-directory-extensions.md#configuration-changes-in-azure-ad-made-by-the-wizard).

+Microsoft Entra DS back fills all synchronized users and groups with the onboarded custom attribute values. The custom attribute values gradually populate for objects that contain the directory extension in Microsoft Entra ID. During the backfill synchronization process, incremental changes in Microsoft Entra ID are paused, and the sync time depends on the size of the tenant.

+To check the backfilling status, click **Microsoft Entra DS Health** and verify the **Synchronization with Microsoft Entra ID** monitor has an updated timestamp within an hour since onboarding. Once updated, the backfill is complete.

+To configure onPremisesExtensionAttributes or directory extensions for cloud-only users in Microsoft Entra ID, see [Custom data options in Microsoft Graph](/graph/extensibility-overview?tabs=http#custom-data-options-in-microsoft-graph).

+To sync onPremisesExtensionAttributes or directory extensions from on-premises to Microsoft Entra ID, [configure Microsoft Entra Connect](../active-directory/hybrid/connect/how-to-connect-sync-feature-directory-extensions.md).

+ Title: How trusts work for Microsoft Entra Domain Services | Microsoft Docs

+description: Learn more about how forest trust work with Microsoft Entra Domain Services

+>Microsoft Entra DS only supports one-way transitive trusts where the managed domain will trust other domains, but no other directions or trust types are supported.

+For an overview of how trusts apply to Microsoft Entra DS, see [Forest concepts and features][create-forest-trust].

+To get started using trusts in Microsoft Entra DS, [create a managed domain that uses forest trusts][tutorial-create-advanced].

+> Microsoft Entra Domain Services only supports a one-way forest trust to on-premises Active Directory.

+ > Any Microsoft Entra Domain Services forest with a trust must use this DNS configuration. Hosting a DNS namespace other than the forest DNS namespace is not a feature of Microsoft Entra Domain Services. Conditional forwarders is the proper configuration.

+A managed domain forest supports up to five one-way outbound forest trusts to on-premises forests. The outbound forest trust for Microsoft Entra Domain Services is created in the Microsoft Entra admin center. You don't manually create the trust with the managed domain itself. The incoming forest trust must be configured by a user with the privileges previously noted in the on-premises Active Directory.

+>Alternate UPN suffixes on trusts are not supported. If an on-premises domain uses the same UPN suffix as Microsoft Entra DS, sign in must use **sAMAccountName**.

+To get started with creating a managed domain with a forest trust, see [Create and configure a Microsoft Entra DS managed domain][tutorial-create-advanced]. You can then [Create an outbound forest trust to an on-premises domain][create-forest-trust].

+ Title: Replica sets concepts for Microsoft Entra Domain Services | Microsoft Docs

+description: Learn what replica sets are in Microsoft Entra Domain Services and how they provide redundancy to applications that require identity services.

+# Replica sets concepts and features for Microsoft Entra Domain Services

+When you create a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain, you define a unique namespace. This namespace is the domain name, such as *aaddscontoso.com*, and two domain controllers (DCs) are then deployed into your selected Azure region. This deployment of DCs is known as a replica set.

+You can expand a managed domain to have more than one replica set per Microsoft Entra tenant. Replica sets can be added to any peered virtual network in any Azure region that supports Microsoft Entra DS. Additional replica sets in different Azure regions provide geographical disaster recovery for legacy applications if an Azure region goes offline.

+When you create a managed domain, such as *aaddscontoso.com*, an initial replica set is created. Additional replica sets share the same namespace and configuration. Changes to Microsoft Entra DS, including configuration, user identity and credentials, groups, group policy objects, computer objects, and other changes are applied to all replica sets in the managed domain using AD DS replication.

+All replica sets are connected to each other using a mesh virtual network peering. One replica set receives user and group updates from Microsoft Entra ID. Those changes are then replicated to the other replica sets using intrasite AD DS replication over the peered network.

+To get started with replica sets, [create and configure a Microsoft Entra DS managed domain][tutorial-create-advanced]. When deployed, [create and use additional replica sets][create-replica-set].

+ Title: Create a Microsoft Entra Domain Services forest trust using Azure PowerShell | Microsoft Docs

+description: In this article, learn how to create and configure a Microsoft Entra Domain Services forest trust to an on-premises Active Directory Domain Services environment using Azure PowerShell.

+#Customer intent: As an identity administrator, I want to create a Microsoft Entra Domain Services forest and one-way outbound trust from a Microsoft Entra Domain Services forest to an on-premises Active Directory Domain Services forest using Azure PowerShell to provide authentication and resource access between forests.

+# Create a Microsoft Entra Domain Services forest trust to an on-premises domain using Azure PowerShell

+In environments where you can't synchronize password hashes, or you have users that exclusively sign in using smart cards so they don't know their password, you can create a one-way outbound trust from Microsoft Entra Domain Services (Microsoft Entra DS) to one or more on-premises AD DS environments. This trust relationship lets users, applications, and computers authenticate against an on-premises domain from the Microsoft Entra DS managed domain. In this case, on-premises password hashes are never synchronized.

+

+> * Create a Microsoft Entra DS forest using Azure PowerShell

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+ * If needed, follow the instructions to [install the Azure AD PowerShell module and connect to Microsoft Entra ID](/powershell/azure/active-directory/install-adv2).

+ * Make sure that you sign in to your Microsoft Entra tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet.

+* You need [Application Administrator](../active-directory/roles/permissions-reference.md#application-administrator) and [Groups Administrator](../active-directory/roles/permissions-reference.md#groups-administrator) Microsoft Entra roles in your tenant to enable Microsoft Entra DS.

+* You need [Domain Services Contributor](../role-based-access-control/built-in-roles.md#contributor) Azure role to create the required Microsoft Entra DS resources.

+<a name='create-the-azure-ad-service-principal'></a>

+## Create the Microsoft Entra service principal

+Microsoft Entra DS requires a service principal synchronize data from Microsoft Entra ID. This principal must be created in your Microsoft Entra tenant before you created the managed domain forest.

+Create a Microsoft Entra service principal for Microsoft Entra DS to communicate and authenticate itself. A specific application ID is used named *Domain Controller Services* with an ID of *6ba9a5d4-8456-4118-b521-9c5ca10cdf84*. Don't change this application ID.

+Create a Microsoft Entra service principal using the [New-AzureADServicePrincipal][New-AzureADServicePrincipal] cmdlet:

+To create a managed domain, you use the `New-AzureAaddsForest` script. This script is part of a wider set of commands that support managed domains, including create the one-way bound forest in a following section. These scripts are available from the [PowerShell Gallery](https://www.powershellgallery.com/) and are digitally signed by the Microsoft Entra engineering team.

+ | Subscription | *-azureSubscriptionId* | Subscription ID used for Microsoft Entra DS billing. You can get the list of subscriptions using the [Get-AzureRMSubscription][Get-AzureRMSubscription] cmdlet. |

+ | Location | *-aaddsLocation* | The Azure region to host your managed domain. For available regions, see [supported regions for Microsoft Entra DS.](https://azure.microsoft.com/global-infrastructure/services/?products=active-directory-ds&regions=all) |

+ | Microsoft Entra DS administrator | *-aaddsAdminUser* | The user principal name of the first managed domain administrator. This account must be an existing cloud user account in your Microsoft Entra ID. The user, and the user running the script, is added to the *AAD DC Administrators* group. |

+ | Microsoft Entra DS domain name | *-aaddsDomainName* | The FQDN of the managed domain, based on the previous guidance on how to choose a forest name. |

+ The `New-AzureAaddsForest` script can create the Azure virtual network and Microsoft Entra DS subnet if these resources don't already exist. The script can optionally create the workload subnets, when specified:

+ | Microsoft Entra DS subnet name | *-aaddsSubnetName* | Name of the subnet of the *aaddsVnetName* virtual network hosting the managed domain. Don't deploy your own VMs and workloads into this subnet. |

+ | Microsoft Entra DS address range | *-aaddsSubnetCIDRAddressRange* | Subnet address range in CIDR notation for the Microsoft Entra DS instance, such as *192.168.1.0/24*. Address range must be contained by the address range of the virtual network, and different from other subnets. |

+ It takes quite some time to create the managed domain forest and supporting resources. Allow the script to complete. Continue on to the next section to configure your on-premises network connectivity while the Microsoft Entra forest provisions in the background.

+1. In the Microsoft Entra admin center, search for and select **Microsoft Entra Domain Services**. Choose your managed domain, such as *aaddscontoso.com* and wait for the status to report as **Running**.

+ When running, [update DNS settings for the Azure virtual network](tutorial-create-instance.md#update-dns-settings-for-the-azure-virtual-network) and then [enable user accounts for Microsoft Entra DS](tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds) to finalize the configurations for your managed domain.

+| Microsoft Entra DS domain name | *-ManagedDomainFqdn* | FQDN of the managed domain, such as *aaddscontoso.com* |

+* [On-premises user authentication from the Microsoft Entra DS forest](#on-premises-user-authentication-from-the-azure-ad-ds-forest)

+* [Access resources in the Microsoft Entra DS forest as an on-premises user](#access-resources-in-azure-ad-ds-as-an-on-premises-user)

+<a name='on-premises-user-authentication-from-the-azure-ad-ds-forest'></a>

+### On-premises user authentication from the Microsoft Entra DS forest

+ > To securely connect to your VMs joined to Microsoft Entra Domain Services, you can use the [Azure Bastion Host Service](../bastion/bastion-overview.md) in supported Azure regions.

+<a name='access-resources-in-azure-ad-ds-as-an-on-premises-user'></a>

+### Access resources in Microsoft Entra DS as an on-premises user

+ > To securely connect to your VMs joined to Microsoft Entra Domain Services, you can use the [Azure Bastion Host Service](../bastion/bastion-overview.md) in supported Azure regions.

+For more conceptual information about forest types in Microsoft Entra DS, see [How do forest trusts work in Microsoft Entra DS?][concepts-trust]

+ Title: Group managed service accounts for Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to create a group managed service account (gMSA) for use with Microsoft Entra Domain Services managed domains

+# Create a group managed service account (gMSA) in Microsoft Entra Domain Services

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

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+* A Windows Server management VM that is joined to the Microsoft Entra DS managed domain.

+<a name='using-service-accounts-in-azure-ad-ds'></a>

+## Using service accounts in Microsoft Entra DS

+ * The KDS root key is used to generate and retrieve passwords for gMSAs. In Microsoft Entra DS, the KDS root is created for you.

+First, create a custom OU using the [New-ADOrganizationalUnit][New-AdOrganizationalUnit] cmdlet. For more information on creating and managing custom OUs, see [Custom OUs in Microsoft Entra DS][create-custom-ou].

+ Title: Create an organizational unit (OU) in Microsoft Entra Domain Services | Microsoft Docs'

+description: Learn how to create and manage a custom Organizational Unit (OU) in a Microsoft Entra Domain Services managed domain.

+# Create an Organizational Unit (OU) in a Microsoft Entra Domain Services managed domain

+Microsoft Entra DS managed domains include the following two built-in OUs:

+* *AADDC Users* - includes users and groups synchronized in from the Microsoft Entra tenant.

+As you create and run workloads that use Microsoft Entra DS, you may need to create service accounts for applications to authenticate themselves. To organize these service accounts, you often create a custom OU in the managed domain and then create service accounts within that OU.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+* A Windows Server management VM that is joined to the Microsoft Entra DS managed domain.

+* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

+* A default OU for *AADDC Users* is created that contains all the synchronized user accounts from your Microsoft Entra tenant.

+* User accounts, groups, service accounts, and computer objects that you create under custom OUs aren't available in your Microsoft Entra tenant.

+ * These objects don't show up using the Microsoft Graph API or in the Microsoft Entra UI; they're only available in your managed domain.

+ Title: Microsoft Entra Domain Services for Cloud Solution Providers | Microsoft Docs

+description: Learn how to enable and manage Microsoft Entra Domain Services managed domains for Azure Cloud Solution Providers

+# Microsoft Entra Domain Services deployment and management for Azure Cloud Solution Providers

+The following diagram illustrates how the CSP model works at a high level. Here, Contoso has a Microsoft Entra tenant. They have a partnership with a CSP, who deploys and manages resources in their Azure CSP subscription. Contoso may also have regular (direct) Azure subscriptions, which are billed directly to Contoso.

+The *Admin* agents group is assigned to the tenant administrator role in Contoso's Microsoft Entra tenant. As a result, a user belonging to the CSP partner's admin agents group has tenant admin privileges in Contoso's Microsoft Entra tenant.

+When the CSP partner provisions an Azure CSP subscription for Contoso, their admin agents group is assigned to the owner role for that subscription. As a result, the CSP partner's admin agents have the required privileges to provision Azure resources such as virtual machines, virtual networks, and Microsoft Entra Domain Services on behalf of Contoso.

+<a name='benefits-of-using-azure-ad-ds-in-an-azure-csp-subscription'></a>

+## Benefits of using Microsoft Entra DS in an Azure CSP subscription

+Microsoft Entra Domain Services (Microsoft Entra DS) provides managed domain services such as domain join, group policy, LDAP, Kerberos/NTLM authentication that is fully compatible with Windows Server Active Directory Domain Services. Over the decades, many applications have been built to work against AD using these capabilities. Many independent software vendors (ISVs) have built and deployed applications at their customers' premises. These applications are hard to support since you often require access to the different environments where the applications are deployed. With Azure CSP subscriptions, you have a simpler alternative with the scale and flexibility of Azure.

+Microsoft Entra DS supports Azure CSP subscriptions. You can deploy your application in an Azure CSP subscription tied to your customer's Microsoft Entra tenant. As a result, your employees (support staff) can manage, administer, and service the VMs on which your application is deployed using your organization's corporate credentials.

+You can also deploy a Microsoft Entra DS managed domain in your customer's Microsoft Entra tenant. Your application is then connected to your customer's managed domain. Capabilities within your application that rely on Kerberos / NTLM, LDAP, or the [System.DirectoryServices API](/dotnet/api/system.directoryservices) work seamlessly against your customer's domain. End customers benefit from consuming your application as a service, without needing to worry about maintaining the infrastructure the application is deployed on.

+All billing for Azure resources you consume in that subscription, including Microsoft Entra DS, is charged back to you. You maintain full control over the relationship with the customer when it comes to sales, billing, technical support etc. With the flexibility of the Azure CSP platform, a small team of support agents can service many such customers who have instances of your application deployed.

+<a name='csp-deployment-models-for-azure-ad-ds'></a>

+## CSP deployment models for Microsoft Entra DS

+There are two ways in which you can use Microsoft Entra DS with an Azure CSP subscription. Pick the right one based on the security and simplicity considerations your customers have.

+In this deployment model, Microsoft Entra DS is enabled within a virtual network that belongs to the Azure CSP subscription. The CSP partner's admin agents have the following privileges:

+* *Global administrator* privileges in the customer's Microsoft Entra tenant.

+In this deployment model, the CSP provider's admin agents can administer identities for the customer. These admin agents can perform tasks like provision new users or groups, or add applications within the customer's Microsoft Entra tenant.

+In this deployment model, Microsoft Entra DS is enabled within a virtual network belonging to the customer - a direct Azure subscription paid for by the customer. The CSP partner can deploy applications within a virtual network belonging to the customer's CSP subscription. The virtual networks can then be connected using Azure virtual network peering.

+This deployment model provides a separation of privileges and enables the CSP partner's helpdesk agents to administer the Azure subscription and deploy and manage resources within it. However, the CSP partner's helpdesk agents don't need to have global administrator privileges on the customer's Microsoft Entra directory. The customer's identity administrators can continue to manage identities for their organization.

+This deployment model may be suited to scenarios where an ISV provides a hosted version of their on-premises application, which also needs to connect to the customer's Microsoft Entra ID.

+<a name='administer-azure-ad-ds-in-csp-subscriptions'></a>

+## Administer Microsoft Entra DS in CSP subscriptions

+* **CSP admin agents can provision a managed domain using their credentials:** Microsoft Entra DS supports Azure CSP subscriptions. Users belonging to a CSP partner's admin agents group can provision a new managed domain.

+* **CSPs can script creation of new managed domains for their customers using PowerShell:** See [how to enable Microsoft Entra DS using PowerShell](powershell-create-instance.md) for details.

+* **CSP admin agents can't perform ongoing management tasks on the managed domain using their credentials:** CSP admin users can't perform routine management tasks within the managed domain using their credentials. These users are external to the customer's Microsoft Entra tenant and their credentials aren't available within the customer's Microsoft Entra tenant. Microsoft Entra DS doesn't have access to the Kerberos and NTLM password hashes for these users, so users can't be authenticated on managed domains.

+ > You can't sign in to the managed domain using a CSP admin user's credentials. Use the credentials of a user account belonging to the customer's Microsoft Entra tenant to do so. You need these credentials for tasks such as joining VMs to the managed domain, administering DNS, or administering Group Policy.

+ For a CSP partner to perform these tasks on a managed domain, a user account must be created within the customer's Microsoft Entra tenant. The credentials for this account must be shared with the CSP partner's admin agents. Also, this user account must be added to the *AAD DC Administrators* group to enable configuration tasks on the managed domain to be performed using this user account.

+To get started, [enroll in the Azure CSP program](/partner-center/enrolling-in-the-csp-program). You can then enable Microsoft Entra Domain Services using the [Microsoft Entra admin center](tutorial-create-instance.md) or [Azure PowerShell](powershell-create-instance.md).

+ Title: Delete Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to disable, or delete, a Microsoft Entra Domain Services managed domain

+# Delete a Microsoft Entra Domain Services managed domain

+If you no longer need a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain, you can delete it. There's no option to turn off or temporarily disable a Microsoft Entra DS managed domain. Deleting the managed domain doesn't delete or otherwise adversely impact the Microsoft Entra tenant.

+1. Search for and select **Microsoft Entra Domain Services**.

+Consider [sharing feedback][feedback] for the features that you would like to see in Microsoft Entra DS.

+If you want to get started with Microsoft Entra DS again, see [Create and configure a Microsoft Entra Domain Services managed domain][create-instance].

+ Title: Deploy Microsoft Entra application proxy for Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to provide secure access to internal applications for remote workers by deploying and configuring Microsoft Entra application proxy in a Microsoft Entra Domain Services managed domain

+# Deploy Microsoft Entra application proxy for secure access to internal applications in a Microsoft Entra Domain Services managed domain

+With Microsoft Entra Domain Services (Microsoft Entra DS), you can lift-and-shift legacy applications running on-premises into Azure. Microsoft Entra application proxy then helps you support remote workers by securely publishing those internal applications part of a Microsoft Entra DS managed domain so they can be accessed over the internet.

+If you're new to the Microsoft Entra application proxy and want to learn more, see [How to provide secure remote access to internal applications](../active-directory/app-proxy/application-proxy.md).

+This article shows you how to create and configure a Microsoft Entra application proxy connector to provide secure access to applications in a managed domain.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+ * An **Microsoft Entra ID P1 or P2 license** is required to use the Microsoft Entra application proxy.

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+To route traffic to applications running in your environment, you install the Microsoft Entra application proxy connector component. This Microsoft Entra application proxy connector must be installed on a Windows Server virtual machine (VM) that's joined to the managed domain. For some applications, you can deploy multiple servers that each have the connector installed. This deployment option gives you greater availability and helps handle heavier authentication loads.

+The VM that runs the Microsoft Entra application proxy connector must be on the same, or a peered, virtual network as your managed domain. The VMs that then host the applications you publish using the Application Proxy must also be deployed on the same Azure virtual network.

+To create a VM for the Microsoft Entra application proxy connector, complete the following steps:

+1. [Create a custom OU](create-ou.md). You can delegate permissions to manage this custom OU to users within the managed domain. The VMs for Microsoft Entra application proxy and that run your applications must be a part of the custom OU, not the default *Microsoft Entra DC Computers* OU.

+1. [Domain-join the virtual machines][create-join-windows-vm], both the one that runs the Microsoft Entra application proxy connector, and the ones that run your applications, to the managed domain. Create these computer accounts in the custom OU from the previous step.

+<a name='download-the-azure-ad-application-proxy-connector'></a>

+## Download the Microsoft Entra application proxy connector

+Perform the following steps to download the Microsoft Entra application proxy connector. The setup file you download is copied to your App Proxy VM in the next section.

+ 

+<a name='install-and-register-the-azure-ad-application-proxy-connector'></a>

+## Install and register the Microsoft Entra application proxy connector

+With a VM ready to be used as the Microsoft Entra application proxy connector, now copy and run the setup file downloaded from the Microsoft Entra admin center.

+1. Copy the Microsoft Entra application proxy connector setup file to your VM.

+1. During the install, you're prompted to register the connector with the Application Proxy in your Microsoft Entra directory.

+ * Provide the credentials for a global administrator in your Microsoft Entra directory. The Microsoft Entra Global Administrator credentials may be different from your Azure credentials in the portal

+ > For example, if the Microsoft Entra domain is *contoso.com*, the global administrator should be `admin@contoso.com` or another valid alias on that domain.

+1. At the end of the setup, a note is shown for environments with an outbound proxy. To configure the Microsoft Entra application proxy connector to work through the outbound proxy, run the provided script, such as `C:\Program Files\Microsoft AAD App Proxy connector\ConfigureOutBoundProxy.ps1`.

+ 

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

+If you want to use single sign-on to your applications using integrated Windows authentication (IWA), grant the Microsoft Entra application proxy connectors permission to impersonate users and send and receive tokens on their behalf. To grant these permissions, you configure Kerberos constrained delegation (KCD) for the connector to access resources on the managed domain. As you don't have domain administrator privileges in a managed domain, traditional account-level KCD cannot be configured on a managed domain. Instead, use resource-based KCD.

+For more information, see [Configure Kerberos constrained delegation (KCD) in Microsoft Entra Domain Services](deploy-kcd.md).

+> You must be signed in to a user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant to run the following PowerShell cmdlets.

+> The computer accounts for your App Proxy connector VM and application VMs must be in a custom OU where you have permissions to configure resource-based KCD. You can't configure resource-based KCD for a computer account in the built-in *Microsoft Entra DC Computers* container.

+Use the [Get-ADComputer][Get-ADComputer] to retrieve the settings for the computer on which the Microsoft Entra application proxy connector is installed. From your domain-joined management VM and logged in as user account that's a member of the *Microsoft Entra DC administrators* group, run the following cmdlets.

+The following example gets information about the computer account named *appproxy.aaddscontoso.com*. Provide your own computer name for the Microsoft Entra application proxy VM configured in the previous steps.

+For each application server that runs the apps behind Microsoft Entra application proxy use the [Set-ADComputer][Set-ADComputer] PowerShell cmdlet to configure resource-based KCD. In the following example, the Microsoft Entra application proxy connector is granted permissions to use the *appserver.aaddscontoso.com* computer:

+If you deploy multiple Microsoft Entra application proxy connectors, you must configure resource-based KCD for each connector instance.

+With the Microsoft Entra application proxy integrated with Microsoft Entra DS, publish applications for users to access. For more information, see [publish applications using Microsoft Entra application proxy](../active-directory/app-proxy/application-proxy-add-on-premises-application.md).

+ Title: Kerberos constrained delegation for Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to enable resource-based Kerberos constrained delegation (KCD) in a Microsoft Entra Domain Services managed domain.

+# Configure Kerberos constrained delegation (KCD) in Microsoft Entra Domain Services

+Microsoft Entra Domain Services (Microsoft Entra DS) managed domains are more securely locked down than traditional on-premises AD DS environments, so use a more secure *resource-based* KCD.

+This article shows you how to configure resource-based Kerberos constrained delegation in a Microsoft Entra DS managed domain.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+* A Windows Server management VM that is joined to the Microsoft Entra DS managed domain.

+* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

+ > The computer accounts for the web app and the web API must be in a custom OU where you have permissions to configure resource-based KCD. You can't configure resource-based KCD for a computer account in the built-in *Microsoft Entra DC Computers* container.

+ From your domain-joined management VM and logged in as user account that's a member of the *Microsoft Entra DC administrators* group, run the following cmdlets. Provide your own computer names as needed:

+ > Again, the computer account for the web API VM, and the service account for the web app, must be in a custom OU where you have permissions to configure resource-based KCD. You can't configure resource-based KCD for accounts in the built-in *Microsoft Entra DC Computers* or *Microsoft Entra DC Users* containers. This also means that you can't use user accounts synchronized from Microsoft Entra ID to set up resource-based KCD. You must create and use service accounts specifically created in Microsoft Entra DS.

+ From your domain-joined management VM and logged in as user account that's a member of the *Microsoft Entra DC administrators* group, run the following cmdlets. Provide your own service names as needed:

+ Title: Enable SharePoint User Profile service with Microsoft Entra DS | Microsoft Docs

+description: Learn how to configure a Microsoft Entra Domain Services managed domain to support profile synchronization for SharePoint Server

+# Configure Microsoft Entra Domain Services to support user profile synchronization for SharePoint Server

+SharePoint Server includes a service to synchronize user profiles. This feature allows user profiles to be stored in a central location and accessible across multiple SharePoint sites and farms. To configure the SharePoint Server user profile service, the appropriate permissions must be granted in a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain. For more information, see [user profile synchronization in SharePoint Server](/SharePoint/administration/user-profile-service-administration).

+This article shows you how to configure Microsoft Entra DS to allow the SharePoint Server user profile sync service.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+* A Windows Server management VM that is joined to the Microsoft Entra DS managed domain.

+* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

+In a managed domain, a security group named *Microsoft Entra DC Service Accounts* exists as part of the *Users* organizational unit (OU). Members of this security group are delegated the following privileges:

+The *Microsoft Entra DC Service Accounts* security group is also a member of the built-in group *Pre-Windows 2000 Compatible Access*.

+The service account for SharePoint Server needs adequate privileges to replicate changes to the directory and let SharePoint Server user profile sync work correctly. To provide these privileges, add the service account used for SharePoint user profile synchronization to the *Microsoft Entra DC Service Accounts* group.

+From your Microsoft Entra DS management VM, complete the following steps:

+1. Select the **Users** OU, then choose the *Microsoft Entra DC Service Accounts* security group.

+ 

+[sharepoint-service-account]: /sharepoint/security-for-sharepoint-server/plan-for-administrative-and-service-accounts

+ Title: Microsoft Entra Domain Services (Microsoft Entra DS) feature availability in Azure Government

+description: Learn which Microsoft Entra DS features are available in Azure Government.

+# Microsoft Entra Domain Services feature availability

+This following table lists Microsoft Entra Domain Services (Microsoft Entra DS) feature availability in Azure Government.

+| Deploy Microsoft Entra application proxy | &#x2705; |

+ Title: Check fleet metrics of Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to check fleet metrics of a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain.

+# Check fleet metrics of Microsoft Entra Domain Services

+Administrators can use Azure Monitor Metrics to configure a scope for Microsoft Entra Domain Services (Microsoft Entra DS) and gain insights into how the service is performing.

+You can access Microsoft Entra DS metrics from two places:

+- In Azure Monitor Metrics, click **New chart** > **Select a scope** and select the Microsoft Entra DS instance:

+ :::image type="content" border="true" source="media/fleet-metrics/select.png" alt-text="Screenshot of how to select Microsoft Entra DS for fleet metrics.":::

+- In Microsoft Entra DS, under **Monitoring**, click **Metrics**:

+ :::image type="content" border="true" source="media/fleet-metrics/metrics-scope.png" alt-text="Screenshot of how to select Microsoft Entra DS as scope in Azure Monitor Metrics.":::

+ You can also view metrics for a fleet of Microsoft Entra DS instances:

+ :::image type="content" border="true" source="media/fleet-metrics/metrics-instance.png" alt-text="Screenshot of how to select a Microsoft Entra DS instance as the scope for fleet metrics.":::

+ :::image type="content" border="true" source="media/fleet-metrics/combined-metrics-instance.png" alt-text="Screenshot of combined metrics for a Microsoft Entra DS instance.":::

+The following table describes the metrics that are available for Microsoft Entra DS.

+You can configure metric alerts for Microsoft Entra DS to be notified of possible problems. Metric alerts are one type of alert for Azure Monitor. For more information about other types of alerts, see [What are Azure Monitor Alerts?](../azure-monitor/alerts/alerts-overview.md).

+In Azure Monitor or Microsoft Entra DS Metrics, click **New alert** and configure a Microsoft Entra DS instance as the scope. Then choose the metrics you want to measure from the list of available signals:

+- [Check the health of a Microsoft Entra Domain Services managed domain](check-health.md)

+ Title: Instructions for data retrieval from Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to retrieve data from Microsoft Entra Domain Services (Microsoft Entra DS).

+# Microsoft Entra DS instructions for data retrieval

+This document describes how to retrieve data from Microsoft Entra Domain Services (Microsoft Entra DS).

+<a name='use-azure-active-directory-to-create-read-update-and-delete-user-objects'></a>

+## Use Microsoft Entra ID to create, read, update, and delete user objects

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

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

+ 

+ - **Directory role**: If you require Microsoft Entra administrative permissions for the user, you can add them to a Microsoft Entra role.

+The user is created and added to your Microsoft Entra organization.

+1. Search for and select the user you want to delete from your Microsoft Entra tenant. For example, _Mary Parker_.

+<a name='use-rsat-tools-to-connect-to-an-azure-ad-ds-managed-domain-and-view-users'></a>

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

+1. To see the users and groups that belong to the managed domain, select the **AADDC Users** container. The user accounts and groups from your Microsoft Entra tenant are listed in this container.

+ 

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

+ Title: Join a CentOS VM to Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to configure and join a CentOS Linux virtual machine to a Microsoft Entra Domain Services managed domain.

+# Join a CentOS Linux virtual machine to a Microsoft Entra Domain Services managed domain

+To let users sign in to virtual machines (VMs) in Azure using a single set of credentials, you can join VMs to a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain. When you join a VM to a Microsoft Entra DS managed domain, user accounts and credentials from the domain can be used to sign in and manage servers. Group memberships from the managed domain are also applied to let you control access to files or services on the VM.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, the first tutorial [creates and configures a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+* Deploy the VM into the same, or a peered, virtual network in which you have enabled Microsoft Entra Domain Services.

+1. Now initialize Kerberos using the `kinit` command. Specify a user that's a part of the managed domain. If needed, [add a user account to a group in Microsoft Entra ID](../active-directory/fundamentals/active-directory-groups-members-azure-portal.md).

+ Title: Join a CoreOS VM to Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to configure and join a CoreOS virtual machine to a Microsoft Entra Domain Services managed domain.

+# Join a CoreOS virtual machine to a Microsoft Entra Domain Services managed domain

+To let users sign in to virtual machines (VMs) in Azure using a single set of credentials, you can join VMs to a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain. When you join a VM to a Microsoft Entra DS managed domain, user accounts and credentials from the domain can be used to sign in and manage servers. Group memberships from the managed domain are also applied to let you control access to files or services on the VM.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, the first tutorial [creates and configures a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+* Deploy the VM into the same, or a peered, virtual network in which you have enabled Microsoft Entra Domain Services.

+* Deploy the VM into a different subnet than your Microsoft Entra Domain Services managed domain.

+1. Now join the VM to the managed domain using the `adcli join` command. Specify a user that's a part of the managed domain. If needed, [add a user account to a group in Microsoft Entra ID](../active-directory/fundamentals/active-directory-groups-members-azure-portal.md).

+ Title: Join a RHEL VM to Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to configure and join a Red Hat Enterprise Linux virtual machine to a Microsoft Entra Domain Services managed domain.

+# Join a Red Hat Enterprise Linux virtual machine to a Microsoft Entra Domain Services managed domain

+To let users sign in to virtual machines (VMs) in Azure using a single set of credentials, you can join VMs to a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain. When you join a VM to a Microsoft Entra DS managed domain, user accounts and credentials from the domain can be used to sign in and manage servers. Group memberships from the managed domain are also applied to let you control access to files or services on the VM.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, the first tutorial [creates and configures a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+* Deploy the VM into the same, or a peered, virtual network in which you have enabled Microsoft Entra Domain Services.

+* Deploy the VM into a different subnet than your Microsoft Entra Domain Services managed domain.

+1. Now initialize Kerberos using the `kinit` command. Specify a user that's a part of the managed domain. If needed, [add a user account to a group in Microsoft Entra ID](../active-directory/fundamentals/active-directory-groups-members-azure-portal.md).

+ Title: Join a SLE VM to Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to configure and join a SUSE Linux Enterprise virtual machine to a Microsoft Entra Domain Services managed domain.

+# Join a SUSE Linux Enterprise virtual machine to a Microsoft Entra Domain Services managed domain

+To let users sign in to virtual machines (VMs) in Azure using a single set of credentials, you can join VMs to a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain. When you join a VM to a Microsoft Entra DS managed domain, user accounts and credentials from the domain can be used to sign in and manage servers. Group memberships from the managed domain are also applied to let you control access to files or services on the VM.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, the first tutorial [creates and configures a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+* Deploy the VM into the same, or a peered, virtual network in which you have enabled Microsoft Entra Domain Services.

+* Deploy the VM into a different subnet than your Microsoft Entra Domain Services managed domain.

+1. In the dialog, specify the *Username* and *Password* of a user that's a part of the managed domain. If needed, [add a user account to a group in Microsoft Entra ID](../active-directory/fundamentals/active-directory-groups-members-azure-portal.md).

+3. Check that the date and time in Microsoft Entra ID and Linux are in sync. You can do this by adding the Microsoft Entra server to the NTP service:

+ Title: Join an Ubuntu VM to Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to configure and join an Ubuntu Linux virtual machine to a Microsoft Entra Domain Services managed domain.

+# Join an Ubuntu Linux virtual machine to a Microsoft Entra Domain Services managed domain

+To let users sign in to virtual machines (VMs) in Azure using a single set of credentials, you can join VMs to a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain. When you join a VM to a Microsoft Entra DS managed domain, user accounts and credentials from the domain can be used to sign in and manage servers. Group memberships from the managed domain are also applied to let you control access to files or services on the VM.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, the first tutorial [creates and configures a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+* A user account that's a part of the managed domain. Make sure the SAMAccountName attribute for the user is not autogenerated. If multiple user accounts in the Microsoft Entra tenant have the same mailNickname attribute, the SAMAccountName attribute for each user is autogenerated. For more information, see [How objects and credentials are synchronized in a Microsoft Entra Domain Services managed domain](synchronization.md).

+* Deploy the VM into the same, or a peered, virtual network in which you have enabled Microsoft Entra Domain Services.

+* Deploy the VM into a different subnet than your Microsoft Entra Domain Services managed domain.

+1. Now initialize Kerberos using the `kinit` command. Specify a user that's a part of the managed domain. If needed, [add a user account to a group in Microsoft Entra ID](../active-directory/fundamentals/active-directory-groups-members-azure-portal.md).

+One of the packages installed in a previous step was for System Security Services Daemon (SSSD). When a user tries to sign in to a VM using domain credentials, SSSD relays the request to an authentication provider. In this scenario, SSSD uses Microsoft Entra DS to authenticate the request.

+ Title: Use a template to join a Windows VM to Microsoft Entra DS | Microsoft Docs

+description: Learn how to use Azure Resource Manager templates to join a new or existing Windows Server VM to a Microsoft Entra Domain Services managed domain.

+# Join a Windows Server virtual machine to a Microsoft Entra Domain Services managed domain using a Resource Manager template

+To automate the deployment and configuration of Azure virtual machines (VMs), you can use a Resource Manager template. These templates let you create consistent deployments each time. Extensions can also be included in templates to automatically configure a VM as part of the deployment. One useful extension joins VMs to a domain, which can be used with Microsoft Entra Domain Services (Microsoft Entra DS) managed domains.

+This article shows you how to create and join a Windows Server VM to a Microsoft Entra DS managed domain using Resource Manager templates. You also learn how to join an existing Windows Server VM to a Microsoft Entra DS domain.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, the first tutorial [creates and configures a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+* A user account that's a part of the *AAD DC Administrators* group.

+ | Subscription | Pick the same Azure subscription in which you have enabled Microsoft Entra Domain Services. |

+ | Optional OU Path | The custom OU in which to add the VM. If you don't specify a value for this parameter, the VM is added to the default *Microsoft Entra DC Computers* OU. |

+ | Subscription | Pick the same Azure subscription in which you have enabled Microsoft Entra Domain Services. |

+ | Optional OU Path | The custom OU in which to add the VM. If you don't specify a value for this parameter, the VM is added to the default *Microsoft Entra DC Computers* OU. |

+ Title: Join a Windows Server VM to a Microsoft Entra Domain Services managed domain | Microsoft Docs

+description: In this tutorial, learn how to join a Windows Server virtual machine to a Microsoft Entra Domain Services managed domain.

+#Customer intent: As an server administrator, I want to learn how to join a Windows Server VM to a Microsoft Entra Domain Services managed domain to provide centralized identity and policy.

+# Tutorial: Join a Windows Server virtual machine to a Microsoft Entra Domain Services managed domain

+Microsoft Entra Domain Services (Microsoft Entra DS) provides managed domain services such as domain join, group policy, LDAP, Kerberos/NTLM authentication that is fully compatible with Windows Server Active Directory. With a Microsoft Entra DS managed domain, you can provide domain join features and management to virtual machines (VMs) in Azure. This tutorial shows you how to create a Windows Server VM then join it to a managed domain.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+ * Make sure that Microsoft Entra Connect password hash synchronization or self-service password reset has been performed so the account is able to sign in to managed domain.

+* An Azure Bastion host deployed in your Microsoft Entra DS virtual network.

+1. Enter domain credentials to join the domain. Provide credentials for a user that's a part of the managed domain. The account must be part of the managed domain or Microsoft Entra tenant - accounts from external directories associated with your Microsoft Entra tenant can't correctly authenticate during the domain-join process.

+ * **UPN format** (recommended) - Enter the user principal name (UPN) suffix for the user account, as configured in Microsoft Entra ID. For example, the UPN suffix of the user *contosoadmin* would be `contosoadmin@aaddscontoso.onmicrosoft.com`. There are a couple of common use-cases where the UPN format can be used reliably to sign in to the domain rather than the *SAMAccountName* format:

+ * If multiple users have the same UPN prefix in your Microsoft Entra tenant, such as *dee*, their *SAMAccountName* format might be autogenerated.

+If you [delete the VM](#delete-the-vm) without unjoining from the domain, an orphaned computer object is left in Microsoft Entra DS.

+* Verify the VM is connected to the same virtual network that Microsoft Entra DS is enabled in, or has a peered network connection.

+* Confirm that the account is part of the managed domain or Microsoft Entra tenant. Accounts from external directories associated with your Microsoft Entra tenant can't correctly authenticate during the domain-join process.

+* Wait for password synchronization to be completed. When a user account's password is changed, an automatic background synchronization from Microsoft Entra ID updates the password in Microsoft Entra DS. It takes some time for the password to be available for domain-join use.

+ Title: Manage DNS for Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to install the DNS Server Tools to manage DNS and create conditional forwarders for a Microsoft Entra Domain Services managed domain.

+# Administer DNS and create conditional forwarders in a Microsoft Entra Domain Services managed domain

+Microsoft Entra DS includes a Domain Name System (DNS) server that provides name resolution for the managed domain. This DNS server includes built-in DNS records and updates for the key components that allow the service to run.

+As you run your own applications and services, you may need to create DNS records for machines that aren't joined to the domain, configure virtual IP addresses for load balancers, or set up external DNS forwarders. Users who belong to the *AAD DC Administrators* group are granted DNS administration privileges on the Microsoft Entra DS managed domain and can create and edit custom DNS records.

+This article shows you how to install the DNS Server tools then use the DNS console to manage records and create conditional forwarders in Microsoft Entra DS.

+>Creating or changing root hints or server-level DNS forwarders is not supported and will cause issues for the Microsoft Entra DS managed domain.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+* Connectivity from your Microsoft Entra DS virtual network to where your other DNS namespaces are hosted.

+* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

+> When you manage records using the DNS Server tools, make sure that you don't delete or modify the built-in DNS records that are used by Microsoft Entra DS. Built-in DNS records include domain DNS records, name server records, and other records used for DC location. If you modify these records, domain services are disrupted on the virtual network.

+A Microsoft Entra DS DNS zone should only contain the zone and records for the managed domain itself. Don't create additional zones in the managed domain to resolve named resources in other DNS namespaces. Instead, use conditional forwarders in the managed domain to tell the DNS server where to go in order to resolve addresses for those resources.

+[install-rsat]: /windows-server/remote/remote-server-administration-tools#BKMK_Thresh

+ Title: Create and manage group policy in Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to edit the built-in group policy objects (GPOs) and create your own custom policies in a Microsoft Entra Domain Services managed domain.

+# Administer Group Policy in a Microsoft Entra Domain Services managed domain

+Settings for user and computer objects in Microsoft Entra Domain Services (Microsoft Entra DS) are often managed using Group Policy Objects (GPOs). Microsoft Entra DS includes built-in GPOs for the *AADDC Users* and *AADDC Computers* containers. You can customize these built-in GPOs to configure Group Policy as needed for your environment. Members of the *Microsoft Entra DC administrators* group have Group Policy administration privileges in the Microsoft Entra DS domain, and can also create custom GPOs and organizational units (OUs). For more information on what Group Policy is and how it works, see [Group Policy overview][group-policy-overview].

+In a hybrid environment, group policies configured in an on-premises AD DS environment aren't synchronized to Microsoft Entra DS. To define configuration settings for users or computers in Microsoft Entra DS, edit one of the default GPOs or create a custom GPO.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+* A Windows Server management VM that is joined to the Microsoft Entra DS managed domain.

+* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

+To group similar policy settings, you often create additional GPOs instead of applying all of the required settings in the single, default GPO. With Microsoft Entra DS, you can create or import your own custom group policy objects and link them to a custom OU. If you need to first create a custom OU, see [create a custom OU in a managed domain](create-ou.md).

+ Title: Fix mismatched directory errors in Microsoft Entra Domain Services | Microsoft Docs

+description: Learn what a mismatched directory error means and how to resolve it in Microsoft Entra Domain Services

+# Resolve mismatched directory errors for existing Microsoft Entra Domain Services managed domains

+If a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain shows a mismatched tenant error, you can't administer the managed domain until resolved. This error occurs if the underlying Azure virtual network is moved to a different Microsoft Entra directory.

+A mismatched directory error happens when a Microsoft Entra DS managed domain and virtual network belong to two different Microsoft Entra tenants. For example, you may have a managed domain called *aaddscontoso.com* that runs in Contoso's Microsoft Entra tenant. However, the Azure virtual network for managed domain is part of the Fabrikam Microsoft Entra tenant.

+Azure role-based access control (Azure RBAC) is used to limit access to resources. When you enable Microsoft Entra DS in a Microsoft Entra tenant, credential hashes are synchronized to the managed domain. This operation requires you to be a tenant admin for the Microsoft Entra directory, and access to the credentials must be controlled.

+For Azure RBAC to work consistently and secure access to all the resources Microsoft Entra DS uses, the managed domain and the virtual network must belong to the same Microsoft Entra tenant.

+- A Microsoft Entra directory may have multiple Azure subscriptions.

+- A single managed domain is enabled for a Microsoft Entra directory.

+- A managed domain can be enabled on a virtual network belonging to any of the Azure subscriptions within the same Microsoft Entra tenant.

+In the following example deployment scenario, the Contoso managed domain is enabled in the Contoso Microsoft Entra tenant. The managed domain is deployed in a virtual network that belongs to an Azure subscription owned by the Contoso Microsoft Entra tenant.

+Both the managed domain and the virtual network belong to the same Microsoft Entra tenant. This example configuration is valid and fully supported.

+

+In this example deployment scenario, the Contoso managed domain is enabled in the Contoso Microsoft Entra tenant. However, the managed domain is deployed in a virtual network that belongs to an Azure subscription owned by the Fabrikam Microsoft Entra tenant.

+The managed domain and the virtual network belong to two different Microsoft Entra tenants. This example configuration is a mismatched tenant and isn't supported. The virtual network must be moved to the same Microsoft Entra tenant as the managed domain.

+* First, [delete the managed domain](delete-aadds.md) from your existing Microsoft Entra directory. Then, [create a replacement managed domain](tutorial-create-instance.md) in the same Microsoft Entra directory as the virtual network you wish to use. When ready, join all machines previously joined to the deleted domain to the recreated managed domain.

+* [Move the Azure subscription](../cost-management-billing/manage/billing-subscription-transfer.md) containing the virtual network to the same Microsoft Entra directory as the managed domain.

+For more information on troubleshooting issues with Microsoft Entra DS, see the [troubleshooting guide](troubleshoot.md).

+ Title: Network planning and connections for Microsoft Entra Domain Services | Microsoft Docs

+description: Learn about some of the virtual network design considerations and resources used for connectivity when you run Microsoft Entra Domain Services.

+# Virtual network design considerations and configuration options for Microsoft Entra Domain Services

+Microsoft Entra Domain Services (Microsoft Entra DS) provides authentication and management services to other applications and workloads. Network connectivity is a key component. Without correctly configured virtual network resources, applications and workloads can't communicate with and use the features provided by Microsoft Entra DS. Plan your virtual network requirements to make sure that Microsoft Entra DS can serve your applications and workloads as needed.

+This article outlines design considerations and requirements for an Azure virtual network to support Microsoft Entra DS.

+To provide network connectivity and allow applications and services to authenticate against a Microsoft Entra DS managed domain, you use an Azure virtual network and subnet. Ideally, the managed domain should be deployed into its own virtual network.

+You can include a separate application subnet in the same virtual network to host your management VM or light application workloads. A separate virtual network for larger or complex application workloads, peered to the Microsoft Entra DS virtual network, is usually the most appropriate design.

+As you design the virtual network for Microsoft Entra DS, the following considerations apply:

+* Microsoft Entra DS must be deployed into the same Azure region as your virtual network.

+ * At this time, you can only deploy one managed domain per Microsoft Entra tenant. The managed domain is deployed to single region. Make sure that you create or select a virtual network in a [region that supports Microsoft Entra DS](https://azure.microsoft.com/global-infrastructure/services/?products=active-directory-ds&regions=all).

+ * Microsoft Entra DS provides its own DNS service. The virtual network must be configured to use these DNS service addresses. Name resolution for additional namespaces can be accomplished using conditional forwarders.

+> You can't move Microsoft Entra DS to a different virtual network after you've enabled the service.

+A managed domain connects to a subnet in an Azure virtual network. Design this subnet for Microsoft Entra DS with the following considerations:

+<a name='connections-to-the-azure-ad-ds-virtual-network'></a>

+## Connections to the Microsoft Entra DS virtual network

+As noted in the previous section, you can only create a managed domain in a single virtual network in Azure, and only one managed domain can be created per Microsoft Entra tenant. Based on this architecture, you may need to connect one or more virtual networks that host your application workloads to your managed domain's virtual network.

+<a name='network-resources-used-by-azure-ad-ds'></a>

+## Network resources used by Microsoft Entra DS

+Don't lock the networking resources used by Microsoft Entra DS. If networking resources get locked, they can't be deleted. When domain controllers need to be rebuilt in that case, new networking resources with different IP addresses need to be created.

+| Network interface card | Microsoft Entra DS hosts the managed domain on two domain controllers (DCs) that run on Windows Server as Azure VMs. Each VM has a virtual network interface that connects to your virtual network subnet. |

+| Dynamic standard public IP address | Microsoft Entra DS communicates with the synchronization and management service using a Standard SKU public IP address. For more information about public IP addresses, see [IP address types and allocation methods in Azure](../virtual-network/ip-services/public-ip-addresses.md). |

+| Azure standard load balancer | Microsoft Entra DS uses a Standard SKU load balancer for network address translation (NAT) and load balancing (when used with secure LDAP). For more information about Azure load balancers, see [What is Azure Load Balancer?](../load-balancer/load-balancer-overview.md) |

+| Network address translation (NAT) rules | Microsoft Entra DS creates and uses two Inbound NAT rules on the load balancer for secure PowerShell remoting. If a Standard SKU load balancer is used, it will have an Outbound NAT Rule too. For the Basic SKU load balancer, no Outbound NAT rule is required. |

+> Don't delete or modify any of the network resource created by Microsoft Entra DS, such as manually configuring the load balancer or rules. If you delete or modify any of the network resources, a Microsoft Entra DS service outage may occur.

+Microsoft Entra DS also relies on the Default Security rules AllowVnetInBound and AllowAzureLoadBalancerInBound.

+The AllowAzureLoadBalancerInBound rule is also required so that the service can properly communicate over the loadbalancer to manage the DCs. This network security group secures Microsoft Entra DS and is required for the managed domain to work correctly. Don't delete this network security group. The load balancer won't work correctly without it.

+> When you associate a misconfigured network security group or a user defined route table with the subnet in which the managed domain is deployed, you may disrupt Microsoft's ability to service and manage the domain. Synchronization between your Microsoft Entra tenant and your managed domain is also disrupted. Follow all listed requirements to avoid an unsupported configuration that could break sync, patching, or management.

+| 443 | TCP | Any | AzureActiveDirectoryDomainServices| Allow | Yes | Communication with the Microsoft Entra Domain Services management service. |

+| 443 | TCP | Any | Microsoft Entra ID | Allow | Yes | Communication with Microsoft Entra ID. |

+User-defined routes aren't created by default, and aren't needed for Microsoft Entra DS to work correctly. If you're required to use route tables, avoid making any changes to the *0.0.0.0* route. Changes to this route disrupt Microsoft Entra DS and puts the managed domain in an unsupported state.

+For more information about some of the network resources and connection options used by Microsoft Entra DS, see the following articles:

+ Title: Email notifications for Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to configure email notifications to alert you about issues in a Microsoft Entra Domain Services managed domain

+# Configure email notifications for issues in Microsoft Entra Domain Services

+The health of a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain is monitored by the Azure platform. The health status page in the Microsoft Entra admin center shows any alerts for the managed domain. To make sure issues are responded to in a timely manner, email notifications can be configured to report on health alerts as soon as they're detected in the Microsoft Entra DS managed domain.

+Microsoft Entra DS sends email notifications for important updates about the managed domain. These notifications are only for urgent issues that impact the service and should be addressed immediately. Each email notification is triggered by an alert on the managed domain. The alerts also appear in the Microsoft Entra admin center and can be viewed on the [Microsoft Entra DS health page][check-health].

+Microsoft Entra DS doesn't send emails for advertisement, updates, or sales purposes.

+The list of email recipients for Microsoft Entra DS should be composed of people who are able to administer and make changes to the managed domain. This email list should be thought of as your "first responders" to any alerts and issues.

+You can also choose to have all *Global Administrators* of the Microsoft Entra directory and every member of the *AAD DC Administrators* group receive email notifications. Microsoft Entra DS only sends notification to up to 100 email addresses, including the list of global administrators and AAD DC Administrators.

+1. Search for and select **Microsoft Entra Domain Services**.

+1. On the left-hand side of the Microsoft Entra DS resource window, select **Notification settings**. The existing recipients for email notifications are shown.

+If you're unable to access the notification settings page in the Microsoft Entra admin center, you don't have the permissions to edit the managed domain. Contact a global administrator to either get permissions to edit Microsoft Entra DS resource or be removed from the recipient list.

+ Title: Overview of Microsoft Entra Domain Services | Microsoft Docs

+description: In this overview, learn what Microsoft Entra Domain Services provides and how to use it in your organization to provide identity services to applications and services in the cloud.

+#Customer intent: As an IT administrator or decision maker, I want to understand what Microsoft Entra DS is and how it can benefit my organization.

+# What is Microsoft Entra Domain Services?

+Microsoft Entra Domain Services (Microsoft Entra DS) provides managed domain services such as domain join, group policy, lightweight directory access protocol (LDAP), and Kerberos/NTLM authentication. You use these domain services without the need to deploy, manage, and patch domain controllers (DCs) in the cloud.

+A Microsoft Entra DS managed domain lets you run legacy applications in the cloud that can't use modern authentication methods, or where you don't want directory lookups to always go back to an on-premises AD DS environment. You can lift and shift those legacy applications from your on-premises environment into a managed domain, without needing to manage the AD DS environment in the cloud.

+Microsoft Entra DS integrates with your existing Microsoft Entra tenant. This integration lets users sign in to services and applications connected to the managed domain using their existing credentials. You can also use existing groups and user accounts to secure access to resources. These features provide a smoother lift-and-shift of on-premises resources to Azure.

+> [To get started, create a Microsoft Entra DS managed domain using the Microsoft Entra admin center][tutorial-create]

+Take a look at our short video to learn more about Microsoft Entra DS.

+<a name='how-does-azure-ad-ds-work'></a>

+## How does Microsoft Entra DS work?

+When you create a Microsoft Entra DS managed domain, you define a unique namespace. This namespace is the domain name, such as *aaddscontoso.com*. Two Windows Server domain controllers (DCs) are then deployed into your selected Azure region. This deployment of DCs is known as a replica set.

+A managed domain is configured to perform a one-way synchronization from Microsoft Entra ID to provide access to a central set of users, groups, and credentials. You can create resources directly in the managed domain, but they aren't synchronized back to Microsoft Entra ID. Applications, services, and VMs in Azure that connect to the managed domain can then use common AD DS features such as domain join, group policy, LDAP, and Kerberos/NTLM authentication.

+In a hybrid environment with an on-premises AD DS environment, [Microsoft Entra Connect][azure-ad-connect] synchronizes identity information with Microsoft Entra ID, which is then synchronized to the managed domain.

+

+Microsoft Entra DS replicates identity information from Microsoft Entra ID, so it works with Microsoft Entra tenants that are cloud-only, or synchronized with an on-premises AD DS environment. The same set of Microsoft Entra DS features exists for both environments.

+* For cloud-only environments, you don't need a traditional on-premises AD DS environment to use the centralized identity services of Microsoft Entra DS.

+You can expand a managed domain to have more than one replica set per Microsoft Entra tenant. Replica sets can be added to any peered virtual network in any Azure region that supports Microsoft Entra DS. Additional replica sets in different Azure regions provide geographical disaster recovery for legacy applications if an Azure region goes offline. For more information, see [Replica sets concepts and features for managed domains][concepts-replica-sets].

+Take a look at this video about how Microsoft Entra DS integrates with your applications and workloads to provide identity services in the cloud:

+To see Microsoft Entra DS deployment scenarios in action, you can explore the following examples:

+* [Microsoft Entra DS for hybrid organizations](scenarios.md#azure-ad-ds-for-hybrid-organizations)

+* [Microsoft Entra DS for cloud-only organizations](scenarios.md#azure-ad-ds-for-cloud-only-organizations)

+<a name='azure-ad-ds-features-and-benefits'></a>

+## Microsoft Entra DS features and benefits

+To provide identity services to applications and VMs in the cloud, Microsoft Entra DS is fully compatible with a traditional AD DS environment for operations such as domain-join, secure LDAP (LDAPS), Group Policy, DNS management, and LDAP bind and read support. LDAP write support is available for objects created in the managed domain, but not resources synchronized from Microsoft Entra ID.

+To learn more about your identity options, [compare Microsoft Entra DS with Microsoft Entra ID, AD DS on Azure VMs, and AD DS on-premises][compare].

+The following features of Microsoft Entra DS simplify deployment and management operations:

+* **Simplified deployment experience:** Microsoft Entra DS is enabled for your Microsoft Entra tenant using a single wizard in the Microsoft Entra admin center.

+* **Integrated with Microsoft Entra ID:** User accounts, group memberships, and credentials are automatically available from your Microsoft Entra tenant. New users, groups, or changes to attributes from your Microsoft Entra tenant or your on-premises AD DS environment are automatically synchronized to Microsoft Entra DS.

+ * Accounts in external directories linked to your Microsoft Entra ID aren't available in Microsoft Entra DS. Credentials aren't available for those external directories, so can't be synchronized into a managed domain.

+* **Use your corporate credentials/passwords:** Passwords for users in Microsoft Entra DS are the same as in your Microsoft Entra tenant. Users can use their corporate credentials to domain-join machines, sign in interactively or over remote desktop, and authenticate against the managed domain.

+* **High availability:** Microsoft Entra DS includes multiple domain controllers, which provide high availability for your managed domain. This high availability guarantees service uptime and resilience to failures.

+ * If needed, you can create one-way outbound forest trusts from Microsoft Entra DS to an on-premises AD DS environment. For more information, see [Forest concepts and features for Microsoft Entra DS][forest-trusts].

+For hybrid environments that run AD DS on-premises, you don't need to manage AD replication to the managed domain. User accounts, group memberships, and credentials from your on-premises directory are synchronized to Microsoft Entra ID via [Microsoft Entra Connect][azure-ad-connect]. These user accounts, group memberships, and credentials are automatically available within the managed domain.

+To learn more about Microsoft Entra DS compares with other identity solutions and how synchronization works, see the following articles:

+* [Compare Microsoft Entra DS with Microsoft Entra ID, Active Directory Domain Services on Azure VMs, and Active Directory Domain Services on-premises][compare]

+* [Learn how Microsoft Entra Domain Services synchronizes with your Microsoft Entra directory][synchronization]

+* To learn how to administrator a managed domain, see [management concepts for user accounts, passwords, and administration in Microsoft Entra DS][administration-concepts].

+ Title: Create and use password policies in Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how and why to use fine-grained password policies to secure and control account passwords in a Microsoft Entra DS managed domain.

+# Password and account lockout policies on Microsoft Entra Domain Services managed domains

+To manage user security in Microsoft Entra Domain Services (Microsoft Entra DS), you can define fine-grained password policies that control account lockout settings or minimum password length and complexity. A default fine grained password policy is created and applied to all users in a Microsoft Entra DS managed domain. To provide granular control and meet specific business or compliance needs, additional policies can be created and applied to specific users or groups.

+This article shows you how to create and configure a fine-grained password policy in Microsoft Entra DS using the Active Directory Administrative Center.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

+Password policies behave a little differently depending on how the user account they're applied to was created. There are two ways a user account can be created in Microsoft Entra DS:

+* The user account can be synchronized in from Microsoft Entra ID. This includes cloud-only user accounts created directly in Azure, and hybrid user accounts synchronized from an on-premises AD DS environment using Microsoft Entra Connect.

+ * The majority of user accounts in Microsoft Entra DS are created through the synchronization process from Microsoft Entra ID.

+* The user account can be manually created in a managed domain, and doesn't exist in Microsoft Entra ID.

+All users, regardless of how they're created, have the following account lockout policies applied by the default password policy in Microsoft Entra DS:

+Account lockouts only occur within the managed domain. User accounts are only locked out in Microsoft Entra DS, and only due to failed sign-in attempts against the managed domain. User accounts that were synchronized in from Microsoft Entra ID or on-premises aren't locked out in their source directories, only in Microsoft Entra DS.

+If you have a Microsoft Entra password policy that specifies a maximum password age greater than 90 days, that password age is applied to the default policy in Microsoft Entra DS. You can configure a custom password policy to define a different maximum password age in Microsoft Entra DS. Take care if you have a shorter maximum password age configured in a Microsoft Entra DS password policy than in Microsoft Entra ID or an on-premises AD DS environment. In that scenario, a user's password may expire in Microsoft Entra DS before they're prompted to change in Microsoft Entra ID or an on-premises AD DS environment.

+For user accounts created manually in a managed domain, the following additional password settings are also applied from the default policy. These settings don't apply to user accounts synchronized in from Microsoft Entra ID, as a user can't update their password directly in Microsoft Entra DS.

+1. Edit other password policy settings as desired. Account lockout settings apply to all users, but only take effect within the managed domain and not in Microsoft Entra itself.

+[tutorial-create-management-vm]: tutorial-create-management-vm.md

+ Title: Built-in policy definitions for Microsoft Entra Domain Services

+description: Lists Azure Policy built-in policy definitions for Microsoft Entra Domain Services. These built-in policy definitions provide common approaches to managing your Azure resources.

+# Azure Policy built-in definitions for Microsoft Entra Domain Services

+definitions for Microsoft Entra Domain Services. For additional Azure Policy built-ins for

+<a name='azure-active-directory-domain-services'></a>

+## Microsoft Entra Domain Services

+description: Learn how to configure and enable Microsoft Entra Domain Services using Azure AD PowerShell and Azure PowerShell.

+# Enable Microsoft Entra Domain Services using PowerShell

+Microsoft Entra Domain Services (Microsoft Entra DS) provides managed domain services such as domain join, group policy, LDAP, Kerberos/NTLM authentication that is fully compatible with Windows Server Active Directory. You consume these domain services without deploying, managing, and patching domain controllers yourself. Microsoft Entra DS integrates with your existing Microsoft Entra tenant. This integration lets users sign in using their corporate credentials, and you can use existing groups and user accounts to secure access to resources.

+This article shows you how to enable Microsoft Entra DS using PowerShell.

+ * If needed, follow the instructions to [install the Azure AD PowerShell module and connect to Microsoft Entra ID](/powershell/azure/active-directory/install-adv2).

+ * Make sure that you sign in to your Microsoft Entra tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet.

+* You need *global administrator* privileges in your Microsoft Entra tenant to enable Microsoft Entra DS.

+* You need *Contributor* privileges in your Azure subscription to create the required Microsoft Entra DS resources.

+<a name='create-required-azure-ad-resources'></a>

+## Create required Microsoft Entra resources

+Microsoft Entra DS requires a service principal to authenticate and communicate and a Microsoft Entra group to define which users have administrative permissions in the managed domain.

+First, create a Microsoft Entra service principal by using a specific application ID named *Domain Controller Services*. The ID value is *2565bd9d-da50-47d4-8b85-4c97f669dc36* for global Azure and *6ba9a5d4-8456-4118-b521-9c5ca10cdf84* for other Azure clouds. Don't change this application ID.

+Create a Microsoft Entra service principal using the [New-AzureADServicePrincipal][New-AzureADServicePrincipal] cmdlet:

+Now create a Microsoft Entra group named *AAD DC Administrators*. Users added to this group are then granted permissions to perform administration tasks on the managed domain.

+First, register the Microsoft Entra Domain Services resource provider using the [Register-AzResourceProvider][Register-AzResourceProvider] cmdlet:

+Create the virtual network and subnets for Microsoft Entra Domain Services. Two subnets are created - one for *DomainServices*, and one for *Workloads*. Microsoft Entra DS is deployed into the dedicated *DomainServices* subnet. Don't deploy other applications or workloads into this subnet. Use the separate *Workloads* or other subnets for the rest of your VMs.

+Microsoft Entra DS needs a network security group to secure the ports needed for the managed domain and block all other incoming traffic. A [network security group (NSG)][nsg-overview] contains a list of rules that allow or deny network traffic to traffic in an Azure virtual network. In Microsoft Entra DS, the network security group acts as an extra layer of protection to lock down access to the managed domain. To view the ports required, see [Network security groups and required ports][network-ports].

+If you choose a region that supports Availability Zones, the Microsoft Entra DS resources are distributed across zones for redundancy.

+There's nothing for you to configure for Microsoft Entra DS to be distributed across zones. The Azure platform automatically handles the zone distribution of resources. For more information and to see region availability, see [What are Availability Zones in Azure?][availability-zones].

+* [Enable password synchronization to Microsoft Entra DS](tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds) so end users can sign in to the managed domain using their corporate credentials.

+> To enable Microsoft Entra DS, you must be a global administrator for the Microsoft Entra tenant. You also need at least *Contributor* privileges in the Azure subscription.

+* [Enable password synchronization to Microsoft Entra DS](tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds) so end users can sign in to the managed domain using their corporate credentials.

+ Title: Scoped synchronization using PowerShell for Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to use Azure AD PowerShell to configure scoped synchronization from Microsoft Entra ID to a Microsoft Entra Domain Services managed domain

+# Configure scoped synchronization from Microsoft Entra ID to Microsoft Entra Domain Services using Azure AD PowerShell

+To provide authentication services, Microsoft Entra Domain Services (Microsoft Entra DS) synchronizes users and groups from Microsoft Entra ID. In a hybrid environment, users and groups from an on-premises Active Directory Domain Services (AD DS) environment can be first synchronized to Microsoft Entra ID using Microsoft Entra Connect, and then synchronized to Microsoft Entra DS.

+By default, all users and groups from a Microsoft Entra directory are synchronized to a Microsoft Entra DS managed domain. If you have specific needs, you can instead choose to synchronize only a defined set of users.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][tutorial-create-instance].

+* You need [Application Administrator](../active-directory/roles/permissions-reference.md#application-administrator) and [Groups Administrator](../active-directory/roles/permissions-reference.md#groups-administrator) Microsoft Entra roles in your tenant to change the Microsoft Entra DS synchronization scope.

+By default, all users and groups from a Microsoft Entra directory are synchronized to a managed domain. If only a few users need to access the managed domain, you can synchronize only those user accounts. This scoped synchronization is group-based. When you configure group-based scoped synchronization, only the user accounts that belong to the groups you specify are synchronized to the managed domain. Nested groups aren't synchronized, only the specific groups you select.

+To learn more about the synchronization process, see [Understand synchronization in Microsoft Entra Domain Services][concepts-sync].

+This script configures Microsoft Entra DS to synchronize selected groups from Microsoft Entra ID. All user accounts that are part of the specified groups are synchronized to the managed domain.

+1. First set *"filteredSync" = "Enabled"* on the Microsoft Entra DS resource, then update the managed domain.

+ When prompted, specify the credentials for a *global admin* to sign in to your Microsoft Entra tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet:

+When prompted, specify the credentials for a *global admin* to sign in to your Microsoft Entra tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet:

+To disable group-based scoped synchronization for a managed domain, set *"filteredSync" = "Disabled"* on the Microsoft Entra DS resource, then update the managed domain. When complete, all users and groups are set to synchronize from Microsoft Entra ID.

+When prompted, specify the credentials for a *global admin* to sign in to your Microsoft Entra tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet:

+To learn more about the synchronization process, see [Understand synchronization in Microsoft Entra Domain Services](synchronization.md).

+ Title: Common deployment scenarios for Microsoft Entra Domain Services | Microsoft Docs

+description: Learn about some of the common scenarios and use-cases for Microsoft Entra Domain Services to provide value and meet business needs.

+# Common use-cases and scenarios for Microsoft Entra Domain Services

+Microsoft Entra Domain Services provides managed domain services such as domain join, group policy, lightweight directory access protocol (LDAP), and Kerberos / NTLM authentication. Microsoft Entra Domain Services integrates with your existing Microsoft Entra tenant, which makes it possible for users to sign in using their existing credentials. You use these domain services without the need to deploy, manage, and patch domain controllers in the cloud, which provides a smoother lift-and-shift of on-premises resources to Azure.

+This article outlines some common business scenarios where Microsoft Entra Domain Services provides value and meets those needs.

+Microsoft Entra Domain Services offers alternatives to the need to create VPN connections back to an on-premises AD DS environment or run and manage VMs in Azure to provide identity services. As a managed service, Microsoft Entra Domain Services reduces the complexity to create an integrated identity solution for both hybrid and cloud-only environments.

+> [Compare Microsoft Entra Domain Services with Microsoft Entra ID and self-managed AD DS on Azure VMs or on-premises][compare]

+<a name='azure-ad-ds-for-hybrid-organizations'></a>

+<a name='microsoft-entra-ds-for-hybrid-organizations'></a>

+## Microsoft Entra Domain Services for hybrid organizations

+Many organizations run a hybrid infrastructure that includes both cloud and on-premises application workloads. Legacy applications migrated to Azure as part of a lift and shift strategy may use traditional LDAP connections to provide identity information. To support this hybrid infrastructure, identity information from an on-premises AD DS environment can be synchronized to a Microsoft Entra tenant. Microsoft Entra Domain Services then provides these legacy applications in Azure with an identity source, without the need to configure and manage application connectivity back to on-premises directory services.

+

+* To synchronize identity information from their on-premises directory to their Microsoft Entra tenant, Litware Corporation deploys [Microsoft Entra Connect][azure-ad-connect].

+* Litware's IT team enables Microsoft Entra Domain Services for their Microsoft Entra tenant in this, or a peered, virtual network.

+* Applications and VMs deployed in the Azure virtual network can then use Microsoft Entra Domain Services features like domain join, LDAP read, LDAP bind, NTLM and Kerberos authentication, and Group Policy.

+> Microsoft Entra Connect should only be installed and configured for synchronization with on-premises AD DS environments. It's not supported to install Microsoft Entra Connect in a managed domain to synchronize objects back to Microsoft Entra ID.

+<a name='azure-ad-ds-for-cloud-only-organizations'></a>

+<a name='microsoft-entra-ds-for-cloud-only-organizations'></a>

+## Microsoft Entra Domain Services for cloud-only organizations

+A cloud-only Microsoft Entra tenant doesn't have an on-premises identity source. User accounts and group memberships, for example, are created and managed directly in Microsoft Entra ID.

+Now let's look at an example for Contoso, a cloud-only organization that uses Microsoft Entra ID for identity. All user identities, their credentials, and group memberships are created and managed in Microsoft Entra ID. There is no additional configuration of Microsoft Entra Connect to synchronize any identity information from an on-premises directory.

+

+* Contoso's IT team enables Microsoft Entra Domain Services for their Microsoft Entra tenant in this, or a peered, virtual network.

+* Applications and VMs deployed in the Azure virtual network can then use Microsoft Entra Domain Services features like domain join, LDAP read, LDAP bind, NTLM and Kerberos authentication, and Group Policy.

+To let you use a single set of AD credentials, Azure virtual machines (VMs) can be joined to a Microsoft Entra Domain Services managed domain. This approach reduces credential management issues such as maintaining local administrator accounts on each VM or separate accounts and passwords between environments.

+Microsoft Entra Domain Services is a great fit for this use-case. A managed domain lets you domain-join VMs, use a single set of credentials, and apply group policy. And because it's a managed domain, you don't have to configure and maintain the domain controllers yourself.

+* Microsoft Entra Domain Services uses a built-in GPO each for the users and computers containers. For additional control, you can [create custom GPOs][create-gpo] and target them to custom OUs.

+* Microsoft Entra Domain Services supports the base AD computer object schema. You can't extend the computer object's schema.

+For this scenario, Microsoft Entra Domain Services lets applications perform LDAP binds as part of the authentication process. Legacy on-premises applications can lift-and-shift into Azure and continue to seamlessly authenticate users without any change in configuration or user experience.

+* You can't change passwords directly against a managed domain. End users can change their password either using the [Microsoft Entra self-service password change mechanism][sspr] or against the on-premises directory. These changes are then automatically synchronized and available in the managed domain.

+To help with this scenario, Microsoft Entra Domain Services lets applications perform LDAP reads against the managed domain to get the attribute information it needs. The application doesn't need to be rewritten, so a lift-and-shift into Azure lets users continue to use the app without realizing there's a change in where it runs.

+* Make sure that the application doesn't need a custom/extended Active Directory schema. Schema extensions aren't supported in Microsoft Entra Domain Services.

+Some applications include multiple tiers, where one of the tiers needs to perform authenticated calls to a backend tier, such as a database. AD service accounts are commonly used in these scenarios. When you lift-and-shift applications into Azure, Microsoft Entra Domain Services lets you continue to use service accounts in the same way. You can choose to use the same service account that is synchronized from your on-premises directory to Microsoft Entra ID or create a custom OU and then create a separate service account in that OU. With either approach, applications continue to function the same way to make authenticated calls to other tiers and services.

+For this scenario, the servers hosting the web front end, SQL server, and the FTP server can be migrated to Azure VMs and joined to a managed domain. The VMs can then use the same service account in their on-premises directory for the app's authentication purposes, which is synchronized through Microsoft Entra ID using Microsoft Entra Connect.

+* Make sure that the applications use a username and password for authentication. Certificate or smartcard-based authentication isn't supported by Microsoft Entra Domain Services.

+* You can't change passwords directly against a managed domain. End users can change their password either using the [Microsoft Entra self-service password change mechanism][sspr] or against the on-premises directory. These changes are then automatically synchronized and available in the managed domain.

+You can use Microsoft Entra Domain Services to provide managed domain services to remote desktop servers deployed in Azure.

+For more information about this deployment scenario, see [how to integrate Microsoft Entra Domain Services with your RDS deployment][windows-rds].

+To get started, [Create and configure a Microsoft Entra Domain Services managed domain][tutorial-create-instance].

+[windows-rds]: /windows-server/remote/remote-desktop-services/rds-azure-adds

+ Title: Scoped synchronization for Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to use the Microsoft Entra admin center to configure scoped synchronization from Microsoft Entra ID to a Microsoft Entra Domain Services managed domain

+# Configure scoped synchronization from Microsoft Entra ID to Microsoft Entra Domain Services using the Microsoft Entra admin center

+To provide authentication services, Microsoft Entra Domain Services (Microsoft Entra DS) synchronizes users and groups from Microsoft Entra ID. In a hybrid environment, users and groups from an on-premises Active Directory Domain Services (AD DS) environment can be first synchronized to Microsoft Entra ID using Microsoft Entra Connect, and then synchronized to a Microsoft Entra DS managed domain.

+By default, all users and groups from a Microsoft Entra directory are synchronized to a managed domain. If only some users need to use Microsoft Entra DS, you can instead choose to synchronize only groups of users. You can filter synchronization for groups on-premises, cloud only, or both.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, complete the tutorial to [create and configure a Microsoft Entra Domain Services managed domain][tutorial-create-instance].

+* You need [Application Administrator](../active-directory/roles/permissions-reference.md#application-administrator) and [Groups Administrator](../active-directory/roles/permissions-reference.md#groups-administrator) Microsoft Entra roles in your tenant to change the Microsoft Entra DS synchronization scope.

+By default, all users and groups from a Microsoft Entra directory are synchronized to a managed domain. You can scope synchronization to only user accounts that were created in Microsoft Entra ID, or synchronize all users.

+To learn more about the synchronization process, see [Understand synchronization in Microsoft Entra Domain Services][concepts-sync].

+1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Microsoft Entra Domain Services**. Choose your managed domain, such as *aaddscontoso.com*.

+1. To filter synchronization for selected groups, click **Show selected groups**, choose whether to synchronize cloud-only groups, on-premises groups, or both. For example, the following screenshot shows how to synchronize only three groups that were created in Microsoft Entra ID. Only users who belong to those groups will have their accounts synchronized to Microsoft Entra DS.

+1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Microsoft Entra Domain Services**. Choose your managed domain, such as *aaddscontoso.com*.

+1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Microsoft Entra Domain Services**. Choose your managed domain, such as *aaddscontoso.com*.

+To learn more about the synchronization process, see [Understand synchronization in Microsoft Entra Domain Services][concepts-sync].

+ Title: Secure remote VM access in Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to secure remote access to VMs using Network Policy Server (NPS) and Microsoft Entra multifactor authentication with a Remote Desktop Services deployment in a Microsoft Entra Domain Services managed domain.

+# Secure remote access to virtual machines in Microsoft Entra Domain Services

+To secure remote access to virtual machines (VMs) that run in a Microsoft Entra Domain Services (Microsoft Entra DS) managed domain, you can use Remote Desktop Services (RDS) and Network Policy Server (NPS). Microsoft Entra DS authenticates users as they request access through the RDS environment. For enhanced security, you can integrate Microsoft Entra multifactor authentication to provide an additional authentication prompt during sign-in events. Microsoft Entra multifactor authentication uses an extension for NPS to provide this feature.

+> The recommended way to securely connect to your VMs in a Microsoft Entra DS managed domain is using Azure Bastion, a fully platform-managed PaaS service that you provision inside your virtual network. A bastion host provides secure and seamless Remote Desktop Protocol (RDP) connectivity to your VMs directly in the Azure portal over SSL. When you connect via a bastion host, your VMs don't need a public IP address, and you don't need to use network security groups to expose access to RDP on TCP port 3389.

+> We strongly recommend that you use Azure Bastion in all regions where it's supported. In regions without Azure Bastion availability, follow the steps detailed in this article until Azure Bastion is available. Take care with assigning public IP addresses to VMs joined to Microsoft Entra DS where all incoming RDP traffic is allowed.

+This article shows you how to configure RDS in Microsoft Entra DS and optionally use the Microsoft Entra multifactor authentication NPS extension.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+* A *workloads* subnet created in your Microsoft Entra Domain Services virtual network.

+ * If needed, [Configure virtual networking for a Microsoft Entra Domain Services managed domain][configure-azureadds-vnet].

+* A user account that's a member of the *Microsoft Entra DC administrators* group in your Microsoft Entra tenant.

+Make sure that VMs are deployed into a *workloads* subnet of your Microsoft Entra DS virtual network, then join the VMs to managed domain. For more information, see how to [create and join a Windows Server VM to a managed domain][tutorial-create-join-vm].

+1. Sign in to VMs created for the RD environment with an account that's part of the *Microsoft Entra DC Administrators* group, such as *contosoadmin*.

+ * Specific to Microsoft Entra DS - when you configure RD licensing, set it to **Per Device** mode, not **Per User** as noted in the deployment guide.

+<a name='deploy-and-configure-nps-and-the-azure-ad-mfa-nps-extension'></a>

+## Deploy and configure NPS and the Microsoft Entra multifactor authentication NPS extension

+If you want to increase the security of the user sign-in experience, you can optionally integrate the RD environment with Microsoft Entra multifactor authentication. With this configuration, users receive an additional prompt during sign-in to confirm their identity.

+To provide this capability, an additional Network Policy Server (NPS) is installed in your environment along with the Microsoft Entra multifactor authentication NPS extension. This extension integrates with Microsoft Entra ID to request and return the status of multifactor authentication prompts.

+Users must be [registered to use Microsoft Entra multifactor authentication][user-mfa-registration], which may require additional Microsoft Entra ID licenses.

+To integrate Microsoft Entra multifactor authentication in to your Microsoft Entra DS Remote Desktop environment, create an NPS Server and install the extension:

+1. Create an additional Windows Server 2016 or 2019 VM, such as *NPSVM01*, that's connected to a *workloads* subnet in your Microsoft Entra DS virtual network. Join the VM to the managed domain.

+1. Sign in to NPS VM as account that's part of the *Microsoft Entra DC Administrators* group, such as *contosoadmin*.

+1. Use the existing how-to article to [install and configure the Microsoft Entra multifactor authentication NPS extension][nps-extension].

+With the NPS server and Microsoft Entra multifactor authentication NPS extension installed, complete the next section to configure it for use with the RD environment.

+<a name='integrate-remote-desktop-gateway-and-azure-ad-multi-factor-authentication'></a>

+## Integrate Remote Desktop Gateway and Microsoft Entra multifactor authentication

+To integrate the Microsoft Entra multifactor authentication NPS extension, use the existing how-to article to [integrate your Remote Desktop Gateway infrastructure using the Network Policy Server (NPS) extension and Microsoft Entra ID][azure-mfa-nps-integration].

+1. If you use Windows Server 2019 for the NPS server and Microsoft Entra multifactor authentication NPS extension, run the following command to update the secure channel to allow the NPS server to communicate correctly:

+For more information about securing user sign-in, see [How it works: Microsoft Entra multifactor authentication][concepts-mfa].

+[rds-high-availability]: /windows-server/remote/remote-desktop-services/rds-plan-high-availability

+ Title: Secure Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to disable weak ciphers, old protocols, and NTLM password hash synchronization for a Microsoft Entra Domain Services managed domain.

+# Harden a Microsoft Entra Domain Services managed domain

+By default, Microsoft Entra Domain Services (Microsoft Entra DS) enables the use of ciphers such as NTLM v1 and TLS v1. These ciphers may be required for some legacy applications, but are considered weak and can be disabled if you don't need them. If you have on-premises hybrid connectivity using Microsoft Entra Connect, you can also disable the synchronization of NTLM password hashes.

+* A Microsoft Entra tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

+ * If needed, [create a Microsoft Entra tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

+* A Microsoft Entra Domain Services managed domain enabled and configured in your Microsoft Entra tenant.

+ * If needed, [create and configure a Microsoft Entra Domain Services managed domain][create-azure-ad-ds-instance].

+1. Search for and select **Microsoft Entra Domain Services**.

+- If the assignment is **Audit**, the compliance will report if the Microsoft Entra DS instance is compliant.

+- If the assignment is **Deny**, the compliance will prevent a Microsoft Entra DS instance from being created if TLS 1.2 is not required and prevent any update to a Microsoft Entra DS instance until TLS 1.2 is required.

+While disabling NTLM password synchronization will improve security, many applications and services are not designed to work without it. For example, connecting to any resource by its IP address, such as DNS Server management or RDP, will fail with Access Denied. If you disable NTLM password synchronization and your application or service isnΓÇÖt working as expected, you can check for NTLM authentication failures by enabling security auditing for the **Logon/Logoff** > **Audit Logon** event category, where NTLM is specified as the **Authentication Package** in the event details. For more information, see [Enable security audits for Microsoft Entra Domain Services](security-audit-events.md).

+Also if needed, [install and configure Azure AD PowerShell](/powershell/azure/active-directory/install-adv2). Make sure that you sign in to your Microsoft Entra tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet.

+To disable weak cipher suites and NTLM credential hash synchronization, sign in to your Azure account, then get the Microsoft Entra DS resource using the [Get-AzResource][Get-AzResource] cmdlet:

+> Users and service accounts can't perform LDAP simple binds if you disable NTLM password hash synchronization in the Microsoft Entra DS managed domain. If you need to perform LDAP simple binds, don't set the *"SyncNtlmPasswords"="Disabled";* security configuration option in the following command.

+Finally, apply the defined security settings to the managed domain using the [Set-AzResource][Set-AzResource] cmdlet. Specify the Microsoft Entra DS resource from the first step, and the security settings from the previous step.

+> After you disable NTLM, perform a full password hash synchronization in Microsoft Entra Connect to remove all the password hashes from the managed domain. If you disable NTLM but don't force a password hash sync, NTLM password hashes for a user account are only removed on the next password change. This behavior could allow a user to continue to sign in if they have cached credentials on a system where NTLM is used as the authentication method.

+ Title: Enable security and DNS audits for Microsoft Entra Domain Services | Microsoft Docs

+description: Learn how to enable security audits to centralize the logging of events for analysis and alerts in Microsoft Entra Domain Services

+# Enable security and DNS audits for Microsoft Entra Domain Services

+Microsoft Entra Domain Services (Microsoft Entra DS) security and DNS audits let Azure stream events to targeted resources. These resources include Azure Storage, Azure Log Analytics workspaces, or Azure Event Hub. After you enable security audit events, Microsoft Entra DS sends all the audited events for the selected category to the targeted resource.

+You can use Azure Storage, Azure Event Hubs, or Azure Log Analytics workspaces as a target resource for Microsoft Entra DS security audits. These destinations can be combined. For example, you could use Azure Storage for archiving security audit events, but an Azure Log Analytics workspace to analyze and report on the information in the short term.

+> You need to create the target resource before you enable Microsoft Entra DS security audits. You can create these resources using the Microsoft Entra admin center, Azure PowerShell, or the Azure CLI.

+|Azure Storage| This target should be used when your primary need is to store security audit events for archival purposes. Other targets can be used for archival purposes, however those targets provide capabilities beyond the primary need of archiving. <br /><br />Before you enable Microsoft Entra DS security audit events, first [Create an Azure Storage account](../storage/common/storage-account-create.md).|

+|Azure Event Hubs| This target should be used when your primary need is to share security audit events with additional software such as data analysis software or security information & event management (SIEM) software.<br /><br />Before you enable Microsoft Entra DS security audit events, [Create an event hub using Microsoft Entra admin center](../event-hubs/event-hubs-create.md)|

+|Azure Log Analytics Workspace| This target should be used when your primary need is to analyze and review secure audits from the Microsoft Entra admin center directly.<br /><br />Before you enable Microsoft Entra DS security audit events, [Create a Log Analytics workspace in the Microsoft Entra admin center.](../azure-monitor/logs/quick-create-workspace.md)|

+To enable Microsoft Entra DS security audit events using the Microsoft Entra admin center, complete the following steps.

+> Microsoft Entra DS security audits aren't retroactive. You can't retrieve or replay events from the past. Microsoft Entra DS can only send events that occur af