-description: Custom policy reference for Azure AD SSPR technical profiles in Azure AD B2C.

-# Define an Azure AD 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 Azure AD SSPR technical profile to generate and send a code to an email address, and then verify the code. The Azure AD 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.

-The following example shows an Azure AD SSPR technical profile:

-The **InputClaims** element contains a list of claims to send to Azure AD 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 Azure AD SSPR service.

-The Azure AD 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 Azure AD SSPR protocol provider as long as you set the `DefaultValue` attribute.

-The following example shows an Azure AD SSPR technical profile that is used to send a code via email.

-The **InputClaims** element contains a list of claims to send to Azure AD 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 Azure AD SSPR service.

-The Azure AD 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 Azure AD SSPR protocol provider as long as you set the `DefaultValue` attribute.

-The following example shows an Azure AD 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 Azure AD, it does not work for applications registered in Azure AD B2C, regardless of the tenant (Azure AD or Azure AD B2C) that is issuing the tokens.

-description: Define an Azure Active Directory technical profile in a custom policy in Azure Active Directory B2C.

-# Define an Azure Active Directory technical profile in an Azure Active Directory B2C custom policy

-Azure Active Directory B2C (Azure AD B2C) provides support for the Azure Active Directory 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) Azure AD technical profiles include the **AAD-Common** technical profile. The Azure AD 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 Azure AD technical profiles. You may need to map the name of the claim defined in your policy to the name defined in Azure Active Directory.

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

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

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

-The name of the claim is the name of the Azure AD attribute unless the **PartnerClaimType** attribute is specified, which contains the Azure AD attribute name.

-## Azure AD technical profile operations

-See the following article, for example of using Azure AD technical profile:

-When the web API receives an HTTP request from Azure AD during a user flow, it can return a "continuation response."

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

-1. On the **Portal settings | Directories + subscriptions** page, find your Azure AD 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, & Azure AD). 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 Azure AD during a user flow, it can return these responses:

-When the web API receives an HTTP request from Azure AD during a user flow, it can return these responses:

-When the web API receives an HTTP request from Azure AD during a user flow, it can return these responses:

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

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

-* [Azure AD (Single-tenant)](identity-provider-azure-ad-single-tenant.md)

-* [Azure AD (Multi-tenant)](identity-provider-azure-ad-multi-tenant.md)

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

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

-1. Make sure you're using the directory that has your Azure AD 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 Azure AD directory that has your subscription in the **Directory name** list, and then select **Switch**

-1. Open the **Application Insights** resource in your Azure Active Directory tenant.

-description: Use Azure Active Directory (Azure AD) 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, & Azure AD). 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:

-The new experience shows all Azure AD B2C app registrations and Azure AD 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 **Azure Active Directory** 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 Azure AD 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 Azure AD service.

-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 Azure AD. Certificates can't be used to authenticate against Azure AD B2C.

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

-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 Azure AD. 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 Azure AD 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 Azure AD 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 Azure AD 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 [Azure AD 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), [Azure Active Directory](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, Azure AD 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 Azure AD 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 Azure AD supports is Bearer. |

-| scope |Recommended |A space-separated list of scopes. A single scope value indicates to Azure AD 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 Azure AD supports is Bearer. |

-Azure AD B2C uses [Azure Active Directory monitoring](../active-directory/reports-monitoring/overview-monitoring-health.md). Unlike Azure AD 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 Azure Active Directory 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 an Azure AD (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 Azure AD 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 Azure AD and Azure AD B2C tenants.

-During this deployment, you'll configure your Azure AD B2C tenant where logs are generated. You'll also configure Azure AD 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 Azure AD 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 Azure AD 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 Azure AD 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.

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

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

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

-1. On the **Portal settings | Directories + subscriptions** page, find your Azure AD 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 Azure AD tenant.

-1. Select **Azure Active Directory**, select **Overview**.

-To make management easier, we recommend using Azure AD 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 an Azure AD 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 Azure Active Directory](../active-directory/fundamentals/how-to-manage-groups.md).

-1. With **Azure Active Directory** 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 Azure Active Directory](../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 Azure AD 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 Azure AD tenant (not the Azure AD B2C tenant).

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

-1. On the **Portal settings | Directories + subscriptions** page, find your Azure AD 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 Azure AD. To monitor multiple Azure AD B2C tenants, use different names. |

- | Authorizations | Specify a JSON array of objects that include the Azure AD `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 Azure AD 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 Azure AD 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 Azure AD tenants are selected under **Current + delegated directories**.

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

-1. Select **Azure Active Directory**

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

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

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

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

-1. Make sure you're using the directory that contains your *Azure AD* tenant:

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

-1. The EMEA Azure AD B2C tenant performs an Azure AD 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 an Azure AD 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 an Azure AD bearer token.

-1. The EMEA Azure AD B2C tenant performs an Azure AD ROPC flow against the NOAM Azure AD B2C tenant to verify credentials.

-Azure Active Directory B2C (Azure AD B2C) is a separate service from [Azure Active Directory (Azure AD)](../active-directory/fundamentals/whatis.md). It's built on the same technology as Azure AD 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 Azure AD 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 Azure AD'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 Azure AD 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 [Azure AD 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 an Azure AD 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 Azure AD 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 Azure Active Directory (Azure AD) tenant that the subscription is associated with.

-1. Make sure you're using the directory that has your Azure AD 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 Azure AD directory in the **Directory name** list, and then select **Switch**.

-## Change your Azure AD pricing tier

-1. Make sure you're using the Azure AD 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 Azure AD directory in the **Directory name** list, and then select **Switch** button next to it.

-Learn about the [Azure AD 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 Azure AD 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 Azure Active Directory tenant.

-If the source and destination subscriptions are associated with different Azure Active Directory 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 Azure AD 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 Azure Active Directory tenant.

-1. Your Azure AD B2C resource has now moved to the destination Azure subscription (linked to the target Azure Active Directory) and will be billed through this subscription from now on.

-|[Azure Active Directory](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 Azure Active Directory claims provider with the Azure Active Directory 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 Azure AD Identity 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 Azure AD, using these capabilities with Azure AD B2C will be a familiar experience, with the minor differences discussed in this article.

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

-Azure Active Directory (Azure AD) 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. Azure Active Directory (Azure AD) Conditional Access is the tool used by Azure AD B2C to bring signals together, make decisions, and enforce organizational policies.

-When using the Azure AD Conditional Access, consider the following:

-1. Under **Azure services**, select **Azure Active Directory**. Or use the search box to find and select **Azure Active Directory**.

-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 Azure AD Identity Protection sign-in risk detections.

-After you've added the Azure AD 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 Azure AD 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 Azure AD 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 Azure AD, 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 Azure Active Directory.

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

-## Step 1. Add a custom domain name to your Azure AD B2C tenant

-1. [Add your custom domain name to Azure AD](../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 **Azure Active Directory** 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 Azure AD, 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 `@`, Azure AD 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 Azure AD 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

-|[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 Azure AD storage by using Azure AD B2C custom policy. You use the Azure Active Directory technical profile.|

-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:

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

-### Step 3.4 - Create Azure AD technical profiles

-Just like in sign-in with a local account, you need to configure the [Azure AD Technical Profiles](active-directory-technical-profile.md), which you use to connect to Azure AD 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 Azure AD Technical Profile *AAD-UserWriteUsingAlternativeSecurityId* that writes a new social account into Azure AD.

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

- We've added a new Azure AD Technical Profile *AAD-UserReadUsingAlternativeSecurityId* that reads a new social account from Azure AD. 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.

-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 Azure AD 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 Azure AD 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:

-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 Azure Active Directory (Azure AD).

-Azure Active Directory B2C (Azure AD B2C) is built on Azure Active Directory (Azure AD), and so it uses Azure AD 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 Azure AD storage by using [Azure AD 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 Azure AD technical profiles to store and read a user account before a JWT token is returned.

-## Step 2 - Create Azure AD technical profiles

-You need to configure two [Azure AD Technical Profile](active-directory-technical-profile.md). One technical profile writes user details into Azure AD storage, and the other reads a user account from Azure AD 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 Azure AD technical profiles:

-1. In the claims provider you just created, add an Azure AD technical profile by using the following code:

- We've added a new Azure AD 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 an Azure AD 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 Azure AD 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 Azure AD 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 Azure AD 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.

-## Step 3 - Use the Azure AD technical profile

-After we collect user details by using the `UserInformationCollector` self-asserted technical profile, we need to write a user account into Azure AD 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 Azure AD storage. In the new code, we remove the *GenerateRandomObjectIdTransformation* as the `objectId` is created and returned by Azure AD 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 Azure AD storage.

-In our *AAD-UserWrite* Azure AD Technical Profile, we specify that if the user already exists, we raise an error message.

-Azure AD B2C uses [Azure AD 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.

-## Update user account by using Azure AD technical profile

-You can configure an Azure AD technical profile to update a user account instead of attempting to create a new one. To do so, set the Azure AD 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*:

-|[Azure AD (Single-tenant)](identity-provider-azure-ad-single-tenant.md) | GA | GA | |

-|[Azure AD (Multi-tenant)](identity-provider-azure-ad-multi-tenant.md) | NA | GA | |

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

-| [Azure AD MFA authentication](multi-factor-auth-technical-profile.md) | GA | |

-| [Azure Active Directory](active-directory-technical-profile.md) as local directory | GA | |

-|[DefaultSSOSessionProvider](#defaultssosessionprovider) | [Self-asserted](self-asserted-technical-profile.md), [Azure Active Directory](active-directory-technical-profile.md), [Azure AD Multi-Factor 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 Azure Active Directory.

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

-1. Make sure you're using the directory that contains your Azure AD tenant, and which has a subscription:

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

-1. Select **Review + create** and wait a few seconds for Azure AD to run a validation.

-You can customize your Azure AD B2C pages with a banner logo, background image, and background color by using Azure Active Directory [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 Azure Active Directory, then you enable it in your user flows in Azure AD B2C.

-1. Follow the steps in [Add branding to your organization's Azure Active Directory 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 Azure AD 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 Azure Active Directory data is located](https://aka.ms/aaddatamap)service.

-The following script acquires an access token from Azure AD. 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 Azure AD tenant. Select the **Directories + Subscriptions** icon in the portal toolbar.

-1. On the **Portal settings | Directories + subscriptions** page, find your Azure AD 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 (MFA) 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 an Azure AD MFA technical profile in an Azure AD B2C custom policy](multi-factor-auth-technical-profile.md).

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

- - 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 Azure Active Directory B2B (Azure AD B2B) in the Microsoft identity platform.

-|[Azure AD: 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 Azure Active Directory (Azure AD) tenant that contains your Azure subscription:

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

-1. In the Azure portal, search for and select **Azure Active Directory**.

-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 Azure Active Directory](../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 Active Directory 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 Open ID 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

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

-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 Azure AD 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 an Azure AD 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).

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

-# Set up sign-in for multi-tenant Azure Active Directory 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 Azure Active Directory (Azure AD). Allowing users from multiple Azure AD 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).

-## Register an Azure AD app

-To enable sign-in for users with an Azure AD 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 Azure AD tenant (for example, Contoso). Select the **Directories + subscriptions** icon in the portal toolbar.

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

-1. Select **Accounts in any organizational directory (Any Azure AD directory ΓÇô Multitenant)** for this application.

-If you want to get the `family_name`, and `given_name` claims from Azure AD, 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 Azure AD app](../active-directory/develop/optional-claims.md).

-1. Sign in to the [Azure portal](https://portal.azure.com). Search for and select **Azure Active Directory**.

-## Configure Azure AD as an identity provider

-To enable users to sign in using an Azure AD account, you need to define Azure AD 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 Azure AD as a claims provider by adding Azure AD to the **ClaimsProvider** element in the extension file of your policy.

-1. Set **client_id** to the application ID of the Azure AD multi-tenant application that you registered earlier.

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

-To obtain the values, look at the OpenID Connect discovery metadata for each of the Azure AD 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 Azure AD tenant name. For example:

-Perform these steps for each Azure AD tenant that should be used to sign in:

-1. From the sign-up or sign-in page, select **Common AAD** to sign in with Azure AD account.

-To test the multi-tenant sign-in capability, perform the last two steps using the credentials for a user that exists another Azure AD 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 Azure AD credentials.

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

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

-This article shows you how to enable sign-in for users from a specific Azure AD 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 Azure AD 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 an Azure AD tenant, [verify your app in the App Registration portal](../active-directory/develop/mark-app-as-publisher-verified.md).

-## Register an Azure AD app

-To enable sign-in for users with an Azure AD account from a specific Azure AD 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 Azure AD tenant (for example, Contoso):

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

-1. In the Azure portal, search for and select **Azure Active Directory**.

-## Configure Azure AD as an identity provider

-1. Enter a **Name**. For example, enter *Contoso Azure AD*.

-1. For **Metadata url**, enter the following URL replacing `{tenant}` with the domain name of your Azure AD tenant:

-## Add Azure AD identity provider to a user flow

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

-1. Click the user flow that you want to add the Azure AD identity provider.

-1. Under **Custom identity providers**, select **Contoso Azure AD**.

-1. From the sign-up or sign-in page, select **Contoso Azure AD** to sign in with Azure AD Contoso account.

-## Configure Azure AD as an identity provider

-To enable users to sign in using an Azure AD account, you need to define Azure AD 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 Azure AD as a claims provider by adding Azure AD to the **ClaimsProvider** element in the extension file of your policy.

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

-1. Azure AD 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 Azure AD 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 Azure AD Contoso account.

-If you want to get the `family_name` and `given_name` claims from Azure AD, 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 Azure AD app](../active-directory/develop/optional-claims.md).

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

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

-1. In the Azure portal, search for and select **Azure Active Directory**.

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

-The following XML is an example of an Azure AD 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 Azure AD 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, Azure AD doesn't include the public key of the certificate.

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

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

-1. For the **Client ID**, enter the Application (client) ID of the Azure AD application that you created earlier.

-If you want to get the `family_name` and `given_name` claims from Azure AD, 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 Azure AD app](../active-directory/develop/optional-claims.md).

-1. Sign in to the [Azure portal](https://portal.azure.com). Search for and select **Azure Active Directory**.

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

-You can define Azure AD 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 Azure AD 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 Azure AD.

-| scope | Yes | A space-separated list of scopes. A single scope value indicates to Azure AD 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 Azure AD Multi-Factor Authentication.

-Now that you've signed the user into your SPA, you can get access tokens for calling web APIs that are secured by Azure AD. 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 multi-factor authentication (MFA) notification languages are provided by [Azure AD MFA](../active-directory/authentication/concept-mfa-howitworks.md).

-| `cancel_message` | The user has canceled multi-factor authentication | `All` |

-## Azure AD MFA error messages

-The following IDs are used for an [Azure AD MFA technical profile](multi-factor-auth-technical-profile.md) error message:

-### Azure AD MFA example

-## Azure AD SSPR

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

-### Azure AD SSPR example

-1. The user signs in to the application. Azure AD B2C enforces authentication with Azure AD Multi-Factor 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 Azure Active Directory](../active-directory/fundamentals/add-users.md).

-1. In the left menu, select **Azure Active Directory**. Or, select **All services** and search for and select **Azure Active Directory**.

-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 Azure Active Directory](../active-directory/fundamentals/users-restore.md).

-1. In your Azure AD B2C directory, search for **Azure Active Directory**.

-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 Azure AD and the Microsoft identity platform `/token` endpoint for an application in your Azure AD B2C tenant.

-* [Get an access token from Azure AD](/graph/auth-v2-service#4-get-an-access-token)

-* [Get audit logs with the Azure AD 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 [Azure AD 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 [Azure AD 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 does the identity assertion. For more information, see [b2cAuthenticationMethodsPolicy resource type](/graph/api/resources/b2cauthenticationmethodspolicy).

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

-> In Azure AD, 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.

-description: Custom policy reference for Azure AD Multi-Factor Authentication (MFA) technical profiles in Azure AD B2C.

-# Define an Azure AD MFA technical profile in an Azure AD B2C custom policy

-The following example shows an Azure AD MFA 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 Azure AD MFA 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:

-The **InputClaims** element contains a list of claims to send to Azure AD MFA. You can also map the name of your claim to the name defined in the MFA technical profile.

-The Azure AD MFA protocol provider doesn't return any output claims, so there's no need to specify output claims.

-The following example shows an Azure AD MFA technical profile that is used to send a code via SMS.

-The **InputClaims** element contains a list of claims to send to Azure AD MFA. You can also map the name of your claim to the name defined in the MFA technical profile.

-The Azure AD MFA protocol provider doesn't return any output claims, so there's no need to specify output claims.

-The following example shows an Azure AD MFA technical profile used to verify the code.

-The **InputClaims** element contains a list of claims to send to Azure AD MFA. 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 Azure AD MFA. You can also map the name of your claim to the name defined in the MFA technical profile.

-The following example shows an Azure AD MFA technical profile used to get the number of available devices.

-The **InputClaims** element contains a list of claims to send to Azure AD MFA. You can also map the name of your claim to the name defined in the MFA technical profile.

-The Azure AD MFA protocol provider doesn't return any output claims, so there's no need to specify output claims.

-The following example shows an Azure AD MFA technical profile used to begin the TOTP verification process.

-The **InputClaims** element contains a list of claims to send to Azure AD MFA. You can also map the name of your claim to the name defined in the MFA technical profile.

-The Azure AD MFA protocol provider doesn't return any output claims, so there's no need to specify output claims.

-The following example shows an Azure AD MFA technical profile used to verify a TOTP code.

-Azure Active Directory B2C (Azure AD B2C) integrates directly with [Azure AD Multi-Factor 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 multi-factor authentication incurs separate charges from the normal Azure AD B2C MAU's pricing model](https://azure.microsoft.com/pricing/details/active-directory/external-identities/).

- > - Multi-factor authentication (MFA) 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.

-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 Azure AD. 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 Azure Active Directory. |

-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 Azure Active Directory (Azure AD). 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.

-Azure AD B2C is a separate service from [Azure Active Directory (Azure AD)](../active-directory/fundamentals/whatis.md). It is built on the same technology as Azure AD 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 Azure Active Directory (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 AD subscription.

-For the following instructions, use the Azure AD tenant with the Azure subscription.

-3. On **Portal settings | Directories + subscriptions**, in the **Directory name** list, locate your Azure AD directory.

-* An Azure AD subscription

-* An Azure AD 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 . See, [Microsoft 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 an Azure AD Multi-Factor Authentication (MFA) token.

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

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

-|{Settings:DfpTenantId}|The ID of the Azure AD 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 an Azure AD tenant or subscription. This value is optional but [recommended to assist with debugging](./troubleshoot-with-application-insights.md).

->Use the deployed service URL to configure Azure AD with the required settings.

-Go to f5.com resources and white papers for: [Easily Configure Secure Access to All Your Applications via Azure AD](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 Open ID 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 Azure AD preauthentication.

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

- 5. Determine if the APM receives the expected Azure AD claims.

-3. At the prompt, enter your credentials. If necessary, include an Azure AD Multi-Factor authentication (MFA) token.

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

-* An Azure AD subscription

-* An Azure AD subscription

-|`loa-2`| Crypto-based Azure AD Multi-Factor Authentication (MFA) only|

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

-You'll need the URL of the deployed service to configure Azure AD with the required settings.

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

->To configure Azure AD, you'll need the deployed service URL.

-15. Add user attributes Azure AD collects with claims Azure AD B2C returns to the client application.

->You'll need deployed service URL to configure Azure AD.

-2. Go to **Azure Active Directory** > **Users**.

-Create a CSR or Helpdesk user who accesses TheAccessHub Admin Tool with enterprise Azure Active Directory credentials.

-6. For **Login ID/Azure AD User Name**, enter the user principal name from the user Azure Active Directory 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 Azure AD.

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

- 

-12. Add user attributes for Azure AD to collect, with claims that Azure AD B2C returns to the client application.

->You'll need the deployed service URL to configure Azure AD.

-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 Open ID 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 **Azure AD Application ID**.

-7. For **Client Secret**, enter the **Key** you generated for the application in Azure AD.

-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 Azure AD App Proxy](../active-directory/app-proxy/application-proxy-configure-single-sign-on-with-headers.md).

-* An Azure AD subscription

-### Create an Azure AD application for Saviynt

-Learn more: [Application and service principal objects in Azure AD](../active-directory/develop/app-objects-and-service-principals.md)

-In this sample tutorial, you'll learn how to integrate Azure Active Directory (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.

- >2. Azure Active DirectoryΓÇÖs initial domain name is used as the client redirect host.

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

-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 multi-factor 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 Azure AD MFA, forcing email verification, or any other custom logic for your scenario.

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

-* An Azure AD subscription

-* **An Azure AD tenant** - the Azure AD B2C tenant stores users and manages access (and scope) in Rampart

- * [Azure Active Directory](https://azure.microsoft.com/services/active-directory/): Authenticate administrative users for the portal

-* An Azure AD subscription

-The following technical profiles are [Active Directory technical profiles](active-directory-technical-profile.md), which read and write data to Azure Active Directory. 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 multi-factor authentication (MFA) 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 multi-factor authentication (MFA)

-With Azure Active Directory (Azure AD) Multi-Factor Authentication (MFA), 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 multi-factor authentication. To set this up please read our instructions for [enabling multi-factor authentication in Azure Active Directory B2C](multi-factor-authentication.md).

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

-# Publish your Azure Active Directory B2C app to the Azure Active Directory app gallery

-The Azure Active Directory (Azure AD) 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 Azure AD 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 Azure AD tenant.

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

-1. If the Azure AD SSO session is active, Azure AD 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 Azure AD identity settings, they might be prompted to:

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

-## Step 2: Set up sign-in for multitenant Azure AD

-To allow employees and consumers from any Azure AD tenant to sign in by using Azure AD B2C, follow the guidance for [setting up sign in for multitenant Azure AD](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 Azure AD app gallery takes users to sign in to your app.

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

-The application includes the Azure AD 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 an Azure AD access token in the request to the protected web API resource to perform operations on the user's to-do list items.

-

-|Tenant Creator| Create new Azure AD 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 BC 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. |

-#### Acquiring an Azure AD access token

-The following example uses a REST API technical profile to make a request to the Azure AD 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 Azure AD to obtain an access token, you need to register an application. Azure AD B2C relies the Azure AD platform. You can create the app in your Azure AD B2C tenant, or in any Azure AD tenant you manage. To register an application:

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

-1. In the left menu, select **Azure Active Directory**. Or, select **All services** and search for and select **Azure Active Directory**.

-1. In the **Azure AD - 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 Azure AD 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 an Azure AD 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 (MFA)|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> |

-The validation technical profile can be any technical profile in the policy, such as [Azure Active Directory](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.

-|Azure Active Directory Multi-Factor Authentication |2 |

-¹ See also [Azure AD 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 Azure Active Directory. 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 Azure AD 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 Azure active Directory](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 Azure AD, Azure AD B2C, and Azure AD 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 Azure AD user account. Later, when you read the account from the directory, use the `StringSplit` to convert the comma delimiter string back to string collection.

-description: Learn about Azure Active Directory features, which are still supported in Azure AD B2C.

-# Supported Azure Active Directory features

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

-|Feature |Azure AD | 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 an Azure AD user as a guest to your Azure AD 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 Azure AD 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 Azure AD 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 Azure AD premium 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 Azure AD premium P1. A subset of Azure AD 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 Azure AD premium 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 Azure AD premium P2. A subset of Azure AD Identity 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 Azure AD 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) | Azure AD Go-Local add-on enables you to store data in the country/region you choose when your Azure AD tenant.| Just like Azure AD, 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 Azure AD 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 an Azure Active Directory tenant, which you may already have.

-Azure AD B2C defines several types of user accounts. Azure Active Directory, Azure Active Directory B2B, and Azure Active Directory B2C share these account types.

-You can also extend the Azure AD 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:

-Azure AD 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 remediation actions and enforce organizational policies.

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

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

-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 Azure AD 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 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 [Azure AD 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 Azure AD attribute name.

-The name of the claim is the name of the [Azure AD attribute](user-profile-attributes.md) unless the **PartnerClaimType** attribute is specified, which contains the Azure AD 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 [Azure AD](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 **Azure Active Directory**.

-1. In the Azure portal, search for and select **Azure Active Directory**.

-It's important that you monitor how you use your Azure Active Directory (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 Azure AD account, make sure you're using the directory that contains your Azure AD B2C tenant:

- - **Directory role**: If you require Azure AD administrative permissions for the user, you can add them to an Azure AD role. You can assign the user to be a Global administrator or one or more of the limited administrator roles in Azure AD. 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 Azure AD because the lifecycle of this identity can be managed externally.

- - **Directory role**: If you require Azure AD administrative permissions for the user, you can add them to an Azure AD role. You can assign the user to be a Global administrator or one or more of the limited administrator roles in Azure AD. 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 Azure Active Directory](../active-directory/fundamentals/users-restore.md).

-If you're not using [Conditional Access](conditional-access-user-flow.md), you can enable [Azure AD 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 **Azure Active Directory**.

- 

-> 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 Azure AD authentication service. In that scenario, because each Azure AD 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 Azure Active Directory, see [Sign-in activity report error codes](../active-directory/reports-monitoring/concept-sign-ins.md).

-1. Make sure you're using the Azure AD 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 Azure AD directory in the **Directory name** list, and then select **Switch**.

-1. Make sure you're using the Azure AD 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 Azure AD directory in the **Directory name** list, and then select **Switch**.

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

-1. Make sure you're using the Azure Active Directory (Azure AD) tenant that contains your subscription:

- 1. On the **Portal settings | Directories + subscriptions** page, find your Azure AD 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 Azure AD Core Store data and Azure AD 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 Azure AD data in \<Country\>** checkbox, then select **Save** button.

-1. In the Azure portal, search for and select the **Azure Active Directory** service.

-1. In the Azure portal, search for and select the **Azure Active Directory** service

-1. In the Azure portal, search for and select the **Azure Active Directory** service.

- 1. Sign out of the Azure portal and then sign back in to refresh your access, and select the **Azure Active Directory** 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 [Azure Active Directory](active-directory-technical-profile.md) technical profile, and provides support for Azure AD user management. Other Azure AD technical profiles include the AAD-Common to use its configuration. Override the AAD-Common technical profile in the extension file.

-> The first time the Azure AD 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 Azure AD extensions.

-* Azure AD Multi-Factor Authentication (MFA)

-* First- and third-party multifactor authentication (MFA) challenges

-| Identity Providers | [Predefined local](identity-provider-local.md) or [social provider](add-identity-provider.md), such as federation with Azure Active Directory 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>Multi-Factor 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 Active Directory](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. Azure Active Directory (Azure AD), Azure Active Directory B2B (Azure AD B2B), and Azure Active Directory B2C (Azure AD B2C) share in the types of user accounts that can be used.

-A work account is created the same way for all tenants based on Azure AD. To create a work account, you can use the information in [Quickstart: Add new users to Azure Active Directory](../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 Azure Active Directory](../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 an Azure Active Directory B2B collaboration user](../active-directory/external-identities/user-properties.md).

-## Azure AD user resource type

-|userState (externalUserState)³|String|For Azure AD 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 Azure Active Directory [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 Azure Active Directory 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 an [Azure Active Directory 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 [Azure Active Directory](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 **Azure Active Directory** 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.

-## Get audit logs with the Azure AD reporting API

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

-To allow script- or application-based access to the Azure AD 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 Azure AD reporting API endpoint.

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

-description: Learn about how to administer an Azure Active Directory Domain Services managed domain and the behavior of user accounts and passwords

-# Management concepts for user accounts, passwords, and administration in Azure Active Directory Domain Services

-When you create and run an Azure Active Directory 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 Azure AD 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 Azure AD, 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 Azure AD. This includes cloud-only user accounts created directly in Azure AD, and hybrid user accounts synchronized from an on-premises AD DS environment using Azure AD Connect.

- * The majority of user accounts in a managed domain are created through the synchronization process from Azure AD.

-* The user account can be manually created in a managed domain, and doesn't exist in Azure AD.

- * 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 Azure AD, user accounts created in the managed domain aren't synchronized back to Azure AD.

-Azure AD 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, Azure AD DS needs password hashes in a format that's suitable for NT LAN Manager (NTLM) and Kerberos authentication. Azure AD doesn't generate or store password hashes in the format that's required for NTLM or Kerberos authentication until you enable Azure AD DS for your tenant. For security reasons, Azure AD also doesn't store any password credentials in clear-text form. Therefore, Azure AD 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 Azure AD. The account isn't synchronized from Azure AD to Azure AD DS until the password is changed.

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

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

-> If your legacy applications don't use NTLM authentication or LDAP simple binds, we recommend that you disable NTLM password hash synchronization for Azure AD 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 Azure AD 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 - Azure AD needs to generate and store the password hashes in the new managed domain. For more information, see [Password hash sync process for Azure AD DS and Azure AD Connect][azure-ad-password-sync].

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

-In Azure AD 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 Azure AD, 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 an Azure AD 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 Azure AD 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.

-## Azure AD DS SKUs

-In Azure AD 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 Azure AD 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 [Azure AD 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* Azure AD, any issues in a managed domain won't impact Azure AD or on-premises AD DS environments and functionality.

-To get started, [create an Azure AD DS managed domain][create-instance].

-description: Learn how to troubleshoot and resolve common alerts with secure LDAP for Azure Active Directory Domain Services.

-# Known issues: Secure LDAP alerts in Azure Active Directory Domain Services

-Applications and services that use lightweight directory access protocol (LDAP) to communicate with Azure Active Directory Domain Services (Azure AD 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 Azure AD DS.

-> TCP port 636 isn't the only rule needed for Azure AD DS to run smoothly. To learn more, see the [Azure AD 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 Azure AD DS, and distribute the certificate to any clients that connect using secure LDAP.

-description: Learn how to troubleshoot and resolve network security group configuration alerts for Azure Active Directory Domain Services

-# Known issues: Network configuration alerts in Azure Active Directory Domain Services

-To let applications and services correctly communicate with an Azure Active Directory Domain Services (Azure AD 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 an Azure AD 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 Azure AD 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 Azure AD directory and Azure AD 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 Azure AD DS secure and allow the Azure platform to monitor, manage, and update the managed domain.

-> Azure AD 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.

-description: Learn how to troubleshoot service principal configuration alerts for Azure Active Directory Domain Services

-# Known issues: Service principal alerts in Azure Active Directory 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 an Azure Active Directory Domain Services (Azure AD DS) managed domain. If a service principal is deleted, functionality in the managed domain is impacted.

-*A Service Principal required for Azure AD Domain Services to function properly has been deleted from your Azure AD 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 Azure AD 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).

-### Re-register the Microsoft AAD namespace

-If application ID *443155a6-77f3-45e3-882b-22b3a8d431fb*, *abba844e-bc0e-44b0-947a-dc74e5d09022*, or *d87dcbc6-a371-462e-88e3-28ad15ec4e64* is missing from your Azure AD 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 Azure AD Domain Services resources needed to service your managed domain. Synchronization of passwords on your managed domain could be affected.*

-Azure AD DS automatically synchronizes user accounts and credentials from Azure AD. If there's a problem with the Azure AD application used for this process, credential synchronization between Azure AD DS and Azure AD fails.

-To recreate the Azure AD 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).

-description: Learn how to the SKU tier for an Azure AD Domain Services managed domain if your business requirements change

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

-# Change the SKU for an existing Azure Active Directory Domain Services managed domain

-In Azure Active Directory Domain Services (Azure AD 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 [Azure AD DS SKU concepts][concepts-sku] and [Azure AD DS pricing][pricing] pages.

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

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

-For more information on these limits, see [Azure AD DS SKU features and limits][concepts-sku].

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

-1. In the menu on the left-hand side of the Azure AD 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 Azure AD DS][create-trust].

-description: Learn how to check the health of an Azure Active Directory Domain Services (Azure AD DS) managed domain and understand status messages.

-# Check the health of an Azure Active Directory Domain Services managed domain

-Azure Active Directory Domain Services (Azure AD 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 Azure AD. If there are issues with the Azure AD 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 Azure AD 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 Azure AD 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 **Azure AD Domain Services**.

-1. On the left-hand side of the Azure AD 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. Azure AD DS currently has monitors for the following areas:

-* Synchronization with Azure AD

-#### Synchronization with Azure AD monitor

-A managed domain regularly synchronizes with Azure Active Directory. The number of users and group objects, and the number of changes made in the Azure AD 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, Azure Active Directory, and Azure Active Directory Domain Services.

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

-# Compare self-managed Active Directory Domain Services, Azure Active Directory, and managed Azure Active Directory 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 Azure Active Directory.

-* **Azure Active Directory (Azure AD)** - 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.

- * Azure AD 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 Azure AD, see [What is Azure Active Directory?][whatis-azuread]

-* **Azure Active Directory Domain Services (Azure AD 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.

- * Azure AD DS integrates with Azure AD, 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 Azure AD and on-premises, see [How objects and credentials are synchronized in a managed domain][synchronization].

-> [To get started, create an Azure AD DS managed domain using the Microsoft Entra admin center][tutorial-create]

-## Azure AD DS and self-managed AD DS

-* A *managed domain* that you create using Azure Active Directory Domain Services (Azure AD DS). Microsoft creates and manages the required resources.

-With Azure AD 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).

-Azure AD 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 Azure AD 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, Azure AD 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 Azure AD DS][administration-concepts].

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

-| **Feature** | **Azure AD DS** | **Self-managed AD DS** |

-## Azure AD DS and Azure AD

-Azure AD 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 Azure AD, which provides the device with an identity. Azure AD then authenticates the device when a user signs in to Azure AD 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 Azure AD. This mechanism offers the same benefits of registering a personal device with Azure AD, such as to allow users to sign in to the device using their corporate credentials.

-Azure AD joined devices give you the following benefits:

-* Single-sign-on (SSO) to applications secured by Azure AD.

-Devices can be joined to Azure AD 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 | Azure AD registered |

-| Organization-owned device not joined to on-premises AD DS | Windows 10 | Azure AD joined |

-| Organization-owned device joined to an on-premises AD DS | Windows 10 | Hybrid Azure AD joined |

-On an Azure AD-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 Azure AD 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** | **Azure AD-joined** | **Azure AD DS-joined** |

-| Device controlled by | Azure AD | Azure AD DS managed domain |

-| Representation in the directory | Device objects in the Azure AD directory | Computer objects in the Azure AD DS managed domain |

-If on-premises AD DS and Azure AD are configured for federated authentication using AD FS, then there's no (current/valid) password hash available in Azure DS. Azure AD 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 Azure AD DS won't be able to validate the users credentials

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

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

-description: Learn how to create and manage custom attributes in an Azure AD DS managed domain.

-# Custom attributes for Azure Active Directory Domain Services

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

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

->- Custom security attributes in Azure AD (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 [Azure Active Directory Domain Pricing](https://azure.microsoft.com/pricing/details/active-directory-ds/).

-## Synchronize Azure AD directory extension attributes

-These are the extended user or group attributes defined in your Azure AD tenant.

->If you would like to see directory extensions synchronized by Azure AD Connect, click **Enterprise App** and look for the Application ID of the **Tenant Schema Extension App**. For more information, see [Azure AD 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).

-Azure AD 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 Azure AD. During the backfill synchronization process, incremental changes in Azure AD are paused, and the sync time depends on the size of the tenant.

-To check the backfilling status, click **Azure AD DS Health** and verify the **Synchronization with Azure AD** 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 Azure AD, 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 Azure AD, [configure Azure AD Connect](../active-directory/hybrid/connect/how-to-connect-sync-feature-directory-extensions.md).

-description: Learn more about how forest trust work with Azure AD Domain Services

->Azure AD 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 Azure AD DS, see [Forest concepts and features][create-forest-trust].

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

-> Azure AD Domain Services only supports a one-way forest trust to on-premises Active Directory.

- > Any Azure AD 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 Azure AD 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 Azure AD 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 Azure AD DS, sign in must use **sAMAccountName**.

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

-description: Learn what replica sets are in Azure Active Directory Domain Services and how they provide redundancy to applications that require identity services.

-# Replica sets concepts and features for Azure Active Directory Domain Services

-When you create an Azure Active Directory Domain Services (Azure AD 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 Azure AD tenant. Replica sets can be added to any peered virtual network in any Azure region that supports Azure AD 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 Azure AD 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 Azure AD. 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 an Azure AD DS managed domain][tutorial-create-advanced]. When deployed, [create and use additional replica sets][create-replica-set].

-description: In this article, learn how to create and configure an Azure Active Directory 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 an Azure AD Domain Services forest and one-way outbound trust from an Azure Active Directory Domain Services forest to an on-premises Active Directory Domain Services forest using Azure PowerShell to provide authentication and resource access between forests.

-# Create an Azure Active Directory 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 Azure Active Directory Domain Services (Azure AD 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 Azure AD DS managed domain. In this case, on-premises password hashes are never synchronized.

-

-> * Create an Azure AD DS forest using Azure PowerShell

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory 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 Azure AD](/powershell/azure/active-directory/install-adv2).

- * Make sure that you sign in to your Azure AD 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) Azure AD roles in your tenant to enable Azure AD DS.

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

-## Create the Azure AD service principal

-Azure AD DS requires a service principal synchronize data from Azure AD. This principal must be created in your Azure AD tenant before you created the managed domain forest.

-Create an Azure AD service principal for Azure AD 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 an Azure AD 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 Azure AD engineering team.

- | Subscription | *-azureSubscriptionId* | Subscription ID used for Azure AD 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 Azure AD DS.](https://azure.microsoft.com/global-infrastructure/services/?products=active-directory-ds&regions=all) |

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

- | Azure AD 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 Azure AD DS subnet if these resources don't already exist. The script can optionally create the workload subnets, when specified:

- | Azure AD 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. |

- | Azure AD DS address range | *-aaddsSubnetCIDRAddressRange* | Subnet address range in CIDR notation for the Azure AD 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 Azure AD forest provisions in the background.

-1. In the Microsoft Entra admin center, search for and select **Azure AD 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 Azure AD DS](tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds) to finalize the configurations for your managed domain.

-| Azure AD DS domain name | *-ManagedDomainFqdn* | FQDN of the managed domain, such as *aaddscontoso.com* |

-* [On-premises user authentication from the Azure AD DS forest](#on-premises-user-authentication-from-the-azure-ad-ds-forest)

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

-### On-premises user authentication from the Azure AD DS forest

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

-### Access resources in Azure AD DS as an on-premises user

- > To securely connect to your VMs joined to Azure AD 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 Azure AD DS, see [How do forest trusts work in Azure AD DS?][concepts-trust]

-description: Learn how to create a group managed service account (gMSA) for use with Azure Active Directory Domain Services managed domains

-# Create a group managed service account (gMSA) in Azure Active Directory Domain Services

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

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, complete the tutorial to [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

-* A Windows Server management VM that is joined to the Azure AD DS managed domain.

-## Using service accounts in Azure AD DS

- * The KDS root key is used to generate and retrieve passwords for gMSAs. In Azure AD 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 Azure AD DS][create-custom-ou].

-description: Learn how to create and manage a custom Organizational Unit (OU) in an Azure AD Domain Services managed domain.

-# Create an Organizational Unit (OU) in an Azure Active Directory Domain Services managed domain

-Azure AD DS managed domains include the following two built-in OUs:

-* *AADDC Users* - includes users and groups synchronized in from the Azure AD tenant.

-As you create and run workloads that use Azure AD 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.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, complete the tutorial to [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

-* A Windows Server management VM that is joined to the Azure AD DS managed domain.

-* A user account that's a member of the *Azure AD DC administrators* group in your Azure AD tenant.

-* A default OU for *AADDC Users* is created that contains all the synchronized user accounts from your Azure AD tenant.

-* User accounts, groups, service accounts, and computer objects that you create under custom OUs aren't available in your Azure AD tenant.

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

-description: Learn how to enable and manage Azure Active Directory Domain Services managed domains for Azure Cloud Solution Providers

-# Azure Active Directory 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 an Azure Active Directory (Azure AD) 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 Azure AD tenant. As a result, a user belonging to the CSP partner's admin agents group has tenant admin privileges in Contoso's Azure AD 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 Azure AD Domain Services on behalf of Contoso.

-## Benefits of using Azure AD DS in an Azure CSP subscription

-Azure Active Directory Domain Services (Azure AD 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.

-Azure AD DS supports Azure CSP subscriptions. You can deploy your application in an Azure CSP subscription tied to your customer's Azure AD 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 an Azure AD DS managed domain in your customer's Azure AD 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 Azure AD 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.

-## CSP deployment models for Azure AD DS

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

-In this deployment model, Azure AD 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 Azure AD 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 Azure AD tenant.

-In this deployment model, Azure AD 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 Azure AD 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 Azure AD.

-## Administer Azure AD DS in CSP subscriptions

-* **CSP admin agents can provision a managed domain using their credentials:** Azure AD 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 Azure AD 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 Azure AD tenant and their credentials aren't available within the customer's Azure AD tenant. Azure AD 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 Azure AD 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 Azure AD 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 Azure AD Domain Services using the [Microsoft Entra admin center](tutorial-create-instance.md) or [Azure PowerShell](powershell-create-instance.md).

-description: Learn how to disable, or delete, an Azure Active Directory Domain Services managed domain

-# Delete an Azure Active Directory Domain Services managed domain

-If you no longer need an Azure Active Directory Domain Services (Azure AD DS) managed domain, you can delete it. There's no option to turn off or temporarily disable an Azure AD DS managed domain. Deleting the managed domain doesn't delete or otherwise adversely impact the Azure AD tenant.

-1. Search for and select **Azure AD Domain Services**.

-Consider [sharing feedback][feedback] for the features that you would like to see in Azure AD DS.

-If you want to get started with Azure AD DS again, see [Create and configure an Azure Active Directory Domain Services managed domain][create-instance].

-description: Learn how to provide secure access to internal applications for remote workers by deploying and configuring Azure Active Directory Application Proxy in an Azure Active Directory Domain Services managed domain

-# Deploy Azure AD Application Proxy for secure access to internal applications in an Azure Active Directory Domain Services managed domain

-With Azure AD Domain Services (Azure AD DS), you can lift-and-shift legacy applications running on-premises into Azure. Azure Active Directory (AD) Application Proxy then helps you support remote workers by securely publishing those internal applications part of an Azure AD DS managed domain so they can be accessed over the internet.

-If you're new to the Azure AD 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 an Azure AD Application Proxy connector to provide secure access to applications in a managed domain.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

- * An **Azure AD Premium license** is required to use the Azure AD Application Proxy.

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

-To route traffic to applications running in your environment, you install the Azure AD Application Proxy connector component. This Azure AD 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 Azure AD 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 Azure AD 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 Azure AD Application Proxy and that run your applications must be a part of the custom OU, not the default *AAD DC Computers* OU.

-1. [Domain-join the virtual machines][create-join-windows-vm], both the one that runs the Azure AD 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.

-## Download the Azure AD Application Proxy connector

-Perform the following steps to download the Azure AD Application Proxy connector. The setup file you download is copied to your App Proxy VM in the next section.

- 

-## Install and register the Azure AD Application Proxy connector

-With a VM ready to be used as the Azure AD Application Proxy connector, now copy and run the setup file downloaded from the Microsoft Entra admin center.

-1. Copy the Azure AD 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 Azure AD directory.

- * Provide the credentials for a global administrator in your Azure AD directory. The Azure AD global administrator credentials may be different from your Azure credentials in the portal

- > For example, if the Azure AD 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 Azure AD 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 Azure AD 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 Azure AD 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 Azure Active Directory Domain Services](deploy-kcd.md).

-> You must be signed in to a user account that's a member of the *Azure AD DC administrators* group in your Azure AD 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 *AAD DC Computers* container.

-Use the [Get-ADComputer][Get-ADComputer] to retrieve the settings for the computer on which the Azure AD Application Proxy connector is installed. From your domain-joined management VM and logged in as user account that's a member of the *Azure AD 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 Azure AD Application Proxy VM configured in the previous steps.

-For each application server that runs the apps behind Azure AD Application Proxy use the [Set-ADComputer][Set-ADComputer] PowerShell cmdlet to configure resource-based KCD. In the following example, the Azure AD Application Proxy connector is granted permissions to use the *appserver.aaddscontoso.com* computer:

-If you deploy multiple Azure AD Application Proxy connectors, you must configure resource-based KCD for each connector instance.

-With the Azure AD Application Proxy integrated with Azure AD DS, publish applications for users to access. For more information, see [publish applications using Azure AD Application Proxy](../active-directory/app-proxy/application-proxy-add-on-premises-application.md).

-description: Learn how to enable resource-based Kerberos constrained delegation (KCD) in an Azure Active Directory Domain Services managed domain.

-# Configure Kerberos constrained delegation (KCD) in Azure Active Directory Domain Services

-Azure Active Directory Domain Services (Azure AD 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 an Azure AD DS managed domain.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

-* A Windows Server management VM that is joined to the Azure AD DS managed domain.

-* A user account that's a member of the *Azure AD DC administrators* group in your Azure AD 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 *AAD DC Computers* container.

- From your domain-joined management VM and logged in as user account that's a member of the *Azure AD 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 *AAD DC Computers* or *AAD DC Users* containers. This also means that you can't use user accounts synchronized from Azure AD to set up resource-based KCD. You must create and use service accounts specifically created in Azure AD DS.

- From your domain-joined management VM and logged in as user account that's a member of the *Azure AD DC administrators* group, run the following cmdlets. Provide your own service names as needed:

-description: Learn how to configure an Azure Active Directory Domain Services managed domain to support profile synchronization for SharePoint Server

-# Configure Azure Active Directory 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 an Azure Active Directory Domain Services (Azure AD 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 Azure AD DS to allow the SharePoint Server user profile sync service.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, complete the tutorial to [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

-* A Windows Server management VM that is joined to the Azure AD DS managed domain.

-* A user account that's a member of the *Azure AD DC administrators* group in your Azure AD tenant.

-In a managed domain, a security group named *AAD DC Service Accounts* exists as part of the *Users* organizational unit (OU). Members of this security group are delegated the following privileges:

-The *AAD 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 *AAD DC Service Accounts* group.

-From your Azure AD DS management VM, complete the following steps:

-1. Select the **Users** OU, then choose the *AAD DC Service Accounts* security group.

- 

-[sharepoint-service-account]: /sharepoint/security-for-sharepoint-server/plan-for-administrative-and-service-accounts

-description: Learn which Azure AD DS features are available in Azure Government.

-# Azure Active Directory Domain Services feature availability

-This following table lists Azure Active Directory Domain Services (Azure AD DS) feature availability in Azure Government.

-| Deploy Azure AD Application Proxy | &#x2705; |

-description: Learn how to check fleet metrics of an Azure Active Directory Domain Services (Azure AD DS) managed domain.

-# Check fleet metrics of Azure Active Directory Domain Services

-Administrators can use Azure Monitor Metrics to configure a scope for Azure Active Directory Domain Services (Azure AD DS) and gain insights into how the service is performing.

-You can access Azure AD DS metrics from two places:

- :::image type="content" border="true" source="media/fleet-metrics/select.png" alt-text="Screenshot of how to select Azure AD DS for fleet metrics.":::

- :::image type="content" border="true" source="media/fleet-metrics/metrics-scope.png" alt-text="Screenshot of how to select Azure AD DS as scope in Azure Monitor Metrics.":::

- You can also view metrics for a fleet of Azure AD DS instances:

- :::image type="content" border="true" source="media/fleet-metrics/metrics-instance.png" alt-text="Screenshot of how to select an Azure AD 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 an Azure AD DS instance.":::

-The following table describes the metrics that are available for Azure AD DS.

-You can configure metric alerts for Azure AD 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 Azure AD DS Metrics, click **New alert** and configure an Azure AD DS instance as the scope. Then choose the metrics you want to measure from the list of available signals:

-description: Learn how to retrieve data from Azure Active Directory Domain Services (Azure AD DS).

-# Azure AD DS instructions for data retrieval

-This document describes how to retrieve data from Azure Active Directory Domain Services (Azure AD DS).

-## Use Azure Active Directory to create, read, update, and delete user objects

-You can create a user in the Azure AD 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 Azure AD portal.

-You can create a new user using the Azure Active Directory portal.

- 

- - **Directory role**: If you require Azure AD administrative permissions for the user, you can add them to an Azure AD role.

-The user is created and added to your Azure AD organization.

-1. Search for and select the user you want to delete from your Azure AD tenant. For example, _Mary Parker_.

-## Use RSAT tools to connect to an Azure AD 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 Azure AD tenant are listed in this container.

- 

-* [Azure AD DS Overview](overview.md)

-description: Learn how to configure and join a CentOS Linux virtual machine to an Azure Active Directory Domain Services managed domain.

-# Join a CentOS Linux virtual machine to an Azure Active Directory 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 an Azure Active Directory Domain Services (Azure AD DS) managed domain. When you join a VM to an Azure AD 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.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, the first tutorial [creates and configures an Azure Active Directory 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 Azure AD 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 Azure AD](../active-directory/fundamentals/active-directory-groups-members-azure-portal.md).

-description: Learn how to configure and join a CoreOS virtual machine to an Azure AD Domain Services managed domain.

-# Join a CoreOS virtual machine to an Azure Active Directory 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 an Azure Active Directory Domain Services (Azure AD DS) managed domain. When you join a VM to an Azure AD 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.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, the first tutorial [creates and configures an Azure Active Directory 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 Azure AD Domain Services.

-* Deploy the VM into a different subnet than your Azure AD 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 Azure AD](../active-directory/fundamentals/active-directory-groups-members-azure-portal.md).

-description: Learn how to configure and join a Red Hat Enterprise Linux virtual machine to an Azure AD Domain Services managed domain.

-# Join a Red Hat Enterprise Linux virtual machine to an Azure Active Directory 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 an Azure Active Directory Domain Services (Azure AD DS) managed domain. When you join a VM to an Azure AD 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.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, the first tutorial [creates and configures an Azure Active Directory 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 Azure AD Domain Services.

-* Deploy the VM into a different subnet than your Azure AD 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 Azure AD](../active-directory/fundamentals/active-directory-groups-members-azure-portal.md).

-description: Learn how to configure and join a SUSE Linux Enterprise virtual machine to an Azure AD Domain Services managed domain.

-# Join a SUSE Linux Enterprise virtual machine to an Azure Active Directory 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 an Azure Active Directory Domain Services (Azure AD DS) managed domain. When you join a VM to an Azure AD 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.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, the first tutorial [creates and configures an Azure Active Directory 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 Azure AD Domain Services.

-* Deploy the VM into a different subnet than your Azure AD 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 Azure AD](../active-directory/fundamentals/active-directory-groups-members-azure-portal.md).

-3. Check that the date and time in Azure AD and Linux are in sync. You can do this by adding the Azure AD server to the NTP service:

-description: Learn how to configure and join an Ubuntu Linux virtual machine to an Azure AD Domain Services managed domain.

-# Join an Ubuntu Linux virtual machine to an Azure Active Directory 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 an Azure Active Directory Domain Services (Azure AD DS) managed domain. When you join a VM to an Azure AD 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.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, the first tutorial [creates and configures an Azure Active Directory 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 Azure AD 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 an Azure Active Directory Domain Services managed domain](synchronization.md).

-* Deploy the VM into the same, or a peered, virtual network in which you have enabled Azure AD Domain Services.

-* Deploy the VM into a different subnet than your Azure AD 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 Azure AD](../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 Azure AD DS to authenticate the request.

-description: Learn how to use Azure Resource Manager templates to join a new or existing Windows Server VM to an Azure Active Directory Domain Services managed domain.

-# Join a Windows Server virtual machine to an Azure Active Directory 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 Azure Active Directory Domain Services (Azure AD DS) managed domains.

-This article shows you how to create and join a Windows Server VM to an Azure AD DS managed domain using Resource Manager templates. You also learn how to join an existing Windows Server VM to an Azure AD DS domain.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, the first tutorial [creates and configures an Azure Active Directory 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 Azure AD 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 *AAD DC Computers* OU. |

- | Subscription | Pick the same Azure subscription in which you have enabled Azure AD 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 *AAD DC Computers* OU. |

-description: In this tutorial, learn how to join a Windows Server virtual machine to an Azure Active Directory Domain Services managed domain.

-#Customer intent: As an server administrator, I want to learn how to join a Windows Server VM to an Azure Active Directory Domain Services managed domain to provide centralized identity and policy.

-# Tutorial: Join a Windows Server virtual machine to an Azure Active Directory Domain Services managed domain

-Azure Active Directory Domain Services (Azure AD 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 an Azure AD 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.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

- * Make sure that Azure AD 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 Azure AD 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 Azure AD tenant - accounts from external directories associated with your Azure AD 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 Azure AD. 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 Azure AD 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 Azure AD DS.

-* Verify the VM is connected to the same virtual network that Azure AD DS is enabled in, or has a peered network connection.

-* Confirm that the account is part of the managed domain or Azure AD tenant. Accounts from external directories associated with your Azure AD 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 Azure AD updates the password in Azure AD DS. It takes some time for the password to be available for domain-join use.

-description: Learn how to install the DNS Server Tools to manage DNS and create conditional forwarders for an Azure Active Directory Domain Services managed domain.

-# Administer DNS and create conditional forwarders in an Azure Active Directory Domain Services managed domain

-Azure AD 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 Azure AD 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 Azure AD DS.

->Creating or changing root hints or server-level DNS forwarders is not supported and will cause issues for the Azure AD DS managed domain.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, complete the tutorial to [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

-* Connectivity from your Azure AD DS virtual network to where your other DNS namespaces are hosted.

-* A user account that's a member of the *Azure AD DC administrators* group in your Azure AD 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 Azure AD 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.

-An Azure AD 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

-description: Learn how to edit the built-in group policy objects (GPOs) and create your own custom policies in an Azure Active Directory Domain Services managed domain.

-# Administer Group Policy in an Azure Active Directory Domain Services managed domain

-Settings for user and computer objects in Azure Active Directory Domain Services (Azure AD DS) are often managed using Group Policy Objects (GPOs). Azure AD 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 *Azure AD DC administrators* group have Group Policy administration privileges in the Azure AD 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 Azure AD DS. To define configuration settings for users or computers in Azure AD DS, edit one of the default GPOs or create a custom GPO.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, complete the tutorial to [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

-* A Windows Server management VM that is joined to the Azure AD DS managed domain.

-* A user account that's a member of the *Azure AD DC administrators* group in your Azure AD 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 Azure AD 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).

-description: Learn what a mismatched directory error means and how to resolve it in Azure AD Domain Services

-# Resolve mismatched directory errors for existing Azure Active Directory Domain Services managed domains

-If an Azure Active Directory Domain Services (Azure AD 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 Azure AD directory.

-A mismatched directory error happens when an Azure AD DS managed domain and virtual network belong to two different Azure AD tenants. For example, you may have a managed domain called *aaddscontoso.com* that runs in Contoso's Azure AD tenant. However, the Azure virtual network for managed domain is part of the Fabrikam Azure AD tenant.

-Azure role-based access control (Azure RBAC) is used to limit access to resources. When you enable Azure AD DS in an Azure AD tenant, credential hashes are synchronized to the managed domain. This operation requires you to be a tenant admin for the Azure AD directory, and access to the credentials must be controlled.

-For Azure RBAC to work consistently and secure access to all the resources Azure AD DS uses, the managed domain and the virtual network must belong to the same Azure AD tenant.

-In the following example deployment scenario, the Contoso managed domain is enabled in the Contoso Azure AD tenant. The managed domain is deployed in a virtual network that belongs to an Azure subscription owned by the Contoso Azure AD tenant.

-Both the managed domain and the virtual network belong to the same Azure AD tenant. This example configuration is valid and fully supported.

-

-In this example deployment scenario, the Contoso managed domain is enabled in the Contoso Azure AD tenant. However, the managed domain is deployed in a virtual network that belongs to an Azure subscription owned by the Fabrikam Azure AD tenant.

-The managed domain and the virtual network belong to two different Azure AD tenants. This example configuration is a mismatched tenant and isn't supported. The virtual network must be moved to the same Azure AD tenant as the managed domain.

-* First, [delete the managed domain](delete-aadds.md) from your existing Azure AD directory. Then, [create a replacement managed domain](tutorial-create-instance.md) in the same Azure AD 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 Azure AD directory as the managed domain.

-For more information on troubleshooting issues with Azure AD DS, see the [troubleshooting guide](troubleshoot.md).

-description: Learn about some of the virtual network design considerations and resources used for connectivity when you run Azure Active Directory Domain Services.

-# Virtual network design considerations and configuration options for Azure Active Directory Domain Services

-Azure Active Directory Domain Services (Azure AD 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 Azure AD DS. Plan your virtual network requirements to make sure that Azure AD DS can serve your applications and workloads as needed.

-This article outlines design considerations and requirements for an Azure virtual network to support Azure AD DS.

-To provide network connectivity and allow applications and services to authenticate against an Azure AD 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 Azure AD DS virtual network, is usually the most appropriate design.

-As you design the virtual network for Azure AD DS, the following considerations apply:

-* Azure AD DS must be deployed into the same Azure region as your virtual network.

- * At this time, you can only deploy one managed domain per Azure AD tenant. The managed domain is deployed to single region. Make sure that you create or select a virtual network in a [region that supports Azure AD DS](https://azure.microsoft.com/global-infrastructure/services/?products=active-directory-ds&regions=all).

- * Azure AD 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 Azure AD 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 Azure AD DS with the following considerations:

-## Connections to the Azure AD 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 Azure AD 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.

-## Network resources used by Azure AD DS

-Don't lock the networking resources used by Azure AD 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 | Azure AD 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 | Azure AD 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 | Azure AD 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 | Azure AD 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 Azure AD DS, such as manually configuring the load balancer or rules. If you delete or modify any of the network resources, an Azure AD DS service outage may occur.

-Azure AD 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 Azure AD 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 Azure AD 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 Azure AD Domain Services management service. |

-| 443 | TCP | Any | AzureActiveDirectory | Allow | Yes | Communication with Azure Active Directory. |

-User-defined routes aren't created by default, and aren't needed for Azure AD 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 Azure AD DS and puts the managed domain in an unsupported state.

-For more information about some of the network resources and connection options used by Azure AD DS, see the following articles:

-description: Learn how to configure email notifications to alert you about issues in an Azure Active Directory Domain Services managed domain

-# Configure email notifications for issues in Azure Active Directory Domain Services

-The health of an Azure Active Directory Domain Services (Azure AD 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 Azure AD DS managed domain.

-Azure AD 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 [Azure AD DS health page][check-health].

-Azure AD DS doesn't send emails for advertisement, updates, or sales purposes.

-The list of email recipients for Azure AD 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 Azure AD directory and every member of the *AAD DC Administrators* group receive email notifications. Azure AD 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 **Azure AD Domain Services**.

-1. On the left-hand side of the Azure AD 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 Azure AD DS resource or be removed from the recipient list.

-description: In this overview, learn what Azure Active Directory 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 Azure AD DS is and how it can benefit my organization.

-# What is Azure Active Directory Domain Services?

-Azure Active Directory Domain Services (Azure AD 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.

-An Azure AD 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.

-Azure AD DS integrates with your existing Azure AD 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 an Azure AD DS managed domain using the Microsoft Entra admin center][tutorial-create]

-Take a look at our short video to learn more about Azure AD DS.

-## How does Azure AD DS work?

-When you create an Azure AD 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 Azure AD 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 Azure AD. 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, [Azure AD Connect][azure-ad-connect] synchronizes identity information with Azure AD, which is then synchronized to the managed domain.

-

-Azure AD DS replicates identity information from Azure AD, so it works with Azure AD tenants that are cloud-only, or synchronized with an on-premises AD DS environment. The same set of Azure AD 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 Azure AD DS.

-You can expand a managed domain to have more than one replica set per Azure AD tenant. Replica sets can be added to any peered virtual network in any Azure region that supports Azure AD 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 Azure AD DS integrates with your applications and workloads to provide identity services in the cloud:

-To see Azure AD DS deployment scenarios in action, you can explore the following examples:

-* [Azure AD DS for hybrid organizations](scenarios.md#azure-ad-ds-for-hybrid-organizations)

-* [Azure AD DS for cloud-only organizations](scenarios.md#azure-ad-ds-for-cloud-only-organizations)

-## Azure AD DS features and benefits

-To provide identity services to applications and VMs in the cloud, Azure AD 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 Azure AD.

-To learn more about your identity options, [compare Azure AD DS with Azure AD, AD DS on Azure VMs, and AD DS on-premises][compare].

-The following features of Azure AD DS simplify deployment and management operations:

-* **Simplified deployment experience:** Azure AD DS is enabled for your Azure AD tenant using a single wizard in the Microsoft Entra admin center.

-* **Integrated with Azure AD:** User accounts, group memberships, and credentials are automatically available from your Azure AD tenant. New users, groups, or changes to attributes from your Azure AD tenant or your on-premises AD DS environment are automatically synchronized to Azure AD DS.

- * Accounts in external directories linked to your Azure AD aren't available in Azure AD 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 Azure AD DS are the same as in your Azure AD 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:** Azure AD 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 Azure AD DS to an on-premises AD DS environment. For more information, see [Forest concepts and features for Azure AD 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 Azure AD via [Azure AD Connect][azure-ad-connect]. These user accounts, group memberships, and credentials are automatically available within the managed domain.

-To learn more about Azure AD DS compares with other identity solutions and how synchronization works, see the following articles:

-* [Compare Azure AD DS with Azure AD, Active Directory Domain Services on Azure VMs, and Active Directory Domain Services on-premises][compare]

-* [Learn how Azure AD Domain Services synchronizes with your Azure AD directory][synchronization]

-* To learn how to administrator a managed domain, see [management concepts for user accounts, passwords, and administration in Azure AD DS][administration-concepts].

-description: Learn how and why to use fine-grained password policies to secure and control account passwords in an Azure AD DS managed domain.

-# Password and account lockout policies on Azure Active Directory Domain Services managed domains

-To manage user security in Azure Active Directory Domain Services (Azure AD 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 an Azure AD 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 Azure AD DS using the Active Directory Administrative Center.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, complete the tutorial to [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

-* A user account that's a member of the *Azure AD DC administrators* group in your Azure AD 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 Azure AD DS:

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

- * The majority of user accounts in Azure AD DS are created through the synchronization process from Azure AD.

-* The user account can be manually created in a managed domain, and doesn't exist in Azure AD.

-All users, regardless of how they're created, have the following account lockout policies applied by the default password policy in Azure AD DS:

-Account lockouts only occur within the managed domain. User accounts are only locked out in Azure AD DS, and only due to failed sign-in attempts against the managed domain. User accounts that were synchronized in from Azure AD or on-premises aren't locked out in their source directories, only in Azure AD DS.

-If you have an Azure AD password policy that specifies a maximum password age greater than 90 days, that password age is applied to the default policy in Azure AD DS. You can configure a custom password policy to define a different maximum password age in Azure AD DS. Take care if you have a shorter maximum password age configured in an Azure AD DS password policy than in Azure AD or an on-premises AD DS environment. In that scenario, a user's password may expire in Azure AD DS before they're prompted to change in Azure AD 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 Azure AD, as a user can't update their password directly in Azure AD 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 Azure AD itself.

-[tutorial-create-management-vm]: tutorial-create-management-vm.md

-description: Lists Azure Policy built-in policy definitions for Azure Active Directory Domain Services. These built-in policy definitions provide common approaches to managing your Azure resources.

-# Azure Policy built-in definitions for Azure Active Directory Domain Services

-definitions for Azure Active Directory Domain Services. For additional Azure Policy built-ins for

-## Azure Active Directory Domain Services

-description: Learn how to configure and enable Azure Active Directory Domain Services using Azure AD PowerShell and Azure PowerShell.

-# Enable Azure Active Directory Domain Services using PowerShell

-Azure Active Directory Domain Services (Azure AD 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. Azure AD DS integrates with your existing Azure AD 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 Azure AD DS using PowerShell.

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

- * Make sure that you sign in to your Azure AD tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet.

-* You need *global administrator* privileges in your Azure AD tenant to enable Azure AD DS.

-* You need *Contributor* privileges in your Azure subscription to create the required Azure AD DS resources.

-## Create required Azure AD resources

-Azure AD DS requires a service principal to authenticate and communicate and an Azure AD group to define which users have administrative permissions in the managed domain.

-First, create an Azure AD 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 an Azure AD service principal using the [New-AzureADServicePrincipal][New-AzureADServicePrincipal] cmdlet:

-Now create an Azure AD 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 Azure AD Domain Services resource provider using the [Register-AzResourceProvider][Register-AzResourceProvider] cmdlet:

-Create the virtual network and subnets for Azure AD Domain Services. Two subnets are created - one for *DomainServices*, and one for *Workloads*. Azure AD 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.

-Azure AD 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 Azure AD 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 Azure AD DS resources are distributed across zones for redundancy.

-There's nothing for you to configure for Azure AD 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 Azure AD 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 Azure AD DS, you must be a global administrator for the Azure AD tenant. You also need at least *Contributor* privileges in the Azure subscription.

-* [Enable password synchronization to Azure AD 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.

-description: Learn how to use Azure AD PowerShell to configure scoped synchronization from Azure AD to an Azure Active Directory Domain Services managed domain

-# Configure scoped synchronization from Azure AD to Azure Active Directory Domain Services using Azure AD PowerShell

-To provide authentication services, Azure Active Directory Domain Services (Azure AD DS) synchronizes users and groups from Azure AD. In a hybrid environment, users and groups from an on-premises Active Directory Domain Services (AD DS) environment can be first synchronized to Azure AD using Azure AD Connect, and then synchronized to Azure AD DS.

-By default, all users and groups from an Azure AD directory are synchronized to an Azure AD DS managed domain. If you have specific needs, you can instead choose to synchronize only a defined set of users.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, complete the tutorial to [create and configure an Azure Active Directory 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) Azure AD roles in your tenant to change the Azure AD DS synchronization scope.

-By default, all users and groups from an Azure AD 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 Azure AD Domain Services][concepts-sync].

-This script configures Azure AD DS to synchronize selected groups from Azure AD. All user accounts that are part of the specified groups are synchronized to the managed domain.

-1. First set *"filteredSync" = "Enabled"* on the Azure AD DS resource, then update the managed domain.

- When prompted, specify the credentials for a *global admin* to sign in to your Azure AD tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet:

-When prompted, specify the credentials for a *global admin* to sign in to your Azure AD tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet:

-To disable group-based scoped synchronization for a managed domain, set *"filteredSync" = "Disabled"* on the Azure AD DS resource, then update the managed domain. When complete, all users and groups are set to synchronize from Azure AD.

-When prompted, specify the credentials for a *global admin* to sign in to your Azure AD tenant using the [Connect-AzureAD][Connect-AzureAD] cmdlet:

-To learn more about the synchronization process, see [Understand synchronization in Azure AD Domain Services](synchronization.md).

-description: Learn about some of the common scenarios and use-cases for Azure Active Directory Domain Services to provide value and meet business needs.

-# Common use-cases and scenarios for Azure Active Directory Domain Services

-Azure Active Directory Domain Services (Azure AD DS) provides managed domain services such as domain join, group policy, lightweight directory access protocol (LDAP), and Kerberos / NTLM authentication. Azure AD DS integrates with your existing Azure AD 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 Azure AD DS provides value and meets those needs.

-Azure AD DS 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, Azure AD DS reduces the complexity to create an integrated identity solution for both hybrid and cloud-only environments.

-> [Compare Azure AD DS with Azure AD and self-managed AD DS on Azure VMs or on-premises][compare]

-## Azure AD DS 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 an Azure AD tenant. Azure AD DS 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 Azure AD tenant, Litware Corporation deploys [Azure AD Connect][azure-ad-connect].

-* Litware's IT team enables Azure AD DS for their Azure AD tenant in this, or a peered, virtual network.

-* Applications and VMs deployed in the Azure virtual network can then use Azure AD DS features like domain join, LDAP read, LDAP bind, NTLM and Kerberos authentication, and Group Policy.

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

-## Azure AD DS for cloud-only organizations

-A cloud-only Azure AD tenant doesn't have an on-premises identity source. User accounts and group memberships, for example, are created and managed directly in Azure AD.

-Now let's look at an example for Contoso, a cloud-only organization that uses Azure AD for identity. All user identities, their credentials, and group memberships are created and managed in Azure AD. There is no additional configuration of Azure AD Connect to synchronize any identity information from an on-premises directory.

-

-* Contoso's IT team enables Azure AD DS for their Azure AD tenant in this, or a peered, virtual network.

-* Applications and VMs deployed in the Azure virtual network can then use Azure AD DS 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 an Azure AD DS managed domain. This approach reduces credential management issues such as maintaining local administrator accounts on each VM or separate accounts and passwords between environments.

-Azure AD DS 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.

-* Azure AD DS 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.

-* Azure AD DS supports the base AD computer object schema. You can't extend the computer object's schema.

-For this scenario, Azure AD DS 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 [Azure AD's 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, Azure AD DS 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 Azure AD DS.

-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, Azure AD DS 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 Azure AD 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 Azure AD using Azure AD Connect.

-* Make sure that the applications use a username and password for authentication. Certificate or smartcard-based authentication isn't supported by Azure AD DS.

-* You can't change passwords directly against a managed domain. End users can change their password either using [Azure AD's 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 Azure AD DS to provide managed domain services to remote desktop servers deployed in Azure.

-For more information about this deployment scenario, see [how to integrate Azure AD Domain Services with your RDS deployment][windows-rds].

-To get started, [Create and configure an Azure Active Directory Domain Services managed domain][tutorial-create-instance].

-[windows-rds]: /windows-server/remote/remote-desktop-services/rds-azure-adds

-description: Learn how to use the Microsoft Entra admin center to configure scoped synchronization from Azure AD to an Azure Active Directory Domain Services managed domain

-# Configure scoped synchronization from Azure AD to Azure Active Directory Domain Services using the Microsoft Entra admin center

-To provide authentication services, Azure Active Directory Domain Services (Azure AD DS) synchronizes users and groups from Azure AD. In a hybrid environment, users and groups from an on-premises Active Directory Domain Services (AD DS) environment can be first synchronized to Azure AD using Azure AD Connect, and then synchronized to an Azure AD DS managed domain.

-By default, all users and groups from an Azure AD directory are synchronized to a managed domain. If only some users need to use Azure AD DS, you can instead choose to synchronize only groups of users. You can filter synchronization for groups on-premises, cloud only, or both.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, complete the tutorial to [create and configure an Azure Active Directory 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) Azure AD roles in your tenant to change the Azure AD DS synchronization scope.

-By default, all users and groups from an Azure AD directory are synchronized to a managed domain. You can scope synchronization to only user accounts that were created in Azure AD, or synchronize all users.

-To learn more about the synchronization process, see [Understand synchronization in Azure AD Domain Services][concepts-sync].

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Azure AD 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 Azure AD. Only users who belong to those groups will have their accounts synchronized to Azure AD DS.

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Azure AD 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 **Azure AD Domain Services**. Choose your managed domain, such as *aaddscontoso.com*.

-To learn more about the synchronization process, see [Understand synchronization in Azure AD Domain Services][concepts-sync].

-description: Learn how to secure remote access to VMs using Network Policy Server (NPS) and Azure AD Multi-Factor Authentication with a Remote Desktop Services deployment in an Azure Active Directory Domain Services managed domain.

-# Secure remote access to virtual machines in Azure Active Directory Domain Services

-To secure remote access to virtual machines (VMs) that run in an Azure Active Directory Domain Services (Azure AD DS) managed domain, you can use Remote Desktop Services (RDS) and Network Policy Server (NPS). Azure AD DS authenticates users as they request access through the RDS environment. For enhanced security, you can integrate Azure AD Multi-Factor Authentication to provide an additional authentication prompt during sign-in events. Azure AD Multi-Factor Authentication uses an extension for NPS to provide this feature.

-> The recommended way to securely connect to your VMs in an Azure AD 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 Azure AD DS where all incoming RDP traffic is allowed.

-This article shows you how to configure RDS in Azure AD DS and optionally use the Azure AD Multi-Factor Authentication NPS extension.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

-* A *workloads* subnet created in your Azure Active Directory Domain Services virtual network.

- * If needed, [Configure virtual networking for an Azure Active Directory Domain Services managed domain][configure-azureadds-vnet].

-* A user account that's a member of the *Azure AD DC administrators* group in your Azure AD tenant.

-Make sure that VMs are deployed into a *workloads* subnet of your Azure AD 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 *Azure AD DC Administrators* group, such as *contosoadmin*.

- * Specific to Azure AD DS - when you configure RD licensing, set it to **Per Device** mode, not **Per User** as noted in the deployment guide.

-## Deploy and configure NPS and the Azure AD MFA NPS extension

-If you want to increase the security of the user sign-in experience, you can optionally integrate the RD environment with Azure AD Multi-Factor 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 Azure AD Multi-Factor Authentication NPS extension. This extension integrates with Azure AD to request and return the status of multi-factor authentication prompts.

-Users must be [registered to use Azure AD Multi-Factor Authentication][user-mfa-registration], which may require additional Azure AD licenses.

-To integrate Azure AD Multi-Factor Authentication in to your Azure AD 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 Azure AD DS virtual network. Join the VM to the managed domain.

-1. Sign in to NPS VM as account that's part of the *Azure AD DC Administrators* group, such as *contosoadmin*.

-1. Use the existing how-to article to [install and configure the Azure AD MFA NPS extension][nps-extension].

-With the NPS server and Azure AD Multi-Factor Authentication NPS extension installed, complete the next section to configure it for use with the RD environment.

-## Integrate Remote Desktop Gateway and Azure AD Multi-Factor Authentication

-To integrate the Azure AD Multi-Factor Authentication NPS extension, use the existing how-to article to [integrate your Remote Desktop Gateway infrastructure using the Network Policy Server (NPS) extension and Azure AD][azure-mfa-nps-integration].

-1. If you use Windows Server 2019 for the NPS server and Azure AD Multi-Factor 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: Azure AD Multi-Factor Authentication][concepts-mfa].

-[rds-high-availability]: /windows-server/remote/remote-desktop-services/rds-plan-high-availability

-description: Learn how to disable weak ciphers, old protocols, and NTLM password hash synchronization for an Azure Active Directory Domain Services managed domain.

-# Harden an Azure Active Directory Domain Services managed domain

-By default, Azure Active Directory Domain Services (Azure AD 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 Azure AD Connect, you can also disable the synchronization of NTLM password hashes.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

-1. Search for and select **Azure AD Domain Services**.

-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 Azure Active Directory 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 Azure AD 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 Azure AD 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 Azure AD 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 Azure AD 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 Azure AD 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.

-description: Learn how to enable security audits to centralize the logging of events for analysis and alerts in Azure AD Domain Services

-# Enable security and DNS audits for Azure Active Directory Domain Services

-Azure Active Directory Domain Services (Azure AD 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, Azure AD 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 Azure AD 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 Azure AD 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 Azure AD 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 Azure AD 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 Azure AD DS security audit events, [Create a Log Analytics workspace in the Microsoft Entra admin center.](../azure-monitor/logs/quick-create-workspace.md)|

-To enable Azure AD DS security audit events using the Microsoft Entra admin center, complete the following steps.

-> Azure AD DS security audits aren't retroactive. You can't retrieve or replay events from the past. Azure AD DS can only send events that occur after security audits are enabled.

-1. Search for and select **Azure AD Domain Services**. Choose your managed domain, such as *aaddscontoso.com*.

-1. In the Azure AD DS window, select **Diagnostic settings** on the left-hand side.

- 

-1. When done, select **Save** to commit your changes. The target resources start to receive Azure AD DS audit events soon after the configuration is saved.

-To enable Azure AD DS security and DNS audit events using Azure PowerShell, complete the following steps. If needed, first [install the Azure PowerShell module and connect to your Azure subscription](/powershell/azure/install-azure-powershell).

-> Azure AD DS audits aren't retroactive. You can't retrieve or replay events from the past. Azure AD DS can only send events that occur after audits are enabled.

- * **Azure event hubs** - [Create an event hub using Azure PowerShell](../event-hubs/event-hubs-quickstart-powershell.md). You may also need to use the [New-AzEventHubAuthorizationRule](/powershell/module/az.eventhub/new-azeventhubauthorizationrule) cmdlet to create an authorization rule that grants Azure AD DS permissions to the event hub *namespace*. The authorization rule must include the **Manage**, **Listen**, and **Send** rights.

-1. Get the resource ID for your Azure AD DS managed domain using the [Get-AzResource](/powershell/module/Az.Resources/Get-AzResource) cmdlet. Create a variable named *$aadds.ResourceId* to hold the value:

-1. Configure the Azure Diagnostic settings using the [Set-AzDiagnosticSetting](/powershell/module/Az.Monitor/Set-AzDiagnosticSetting) cmdlet to use the target resource for Azure AD Domain Services audit events. In the following examples, the variable *$aadds.ResourceId* is used from the previous step.

-The following sample queries can be used to start analyzing audit events from Azure AD DS.

-Azure AD DS security and DNS audits align with traditional auditing for traditional AD DS domain controllers. In hybrid environments, you can reuse existing audit patterns so the same logic may be used when analyzing the events. Depending on the scenario you need to troubleshoot or analyze, the different audit event categories need to be targeted.

- Azure AD DS security and DNS audits record the following event IDs when the specific action triggers an auditable event:

-description: Learn about the different health states for an Azure AD DS managed domain and how to restore a suspended domain.

-# Understand the health states and resolve suspended domains in Azure Active Directory Domain Services

-When Azure Active Directory Domain Services (Azure AD DS) is unable to service a managed domain for a long period of time, it puts the managed domain into a suspended state. If a managed domain remains in a suspended state, it's automatically deleted. To keep your Azure AD DS managed domain healthy and avoid suspension, resolve any alerts as quickly as you can.

-* Changes from Azure Active Directory are regularly synchronized to the managed domain.

-* Changes from Azure Active Directory may not be synchronized to the managed domain.

- * Critical alerts can be caused by a misconfiguration that blocks access to resources that are needed by Azure AD DS. For example, the alert [AADDS104: Network Error][alert-nsg] has been unresolved for more than 15 days in the managed domain.

-* Synchronization with Azure AD stops.

-You see an [alert][resolve-alerts] on the Azure AD DS Health page in the Microsoft Entra admin center that notes the domain is suspended. The state of the domain also shows *Suspended*.

-* You can't restore the managed domain. You must create a replacement managed domain to reuse Azure AD DS.

-description: Learn how the synchronization process works for objects and credentials from an Azure AD tenant or on-premises Active Directory Domain Services environment to an Azure Active Directory Domain Services managed domain.

-# How objects and credentials are synchronized in an Azure Active Directory Domain Services managed domain

-Objects and credentials in an Azure Active Directory Domain Services (Azure AD DS) managed domain can either be created locally within the domain, or synchronized from an Azure Active Directory (Azure AD) tenant. When you first deploy Azure AD DS, an automatic one-way synchronization is configured and started to replicate the objects from Azure AD. This one-way synchronization continues to run in the background to keep the Azure AD DS managed domain up-to-date with any changes from Azure AD. No synchronization occurs from Azure AD DS back to Azure AD.

-In a hybrid environment, objects and credentials from an on-premises AD DS domain can be synchronized to Azure AD using Azure AD Connect. Once those objects are successfully synchronized to Azure AD, the automatic background sync then makes those objects and credentials available to applications using the managed domain.

-The following diagram illustrates how synchronization works between Azure AD DS, Azure AD, and an optional on-premises AD DS environment:

-

-## Synchronization from Azure AD to Azure AD DS

-User accounts, group memberships, and credential hashes are synchronized one way from Azure AD to Azure AD DS. This synchronization process is automatic. You don't need to configure, monitor, or manage this synchronization process. The initial synchronization may take a few hours to a couple of days, depending on the number of objects in the Azure AD directory. After the initial synchronization is complete, changes that are made in Azure AD, such as password or attribute changes, are then automatically synchronized to Azure AD DS.

-When a user is created in Azure AD, they're not synchronized to Azure AD DS until they change their password in Azure AD. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. The password hashes are needed to successfully authenticate a user in Azure AD DS.

-The synchronization process is one-way by design. There's no reverse synchronization of changes from Azure AD DS back to Azure AD. A managed domain is largely read-only except for custom OUs that you can create. You can't make changes to user attributes, user passwords, or group memberships within a managed domain.

-## Attribute synchronization and mapping to Azure AD DS

-The following table lists some common attributes and how they're synchronized to Azure AD DS.

-| Attribute in Azure AD DS | Source | Notes |

-| UPN | User's *UPN* attribute in Azure AD tenant | The UPN attribute from the Azure AD tenant is synchronized as-is to Azure AD DS. The most reliable way to sign in to a managed domain is using the UPN. |

-| SAMAccountName | User's *mailNickname* attribute in Azure AD tenant or autogenerated | The *SAMAccountName* attribute is sourced from the *mailNickname* attribute in the Azure AD tenant. If multiple user accounts have the same *mailNickname* attribute, the *SAMAccountName* is autogenerated. If the user's *mailNickname* or *UPN* prefix is longer than 20 characters, the *SAMAccountName* is autogenerated to meet the 20 character limit on *SAMAccountName* attributes. |

-| Passwords | User's password from the Azure AD tenant | Legacy password hashes required for NTLM or Kerberos authentication are synchronized from the Azure AD tenant. If the Azure AD tenant is configured for hybrid synchronization using Azure AD Connect, these password hashes are sourced from the on-premises AD DS environment. |

-| Primary user/group SID | Autogenerated | The primary SID for user/group accounts is autogenerated in Azure AD DS. This attribute doesn't match the primary user/group SID of the object in an on-premises AD DS environment. This mismatch is because the managed domain has a different SID namespace than the on-premises AD DS domain. |

-| SID history for users and groups | On-premises primary user and group SID | The *SidHistory* attribute for users and groups in Azure AD DS is set to match the corresponding primary user or group SID in an on-premises AD DS environment. This feature helps make lift-and-shift of on-premises applications to Azure AD DS easier as you don't need to re-ACL resources. |

-The following table illustrates how specific attributes for user objects in Azure AD are synchronized to corresponding attributes in Azure AD DS.

-| User attribute in Azure AD | User attribute in Azure AD DS |

-The following table illustrates how specific attributes for group objects in Azure AD are synchronized to corresponding attributes in Azure AD DS.

-| Group attribute in Azure AD | Group attribute in Azure AD DS |

-## Synchronization from on-premises AD DS to Azure AD and Azure AD DS

-Azure AD Connect is used to synchronize user accounts, group memberships, and credential hashes from an on-premises AD DS environment to Azure AD. Attributes of user accounts such as the UPN and on-premises security identifier (SID) are synchronized. To sign in using Azure AD DS, legacy password hashes required for NTLM and Kerberos authentication are also synchronized to Azure AD.

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

-If you configure writeback, changes from Azure AD are synchronized back to the on-premises AD DS environment. For example, if a user changes their password using Azure AD self-service password management, the password is updated back in the on-premises AD DS environment.

-> Always use the latest version of Azure AD Connect to ensure you have fixes for all known bugs.

-Many organizations have a fairly complex on-premises AD DS environment that includes multiple forests. Azure AD Connect supports synchronizing users, groups, and credential hashes from multi-forest environments to Azure AD.

-Azure AD has a much simpler and flat namespace. To enable users to reliably access applications secured by Azure AD, resolve UPN conflicts across user accounts in different forests. Managed domains use a flat OU structure, similar to Azure AD. All user accounts and groups are stored in the *AADDC Users* container, despite being synchronized from different on-premises domains or forests, even if you've configured a hierarchical OU structure on-premises. The managed domain flattens any hierarchical OU structures.

-As previously detailed, there's no synchronization from Azure AD DS back to Azure AD. You can [create a custom Organizational Unit (OU)](create-ou.md) in Azure AD DS and then users, groups, or service accounts within those custom OUs. None of the objects created in custom OUs are synchronized back to Azure AD. These objects are available only within the managed domain, and aren't visible using Azure AD PowerShell cmdlets, Microsoft Graph API, or using the Azure AD management UI.

-## What isn't synchronized to Azure AD DS

-The following objects or attributes aren't synchronized from an on-premises AD DS environment to Azure AD or Azure AD DS:

-* **Excluded attributes:** You can choose to exclude certain attributes from synchronizing to Azure AD from an on-premises AD DS environment using Azure AD Connect. These excluded attributes aren't then available in Azure AD DS.

-* **Group Policies:** Group Policies configured in an on-premises AD DS environment aren't synchronized to Azure AD DS.

-* **Sysvol folder:** The contents of the *Sysvol* folder in an on-premises AD DS environment aren't synchronized to Azure AD DS.

-* **Computer objects:** Computer objects for computers joined to an on-premises AD DS environment aren't synchronized to Azure AD DS. These computers don't have a trust relationship with the managed domain and only belong to the on-premises AD DS environment. In Azure AD DS, only computer objects for computers that have explicitly domain-joined to the managed domain are shown.

-* **SidHistory attributes for users and groups:** The primary user and primary group SIDs from an on-premises AD DS environment are synchronized to Azure AD DS. However, existing *SidHistory* attributes for users and groups aren't synchronized from the on-premises AD DS environment to Azure AD DS.

-* **Organization Units (OU) structures:** Organizational Units defined in an on-premises AD DS environment don't synchronize to Azure AD DS. There are two built-in OUs in Azure AD DS - one for users, and one for computers. The managed domain has a flat OU structure. You can choose to [create a custom OU in your managed domain](create-ou.md).

-When you enable Azure AD DS, legacy password hashes for NTLM and Kerberos authentication are required. Azure AD doesn't store clear-text passwords, so these hashes can't be automatically generated for existing user accounts. NTLM and Kerberos compatible password hashes are always stored in an encrypted manner in Azure AD.

-The encryption keys are unique to each Azure AD tenant. These hashes are encrypted such that only Azure AD DS has access to the decryption keys. No other service or component in Azure AD has access to the decryption keys.

-Legacy password hashes are then synchronized from Azure AD into the domain controllers for a managed domain. The disks for these managed domain controllers in Azure AD DS are encrypted at rest. These password hashes are stored and secured on these domain controllers similar to how passwords are stored and secured in an on-premises AD DS environment.

-For cloud-only Azure AD environments, [users must reset/change their password](tutorial-create-instance.md#enable-user-accounts-for-azure-ad-ds) in order for the required password hashes to be generated and stored in Azure AD. For any cloud user account created in Azure AD after enabling Azure AD Domain Services, the password hashes are generated and stored in the NTLM and Kerberos compatible formats. All cloud user accounts must change their password before they're synchronized to Azure AD DS.

-For hybrid user accounts synced from on-premises AD DS environment using Azure AD Connect, you must [configure Azure AD Connect to synchronize password hashes in the NTLM and Kerberos compatible formats](tutorial-configure-password-hash-sync.md).

-For more information on the specifics of password synchronization, see [How password hash synchronization works with Azure AD Connect](../active-directory/hybrid/how-to-connect-password-hash-synchronization.md?context=/azure/active-directory-domain-services/context/azure-ad-ds-context).

-To get started with Azure AD DS, [create a managed domain](tutorial-create-instance.md).

-description: Learn how to configure and enable Azure Active Directory Domain Services using an Azure Resource Manager template

-# Create an Azure Active Directory Domain Services managed domain using an Azure Resource Manager template

-Azure Active Directory Domain Services (Azure AD 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. Azure AD DS integrates with your existing Azure AD 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.

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

- * Make sure that you sign in to your Azure AD 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) Azure AD roles in your tenant to enable Azure AD DS.

-* You need Domain Services Contributor Azure role to create the required Azure AD DS resources.

-When you create an Azure AD DS managed domain, you specify a DNS name. There are some considerations when you choose this DNS name:

-## Create required Azure AD resources

-Azure AD DS requires a service principal and an Azure AD group. These resources let the managed domain synchronize data, and define which users have administrative permissions in the managed domain.

-First, register the Azure AD Domain Services resource provider using the [Register-AzResourceProvider][Register-AzResourceProvider] cmdlet:

-Create an Azure AD service principal using the [New-AzureADServicePrincipal][New-AzureADServicePrincipal] cmdlet for Azure AD DS to communicate and authenticate itself. A specific application ID is used named *Domain Controller Services* with an ID of *2565bd9d-da50-47d4-8b85-4c97f669dc36* for Azure Global. For other Azure clouds, search for AppId value *6ba9a5d4-8456-4118-b521-9c5ca10cdf84*.

-Now create an Azure AD group named *AAD DC Administrators* using the [New-AzureADGroup][New-AzureADGroup] cmdlet. Users added to this group are then granted permissions to perform administration tasks on the managed domain.

-If you choose a region that supports Availability Zones, the Azure AD DS resources are distributed across zones for additional redundancy. Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. To ensure resiliency, there's a minimum of three separate zones in all enabled regions.

-There's nothing for you to configure for Azure AD 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].

-## Resource definition for Azure AD DS

-| filteredSync | Azure AD DS lets you synchronize *all* users and groups available in Azure AD, or a *scoped* synchronization of only specific groups.<br /><br /> For more information about scoped synchronization, see [Azure AD Domain Services scoped synchronization][scoped-sync].|

-| domainConfigurationType | By default, a managed domain is created as a *User* forest. This type of forest synchronizes all objects from Azure AD, including any user accounts created in an on-premises AD DS environment. You don't need to specify a *domainConfiguration* value to create a user forest.<br /><br /> A *Resource* forest only synchronizes users and groups created directly in Azure AD. Set the value to *ResourceTrusting* to create a resource forest.<br /><br />For more information on *Resource* forests, including why you may use one and how to create forest trusts with on-premises AD DS domains, see [Azure AD DS resource forests overview][resource-forests].|

-The following complete Resource Manager sample template creates a managed domain and the supporting virtual network, subnet, and network security group rules. The network security group rules are required to secure the managed domain and make sure traffic can flow correctly. A user forest with the DNS name of *aaddscontoso.com* is created, with all users synchronized from Azure AD:

-* [Enable password synchronization to Azure AD 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.

-description: Learn how to troubleshoot common problems that cause user accounts to be locked out in Azure Active Directory Domain Services.

-#Customer intent: As a directory administrator, I want to troubleshoot why user accounts are locked out in an Azure Active Directory Domain Services managed domain.

-# Troubleshoot account lockout problems with an Azure Active Directory Domain Services managed domain

-To prevent repeated malicious sign-in attempts, an Azure Active Directory Domain Services (Azure AD DS) managed domain locks accounts after a defined threshold. This account lockout can also happen by accident without a sign-in attack incident. For example, if a user repeatedly enters the wrong password or a service attempts to use an old password, the account gets locked out.

-A user account in an Azure AD DS managed domain is locked out when a defined threshold for unsuccessful sign-in attempts has been met. This account lockout behavior is designed to protect you from repeated brute-force sign-in attempts that may indicate an automated digital attack.

-Fine-grained password policies (FGPPs) let you apply specific restrictions for password and account lockout policies to different users in a domain. FGPP only affects users within a managed domain. Cloud users and domain users synchronized into the managed domain from Azure AD are only affected by the password policies within the managed domain. Their accounts in Azure AD or an on-premises directory aren't impacted.

-For more information on fine-grained password policies, and the differences between users created directly in Azure AD DS versus synchronized in from Azure AD, see [Configure password and account lockout policies][configure-fgpp].

- * If an account password is changed outside of the managed domain, such as in an on-prem AD DS environment, it can take a few minutes for the password change to synchronize through Azure AD and into the managed domain.

-To troubleshoot when account lockout events occur and where they're coming from, [enable security audits for Azure AD DS][security-audit-events]. Audit events are only captured from the time you enable the feature. Ideally, you should enable security audits *before* there's an account lockout issue to troubleshoot. If a user account repeatedly has lockout issues, you can enable security audits ready for the next time the situation occurs.

-For example, a RADIUS server can forward the authentication to Azure AD DS.

-If you still have problems joining your VM to the managed domain, [find help and open a support ticket for Azure Active Directory][azure-ad-support].

-description: Learn how to resolve common alerts generated as part of the health status for Azure Active Directory Domain Services

-# Known issues: Common alerts and resolutions in Azure Active Directory Domain Services

-As a central part of identity and authentication for applications, Azure Active Directory Domain Services (Azure AD DS) sometimes has problems. If you run into issues, there are some common alerts and associated troubleshooting steps to help you get things running again. At any time, you can also [open an Azure support request][azure-support] for additional troubleshooting assistance.

-This article provides troubleshooting information for common alerts in Azure AD DS.

-*The Azure AD directory associated with your managed domain may have been deleted. The managed domain is no longer in a supported configuration. Microsoft cannot monitor, manage, patch, and synchronize your managed domain.*

-This error is usually caused when an Azure subscription is moved to a new Azure AD directory and the old Azure AD directory that's associated with Azure AD DS is deleted.

-*Azure AD Domain Services cannot be enabled in an Azure AD B2C Directory.*

-Azure AD DS automatically synchronizes with an Azure AD directory. If the Azure AD directory is configured for B2C, Azure AD DS can't be deployed and synchronized.

-To use Azure AD DS, you must recreate your managed domain in a non-Azure AD B2C directory using the following steps:

-1. [Delete the managed domain](delete-aadds.md) from your existing Azure AD directory.

-1. Create a new Azure AD directory that isn't an Azure AD B2C directory.

-*The IP address range for the virtual network in which you have enabled Azure AD Domain Services is in a public IP range. Azure AD Domain Services must be enabled in a virtual network with a private IP address range. This configuration impacts Microsoft's ability to monitor, manage, patch, and synchronize your managed domain.*

-Inside a virtual network, VMs can make requests to Azure resources in the same IP address range as configured for the subnet. If you configure a public IP address range for a subnet, requests routed within a virtual network may not reach the intended web resources. This configuration can lead to unpredictable errors with Azure AD DS.

-> If you own the IP address range in the internet that is configured in your virtual network, this alert can be ignored. However, Azure AD Domain Services can't commit to the [SLA](https://azure.microsoft.com/support/legal/sla/active-directory-ds/v1_0/) with this configuration since it can lead to unpredictable errors.

-1. To update the virtual network IP address range, search for and select *Virtual network* in the Microsoft Entra admin center. Select the virtual network for Azure AD DS that incorrectly has a public IP address range set.

-*Your Azure subscription associated with your managed domain has been deleted. Azure AD Domain Services requires an active subscription to continue functioning properly.*

-Azure AD DS requires an active subscription, and can't be moved to a different subscription. If the Azure subscription that the managed domain was associated with is deleted, you must recreate an Azure subscription and managed domain.

-1. [Delete the managed domain](delete-aadds.md) from your existing Azure AD directory.

-*Your Azure subscription associated with your managed domain is not active. Azure AD Domain Services requires an active subscription to continue functioning properly.*

-Azure AD DS requires an active subscription. If the Azure subscription that the managed domain was associated with isn't active, you must renew it to reactivate the subscription.

-2. Once the subscription is renewed, an Azure AD DS notification lets you re-enable the managed domain.

-*The subscription used by Azure AD Domain Services has been moved to another directory. Azure AD Domain Services needs to have an active subscription in the same directory to function properly.*

-Azure AD DS requires an active subscription, and can't be moved to a different subscription. If the Azure subscription that the managed domain was associated with is moved, move the subscription back to the previous directory, or [delete your managed domain](delete-aadds.md) from the existing directory and [create a replacement managed domain in the chosen subscription](tutorial-create-instance.md).

-*A resource that is used for your managed domain has been deleted. This resource is needed for Azure AD Domain Services to function properly.*

-Azure AD DS creates additional resources to function properly, such as public IP addresses, virtual network interfaces, and a load balancer. If any of these resources are deleted, the managed domain is in an unsupported state and prevents the domain from being managed. For more information on these resources, see [Network resources used by Azure AD DS](network-considerations.md#network-resources-used-by-azure-ad-ds).

-*The subnet selected for deployment of Azure AD Domain Services is full, and does not have space for the additional domain controller that needs to be created.*

-The virtual network subnet for Azure AD DS needs sufficient IP addresses for the automatically created resources. This IP address space includes the need to create replacement resources if there's a maintenance event. To minimize the risk of running out of available IP addresses, don't deploy additional resources, such as your own VMs, into the same virtual network subnet as the managed domain.

-*A service principal that Azure AD Domain Services uses to service your domain is not authorized to manage resources on the Azure subscription. The service principal needs to gain permissions to service your managed domain.*

-*We have identified that the subnet of the virtual network in this domain may not have enough IP addresses. Azure AD Domain Services needs at-least two available IP addresses within the subnet it is enabled in. We recommend having at-least 3-5 spare IP addresses within the subnet. This may have occurred if other virtual machines are deployed within the subnet, thus exhausting the number of available IP addresses or if there is a restriction on the number of available IP addresses in the subnet.*

-The virtual network subnet for Azure AD DS needs enough IP addresses for the automatically created resources. This IP address space includes the need to create replacement resources if there's a maintenance event. To minimize the risk of running out of available IP addresses, don't deploy additional resources, such as your own VMs, into the same virtual network subnet as the managed domain.

-*The resources used by Azure AD Domain Services were detected in an unexpected state and cannot be recovered.*

-Azure AD DS creates additional resources to function properly, such as public IP addresses, virtual network interfaces, and a load balancer. If any of these resources are modified, the managed domain is in an unsupported state and can't be managed. For more information about these resources, see [Network resources used by Azure AD DS](network-considerations.md#network-resources-used-by-azure-ad-ds).

-This alert is generated when one of these required resources is modified and can't automatically be recovered by Azure AD DS. To resolve the alert, [open an Azure support request][azure-support] to fix the instance.

-*The subnet selected for deployment of Azure AD Domain Services is invalid, and cannot be used.*

-Resource locks can be applied to Azure resources to prevent change or deletion. As Azure AD DS is a managed service, the Azure platform needs the ability to make configuration changes. If a resource lock is applied on some of the Azure AD DS components, the Azure platform can't perform its management tasks.

-To check for resource locks on the Azure AD DS components and remove them, complete the following steps:

-Policies are applied to Azure resources and resource groups that control what configuration actions are allowed. As Azure AD DS is a managed service, the Azure platform needs the ability to make configuration changes. If a policy is applied on some of the Azure AD DS components, the Azure platform may not be able to perform its management tasks.

-To check for applied policies on the Azure AD DS components and update them, complete the following steps:

-*The following Azure AD extension properties have not successfully onboarded as a custom attribute for synchronization. This may happen if a property conflicts with the built-in schema: \[extensions]*

-Review the [Azure AD DS Health](check-health.md) alert and see which Azure AD extension properties failed to onboard successfully. Navigate to the **Custom Attributes** page to find the expected Azure AD DS LDAPName of the extension. Make sure the LDAPName doesn't conflict with another AD schema attribute, or that it's one of the allowed built-in AD attributes.

-Upon successful onboarding, Azure AD DS will back fill synchronized users and groups with the onboarded custom attribute values. The custom attribute values appear gradually, depending on the size of the tenant. To check the backfill status, go to [Azure AD DS Health](check-health.md) and verify the **Synchronization with Azure AD** monitor timestamp has updated within the last hour.

-*The managed domain was last synchronized with Azure AD on [date]. Users may be unable to sign-in on the managed domain or group memberships may not be in sync with Azure AD.*

-[Check the Azure AD DS health](check-health.md) for any alerts that indicate problems in the configuration of the managed domain. Problems with the network configuration can block the synchronization from Azure AD. If you're able to resolve alerts that indicate a configuration issue, wait two hours and check back to see if the synchronization has successfully completed.

-* Required network connectivity is blocked. To learn more about how to check the Azure virtual network for problems and what's required, see [troubleshoot network security groups](alert-nsg.md) and the [network requirements for Azure AD DS](network-considerations.md).

-[Check the Azure AD DS health](check-health.md) for alerts that indicate problems in the configuration of the managed domain. Problems with the network configuration can block the Azure platform from successfully taking backups. If you're able to resolve alerts that indicate a configuration issue, wait two hours and check back to see if the synchronization has successfully completed.

-> If a managed domain is suspended for an extended period of time, there's a danger of it being deleted. Resolve the reason for suspension as quickly as possible. For more information, see [Understand the suspended states for Azure AD DS](suspension.md).

-Azure AD DS requires an active subscription. If the Azure subscription that the managed domain was associated with isn't active, you must renew it to reactivate the subscription.

-2. Once the subscription is renewed, an Azure AD DS notification lets you re-enable the managed domain.

-> If a managed domain is suspended for an extended period of time, there's a danger of it being deleted. Resolve the reason for suspension as quickly as possible. For more information, see [Understand the suspended states for Azure AD DS](suspension.md).

-[Check the Azure AD DS health](check-health.md) for alerts that indicate problems in the configuration of the managed domain. If you're able to resolve alerts that indicate a configuration issue, wait two hours and check back to see if the synchronization has completed. When ready, [open an Azure support request][azure-support] to re-enable the managed domain.

-> If a managed domain is suspended for an extended period of time, there's a danger of it being deleted. Resolve the reason for suspension as quickly as possible. For more information, see [Understand the suspended states for Azure AD DS](suspension.md).

-[Check the Azure AD DS health](check-health.md) for alerts that indicate problems in the configuration of the managed domain. If you're able to resolve alerts that indicate a configuration issue, wait six hours and check back to see if the alert is removed. [Open an Azure support request][azure-support] if you need assistance.

-[azure-support]: ../active-directory/fundamentals/active-directory-troubleshooting-support-howto.md

-description: Learn how to troubleshoot common problems when you try to domain-join a VM or connect an application to Azure Active Directory Domain Services and you can't connect or authenticate to the managed domain.

-#Customer intent: As a directory administrator, I want to troubleshoot why VMs can't join an Azure Active Directory Domain Services managed domain.

-# Troubleshoot domain-join problems with an Azure Active Directory Domain Services managed domain

-When you try to join a virtual machine (VM) or connect an application to an Azure Active Directory Domain Services (Azure AD DS) managed domain, you may get an error that you're unable to do so. To troubleshoot domain-join problems, review at which of the following points you have an issue:

-* If you don't receive an authentication prompt, the VM or application can't connect to the Azure AD DS managed domain.

-When you create a managed domain, a network security group is also created with the appropriate rules for successful domain operation. If you edit or create additional network security group rules, you may unintentionally block ports required for Azure AD DS to provide connection and authentication services. These network security group rules can cause issues such as password sync not completing, users not being able to sign in, or domain-join issues.

-1. Try using the UPN format to specify credentials, such as `dee@contoso.onmicrosoft.com`. Make sure that this UPN is configured correctly in Azure AD.

-If you still have problems joining your VM to the managed domain, [find help and open a support ticket for Azure Active Directory][azure-ad-support].

-description: Learn how to troubleshoot common user sign-in problems and errors in Azure Active Directory Domain Services.

-#Customer intent: As a directory administrator, I want to troubleshoot user account sign in problems in an Azure Active Directory Domain Services managed domain.

-# Troubleshoot account sign-in problems with an Azure Active Directory Domain Services managed domain

-The most common reasons for a user account that can't sign in to an Azure Active Directory Domain Services (Azure AD DS) managed domain include the following scenarios:

-* [The account isn't synchronized into Azure AD DS yet.](#account-isnt-synchronized-into-azure-ad-ds-yet)

-* [Azure AD DS doesn't have the password hashes to let the account sign in.](#azure-ad-ds-doesnt-have-the-password-hashes)

-> Azure AD DS can't synchronize in credentials for accounts that are external to the Azure AD tenant. External users can't sign in to the Azure AD DS managed domain.

-## Account isn't synchronized into Azure AD DS yet

-Depending on the size of your directory, it may take a while for user accounts and credential hashes to be available in a managed domain. For large directories, this initial one-way sync from Azure AD can take few hours, and up to a day or two. Make sure that you wait long enough before retrying authentication.

-For hybrid environments that user Azure AD Connect to synchronize on-premises directory data into Azure AD, make sure that you run the latest version of Azure AD Connect and have [configured Azure AD Connect to perform a full synchronization after enabling Azure AD DS][azure-ad-connect-phs]. If you disable Azure AD DS and then re-enable, you have to follow these steps again.

-If you continue to have issues with accounts not synchronizing through Azure AD Connect, restart the Azure AD Sync Service. From the computer with Azure AD Connect installed, open a command prompt window, then run the following commands:

-## Azure AD DS doesn't have the password hashes

-Azure AD doesn't generate or store password hashes in the format that's required for NTLM or Kerberos authentication until you enable Azure AD DS for your tenant. For security reasons, Azure AD also doesn't store any password credentials in clear-text form. Therefore, Azure AD can't automatically generate these NTLM or Kerberos password hashes based on users' existing credentials.

-For hybrid environments using Azure AD Connect to synchronize from an on-premises AD DS environment, you can locally generate and synchronize the required NTLM or Kerberos password hashes into Azure AD. After you create your managed domain, [enable password hash synchronization to Azure Active Directory Domain Services][azure-ad-connect-phs]. Without completing this password hash synchronization step, you can't sign in to an account using the managed domain. If you disable Azure AD DS and then re-enable, you have to follow those steps again.

-For more information, see [How password hash synchronization works for Azure AD DS][phs-process].

-Managed domains with no on-premises synchronization, only accounts in Azure AD, also need to generate the required NTLM or Kerberos password hashes. If a cloud-only account can't sign in, has a password change process successfully completed for the account after enabling Azure AD DS?

- * If you disable Azure AD DS and then re-enable, each account must follow the steps again to change their password and generate the required password hashes.

- * The *SAMAccountName* may be automatically generated for users whose UPN prefix is overly long or is the same as another user on the managed domain. The *UPN* format is guaranteed to be unique within an Azure AD tenant.

-For more information and how to resolve account lockout issues, see [Troubleshoot account lockout problems in Azure AD DS][troubleshoot-account-lockout].

-If you still have problems joining your VM to the managed domain, [find help and open a support ticket for Azure Active Directory][azure-ad-support].

-[azure-ad-support]: ../active-directory/fundamentals/active-directory-troubleshooting-support-howto.md

-description: Learn how to troubleshoot common errors when you create or manage Azure Active Directory Domain Services

-# Common errors and troubleshooting steps for Azure Active Directory Domain Services

-As a central part of identity and authentication for applications, Azure Active Directory Domain Services (Azure AD DS) sometimes has problems. If you run into issues, there are some common error messages and associated troubleshooting steps to help you get things running again. At any time, you can also [open an Azure support request][azure-support] for additional troubleshooting assistance.

-This article provides troubleshooting steps for common issues in Azure AD DS.

-## You cannot enable Azure AD Domain Services for your Azure AD directory

-If you have problems enabling Azure AD DS, review the following common errors and steps to resolve them:

-| *Domain Services could not be enabled in this Azure AD tenant. The service does not have adequate permissions to the application called 'Azure AD Domain Services Sync'. Delete the application called 'Azure AD Domain Services Sync' and then try to enable Domain Services for your Azure AD tenant.* |[Domain Services doesn't have adequate permissions to the Azure AD Domain Services Sync application](troubleshoot.md#inadequate-permissions) |

-| *Domain Services could not be enabled in this Azure AD tenant. The Domain Services application in your Azure AD tenant does not have the required permissions to enable Domain Services. Delete the application with the application identifier d87dcbc6-a371-462e-88e3-28ad15ec4e64 and then try to enable Domain Services for your Azure AD tenant.* |[The Domain Services application isn't configured properly in your Azure AD tenant](troubleshoot.md#invalid-configuration) |

-| *Domain Services could not be enabled in this Azure AD tenant. The Microsoft Azure AD application is disabled in your Azure AD tenant. Enable the application with the application identifier 00000002-0000-0000-c000-000000000000 and then try to enable Domain Services for your Azure AD tenant.* |[The Microsoft Graph application is disabled in your Azure AD tenant](troubleshoot.md#microsoft-graph-disabled) |

-Check that you don't have an existing AD DS environment with the same domain name on the same, or a peered, virtual network. For example, you may have an AD DS domain named *aaddscontoso.com* that runs on Azure VMs. When you try to enable an Azure AD DS managed domain with the same domain name of *aaddscontoso.com* on the virtual network, the requested operation fails.

-This failure is due to name conflicts for the domain name on the virtual network. A DNS lookup checks if an existing AD DS environment responds on the requested domain name. To resolve this failure, use a different name to set up your managed domain, or de-provision the existing AD DS domain and then try again to enable Azure AD DS.

-*Domain Services could not be enabled in this Azure AD tenant. The service does not have adequate permissions to the application called 'Azure AD Domain Services Sync'. Delete the application called 'Azure AD Domain Services Sync' and then try to enable Domain Services for your Azure AD tenant.*

-Check if there's an application named *Azure AD Domain Services Sync* in your Azure AD directory. If this application exists, delete it, then try again to enable Azure AD DS. To check for an existing application and delete it if needed, complete the following steps:

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), select **Azure Active Directory** from the left-hand navigation menu.

-1. In the search box, enter *Azure AD Domain Services Sync*. If the application exists, select it and choose **Delete**.

-1. Once you've deleted the application, try to enable Azure AD DS again.

-*Domain Services could not be enabled in this Azure AD tenant. The Domain Services application in your Azure AD tenant does not have the required permissions to enable Domain Services. Delete the application with the application identifier d87dcbc6-a371-462e-88e3-28ad15ec4e64 and then try to enable Domain Services for your Azure AD tenant.*

-Check if you have an existing application named *AzureActiveDirectoryDomainControllerServices* with an application identifier of *d87dcbc6-a371-462e-88e3-28ad15ec4e64* in your Azure AD directory. If this application exists, delete it and then try again to enable Azure AD DS.

-*Domain Services could not be enabled in this Azure AD tenant. The Microsoft Azure AD application is disabled in your Azure AD tenant. Enable the application with the application identifier 00000002-0000-0000-c000-000000000000 and then try to enable Domain Services for your Azure AD tenant.*

-Check if you've disabled an application with the identifier *00000002-0000-0000-c000-000000000000*. This application is the Microsoft Azure AD application and provides Graph API access to your Azure AD tenant. To synchronize your Azure AD tenant, this application must be enabled.

-1. Once you've enabled the application, try to enable Azure AD DS again.

-## Users are unable to sign in to the Azure AD Domain Services managed domain

-If one or more users in your Azure AD tenant can't sign in to the managed domain, complete the following troubleshooting steps:

-* **Credentials format** - Try using the UPN format to specify credentials, such as `dee@aaddscontoso.onmicrosoft.com`. The UPN format is the recommended way to specify credentials in Azure AD DS. Make sure this UPN is configured correctly in Azure AD.

-* **Password synchronization** - Make sure that you've enabled password synchronization for [cloud-only users][cloud-only-passwords] or for [hybrid environments using Azure AD Connect][hybrid-phs].

- * You've deployed, or updated to, the [latest recommended release of Azure AD Connect](https://www.microsoft.com/download/details.aspx?id=47594).

- * You've configured Azure AD Connect to [perform a full synchronization][hybrid-phs].

- * If the issue persists after verifying the previous steps, try restarting the *Microsoft Azure AD Sync Service*. From your Azure AD Connect server, open a command prompt, then run the following commands:

- * **Cloud-only accounts**: If the affected user account is a cloud-only user account, make sure that the [user has changed their password after you enabled Azure AD DS][cloud-only-passwords]. This password reset causes the required credential hashes for the managed domain to be generated.

- * Invalid password attempts on the managed domain don't lock out the user account in Azure AD. The user account is locked out only within the managed domain. Check the user account status in the *Active Directory Administrative Console (ADAC)* using the [management VM][management-vm], not in Azure AD.

-* **External accounts** - Check that the affected user account isn't an external account in the Azure AD tenant. Examples of external accounts include Microsoft accounts like `dee@live.com` or user accounts from an external Azure AD directory. Azure AD DS doesn't store credentials for external user accounts so they can't sign in to the managed domain.

-## Users removed from your Azure AD tenant are not removed from your managed domain

-Azure AD protects against accidental deletion of user objects. When you delete a user account from an Azure AD tenant, the corresponding user object is moved to the recycle bin. When this delete operation is synchronized to your managed domain, the corresponding user account is marked as disabled. This feature helps you recover, or undelete, the user account.

-The user account remains in the disabled state in the managed domain, even if you re-create a user account with the same UPN in the Azure AD directory. To remove the user account from the managed domain, you need to forcibly delete it from the Azure AD tenant.

-To fully remove a user account from a managed domain, delete the user permanently from your Azure AD tenant using the [Remove-MsolUser][Remove-MsolUser] PowerShell cmdlet with the `-RemoveFromRecycleBin` parameter.

-description: Learn how to troubleshoot secure LDAP (LDAPS) for an Azure Active Directory Domain Services managed domain

-# Troubleshoot secure LDAP connectivity issues to an Azure Active Directory Domain Services managed domain

-Applications and services that use lightweight directory access protocol (LDAP) to communicate with Azure Active Directory Domain Services (Azure AD 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 troubleshoot issues with secure LDAP access in Azure AD DS.

-If you have trouble connecting to an Azure AD DS managed domain using secure LDAP, review the following troubleshooting steps. After each troubleshooting step, try to connect to the managed domain again:

-description: In this tutorial, you learn how to configure secure lightweight directory access protocol (LDAPS) for an Azure Active Directory Domain Services managed domain.

-#Customer intent: As an identity administrator, I want to secure access to an Azure Active Directory Domain Services managed domain using secure lightweight directory access protocol (LDAPS)

-# Tutorial: Configure secure LDAP for an Azure Active Directory Domain Services managed domain

-To communicate with your Azure Active Directory Domain Services (Azure AD DS) managed domain, the Lightweight Directory Access Protocol (LDAP) is used. By default, the LDAP traffic isn't encrypted, which is a security concern for many environments.

-With Azure AD DS, you can configure the managed domain to use secure Lightweight Directory Access Protocol (LDAPS). When you use secure LDAP, the traffic is encrypted. Secure LDAP is also known as LDAP over Secure Sockets Layer (SSL) / Transport Layer Security (TLS).

-This tutorial shows you how to configure LDAPS for an Azure AD DS managed domain.

-> * Create a digital certificate for use with Azure AD DS

-> * Enable secure LDAP for Azure AD DS

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

-* You need [Application Administrator](../active-directory/roles/permissions-reference.md#application-administrator) and [Groups Administrator](../active-directory/roles/permissions-reference.md#groups-administrator) Azure AD roles in your tenant to enable secure LDAP.

- * The DNS name or subject alternate name of the certificate must be a wildcard certificate to ensure the secure LDAP works properly with the Azure AD Domain Services. Domain Controllers use random names and can be removed or added to ensure the service remains available.

-### Export a certificate for Azure AD DS

-1. On the **File to Export** page, specify the file name and location where you'd like to export the certificate, such as *C:\Users\accountname\azure-ad-ds.pfx*. Keep a note of the password and location of the *.PFX* file as this information would be required in next steps.

-Client computers must trust the issuer of the secure LDAP certificate to be able to connect successfully to the managed domain using LDAPS. The client computers need a certificate to successfully encrypt data that is decrypted by Azure AD DS. If you use a public CA, the computer should automatically trust these certificate issuers and have a corresponding certificate.

-1. On the **File to Export** page, specify the file name and location where you'd like to export the certificate, such as *C:\Users\accountname\azure-ad-ds-client.cer*.

-1. Open File Explorer and browse to the location where you saved the *.CER* certificate file, such as *C:\Users\accountname\azure-ad-ds-client.cer*.

-## Enable secure LDAP for Azure AD DS

-1. In the [Microsoft Entra admin center](https://entra.microsoft.com), enter *domain services* in the **Search resources** box. Select **Azure AD Domain Services** from the search result.

-1. On the left-hand side of the Azure AD DS window, choose **Secure LDAP**.

-1. To apply the replacement certificate to Azure AD DS, in the left menu for Azure AD DS in the Microsoft Entra admin center, select **Secure LDAP**, and then select **Change Certificate**.

-Configure your external DNS provider to create a host record, such as *ldaps*, to resolve to this external IP address. To test locally on your machine first, you can create an entry in the Windows hosts file. To successfully edit the hosts file on your local machine, open *Notepad* as an administrator, then open the file *C:\Windows\System32\drivers\etc\hosts*

-The following example DNS entry, either with your external DNS provider or in the local hosts file, resolves traffic for *ldaps.aaddscontoso.com* to the external IP address of *168.62.205.103*:

-1. Browse to and open the file *C:\Windows\System32\drivers\etc\hosts*

-For the certificate subject name match, the DC will use the Azure AD DS domain name (not the Azure AD domain name) to search its certificate store for the certificate. Spelling mistakes, for example, prevent the DC from selecting the right certificate.

-> * Create a digital certificate for use with Azure AD DS

-> * Enable secure LDAP for Azure AD DS

-> [Configure password hash synchronization for a hybrid Azure AD environment](tutorial-configure-password-hash-sync.md)

-[New-SelfSignedCertificate]: /powershell/module/pki/new-selfsignedcertificate

-description: In this tutorial, you learn how to create and configure an Azure virtual network subnet or network peering for an Azure Active Directory Domain Services managed domain using the Microsoft Entra admin center.

-#Customer intent: As an identity administrator, I want to create and configure a virtual network subnet or network peering for application workloads in an Azure Active Directory Domain Services managed domain

-# Tutorial: Configure virtual networking for an Azure Active Directory Domain Services managed domain

-To provide connectivity to users and applications, an Azure Active Directory Domain Services (Azure AD DS) managed domain is deployed into an Azure virtual network subnet. This virtual network subnet should only be used for the managed domain resources provided by the Azure platform.

-When you create your own VMs and applications, they shouldn't be deployed into the same virtual network subnet. Instead, you should create and deploy your applications into a separate virtual network subnet, or in a separate virtual network that's peered to the Azure AD DS virtual network.

-This tutorial shows you how to create and configure a dedicated virtual network subnet or how to peer a different network to the Azure AD DS managed domain's virtual network.

-> * Understand the virtual network connectivity options for domain-joined resources to Azure AD DS

-> * Create an IP address range and additional subnet in the Azure AD DS virtual network

-> * Configure virtual network peering to a network that's separate from Azure AD DS

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

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

-* You need Domain Services Contributor Azure role to create the required Azure AD DS resources.

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, the first tutorial [creates and configures an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

-In the previous tutorial, a managed domain was created that used some default configuration options for the virtual network. These default options created an Azure virtual network and virtual network subnet. The Azure AD DS domain controllers that provide the managed domain services are connected to this virtual network subnet.

- * As the VMs are part of the same virtual network, they can automatically perform name resolution and communicate with the Azure AD DS domain controllers.

- * When you configure virtual network peering, you must also configure DNS settings to use name resolution back to the Azure AD DS domain controllers.

-* If you want to manage Azure AD DS and connected VMs as one group of resources, you can create an additional virtual network subnet for VMs.

-* If you want to separate the management of Azure AD DS and then any connected VMs, you can use virtual network peering.

-For more information on how to plan and configure the virtual network, see [networking considerations for Azure Active Directory Domain Services][network-considerations].

-You may have an existing Azure virtual network for VMs, or wish to keep your managed domain virtual network separate. To use the managed domain, VMs in other virtual networks need a way to communicate with the Azure AD DS domain controllers. This connectivity can be provided using Azure virtual network peering.

-1. It takes a few moments to create the peering on both the Azure AD DS virtual network and the virtual network you selected. When ready, the **Peering status** reports *Connected*, as shown in the following example:

-For VMs and applications in the peered virtual network to successfully talk to the managed domain, the DNS settings must be updated. The IP addresses of the Azure AD DS domain controllers must be configured as the DNS servers on the peered virtual network. There are two ways to configure the domain controllers as DNS servers for the peered virtual network:

-* Configure the Azure virtual network DNS servers to use the Azure AD DS domain controllers.

-In this tutorial, let's configure the Azure virtual network DNS servers to direct all queries to the Azure AD DS domain controllers.

-1. By default, a virtual network uses the built-in Azure-provided DNS servers. Choose to use **Custom** DNS servers. Enter the IP addresses for the Azure AD DS domain controllers, which are usually *10.0.2.4* and *10.0.2.5*. Confirm these IP addresses on the **Overview** window of your managed domain in the portal.

- 

-> * Understand the virtual network connectivity options for domain-joined resources to Azure AD DS

-> * Create an IP address range and additional subnet in the Azure AD DS virtual network

-> * Configure virtual network peering to a network that's separate from Azure AD DS

-[network-considerations]: network-considerations.md

-description: In this tutorial, learn how to enable password hash synchronization using Azure AD Connect to an Azure Active Directory Domain Services managed domain.

-#Customer intent: As an server administrator, I want to learn how to enable password hash synchronization with Azure AD Connect to create a hybrid environment using an on-premises AD DS domain.

-# Tutorial: Enable password synchronization in Azure Active Directory Domain Services for hybrid environments

-For hybrid environments, an Azure Active Directory (Azure AD) tenant can be configured to synchronize with an on-premises Active Directory Domain Services (AD DS) environment using Azure AD Connect. By default, Azure AD Connect doesn't synchronize legacy NT LAN Manager (NTLM) and Kerberos password hashes that are needed for Azure Active Directory Domain Services (Azure AD DS).

-To use Azure AD DS with accounts synchronized from an on-premises AD DS environment, you need to configure Azure AD Connect to synchronize those password hashes required for NTLM and Kerberos authentication. After Azure AD Connect is configured, an on-premises account creation or password change event also then synchronizes the legacy password hashes to Azure AD.

-> * How to configure legacy password hash synchronization for Azure AD Connect

-* An Azure Active Directory tenant associated with your subscription that's synchronized with an on-premises directory using Azure AD Connect.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

- * If needed, [enable Azure AD Connect for password hash synchronization][enable-azure-ad-connect].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

-## Password hash synchronization using Azure AD Connect

-Azure AD Connect is used to synchronize objects like user accounts and groups from an on-premises AD DS environment into an Azure AD tenant. As part of the process, password hash synchronization enables accounts to use the same password in the on-premises AD DS environment and Azure AD.

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

-Azure AD Connect can be configured to synchronize the required NTLM or Kerberos password hashes for Azure AD DS. Make sure that you have completed the steps to [enable Azure AD Connect for password hash synchronization][enable-azure-ad-connect]. If you had an existing instance of Azure AD Connect, [download and update to the latest version][azure-ad-connect-download] to make sure you can synchronize the legacy password hashes for NTLM and Kerberos. This functionality isn't available in early releases of Azure AD Connect or with the legacy DirSync tool. Azure AD Connect version *1.1.614.0* or later is required.

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

-With Azure AD Connect installed and configured to synchronize with Azure AD, now configure the legacy password hash sync for NTLM and Kerberos. A PowerShell script is used to configure the required settings and then start a full password synchronization to Azure AD. When that Azure AD Connect password hash synchronization process is complete, users can sign in to applications through Azure AD DS that use legacy NTLM or Kerberos password hashes.

-1. On the computer with Azure AD Connect installed, from the Start menu, open the **Azure AD Connect > Synchronization Service**.

-1. Select the **Connectors** tab. The connection information used to establish the synchronization between the on-premises AD DS environment and Azure AD are listed.

- The **Type** indicates either *Windows Azure Active Directory (Microsoft)* for the Azure AD connector or *Active Directory Domain Services* for the on-premises AD DS connector. Make a note of the connector names to use in the PowerShell script in the next step.

- * The Azure AD connector is named *contoso.onmicrosoft.com - Azure AD*

-1. Copy and paste the following PowerShell script to the computer with Azure AD Connect installed. The script triggers a full password sync that includes legacy password hashes. Update the `$azureadConnector` and `$adConnector` variables with the connector names from the previous step.

- Run this script on each AD forest to synchronize on-premises account NTLM and Kerberos password hashes to Azure AD.

- Depending on the size of your directory in terms of number of accounts and groups, synchronization of the legacy password hashes to Azure AD may take some time. The passwords are then synchronized to the managed domain after they've synchronized to Azure AD.

-> * How to configure legacy password hash synchronization for Azure AD Connect

-> [Learn how synchronization works in an Azure AD Domain Services managed domain](synchronization.md)

-description: Learn how to create a one-way outbound forest to an on-premises AD DS domain in the Microsoft Entra admin center for Azure AD Domain Services

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

-# Tutorial: Create an outbound forest trust to an on-premises domain in Azure Active Directory Domain Services

-You can create a one-way outbound trust from Azure AD 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 Azure AD DS managed domain. A forest trust can help users access resources in scenarios such as:

-Trusts can be created in any domain. The domain will automatically block synchronization from an on-premises domain for any user accounts that were synchronized to Azure AD DS. This prevents UPN collisions when users authenticate.

-

-> * Configure DNS in an on-premises AD DS environment to support Azure AD DS connectivity

-> * Create a one-way outbound forest trust in Azure AD DS

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain.

- * If needed, [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance-advanced].

-In this tutorial, you create and configure the outbound forest trust from Azure AD DS using the Microsoft Entra admin center. To get started, first sign in to the [Microsoft Entra admin center](https://entra.microsoft.com). You need [Application Administrator](../active-directory/roles/permissions-reference.md#application-administrator) and [Groups Administrator](../active-directory/roles/permissions-reference.md#groups-administrator) Azure AD roles in your tenant to modify an Azure AD DS instance.

-The virtual network that hosts the Azure AD DS forest needs network connectivity to your on-premises Active Directory. Applications and services also need network connectivity to the virtual network hosting the Azure AD DS forest. Network connectivity to the Azure AD DS forest must be always on and stable otherwise users may fail to authenticate or access resources.

-Before you configure a forest trust in Azure AD DS, make sure your networking between Azure and on-premises environment meets the following requirements:

-* Make sure Azure AD DS has its own subnet, don't share this virtual network subnet with application VMs and services.

- * Azure virtual network peerings must be created between all virtual networks you want to use the Azure AD DS forest trust to the on-premises AD DS environment.

-* Make sure there's continuous name resolution (DNS) between your Azure AD DS forest name and your on-premises Active Directory forest name.

-1. Enter the name for Azure AD DS domain name, such as *aaddscontoso.com*, then select **Next**.

-## Create outbound forest trust in Azure AD DS

-1. In the Microsoft Entra admin center, search for and select **Azure AD Domain Services**, then select your managed domain, such as *aaddscontoso.com*.

-If the forest trust is no longer needed for an environment, complete the following steps to remove it from Azure AD DS:

-1. In the Microsoft Entra admin center, search for and select **Azure AD Domain Services**, then select your managed domain, such as *aaddscontoso.com*.

-* [On-premises user authentication from the Azure AD DS forest](#on-premises-user-authentication-from-the-azure-ad-ds-forest)

-* [Access resources in the Azure AD DS forest using on-premises user](#access-resources-in-the-azure-ad-ds-forest-using-on-premises-user)

-### On-premises user authentication from the Azure AD DS forest

-1. Connect to the Windows Server VM joined to the Azure AD DS forest using [Azure Bastion](../bastion/bastion-overview.md) and your Azure AD DS administrator credentials.

-### Access resources in the Azure AD DS forest using on-premises user

-Using the Windows Server VM joined to the Azure AD DS forest, you can test the scenario where users can access resources hosted in the forest when they authenticate from computers in the on-premises domain with users from the on-premises domain. The following examples show you how to create and test various common scenarios.

-1. Connect to the Windows Server VM joined to the Azure AD DS forest using [Azure Bastion](../bastion/bastion-overview.md) and your Azure AD DS administrator credentials.

- > You must provide credentials because the trust relationship is only one way. This means users from the Azure AD DS managed domain can't access resources or search for users or groups in the trusted (on-premises) domain.

-1. On the Windows Server VM joined to the Azure AD DS forest, create a folder and provide name such as *CrossForestShare*.

-> * Configure DNS in an on-premises AD DS environment to support Azure AD DS connectivity

-> * Create a one-way outbound forest trust in Azure AD DS

-For more conceptual information about forest in Azure AD DS, see [How do forest trusts work in Azure AD DS?][concepts-trust].

-[join-windows-vm]: join-windows-vm.md

-description: In this tutorial, you learn how to create and configure a customized Azure Active Directory Domain Services managed domain and specify advanced configuration options using the Microsoft Entra admin center.

-#Customer intent: As an identity administrator, I want to create an Azure Active Directory Domain Services managed domain and define advanced configuration options so that I can synchronize identity information with my Azure Active Directory tenant and provide Domain Services connectivity to virtual machines and applications in Azure.

-# Tutorial: Create and configure an Azure Active Directory Domain Services managed domain with advanced configuration options

-Azure Active Directory Domain Services (Azure AD 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. Azure AD DS integrates with your existing Azure AD 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.

-You can [create a managed domain using default configuration options][tutorial-create-instance] for networking and synchronization, or manually define these settings. This tutorial shows you how to define those advanced configuration options to create and configure an Azure AD DS managed domain using the Microsoft Entra admin center.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

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

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

-Although not required for Azure AD DS, it's recommended to [configure self-service password reset (SSPR)][configure-sspr] for the Azure AD tenant. Users can change their password without SSPR, but SSPR helps if they forget their password and need to reset it.

-To launch the **Enable Azure AD Domain Services** wizard, complete the following steps:

-1. Enter *Domain Services* into the search bar, then choose *Azure AD Domain Services* from the search suggestions.

-1. On the Azure AD Domain Services page, select **Create**. The **Enable Azure AD Domain Services** wizard is launched.

-1. Choose the Azure **Location** in which the managed domain should be created. If you choose a region that supports Availability Zones, the Azure AD DS resources are distributed across zones for additional redundancy.

- > There's nothing for you to configure for Azure AD 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]

-1. The **SKU** determines the performance and backup frequency. You can change the SKU after the managed domain has been created if your business demands or requirements change. For more information, see [Azure AD DS SKU concepts][concepts-sku].

- 

- * Synchronizes *All* users from Azure AD into the managed domain.

-To provide connectivity, an Azure virtual network and a dedicated subnet are needed. Azure AD DS is enabled in this virtual network subnet. In this tutorial, you create a virtual network, though you could instead choose to use an existing virtual network. In either approach, you must create a dedicated subnet for use by Azure AD DS.

-* The subnet must have at least 3-5 available IP addresses in its address range to support the Azure AD DS resources.

-* Don't select the *Gateway* subnet for deploying Azure AD DS. It's not supported to deploy Azure AD DS into a *Gateway* subnet.

-For more information on how to plan and configure the virtual network, see [networking considerations for Azure Active Directory Domain Services][network-considerations].

-1. On the **Network** page, choose a virtual network to deploy Azure AD DS into from the drop-down menu, or select **Create new**.

- [ ](./media/tutorial-create-instance-advanced/create-vnet-expanded.png#lightbox)

- Make sure to pick an address range that is within your private IP address range. IP address ranges you don't own that are in the public address space cause errors within Azure AD DS.

-A special administrative group named *AAD DC Administrators* is used for management of the Azure AD DS domain. Members of this group are granted administrative permissions on VMs that are domain-joined to the managed domain. On domain-joined VMs, this group is added to the local administrators group. Members of this group can also use Remote Desktop to connect remotely to domain-joined VMs.

-> You don't have *Domain Administrator* or *Enterprise Administrator* permissions on a managed domain using Azure AD DS. These permissions are reserved by the service and aren't made available to users within the tenant.

-The wizard automatically creates the *AAD DC Administrators* group in your Azure AD directory. If you have an existing group with this name in your Azure AD directory, the wizard selects this group. You can optionally choose to add additional users to this *AAD DC Administrators* group during the deployment process. These steps can be completed later.

-1. Select the **Add members** button, then search for and select users from your Azure AD directory. For example, search for your own account, and add it to the *AAD DC Administrators* group.

-Azure AD DS lets you synchronize *all* users and groups available in Azure AD, or a *scoped* synchronization of only specific groups. You can change the synchronize scope now, or once the managed domain is deployed. For more information, see [Azure AD Domain Services scoped synchronization][scoped-sync].

- 

-On the **Summary** page of the wizard, review the configuration settings for your managed domain. You can go back to any step of the wizard to make changes. To redeploy a managed domain to a different Azure AD tenant in a consistent way using these configuration options, you can also **Download a template for automation**.

-1. To create the managed domain, select **Create**. A note is displayed that certain configuration options like DNS name or virtual network can't be changed once the Azure AD DS managed has been created. To continue, select **OK**.

-1. The process of provisioning your managed domain can take up to an hour. A notification is displayed in the portal that shows the progress of your Azure AD DS deployment. Select the notification to see detailed progress for the deployment.

-> The managed domain is associated with your Azure AD tenant. During the provisioning process, Azure AD DS creates two Enterprise Applications named *Domain Controller Services* and *AzureActiveDirectoryDomainControllerServices* in the Azure AD tenant. These Enterprise Applications are needed to service your managed domain. Don't delete these applications.

-With Azure AD DS successfully deployed, now configure the virtual network to allow other connected VMs and applications to use the managed domain. To provide this connectivity, update the DNS server settings for your virtual network to point to the two IP addresses where the managed domain is deployed.

- 

-## Enable user accounts for Azure AD DS

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

-> Synchronized credential information in Azure AD can't be re-used if you later create a 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 - Azure AD needs to generate and store the password hashes in the new managed domain.

-> For more information, see [Password hash sync process for Azure AD DS and Azure AD Connect][password-hash-sync-process].

-The steps to generate and store these password hashes are different for cloud-only user accounts created in Azure AD versus user accounts that are synchronized from your on-premises directory using Azure AD Connect.

-A cloud-only user account is an account that was created in your Azure AD directory using either the Microsoft Entra admin center or Azure AD PowerShell cmdlets. These user accounts aren't synchronized from an on-premises directory.

-In this tutorial, let's work with a basic cloud-only user account. For more information on the additional steps required to use Azure AD Connect, see [Synchronize password hashes for user accounts synced from your on-premises AD to your managed domain][on-prem-sync].

-> If your Azure AD tenant has a combination of cloud-only users and users from your on-premises AD, you need to complete both sets of steps.

-For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. The account isn't synchronized from Azure AD to Azure AD DS until the password is changed. Either expire the passwords for all cloud users in the tenant who need to use Azure AD DS, which forces a password change on next sign-in, or instruct cloud users to manually change their passwords. For this tutorial, let's manually change a user password.

-Before a user can reset their password, the Azure AD tenant must be [configured for self-service password reset][configure-sspr].

-1. Go to the Azure AD Access Panel page at [https://myapps.microsoft.com](https://myapps.microsoft.com).

-It takes a few minutes after you've changed your password for the new password to be usable in Azure AD DS and to successfully sign in to computers joined to the managed domain.

-> * Enable user accounts for Azure AD DS and generate password hashes

-description: In this tutorial, you learn how to create and configure an Azure Active Directory Domain Services managed domain using the Microsoft Entra admin center.

-#Customer intent: As an identity administrator, I want to create an Azure Active Directory Domain Services managed domain so that I can synchronize identity information with my Azure Active Directory tenant and provide Domain Services connectivity to virtual machines and applications in Azure.

-# Tutorial: Create and configure an Azure Active Directory Domain Services managed domain

-Azure Active Directory Domain Services (Azure AD 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. Azure AD DS integrates with your existing Azure AD 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.

-You can create a managed domain using default configuration options for networking and synchronization, or [manually define these settings][tutorial-create-instance-advanced]. This tutorial shows you how to use default options to create and configure an Azure AD DS managed domain using the Microsoft Entra admin center.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

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

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

-Although not required for Azure AD DS, it's recommended to [configure self-service password reset (SSPR)][configure-sspr] for the Azure AD tenant. Users can change their password without SSPR, but SSPR helps if they forget their password and need to reset it.

-To launch the **Enable Azure AD Domain Services** wizard, complete the following steps:

-1. Enter *Domain Services* into the search bar, then choose *Azure AD Domain Services* from the search suggestions.

-1. On the Azure AD Domain Services page, select **Create**. The **Enable Azure AD Domain Services** wizard is launched.

-1. Choose the Azure **Location** in which the managed domain should be created. If you choose a region that supports Azure Availability Zones, the Azure AD DS resources are distributed across zones for additional redundancy.

- > There's nothing for you to configure for Azure AD 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]

-1. The **SKU** determines the performance and backup frequency. You can change the SKU after the managed domain has been created if your business demands or requirements change. For more information, see [Azure AD DS SKU concepts][concepts-sku].

- 

-* Synchronizes *All* users from Azure AD into the managed domain.

-On the **Summary** page of the wizard, review the configuration settings for your managed domain. You can go back to any step of the wizard to make changes. To redeploy a managed domain to a different Azure AD tenant in a consistent way using these configuration options, you can also **Download a template for automation**.

-1. To create the managed domain, select **Create**. A note is displayed that certain configuration options such as DNS name or virtual network can't be changed once the Azure AD DS managed has been created. To continue, select **OK**.

-1. The process of provisioning your managed domain can take up to an hour. A notification is displayed in the portal that shows the progress of your Azure AD DS deployment. Select the notification to see detailed progress for the deployment.

-> The managed domain is associated with your Azure AD tenant. During the provisioning process, Azure AD DS creates two Enterprise Applications named *Domain Controller Services* and *AzureActiveDirectoryDomainControllerServices* in the Azure AD tenant. These Enterprise Applications are needed to service your managed domain. Don't delete these applications.

-With Azure AD DS successfully deployed, now configure the virtual network to allow other connected VMs and applications to use the managed domain. To provide this connectivity, update the DNS server settings for your virtual network to point to the two IP addresses where the managed domain is deployed.

- 

-## Enable user accounts for Azure AD DS

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

-> Synchronized credential information in Azure AD can't be re-used if you later create a 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 - Azure AD needs to generate and store the password hashes in the new managed domain.

-> [Azure AD Connect Cloud Sync is not supported with Azure AD DS](../active-directory/cloud-sync/what-is-cloud-sync.md#comparison-between-azure-ad-connect-and-cloud-sync). On-premises users need to be synced using Azure AD Connect in order to be able to access domain-joined VMs. For more information, see [Password hash sync process for Azure AD DS and Azure AD Connect][password-hash-sync-process].

-The steps to generate and store these password hashes are different for cloud-only user accounts created in Azure AD versus user accounts that are synchronized from your on-premises directory using Azure AD Connect.

-A cloud-only user account is an account that was created in your Azure AD directory using either the Microsoft Entra admin center or Azure AD PowerShell cmdlets. These user accounts aren't synchronized from an on-premises directory.

-> In this tutorial, let's work with a basic cloud-only user account. For more information on the additional steps required to use Azure AD Connect, see [Synchronize password hashes for user accounts synced from your on-premises AD to your managed domain][on-prem-sync].

-> If your Azure AD tenant has a combination of cloud-only users and users from your on-premises AD, you need to complete both sets of steps.

-For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. The account isn't synchronized from Azure AD to Azure AD DS until the password is changed. Either expire the passwords for all cloud users in the tenant who need to use Azure AD DS, which forces a password change on next sign-in, or instruct cloud users to manually change their passwords. For this tutorial, let's manually change a user password.

-Before a user can reset their password, the Azure AD tenant must be [configured for self-service password reset][configure-sspr].

-1. Go to the Azure AD Access Panel page at [https://myapps.microsoft.com](https://myapps.microsoft.com).

-It takes a few minutes after you've changed your password for the new password to be usable in Azure AD DS and to successfully sign in to computers joined to the managed domain.

-> * Enable user accounts for Azure AD DS and generate password hashes

-description: In this tutorial, you learn how to create and configure a Windows virtual machine that you use to administer Azure Active Directory Domain Services managed domain.

-#Customer intent: As an identity administrator, I want to create a management VM and install the required tools to connect to and manage an Azure Active Directory Domain Services managed domain.

-# Tutorial: Create a management VM to configure and administer an Azure Active Directory Domain Services managed domain

-Azure Active Directory Domain Services (Azure AD DS) provides managed domain services such as domain join, group policy, LDAP, and Kerberos/NTLM authentication that is fully compatible with Windows Server Active Directory. You administer this managed domain using the same Remote Server Administration Tools (RSAT) as with an on-premises Active Directory Domain Services domain. As Azure AD DS is a managed service, there are some administrative tasks that you can't perform, such as using remote desktop protocol (RDP) to connect to the domain controllers.

-This tutorial shows you how to configure a Windows Server VM in Azure and install the required tools to administer an Azure AD DS managed domain.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, see the first tutorial to [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

-* A user account that's a member of the *Azure AD DC administrators* group in your Azure AD tenant.

-* An Azure Bastion host deployed in your Azure AD DS virtual network.

-## Available administrative tasks in Azure AD DS

-Azure AD DS provides a managed domain for your users, applications, and services to consume. This approach changes some of the available management tasks you can do, and what privileges you have within the managed domain. These tasks and permissions may be different than what you experience with a regular on-premises Active Directory Domain Services environment. You also can't connect to domain controllers on the managed domain using Remote Desktop.

-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 Azure AD tenant are listed in this container.

- 

-Common Active Directory Administrative Center actions such as resetting a user account password or managing group membership are available. These actions only work for users and groups created directly in the managed domain. Identity information only synchronizes *from* Azure AD to Azure AD DS. There's no write back from Azure AD DS to Azure AD. You can't change passwords or managed group membership for users synchronized from Azure AD and have those changes synchronized back.

-description: Learn how to create and use replica sets in the Microsoft Entra admin center for service resiliency with Azure AD Domain Services

-#Customer intent: As an identity administrator, I want to create and use replica sets in Azure Active Directory Domain Services to provide resiliency or geographical distributed managed domain data.

-# Tutorial: Create and use replica sets for resiliency or geolocation in Azure Active Directory Domain Services

-To improve the resiliency of an Azure Active Directory Domain Services (Azure AD DS) managed domain, or deploy to additional geographic locations close to your applications, you can use *replica sets*. Every Azure AD DS managed domain namespace, such as *aaddscontoso.com*, contains one initial replica set. The ability to create additional replica sets in other Azure regions provides geographical resiliency for a managed domain.

-You can add a replica set to any peered virtual network in any Azure region that supports Azure AD DS.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain created using the Azure Resource Manager deployment model and configured in your Azure AD tenant.

- * If needed, [create and configure an Azure Active Directory Domain Services managed domain][tutorial-create-instance].

-The virtual networks that host replica sets must be able to communicate with each other. Applications and services that depend on Azure AD DS also need network connectivity to the virtual networks hosting the replica sets. Azure virtual network peering should be configured between all virtual networks to create a fully meshed network. These peerings enable effective intra-site replication between replica sets.

-Before you can use replica sets in Azure AD DS, review the following Azure virtual network requirements:

-* Make sure Azure AD DS has its own subnet. Don't share this virtual network subnet with application VMs and services.

-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 Azure AD 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.

-In this tutorial, you create an additional replica set in an Azure region different than the initial Azure AD DS replica set.

-1. In the Microsoft Entra admin center, search for and select **Azure AD Domain Services**.

- Select a virtual network in the destination region, such as *vnet-eastus*, then choose a subnet such as *aadds-subnet*. If needed, choose **Create new** to add a virtual network in the destination region, then **Manage** to create a subnet for Azure AD DS.

-1. In the Microsoft Entra admin center, search for and select **Azure AD Domain Services**.

-1. In the Azure AD DS management VM, access the DNS console and manually delete DNS records for the domain controllers from the deleted replica set.

-For more conceptual information, learn how replica sets work in Azure AD DS.

-description: Learn how to perform a disaster recovery drill using replica sets in Azure AD Domain Services

-#Customer intent: As an identity administrator, I want to perform a disaster recovery drill by using replica sets in Azure Active Directory Domain Services to demonstrate resiliency for geographically distributed domain data.

-# Tutorial: Perform a disaster recovery drill using replica sets in Azure Active Directory Domain Services

-This topic shows how to perform a disaster recovery (DR) drill for Azure AD Domain Services (Azure AD DS) using replica sets. This will simulate one of the replica sets going offline by making changes to the network virtual network properties to block client access to it. It is not a true DR drill in that the replica set will not be taken offline.

-You will be performing these operations for each replica set in the Azure AD DS instance. This will simulate an outage for each replica set. When domain controllers are not reachable, the client will automatically fail over to a reachable domain controller and this experience should be seamless to the end user or workload. Therefore it is critical that applications and services don't point to a specific domain controller.

-These operations demonstrate that the domain is still available even though one of the replica sets is unreachable by the client. Perform this set of steps for each replica set in the Azure AD DS instance.

-After you complete these steps, you will see domain members continue to access the directory if one of the replica sets in the Azure AD DS is not reachable. You can simulate the same behavior by blocking all network access for a replica set instead of a client machine, but we don't recommend it. It wonΓÇÖt change the behavior from a client perspective, but it will impact the health of your Azure AD DS instance until the network access is restored.

-For more conceptual information, learn how replica sets work in Azure AD DS.

-description: Learn how to use Azure Monitor Workbooks to review security audits and understand issues in an Azure Active Directory Domain Services managed domain.

-# Review security audit events in Azure Active Directory Domain Services using Azure Monitor Workbooks

-To help you understand the state of your Azure Active Directory Domain Services (Azure AD DS) managed domain, you can enable security audit events. These security audit events can then be reviewed using Azure Monitor Workbooks that combine text, analytics queries, and parameters into rich interactive reports. Azure AD DS includes workbook templates for security overview and account activity that let you dig into audit events and manage your environment.

-This article shows you how to use Azure Monitor Workbooks to review security audit events in Azure AD DS.

-* An Azure Active Directory tenant associated with your subscription, either synchronized with an on-premises directory or a cloud-only directory.

- * If needed, [create an Azure Active Directory tenant][create-azure-ad-tenant] or [associate an Azure subscription with your account][associate-azure-ad-tenant].

-* An Azure Active Directory Domain Services managed domain enabled and configured in your Azure AD tenant.

- * If needed, complete the tutorial to [create and configure an Azure Active Directory Domain Services managed domain][create-azure-ad-ds-instance].

- * If needed, [enable security audits for Azure AD DS][enable-security-audits].

-When security audit events are turned on in Azure AD DS, it can be hard to analyze and identify issues in the managed domain. Azure Monitor lets you aggregate these security audit events and query the data. With Azure Monitor Workbooks, you can visualize this data to make it quicker and easier to identify issues.

-Azure AD DS includes the following two workbook templates:

-1. Search for and select **Azure AD Domain Services** in the Azure portal.

-1. Search for and select **Azure AD Domain Services** in the Azure portal.

-The two template workbooks provided by Azure AD DS are a good place to start with your own data analysis. If you need to get more granular in the data queries and investigations, you can save your own workbooks and edit the queries.

-# Known issues and resolutions with SCIM 2.0 protocol compliance of the Microsoft Entra User Provisioning service

-Microsoft Entra ID's support for the SCIM 2.0 protocol is described in [Using System for Cross-Domain Identity Management (SCIM) to automatically provision users and groups from Microsoft Entra ID to applications](use-scim-to-provision-users-and-groups.md), which lists the specific parts of the protocol that it implements in order to automatically provision users and groups from Microsoft Entra ID to applications that support SCIM 2.0.

-* If the target directory for the operation is Microsoft Entra ID, then the matched user is soft-deleted. The user can be seen on the Microsoft Azure portal **Deleted users** page for the next 30 days and can be restored during that time.

-1. Copy the name of your managed identity from the Azure portal. For example: The screenshot below shows the name of a system assigned managed identity associated with an Azure Logic Apps workflow called "CSV2SCIMBulkUpload".

-1. Log in to your Azure portal as administrator.

-1. In the browser associated with your Azure portal login, open the GitHub repository URL - https://github.com/joelbyford/CSVtoJSONcore.

-| Manage automatic user provisioning for all applications from the Azure portal| √| X| √ |

-* Microsoft Teams does not support converting the [userType](../external-identities/user-properties.md) property on a B2B user from `member` to `guest` or `guest` to `member`.

-* External / B2B users of type `member` cannot be added to a shared channel in Microsoft Teams. If your organization uses shared channels, please ensure that you update your synchronization configuration to create users as type `guest`. At that point, you will be able to add the native identity (the original account in the source tenant) to the shared channel. If a user is already created as type `member`, you can convert the user to type `guest` in this scenario and add the native identity to the shared channel.

-* External / B2B users will need to switch tenants in Teams to receive messages. This experience does not change for users created by cross-tenant synchronization.

-The Global Reader role is unable to read the provisioning configuration. Create a custom role with the `microsoft.directory/applications/synchronization/standard/read` permission in order to read the provisioning configuration from the Azure portal.

- The attributes that the target application supports are discovered and surfaced in the Azure portal in **Attribute Mappings**. Newly added attributes will continue to be discovered. If an attribute type has changed, for example, string to Boolean, and the attribute is part of the mappings, the type won't change automatically in the Azure portal. Customers will need to go into advanced settings in mappings and manually update the attribute type.

-In cases where an application doesn't support SCIM, partners have built gateways between the Microsoft Entra SCIM client and target applications. **This document serves as a place for partners to attest to integrations that are compatible with Microsoft Entra ID, and for customers to discover these partner-driven integrations.** These gateways are built, maintained, and owned by the third-party vendor.

-Use the Azure portal to view and manage all the applications that support provisioning. See [Finding your apps in the portal](../app-provisioning/configure-automatic-user-provisioning-portal.md).

-If you enable user provisioning for enterprise apps, the [Azure portal](https://portal.azure.com/) controls its attribute values through attribute mapping.

-Use the [Azure portal](https://portal.azure.com/) to manage automatic user account provisioning and deprovisioning for applications that support it. Follow the steps in [How do I set up automatic provisioning to an application?](../app-provisioning/user-provisioning.md)

-* The service is manually stopped, and a new initial cycle is triggered using the [Azure portal](https://portal.azure.com/), or using the appropriate [Microsoft Graph API](/graph/api/resources/synchronization-overview) command.

-

-1. Sign in to the [Azure portal](https://portal.azure.com).

-2. Go to **Microsoft Entra ID** > **Enterprise applications** > **All applications**.

-2. Go to **Microsoft Entra ID** > **Cross-tenant Synchronization** > **Configurations**

- :::image type="content" source="media/provision-on-demand/on-demand-provision-user.png" alt-text="Screenshot that shows the Azure portal UI for provisioning a user on demand." lightbox="media/provision-on-demand/on-demand-provision-user.png":::

-description: This article lists all releases of Azure Active Directory Connect Provisioning Agent and describes new features and fixed issues.

-# Azure Active Directory Connect Provisioning Agent: Version release history

-For example, if you wanted to see data from your cloud sync workflow, your source would be Active Directory and your target would be Azure AD.

-description: Learn which attributes from SuccessFactors are supported by SuccessFactors-HR driven provisioning in Azure Active Directory.

-# SAP SuccessFactors attribute reference for Azure Active Directory

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

-description: Technical deep dive into SAP SuccessFactors-HR driven provisioning for Azure Active Directory.

-# How Azure Active Directory provisioning integrates with SAP SuccessFactors

-[Azure Active Directory user provisioning service](../app-provisioning/user-provisioning.md) integrates with [SAP SuccessFactors Employee Central](https://www.sap.com/products/hcm/employee-central-payroll.html) to manage the identity life cycle of users. Azure Active Directory offers three prebuilt integrations:

-* [SuccessFactors to Azure Active Directory user provisioning](../saas-apps/sap-successfactors-inbound-provisioning-cloud-only-tutorial.md)

-Azure AD provisioning service uses basic authentication to connect to Employee Central OData API endpoints. When setting up the SuccessFactors provisioning app, use the *Tenant URL* parameter in the *Admin Credentials* section to configure the [API data center URL](https://apps.support.sap.com/sap/support/knowledge/en/2215682).

-To further secure the connectivity between Azure AD provisioning service and SuccessFactors, add the Azure AD IP ranges in the SuccessFactors IP allowlist:

-1. Open the file and search for tag **AzureActiveDirectory**

- >

-For every user in SuccessFactors, Azure AD provisioning service retrieves the following entities. Each entity is expanded using the OData API *$expand* query parameter as outlined in the *Retrieval rule* column. Some entities are expanded by default, while some entities are expanded only if a specific attribute is present in the mapping.

-Based on the attribute-mapping, during full sync Azure AD provisioning service sends the following "GET" OData API query to fetch effective data of all active and terminated workers.

-After full sync, Azure AD provisioning service maintains `LastExecutionTimestamp` and uses it to create delta queries for retrieving incremental changes. The timestamp attributes present in each SuccessFactors entity, such as `lastModifiedDateTime`, `startDate`, `endDate`, and `latestTerminationDate`, are evaluated to see if the change falls between the `LastExecutionTimestamp` and `CurrentExecutionTime`. If yes, then the entry change is considered to be effective and processed for sync.

-Here's the OData API request template that Azure AD uses to query SuccessFactors for incremental changes. You can update the variables `SuccessFactorsAPIEndpoint`, `LastExecutionTimestamp` and `CurrentExecutionTime` in the request template use a tool like [Postman](https://www.postman.com/downloads/) to check what data is returned. Alternatively, you can also retrieve the actual request payload from SuccessFactors by [enabling OData API Audit logs](#enabling-odata-api-audit-logs-in-successfactors).

-When Azure AD provisioning service queries SuccessFactors, it retrieves a JSON result set. The JSON result set includes many attributes stored in Employee Central. By default, the provisioning schema is configured to retrieve only a subset of those attributes.

- > If the **Edit attribute list for SuccessFactors** option doesn't show in the Azure portal, use the URL *https://portal.azure.com/?Microsoft_AAD_IAM_forceSchemaEditorEnabled=true* to access the page.

-By using JSONPath transformation, you can customize the behavior of the Azure AD provisioning app to retrieve custom attributes and handle scenarios such as rehiring, worker conversion and global assignment.

-The default Azure AD SuccessFactors provisioning app schema ships with [90+ predefined attributes](sap-successfactors-attribute-reference.md).

-By default, the following custom attributes are predefined in the Azure AD SuccessFactors provisioning app:

-1. Save and reload the mapping change in the Azure portal.

-By default, the Azure AD SuccessFactors connector uses the `activeEmploymentsCount` field of the `PersonEmpTerminationInfo` object to set account status. You may encounter one of the following issues with this attribute.

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

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

-Inbound user provisioning from SAP SuccessFactors to on premises Active Directory and Azure AD now supports advance provisioning of prehires present in the SAP SuccessFactors Onboarding 2.0 module. When the Azure AD provisioning service encounters a new hire profile with a future start date, it queries SAP SuccessFactors to get new hires with one of the following status codes: `active`, `inactive`, `active_external_suite`. The status code `active_external_suite` corresponds to prehires present in the SAP SuccessFactors Onboarding 2.0 module. For a description of these status codes, refer to [SAP support note 2736579](https://launchpad.support.sap.com/#/notes/0002736579).

-The Azure AD SuccessFactors connector uses SuccessFactors OData API to retrieve changes and provision users. If you observe issues with the provisioning service and want to confirm what data was retrieved from SuccessFactors, you can enable OData API Audit logs in SuccessFactors. Retrieve the request payload sent by Azure AD from the audit logs. To troubleshoot, you can copy this request payload in a tool like [Postman](https://www.postman.com/downloads/), set it up to use the same API user that is used by the connector and see if it returns the desired changes from SuccessFactors.

-| 2 | * In SuccessFactors, business email and business phone is primary <br> * Always flow Azure AD telephone number to business phone and mobile to cell phone. | true | true | false | telephoneNumber | mobile |

-| 3 | * In SuccessFactors, business email and cell phone is primary <br> * Always flow Azure AD telephone number to business phone and mobile to cell phone | true | false | true | telephoneNumber | mobile |

-| 4 | * In SuccessFactors business email is primary. <br> * In Azure AD, check if work telephone number is present, if present, then check if mobile number is also present. Mark work telephone number as primary only if mobile number isn't present. | true | Use expression mapping: `IIF(IsPresent([telephoneNumber]), IIF(IsPresent([mobile]),"false", "true"), "false")` | Use expression mapping: `IIF(IsPresent([mobile]),"false", "true")` | telephoneNumber | mobile |

-| 5 | * In SuccessFactors business email and business phone is primary. <br> * In Azure AD, if mobile is available, then set it as the business phone, else use telephoneNumber. | true | true | false | `IIF(IsPresent([mobile]), [mobile], [telephoneNumber])` | \[Not Set\] |

-1. Open the SuccessFactors to Azure AD user provisioning app or SuccessFactors to on-premises AD user provisioning app.

-1. Ensure that `extensionAttribute[1-15]` in Azure AD always stores the `userId` of every worker's active employment record. The record maps SuccessFactors `userId` attribute to `extensionAttribute[1-15]` in Azure AD.

-1. For guidance regarding JSONPath settings, refer to the section [Handling worker conversion and rehiring scenarios](#handling-worker-conversion-and-rehiring-scenarios) to ensure the *userId* value of the active employment record flows into Azure AD.

-1. Run the provisioning job to ensure that the *userId* values flow into Azure AD.

- > If you're using SuccessFactors to on-premises Active Directory user provisioning, configure AAD Connect to sync the *userId* attribute value from on-premises Active Directory to Azure AD.

-1. In the schema editor, hit Ctrl-F and search for the JSON node containing the userId mapping, where it's mapped to a source Azure AD attribute.

-description: Using SCIM and the Microsoft Graph together to provision users and enrich your application with the data it needs in Azure Active Directory.

-**Target audience:** This article is targeted towards developers building applications to be integrated with Azure Active Directory (Azure AD). If you're looking to use applications already integrated with Azure AD, such as Zoom, ServiceNow, and DropBox, you can skip this article and review the application specific [tutorials](../saas-apps/tutorial-list.md) or review [how the provisioning service works](./how-provisioning-works.md).

-Azure AD provides an out of the box service for provisioning and an extensible platform to build your applications on. The decision tree outlines how a developer would use [SCIM](https://aka.ms/scimoverview) and the [Microsoft Graph](/graph/overview) to automate provisioning.

-> * Automatically create, update, and delete users and groups in Azure AD and Active Directory

-* If your customers use various IdPs and you do not want to maintain a sync engine to integrate with each, support a SCIM compliant [/Users](https://aka.ms/scimreferencecode) endpoint. Your customers will be able to easily use this endpoint to integrate with the Azure AD provisioning service and automatically create user accounts when they need access. You can build the endpoint once and it will be compatible with all IdPs. Check out the example request below for how a user would be created using SCIM.

-* If you require user data found on the user object in Azure AD and other data from across Microsoft, consider building a SCIM endpoint for user provisioning and calling into the Microsoft Graph to get the rest of the data.

-**Recommendation:** Support a SCIM compliant /Users endpoint. The Azure AD provisioning service will send requests to disable and delete when the user shouldn't have access anymore. We recommend supporting both disabling and deleting users. See the examples below for what a disable and delete request look like.

-My application relies on groups for access to various resources, and customers want to reuse the groups that they have in Azure AD. How can I import groups from Azure AD and keep them updated as the memberships change?

-**Recommendation:** Support a SCIM compliant /Groups [endpoint](https://aka.ms/scimreferencecode). The Azure AD provisioning service will take care of creating groups and managing membership updates in your application.

-## Scenario 5: Track changes in Microsoft services such as Teams, Outlook, and Azure AD

-## Scenario 6: Provision users and groups in Azure AD

-My application creates information about a user that customers need in Azure AD. This could be an HR application than manages hiring, a communications app that creates phone numbers for users, or some other app that generates data that would be valuable in Azure AD. How do I populate the user record in Azure AD with that data?

-**Recommendation** The Microsoft graph exposes /Users and /Groups endpoints that you can integrate with today to provision users into Azure AD. Please note that Azure Active Directory doesn't support writing those users back into Active Directory.

-description: This tutorial describes how to use the Azure AD SCIM Validator to validate that your provisioning server is compatible with the Azure SCIM client.

-This tutorial describes how to use the Azure AD SCIM Validator to validate that your provisioning server is compatible with the Azure SCIM client. The tutorial is intended for developers who want to build a SCIM compatible server to manage their identities with the Azure AD provisioning service.

-**Upload Azure AD Schema** - Upload the schema you've downloaded from your sample app on Azure AD.

-3. If you're uploading a schema, then select your .json file to upload. The option accepts a .json file exported from your sample app on the Azure portal. To learn how to export a schema, see [How-to: Export provisioning configuration and roll back to a known good state](export-import-provisioning-configuration.md#export-your-provisioning-configuration).

-> You can only use HTTP endpoints for local tests. The Azure AD provisioning service requires that your endpoint support HTTPS.

-## Known Issues with Azure AD SCIM Validator

-description: Learn how to override the default behavior of deprovisioning out of scope users in Azure Active Directory.

-# Skip deletion of user accounts that go out of scope in Azure Active Directory

-By default, the Azure AD provisioning engine soft deletes or disables users that go out of scope. However, for certain scenarios like Workday to AD User Inbound Provisioning, this behavior may not be the expected and you may want to override this default behavior.

-Because this configuration is widely used with the *Workday to Active Directory user provisioning* app, the following steps include screenshots of the Workday application. However, the configuration can also be used with *all other apps*, such as ServiceNow, Salesforce, and Dropbox. To successfully complete this procedure, you must have first set up app provisioning for the app. Each app has its own configuration article. For example, to configure the Workday application, see [Tutorial: Configure Workday to Azure AD user provisioning](../saas-apps/workday-inbound-cloud-only-tutorial.md). SkipOutOfScopeDeletions does not work for cross-tenant synchronization.

-1. Click on the "Sign-In with Microsoft" button and sign-in using Azure AD Global Administrator or App Admin credentials.

-In the next provisioning cycle, the Azure AD provisioning service identifies that the user 21173 has gone out of scope. If the `SkipOutOfScopeDeletions` property is enabled, then the synchronization rule for that user displays a message as shown:

-description: This tutorial describes how to provision users from Azure AD into a SQL database.

-# Configuring Azure AD to provision users into a SQL database

-description: Learn to develop a SCIM endpoint, integrate your SCIM API with Azure Active Directory, and automatically provision users and groups into your cloud applications.

-# Tutorial: Develop a sample SCIM endpoint in Azure Active Directory

-This tutorial describes how to deploy the SCIM [reference code](https://aka.ms/scimreferencecode) with [Azure App Service](../../app-service/index.yml). Then, test the code by using Postman or by integrating with the Azure Active Directory (Azure AD) Provisioning Service. The tutorial is intended for developers who want to get started with SCIM, or anyone interested in testing a [SCIM endpoint](./use-scim-to-provision-users-and-groups.md).

-Go to the application in **Azure App Service** > **Configuration** and select **New application setting** to add the *Token__TokenIssuer* setting with the value `https://sts.windows.net/<tenant_id>/`. Replace `<tenant_id>` with your Azure AD tenant ID. If you want to test the SCIM endpoint by using [Postman](https://github.com/AzureAD/SCIMReferenceCode/wiki/Test-Your-SCIM-Endpoint), add an *ASPNETCORE_ENVIRONMENT* setting with the value `Development`.

-When you test your endpoint with an enterprise application in the [Azure portal](use-scim-to-provision-users-and-groups.md#integrate-your-scim-endpoint-with-the-azure-ad-provisioning-service), you have two options. You can keep the environment in `Development` and provide the testing token from the `/scim/token` endpoint, or you can change the environment to `Production` and leave the token field empty.

-Be sure to avoid methods that aren't secure, such as username and password, in favor of a more secure method such as OAuth. Azure AD supports long-lived bearer tokens (for gallery and non-gallery applications) and the OAuth authorization grant (for gallery applications).

-> The authorization methods provided in the repo are for testing only. When you integrate with Azure AD, you can review the authorization guidance. See [Plan provisioning for a SCIM endpoint](use-scim-to-provision-users-and-groups.md).

-The default token validation code is configured to use an Azure AD token and requires the issuing tenant be configured by using the **Token:TokenIssuer** parameter in the *appsettings.json* file.

-description: System for Cross-domain Identity Management (SCIM) standardizes automatic user provisioning. In this tutorial, you learn to develop a SCIM endpoint, integrate your SCIM API with Azure Active Directory, and start automating provisioning users and groups into your cloud applications.

-# Tutorial: Develop and plan provisioning for a SCIM endpoint in Azure Active Directory

-As an application developer, you can use the System for Cross-Domain Identity Management (SCIM) user management API to enable automatic provisioning of users and groups between your application and Azure Active Directory (Azure AD). This article describes how to build a SCIM endpoint and integrate with the Azure AD provisioning service. The SCIM specification provides a common user schema for provisioning. When used with federation standards like SAML or OpenID Connect, SCIM gives administrators an end-to-end, standards-based solution for access management.

-

-To automate provisioning to an application, it requires building and integrating a SCIM endpoint that is access by the Azure AD Provisioning Service. Use the following steps to start provisioning users and groups into your application.

-1. [Design your user and group schema](#design-your-user-and-group-schema) - Identify the application's objects and attributes to determine how they map to the user and group schema supported by the Azure AD SCIM implementation.

-1. [Understand the Azure AD SCIM implementation](#understand-the-azure-ad-scim-implementation) - Understand how the Azure AD Provisioning Service is implemented to model your SCIM protocol request handling and responses.

-1. [Build a SCIM endpoint](#build-a-scim-endpoint) - An endpoint must be SCIM 2.0-compatible to integrate with the Azure AD provisioning service. As an option, use Microsoft Common Language Infrastructure (CLI) libraries and code samples to build your endpoint. These samples are for reference and testing only; we recommend against using them as dependencies in your production app.

-1. [Integrate your SCIM endpoint](#integrate-your-scim-endpoint-with-the-azure-ad-provisioning-service) with the Azure AD Provisioning Service. Azure AD supports several third-party applications that implement SCIM 2.0. If you use one of these apps, then you can quickly automate both provisioning and deprovisioning of users and groups.

-1. [Optional] [Publish your application to the Azure AD application gallery](#publish-your-application-to-the-azure-ad-application-gallery) - Make it easy for customers to discover your application and easily configure provisioning.

-1. Map SCIM attributes to the user attributes in Azure AD. If one of the attributes you've defined in your SCIM endpoint doesn't have a clear counterpart on the Azure AD user schema, guide the tenant administrator to extend their schema, or use an extension attribute as shown in the example for the `tags` property.

-|Required app attribute|Mapped SCIM attribute|Mapped Azure AD attribute|

-It helps to categorize between `/User` and `/Group` to map any default user attributes in Azure AD to the SCIM RFC, see [how customize attributes are mapped between Azure AD and your SCIM endpoint](customize-application-attributes.md).

-| Azure AD user | `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User` |

-| Azure AD group | `urn:ietf:params:scim:schemas:core:2.0:Group` |

-> You are not required to support both users and groups, or all the attributes shown here, it's only a reference on how attributes in Azure AD are often mapped to properties in the SCIM protocol.

-## Understand the Azure AD SCIM implementation

-The Azure AD Provisioning Services is designed to support a SCIM 2.0 user management API.

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

-|Accept a single bearer token for authentication and authorization of Azure AD to your application.||

-Use the general guidelines when implementing a SCIM endpoint to ensure compatibility with Azure AD:

-* Values sent should be stored in the same format they were sent. Invalid values should be rejected with a descriptive, actionable error message. Transformations of data shouldn't happen between data from Azure AD and data stored in the SCIM application. (for example. A phone number sent as 55555555555 shouldn't be saved/returned as +5 (555) 555-5555)

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

-* Microsoft Azure AD makes requests to fetch a random user and group to ensure that the endpoint and the credentials are valid. It's also done as a part of the **Test Connection** flow in the [Azure portal](https://portal.azure.com).

-* Custom complex and multivalued attributes are supported but Azure AD doesn't have many complex data structures to pull data from in these cases. Name/value attributes can be mapped to easily, but flowing data to complex attributes with three or more subattributes isn't supported.

-* The attribute that the resources can be queried on should be set as a matching attribute on the application in the [Azure portal](https://portal.azure.com), see [Customizing User Provisioning Attribute Mappings](customize-application-attributes.md).

-* Groups must have uniqueness on the 'displayName' value to match with Azure AD and the SCIM application. The uniqueness isn't a requirement of the SCIM protocol, but is a requirement for integrating a SCIM endpoint with Azure AD.

-* The Azure AD Provisioning Service makes the /schemas request when you save the provisioning configuration in the Azure portal. The request is also made when you open the edit provisioning page in the Azure portal. Other attributes discovered are surfaced to customers in the attribute mappings under the target attribute list. Schema discovery only leads to more target attributes being added. Attributes aren't removed.

-The following diagram shows the messages that Azure AD sends to a SCIM endpoint to manage the lifecycle of a user in your application's identity store.

-Group provisioning and deprovisioning are optional. When implemented and enabled, the following illustration shows the messages that Azure AD sends to a SCIM endpoint to manage the lifecycle of a group in your application's identity store. Those messages differ from the messages about users in two ways:

-This article provides example SCIM requests emitted by the Azure Active Directory (Azure AD) Provisioning Service and example expected responses. For best results, you should code your app to handle these requests in this format and emit the expected responses.

-> To understand how and when the Azure AD user provisioning service emits the operations described in the example, see the section [Provisioning cycles: Initial and incremental](how-provisioning-works.md#provisioning-cycles-initial-and-incremental) in [How provisioning works](how-provisioning-works.md).

-The Azure AD provisioning service currently operates under the IP Ranges for AzureActiveDirectory as listed [here](https://www.microsoft.com/download/details.aspx?id=56519&WT.mc_id=rss_alldownloads_all). You can add the IP ranges listed under the AzureActiveDirectory tag to allow traffic from the Azure AD provisioning service into your application. You need to review the IP range list carefully for computed addresses. An address such as '40.126.25.32' could be represented in the IP range list as '40.126.0.0/18'. You can also programmatically retrieve the IP range list using the following [API](/rest/api/virtualnetwork/servicetags/list).

-Azure AD also supports an agent based solution to provide connectivity to applications in private networks (on-premises, hosted in Azure, hosted in AWS, etc.). Customers can deploy a lightweight agent, which provides connectivity to Azure AD without opening any inbound ports, on a server in their private network. Learn more [here](./on-premises-scim-provisioning.md).

-Now that you've designed your schema and understood the Azure AD SCIM implementation, you can get started developing your SCIM endpoint. Rather than starting from scratch and building the implementation completely on your own, you can rely on many open source SCIM libraries published by the SCIM community.

-The open source .NET Core [reference code example](https://aka.ms/SCIMReferenceCode) published by the Azure AD provisioning team is one such resource that can jump start your development. Build a SCIM endpoint, then test it out. Use the collection of [Postman tests](https://github.com/AzureAD/SCIMReferenceCode/wiki/Test-Your-SCIM-Endpoint) provided as part of the reference code or run through the sample requests / responses [provided](#user-operations).

-Requests from Azure AD Provisioning Service include an OAuth 2.0 bearer token. An authorization server issues the bearer token. Azure AD is an example of a trusted authorization server. Configure the Azure AD provisioning service to use one of the following tokens:

- - The application that receives requests should validate the token issuer as being Azure AD for an expected Azure AD tenant.

- - An `iss` claim identifies the issuer of the token. For example, `"iss":"https://sts.windows.net/12345678-0000-0000-0000-000000000000/"`. In this example, the base address of the claim value, `https://sts.windows.net` identifies Azure AD as the issuer, while the relative address segment, _12345678-0000-0000-0000-000000000000_, is a unique identifier of the Azure AD tenant for which the token was issued.

- - The audience for a token is the **Application ID** for the application in the gallery. Applications registered in a single tenant receive the same `iss` claim with SCIM requests. The application ID for all custom apps is _8adf8e6e-67b2-4cf2-a259-e3dc5476c621_. The token generated by the Azure AD provisioning service should only be used for testing. It shouldn't be used in production environments.

-In the sample code, requests are authenticated using the Microsoft.AspNetCore.Authentication.JwtBearer package. The following code enforces that requests to any of the service's endpoints are authenticated using the bearer token issued by Azure AD for a specified tenant:

-Azure AD queries the service for a user with an `externalId` attribute value matching the mailNickname attribute value of a user in Azure AD. The query is expressed as a Hypertext Transfer Protocol (HTTP) request such as this example, wherein jyoung is a sample of a mailNickname of a user in Azure AD.

-> This is an example only. Not all users will have a mailNickname attribute, and the value a user has may not be unique in the directory. Also, the attribute used for matching (which in this case is `externalId`) is configurable in the [Azure AD attribute mappings](customize-application-attributes.md).

-If the response to a query to the SCIM endpoint for a user with an `externalId` attribute value that matches the mailNickname attribute value of a user doesn't return any users, then Azure AD requests that the service provision a user corresponding to the one in Azure AD. Here's an example of such a request:

-Azure AD requests the current state of the specified user from the service with a request such as:

-Azure AD checks the current attribute value in the identity store before updating it. However, only the manager attribute is the checked first for users. Here's an example of a request to determine whether the manager attribute of a user object currently has a certain value:

-***Example 5. Request from Azure AD to an SCIM endpoint to update a user***

-Here's an example of a request from Azure AD to an SCIM endpoint to update a user:

-To deprovision a user from an identity store fronted by an SCIM endpoint, Azure AD sends a request such as:

-## Integrate your SCIM endpoint with the Azure AD Provisioning Service

-Azure AD can be configured to automatically provision assigned users and groups to applications that implement a specific profile of the [SCIM 2.0 protocol](https://tools.ietf.org/html/rfc7644). The specifics of the profile are documented in [Understand the Azure AD SCIM implementation](#understand-the-azure-ad-scim-implementation).

-> The Azure AD SCIM implementation is built on top of the Azure AD user provisioning service, which is designed to constantly keep users in sync between Azure AD and the target application, and implements a very specific set of standard operations. It's important to understand these behaviors to understand the behavior of the Azure AD Provisioning Service. For more information, see the section [Provisioning cycles: Initial and incremental](how-provisioning-works.md#provisioning-cycles-initial-and-incremental) in [How provisioning works](how-provisioning-works.md).

-Applications that support the SCIM profile described in this article can be connected to Azure AD using the "non-gallery application" feature in the Azure AD application gallery. Once connected, Azure AD runs a synchronization process. The process runs every 40 minutes. The process queries the application's SCIM endpoint for assigned users and groups, and creates or modifies them according to the assignment details.

-1. Sign in to the [Azure portal](https://portal.azure.com). You can get access a free trial for Azure AD with P2 licenses by signing up for the [developer program](https://developer.microsoft.com/microsoft-365/dev-program))

-1. Browse to **Azure Active Directory** > **Enterprise applications**.

- The following screenshot shows the Azure AD application gallery:

- 

- The following screenshot shows the configuring provisioning settings in the Azure portal:

- 

-1. If the SCIM endpoint requires an OAuth bearer token from an issuer other than Azure AD, then copy the required OAuth bearer token into the optional **Secret Token** field. If this field is left blank, Azure AD includes an OAuth bearer token issued from Azure AD with each request. Apps that use Azure AD as an identity provider can validate this Azure AD-issued token.

- > It's ***not*** recommended to leave this field blank and rely on a token generated by Azure AD. This option is primarily available for testing purposes.

-1. Select **Test Connection** to have Azure AD attempt to connect to the SCIM endpoint. If the attempt fails, error information is displayed.

- > **Test Connection** queries the SCIM endpoint for a user that doesn't exist, using a random GUID as the matching property selected in the Azure AD configuration. The expected correct response is HTTP 200 OK with an empty SCIM ListResponse message.

-1. In the **Mappings** section, there are two selectable sets of [attribute mappings](customize-application-attributes.md): one for user objects and one for group objects. Select each one to review the attributes that are synchronized from Azure AD to your app. The attributes selected as **Matching** properties are used to match the users and groups in your app for update operations. Select **Save** to commit any changes.

-1. Select **Save** to start the Azure AD provisioning service.

-Once the initial cycle has started, you can select **Provisioning logs** in the left panel to monitor progress, which shows all actions done by the provisioning service on your app. For more information on how to read the Azure AD provisioning logs, see [Reporting on automatic user account provisioning](check-status-user-account-provisioning.md).

-## Publish your application to the Azure AD application gallery

-If you're building an application used by more than one tenant, make it available in the Azure AD application gallery. It's easy for organizations to discover the application and configure provisioning. Publishing your app in the Azure AD gallery and making provisioning available to others is easy. Check out the steps [here](../manage-apps/v2-howto-app-gallery-listing.md). Microsoft works with you to integrate your application into the gallery, test your endpoint, and release onboarding [documentation](../saas-apps/tutorial-list.md) for customers.

-|Username and password (not recommended or supported by Azure AD)|Easy to implement|Insecure - [Your Pa$$word doesn't matter](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/your-pa-word-doesn-t-matter/ba-p/731984)|Not supported for new gallery or non-gallery apps.|

-> It's not recommended to leave the token field blank in the Azure AD provisioning configuration custom app UI. The token generated is primarily available for testing purposes.

-1. Sign in to the [Azure portal](https://portal.azure.com), go to **Enterprise applications** > **Application** > **Provisioning** and select **Authorize**.

- 1. Azure portal redirects user to the Authorization URL (sign in page for the third party app).

- 1. Third party app redirects user back to Azure portal and provides the grant code

- 1. Azure AD Provisioning Service calls the token URL and provides the grant code. The third party application responds with the access token, refresh token, and expiry date

-> While it's not possible to setup OAuth on the non-gallery applications, you can manually generate an access token from your authorization server and input it as the secret token to a non-gallery application. This allows you to verify compatibility of your SCIM server with the Azure AD Provisioning Service before onboarding to the app gallery, which does support the OAuth code grant.

-> * Craft a blog post or press release that describes the joint integration, the benefits and how to get started. [Example: Imprivata and Azure AD Press Release](https://www.imprivata.com/company/press/imprivata-introduces-iam-cloud-platform-healthcare-supported-microsoft)

-> * Leverage your social media like Twitter, Facebook or LinkedIn to promote the integration to your customers. Be sure to include @AzureAD so we can retweet your post. [Example: Imprivata Twitter Post](https://twitter.com/azuread/status/1123964502909779968)

-> * Create a help center article or technical documentation on how customers can get started. [Example: Envoy + Microsoft Azure AD integration.](https://envoy.help/en/articles/3453335-microsoft-azure-active-directory-integration)

-description: When configuring user provisioning with Azure Active Directory and SaaS apps, use the directory extension feature to add source attributes that aren't synchronized by default.

-# Syncing extension attributes for Azure Active Directory Application Provisioning

-Azure Active Directory (Azure AD) must contain all the data (attributes) required to create a user profile when provisioning user accounts from Azure AD to a [SaaS app](../saas-apps/tutorial-list.md) or on-premises application. When customizing attribute mappings for user provisioning, you might find the attribute you want to map doesn't appear in the **Source attribute** list. This article shows you how to add the missing attribute.

-Adding missing attributes needed for an application will start in either on-premises Active Directory or in Azure AD, depending on where the user accounts reside.

-First, identify which users in your Azure AD tenant will need access to the application and therefore are going to be in scope of being provisioned into the application.

-> For users in on-premises Active Directory, you must sync the users to Azure AD. You can sync users and attributes using [Azure AD Connect](../hybrid/connect/whatis-azure-ad-connect.md) or [Azure AD Connect cloud sync](../hybrid/cloud-sync/what-is-cloud-sync.md). Both of these solutions automatically synchronizes certain attributes to Azure AD, but not all attributes. Furthermore, some attributes (such as SAMAccountName) that are synchronized by default might not be exposed using the Graph API. In these cases, you can [use the Azure AD Connect directory extension feature to synchronize the attribute to Azure AD](#create-an-extension-attribute-using-azure-ad-connect) or [use Azure AD Connect cloud sync](#create-an-extension-attribute-using-cloud-sync). That way, the attribute will be visible to the Graph API and the Azure AD provisioning service.

- 1. Configure [Azure AD Connect](../hybrid/connect/whatis-azure-ad-connect.md) or Azure AD Connect cloud sync to synchronize the users with their extension attribute from Active Directory to Azure AD. Azure AD Connect automatically synchronizes certain attributes to Azure AD, but not all attributes. Furthermore, some attributes (such as `sAMAccountName`) that are synchronized by default might not be exposed using the Graph API. In these cases, you can [use the Azure AD Connect directory extension feature to synchronize the attribute to Azure AD](#create-an-extension-attribute-using-azure-ad-connect). That way, the attribute will be visible to the Graph API and the Azure AD provisioning service.

- 1. Wait for Azure AD Connect to synchronize those updates you made in the Active Directory schema and the Active Directory users into Azure AD.

-Alternatively, if none of the users that will need access to the application originate in on-premises Active Directory, then you will need to [create schema extensions using PowerShell or Microsoft Graph](#create-an-extension-attribute-in-a-tenant-with-cloud-only-users) in Azure AD, before configuring provisioning to your application.

-Next, if one or more of the users that will need access to the application do not originate in on-premises Active Directory, then you will need to populate those cloud users in Azure AD with the required attribute, before enabling provisioning to your application. There are four ways to populate the users in bulk:

- - If the properties originate in a cloud HR system, you can configure Azure AD to read the properties from [Workday](../saas-apps/workday-inbound-cloud-only-tutorial.md) or [SAP SuccessFactors](../saas-apps/sap-successfactors-inbound-provisioning-cloud-only-tutorial.md).

- - If the properties originate in an on-premises system, you can configure the [MIM Connector for Microsoft Graph](/microsoft-identity-manager/microsoft-identity-manager-2016-connector-graph) to create or update Azure AD users.

-You can use Microsoft Graph and PowerShell to extend the user schema for users in Azure AD. This is necessary if you have any users who need that attribute and do not originate in on-premises Active Directory. (If you do have Active Directory, then continue reading below in the section on how to [use the Azure AD Connect directory extension feature to synchronize the attribute to Azure AD](#create-an-extension-attribute-using-azure-ad-connect).)

-Once schema extensions are created, these extension attributes are automatically discovered when you next visit the provisioning page in the Azure portal, in most cases.

-You can extend the schema of Azure AD users using [Microsoft Graph](/graph/overview).

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

-1. Sign in to the [Azure portal](https://portal.azure.com) with a hybrid administrator account.

-2. Select Azure AD Connect.

-3. Select **Manage Azure AD cloud sync**.

-## Create an extension attribute using Azure AD Connect

-If users who will access the applications originate in on-premises Active Directory, then you must sync the attributes with the users from Active Directory to Azure AD. You will need to perform the following tasks before configuring provisioning to your application.

-1. Open the Azure AD Connect wizard, choose Tasks, and then choose **Customize synchronization options**.

- 

-2. Sign in as an Azure AD Global Administrator.

- 

-4. Select the attribute(s) you want to extend to Azure AD.

-5. Finish the Azure AD Connect wizard and allow a full synchronization cycle to run. When the cycle is complete, the schema is extended and the new values are synchronized between your on-premises AD and Azure AD.

-6. In the Azure portal, while youΓÇÖre [editing user attribute mappings](customize-application-attributes.md), the **Source attribute** list will now contain the added attribute in the format `<attributename> (extension_<appID>_<attributename>)`, where appID is the identifier of a placeholder application in your tenant. Select the attribute and map it to the target application for provisioning.

- 

-description: An introduction to how you can use Azure Active Directory to automatically provision, deprovision, and continuously update user accounts across multiple third-party applications.

-# What is app provisioning in Azure Active Directory?

-In Azure Active Directory (Azure AD), the term *app provisioning* refers to automatically creating user identities and roles for applications.

-Azure AD application provisioning refers to automatically creating user identities and roles in the applications that users need access to. In addition to creating user identities, automatic provisioning includes the maintenance and removal of user identities as status or roles change. Common scenarios include provisioning an Azure AD user into SaaS applications like [Dropbox](../../active-directory/saas-apps/dropboxforbusiness-provisioning-tutorial.md), [Salesforce](../../active-directory/saas-apps/salesforce-provisioning-tutorial.md), [ServiceNow](../../active-directory/saas-apps/servicenow-provisioning-tutorial.md), and many more.

-Azure AD also supports provisioning users into applications hosted on-premises or in a virtual machine, without having to open up any firewalls. The table below provides a mapping of protocols to connectors supported.

-For detailed guidance on developing a SCIM endpoint to automate the provisioning and deprovisioning of users and groups to an application, see [Build a SCIM endpoint and configure user provisioning](use-scim-to-provision-users-and-groups.md). Many applications integrate directly with Azure Active Directory. Some examples include Slack, Azure Databricks, and Snowflake. For these apps, skip the developer documentation and use the tutorials provided in [Tutorials for integrating SaaS applications with Azure Active Directory](../../active-directory/saas-apps/tutorial-list.md).

-Applications in the Azure AD gallery support one of two provisioning modes:

-* **Manual** provisioning means there's no automatic Azure AD provisioning connector for the app yet. You must create them manually. Examples are adding users directly into the app's administrative portal or uploading a spreadsheet with user account detail. Consult the documentation provided by the app, or contact the app developer to determine what mechanisms are available.

-* **Automatic** means that an Azure AD provisioning connector is available this application. Follow the setup tutorial specific to setting up provisioning for the application. Find the app tutorials at [Tutorials for integrating SaaS applications with Azure Active Directory](../../active-directory/saas-apps/tutorial-list.md).

-Azure AD user provisioning can help address these challenges. To learn more about how customers have been using Azure AD user provisioning, read the [ASOS case study](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/asos-better-protects-its-data-with-azure-ad-automated-user/ba-p/827846). The following video provides an overview of user provisioning in Azure AD.

-## What applications and systems can I use with Azure AD automatic user provisioning?

-Azure AD features preintegrated support for many popular SaaS apps and human resources systems, and generic support for apps that implement specific parts of the [SCIM 2.0 standard](https://techcommunity.microsoft.com/t5/security-compliance-and-identity/provisioning-with-scim-getting-started/ba-p/880010).

-* **Preintegrated applications (gallery SaaS apps)**: You can find all applications for which Azure AD supports a preintegrated provisioning connector in [Tutorials for integrating SaaS applications with Azure Active Directory](../saas-apps/tutorial-list.md). The preintegrated applications listed in the gallery generally use SCIM 2.0-based user management APIs for provisioning.

- To request a new application for provisioning, see [Submit a request to publish your application in Azure Active Directory application gallery](../manage-apps/v2-howto-app-gallery-listing.md). For a user provisioning request, we require the application to have a SCIM-compliant endpoint. Request that the application vendor follows the SCIM standard so we can onboard the app to our platform quickly.

-For preintegrated applications listed in the gallery, use existing step-by-step guidance to set up automatic provisioning, see [Tutorials for integrating SaaS applications with Azure Active Directory](../saas-apps/tutorial-list.md). The following video shows you how to set up automatic user provisioning for SalesForce.

-HR driven provisioning is the process of creating digital identities based on a human resources system. The HR systems, become the start-of-authority for these newly created digital identities and is often the starting point for numerous provisioning processes. For example, if a new employee joins your company, they are created in the human resource system. The creation, triggers the provisioning of a user account into Active Directory and then Azure AD Connect provisions this account to Azure AD, etc.

-Using MIM, you can provision users from your on-premises HR systems to Active Directory or Azure AD.

-description: Learn which which attributes that you can fetch from Workday using XPATH queries in Azure Active Directory.

-# Workday attribute reference for Azure Active Directory

-The table below provides a list of other commonly used custom XPATH API expressions when provisioning workers from Workday to Active Directory or Azure AD. Please test the XPATH API expressions provided here with your version of Workday referring to the instructions captured in the section [Tutorial: Managing your configuration](../saas-apps/workday-inbound-tutorial.md#managing-your-configuration).

-description: Technical deep dive into Workday-HR driven provisioning in Azure Active Directory

-# How Azure Active Directory provisioning integrates with Workday

-[Azure Active Directory user provisioning service](../app-provisioning/user-provisioning.md) integrates with [Workday HCM](https://www.workday.com) to manage the identity life cycle of users. Azure Active Directory offers three prebuilt integrations:

-* [Workday to Azure Active Directory user provisioning](../saas-apps/workday-inbound-cloud-only-tutorial.md)

-### Restricting Workday API access to Azure AD endpoints

-Azure AD provisioning service uses basic authentication to connect to Workday Web Services API endpoints.

-To further secure the connectivity between Azure AD provisioning service and Workday, you can restrict access so that the designated integration system user only accesses the Workday APIs from allowed Azure AD IP ranges. Engage your Workday administrator to complete the following configuration in your Workday tenant.

-1. Open the file and search for tag **AzureActiveDirectory**

- >

-1. Access the **Manage Authentication Policies** task to create a new authentication policy. In the authentication policy, use the authentication allowlist to specify the Azure AD IP range and the security group that is allowed access from this IP range. Save the changes.

-* **Phased rollout scenario**: You have a large Workday tenant and plan to perform a phased rollout of Workday to Azure AD automated provisioning. In this scenario, rather than excluding users who aren't in scope of the current phase with Azure AD scoping filters, we recommend configuring constrained ISSG so that only in-scope workers are visible to Azure AD.

-* **Multiple provisioning jobs scenario**: You have a large Workday tenant and multiple AD domains each supporting a different business unit/division/company. To support this topology, you would like to run multiple Workday to Azure AD provisioning jobs with each job provisioning a specific set of workers. In this scenario, rather than using Azure AD scoping filters to exclude worker data, we recommend configuring constrained ISSG so that only the relevant worker data is visible to Azure AD.

-To test connectivity to Workday, Azure AD sends the following *Get_Workers* Workday Web Services request.

-**Full sync** in the context of Workday-driven provisioning refers to the process of fetching all identities from Workday and determining what provisioning rules to apply to each worker object. Full sync happens when you turn on provisioning for the first time and also when you *restart provisioning* either from the Azure portal or using Graph APIs.

-Azure AD sends the following *Get_Workers* Workday Web Services request to retrieve worker data. The query looks up the Workday transaction log for all effective dated worker entries as of the time corresponding to the full sync run.

-Certain flag values specified in the *Response_Group* node are calculated based on the attributes configured in the Workday Azure AD provisioning application. Refer to the section on *Supported entities* for the criteria used to set the flag values.

-Azure AD provisioning service processes each page and iterates through the all effective workers during full sync.

-After full sync, Azure AD provisioning service maintains `LastExecutionTimestamp` and uses it to create delta queries to retrieve incremental changes. During incremental sync, Azure AD sends the following types of queries to Workday:

->Future-dated hires in Workday have the Active field set to "0" and it changes to "1" on the hire date. The connector by design queries for future-hire information effective on the date of hire and that is why it always gets future hire Worker profile with Active field set to "1". This allows you to setup the Azure AD profile for future hires in advance with the all the right information pre-populated. If you'd like to delay the enabling of the Azure AD account for future hires, use the transformation function [DateDiff](functions-for-customizing-application-data.md#datediff).

-The *Get_Workers* API can return different data sets associated with a worker. Depending on the [XPATH API expressions](workday-attribute-reference.md) configured in the provisioning schema, Azure AD provisioning service determines which data sets to retrieve from Workday. Accordingly, the *Response_Group* flags are set in the *Get_Workers* request.

-1. Sign in to the [Azure portal](https://portal.azure.com) and open your Workday to AD/Azure AD user provisioning app.

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

-This section describes the Azure AD provisioning service support for scenarios when a worker converts from full-time employee (FTE) to contingent worker (CW) or vice versa. Depending on how worker conversions are processed in Workday, there may be different implementation aspects to consider.

-* The Azure AD provisioning service detects this change in the Workday transaction log on January 15, 2023. The service automatically provision attributes of the new FTE profile in the next sync cycle.

-This scenario is similar to the above scenario, except that instead of backdating the transaction, HR performs a worker conversion that is effective immediately. The Azure AD provisioning service detects this change in the Workday transaction log. In the next sync cycle, the service automatically provisions any associated attributes with an active FTE profile. No changes are required in the provisioning app configuration to handle this scenario.

-* On April 15, during incremental cycle, the Azure AD provisioning service automatically transfers ownership of the AD account to the active worker profile. In this case, it unlinks the contingent worker profile from the AD account and establishes a new link between John's active employee worker profile and John's AD account.

-* Since Azure AD provisioning service automatically processes future-dated hires, it processes John's new full-time employee worker profile on January 15, and update John's profile in AD with full-time employment details even though he's still a contingent worker.

- 1. Update the Azure AD provisioning app to read this provisioning group. Refer to instructions here on how to [retrieve the provisioning group](#example-3-retrieving-provisioning-group-assignments)

- 1. Create a [scoping filter](define-conditional-rules-for-provisioning-user-accounts.md) in Azure AD to exclude worker profiles that are part of this provisioning group.

-# Configure Azure AD provisioning to retrieve pronoun information from Workday

-* [Workday to Azure Active Directory user provisioning](../saas-apps/workday-inbound-cloud-only-tutorial.md)

-1. Select the Workday Integration System Security Group used with your Azure AD integration. Update the [domain permissions for the security group](../saas-apps/workday-inbound-tutorial.md#configuring-domain-security-policy-permissions), so it has GET access for the Workday domain **Reports: Public Profile**.

-1. Use Workday Studio or Postman to invoke [Get_Workers API version 38.1](https://community.workday.com/sites/default/files/file-hosting/productionapi/Human_Resources/v38.1/Get_Workers.html) for the test user using the Workday Azure AD integration system user. In the SOAP request header, specify the option Include_Reference_Descriptors_In_Response.

-Once you confirm that pronoun data is available in the *Get_Workers* response, go to the next step of updating your Azure AD provisioning app configuration.

-## Updating Azure AD provisioning app to retrieve pronouns

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

-1. Sign in to the [Azure portal](https://portal.azure.com) as an administrator.

-1. Open your *Workday to AD User provisioning* app OR *Workday to Azure AD User provisioning* app.

- >

-1. You can now add a new attribute mapping to flow the Workday attribute **PreferredPronoun** to any attribute in AD/Azure AD.

-1. If worker *Aaron Hall* has set his pronoun information in Workday as `HE/HIM`, the above expression sets the display name in Azure AD as: *Aaron Hall (HE/HIM)*

-## Overview

- If you change the internal URL but donΓÇÖt want to change the landing page for users, change the Home page URL to the previously published internal URL. This can be done by going to ΓÇ£Microsoft Entra IDΓÇ¥ -&gt; App Registrations -&gt; select the application -&gt; Branding. In the branding section, you see the field ΓÇ£Home Page URLΓÇ¥, which you can adjust to be the desired landing page. If you are still using the legacy App registrations experience the properties tab would show the "Home Page URL" details.

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

- >

-description: How to resolve common access issues with Azure Active Directory Application Proxy applications.

-This article helps you troubleshoot common issues for the "This corporate app can't be accessed" error on an Azure AD Application Proxy application.

-If you see a forbidden error, the user has not been assigned to the application. This error could be either in Azure Active Directory or on the backend application.

-Verify that all required ports are open. For required ports, see the open ports section of [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](application-proxy-add-on-premises-application.md). If all the required ports are open, move to the next section.

-If your application is configured to use integrated Windows authentication (IWA), test the application without single sign-on. If not, move to the next paragraph. To check the application without single sign-on, open your application through **Enterprise Applications,** and go to the **Single Sign-On** menu. Change the drop-down from "Integrated Windows authentication" to "Azure AD single sign-on disabled".

-[Understand Azure AD Application Proxy connectors](application-proxy-connectors.md)

-description: Covers how to troubleshoot errors in Azure Active Directory Application Proxy.

-If errors occur in accessing a published application or in publishing applications, check the following options to see if Microsoft Azure AD Application Proxy is working correctly:

-* Open the Windows Services console. Verify that the **Microsoft AAD Application Proxy Connector** service is enabled and running. You may also want to look at the Application Proxy service properties page, as shown in the following image:

- 

-If registration fails during the Connector wizard installation, there are two ways to view the reason for the failure. Either look in the event log under **Windows Logs\Application** (filter by Source = "Microsoft AAD Application Proxy Connector" , or run the following Windows PowerShell command:

-| Connector registration failed: Make sure you enabled Application Proxy in the Azure Management Portal and that you entered your Active Directory user name and password correctly. Error: 'One or more errors occurred.' | If you closed the registration window without signing in to Azure AD, run the Connector wizard again and register the Connector. <br><br> If the registration window opens and then immediately closes without allowing you to log in, you'll probably get this error. This error occurs when there is a networking error on your system. Make sure that it's possible to connect from a browser to a public website and that the ports are open as specified in [Application Proxy prerequisites](application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment). |

-| Connector registration failed: Make sure you enabled Application Proxy in the Azure Management Portal and that you entered your Active Directory user name and password correctly. Error: 'AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials and search by service principal URI has failed. | You're trying to sign in using a Microsoft Account and not a domain that is part of the organization ID of the directory you're trying to access. Make sure that the admin is part of the same domain name as the tenant domain, for example, if the Azure AD domain is contoso.com, the admin should be admin@contoso.com. |

-| Connector registration failed: Make sure you are an Application Administrator of your Active Directory to register the Connector. Error: 'The registration request was denied.' | The alias you're trying to log in with isn't an admin on this domain. Your Connector is always installed for the directory that owns the userΓÇÖs domain. Make sure that the admin account you're trying to sign in with has at least application administrator permissions to the Azure AD tenant. |

-| 12008 - Azure AD exceeded the maximum number of permitted Kerberos authentication attempts to the backend server. | This error may indicate incorrect configuration between Azure AD and the backend application server, or a problem in time and date configuration on both machines. The backend server declined the Kerberos ticket created by Azure AD. Verify that Azure AD and the backend application server are configured correctly. Make sure that the time and date configuration on the Azure AD and the backend application server are synchronized. |

-| 13016 - Azure AD cannot retrieve a Kerberos ticket on behalf of the user because there is no UPN in the edge token or in the access cookie. | There is a problem with the STS configuration. Fix the UPN claim configuration in the STS. |

-| 13019 - Azure AD cannot retrieve a Kerberos ticket on behalf of the user because of the following general API error. | This event may indicate incorrect configuration between Azure AD and the domain controller server, or a problem in time and date configuration on both machines. The domain controller declined the Kerberos ticket created by Azure AD. Verify that Azure AD and the backend application server are configured correctly, especially the SPN configuration. Make sure the Azure AD is domain joined to the same domain as the domain controller to ensure that the domain controller establishes trust with Azure AD. Make sure that the time and date configuration on the Azure AD and the domain controller are synchronized. |

-| 13020 - Azure AD cannot retrieve a Kerberos ticket on behalf of the user because the backend server SPN is not defined. | This event may indicate incorrect configuration between Azure AD and the domain controller server, or a problem in time and date configuration on both machines. The domain controller declined the Kerberos ticket created by Azure AD. Verify that Azure AD and the backend application server are configured correctly, especially the SPN configuration. Make sure the Azure AD is domain joined to the same domain as the domain controller to ensure that the domain controller establishes trust with Azure AD. Make sure that the time and date configuration on the Azure AD and the domain controller are synchronized. |

-| 13022 - Azure AD cannot authenticate the user because the backend server responds to Kerberos authentication attempts with an HTTP 401 error. | This event may indicate incorrect configuration between Azure AD and the backend application server, or a problem in time and date configuration on both machines. The backend server declined the Kerberos ticket created by Azure AD. Verify that Azure AD and the backend application server are configured correctly. Make sure that the time and date configuration on the Azure AD and the backend application server are synchronized. For more information, see [Troubleshoot Kerberos Constrained Delegation Configurations for Application Proxy](application-proxy-back-end-kerberos-constrained-delegation-how-to.md). |

-| This corporate app canΓÇÖt be accessed. You are not authorized to access this application. Authorization failed. Make sure that the user has a license for Azure Active Directory Premium. | Your user may get this error when trying to access the app you published if they weren't explicitly assigned with a Premium license by the subscriberΓÇÖs administrator. Go to the subscriberΓÇÖs Active Directory **Licenses** tab and make sure that this user or user group is assigned a Premium license. |

-| A server with the specified host name could not be found. | Your user may get this error when trying to access the app you published if the application's custom domain is not configured correctly. Make sure you've uploaded a certificate for the domain and configured the DNS record correctly by following the steps in [Working with custom domains in Azure AD Application Proxy](./application-proxy-configure-custom-domain.md) |

-* [Enable Application Proxy for Azure Active Directory](application-proxy-add-on-premises-application.md)

-description: Provides an understanding of CORS in Azure Active Directory Application Proxy, and how to identify and solve CORS issues.

-# Understand and solve Azure Active Directory Application Proxy CORS issues

-[Cross-origin resource sharing (CORS)](https://www.w3.org/TR/cors/) can sometimes present challenges for the apps and APIs you publish through the Azure Active Directory Application Proxy. This article discusses Azure AD Application Proxy CORS issues and solutions.

-The following example shows a typical Azure AD Application Proxy CORS scenario. The internal server hosts a **CORSWebService** web API controller, and a **CORSWebClient** that calls **CORSWebService**. There's an AJAX request from **CORSWebClient** to **CORSWebService**.

-The CORSWebClient app works when you host it on-premises, but either fails to load or errors out when published through Azure AD Application Proxy. If you published the CORSWebClient and CORSWebService apps separately as different apps through Application Proxy, the two apps are hosted at different domains. An AJAX request from CORSWebClient to CORSWebService is a cross-origin request, and it fails.

-Use an Azure AD Application Proxy [custom domain](./application-proxy-configure-custom-domain.md) to publish from the same origin, without having to make any changes to app origins, code, or headers.

-The following examples show the portal Azure AD Application Proxy page for the CORSWebClient app. When the **Internal URL** is set to *contoso.com/CORSWebClient*, the app can't make successful requests to the *contoso.com/CORSWebService* directory, because they're cross-origin.

-Some CORS issues can't be resolved, such as when your app redirects to *login.microsoftonline.com* to authenticate, and the access token expires. The CORS call then fails. A workaround for this scenario is to extend the lifetime of the access token, to prevent it from expiring during a userΓÇÖs session. For more information about how to do this, see [Configurable token lifetimes in Azure AD](../develop/configurable-token-lifetimes.md).

-description: Learn how to use Wildcard applications in Azure Active Directory Application Proxy.

-# Wildcard applications in the Azure Active Directory Application Proxy

-In Azure Active Directory (Azure AD), configuring a large number of on-premises applications can quickly become unmanageable and introduces unnecessary risks for configuration errors if many of them require the same settings. With [Azure AD Application Proxy](application-proxy.md), you can address this issue by using wildcard application publishing to publish and manage many applications at once. This is a solution that allows you to:

-You can publish the wildcard application using the steps outlined in [Publish applications using Azure AD Application Proxy](application-proxy-add-on-premises-application.md). This scenario assumes:

-description: Azure Active Directory's Application Proxy provides secure remote access to on-premises web applications. After a single sign-on to Azure AD, users can access both cloud and on-premises applications through an external URL or an internal application portal. For example, Application Proxy can provide remote access and single sign-on to Remote Desktop, SharePoint, Teams, Tableau, Qlik, and line of business (LOB) applications.

-# Remote access to on-premises applications through Azure AD Application Proxy

-Azure Active Directory's Application Proxy provides secure remote access to on-premises web applications. After a single sign-on to Azure AD, users can access both cloud and on-premises applications through an external URL or an internal application portal. For example, Application Proxy can provide remote access and single sign-on to Remote Desktop, SharePoint, Teams, Tableau, Qlik, and line of business (LOB) applications.

-Azure AD Application Proxy is:

-Application Proxy is a feature of Azure AD that enables users to access on-premises web applications from a remote client. Application Proxy includes both the Application Proxy service which runs in the cloud, and the Application Proxy connector which runs on an on-premises server. Azure AD, the Application Proxy service, and the Application Proxy connector work together to securely pass the user sign-on token from Azure AD to the web application.

-The following diagram shows how Azure AD and Application Proxy work together to provide single sign-on to on-premises applications.

-

-1. After the user has accessed the application through an endpoint, the user is directed to the Azure AD sign-in page.

-2. After a successful sign-in, Azure AD sends a token to the user's client device.

-> Like most Azure AD hybrid agents, the Application Proxy Connector doesn't require you to open inbound connections through your firewall. User traffic in step 3 terminates at the Application Proxy Service (in Azure AD). The Application Proxy Connector (on-premises) is responsible for the rest of the communication.

-| Endpoint | The endpoint is a URL or an [end-user portal](../manage-apps/end-user-experiences.md). Users can reach applications while outside of your network by accessing an external URL. Users within your network can access the application through a URL or an end-user portal. When users go to one of these endpoints, they authenticate in Azure AD and then are routed through the connector to the on-premises application.|

-| Azure AD | Azure AD performs the authentication using the tenant directory stored in the cloud. |

-| Application Proxy service | This Application Proxy service runs in the cloud as part of Azure AD. It passes the sign-on token from the user to the Application Proxy Connector. Application Proxy forwards any accessible headers on the request and sets the headers as per its protocol, to the client IP address. If the incoming request to the proxy already has that header, the client IP address is added to the end of the comma separated list that is the value of the header.|

-| Application Proxy Connector | The connector is a lightweight agent that runs on a Windows Server inside your network. The connector manages communication between the Application Proxy service in the cloud and the on-premises application. The connector only uses outbound connections, so you don't have to open any inbound ports or put anything in the DMZ. The connectors are stateless and pull information from the cloud as necessary. For more information about connectors, like how they load-balance and authenticate, see [Understand Azure AD Application Proxy connectors](application-proxy-connectors.md).|

-description: Troubleshooting common issues faced when you are unable to sign in to an on-premises application integrated using the Azure Active Directory Application Proxy

-# Problems signing in to an on-premises application using the Azure Active Directory Application Proxy

-## I'm having a problem configuring the Azure AD Application Proxy in the admin portal

-[How to provide secure remote access to on-premises applications](application-proxy.md)

-description: PowerShell example that assigns a group to an Azure Active Directory (Azure AD) Application Proxy application.

-# Assign a group to a specific Azure AD Application Proxy application

-This PowerShell script example allows you to assign a specific group to an Azure Active Directory (Azure AD) Application Proxy application.

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

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-description: PowerShell example that assigns a user to an Azure Active Directory (Azure AD) Application Proxy application.

-# Assign a user to a specific Azure Active Directory Application Proxy application

-This PowerShell script example allows you to assign a user to a specific Azure AD Application Proxy application.

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

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-description: PowerShell example that lists all the users and groups assigned to a specific Azure Active Directory (Azure AD) Application Proxy application.

-This PowerShell script example lists the users and groups assigned to a specific Azure Active Directory (Azure AD) Application Proxy application.

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

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-description: PowerShell example that lists Azure Active Directory (Azure AD) Application Proxy applications along with the application ID (AppId), name (DisplayName), and object ID (ObjId).

-This PowerShell script example lists information about all Azure Active Directory (Azure AD) Application Proxy applications, including the application ID (AppId), name (DisplayName), and object ID (ObjId).

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

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-description: PowerShell example that lists all Azure Active Directory (Azure AD) Application Proxy Connector groups with the assigned applications.

-This PowerShell script example lists information about all Azure Active Directory (Azure AD) Application Proxy Connector groups with the assigned applications.

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

-|[Get-AzureADApplication](/powershell/module/azuread/get-azureadapplication) | Gets an Azure AD application. |

-|[Get-AzureADApplicationProxyApplication](/powershell/module/azuread/get-azureadapplicationproxyapplication) | Retrieves an application configured for Application Proxy in Azure AD. |

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-description: PowerShell example that lists all Azure Active Directory (Azure AD) Application Proxy applications along with the application ID (AppId), name (DisplayName), external URL (ExternalUrl), internal URL (InternalUrl), and authentication type (ExternalAuthenticationType).

-This PowerShell script example lists information about all Azure Active Directory (Azure AD) Application Proxy applications, including the application ID (AppId), name (DisplayName), external URL (ExternalUrl), internal URL (InternalUrl), authentication type (ExternalAuthenticationType), SSO mode and further settings.

-This sample requires the [AzureAD V2 PowerShell for Graph module](/powershell/azure/active-directory/install-adv2) (AzureAD).

-|[Get-AzureADApplication](/powershell/module/azuread/get-azureadapplication) | Gets an Azure AD application. |

-|[Get-AzureADApplicationProxyApplication](/powershell/module/azuread/get-azureadapplicationproxyapplication) | Retrieves an application configured for Application Proxy in Azure AD. |

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-description: PowerShell example that lists all Azure Active Directory (Azure AD) Application Proxy applications in your directory that have a lifetime token policy.

-This PowerShell script example lists all the Azure Active Directory (Azure AD) Application Proxy applications in your directory that have a token lifetime policy and lists details about the policy.

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

-|[Get-AzureADApplication](/powershell/module/azuread/get-azureadapplication) | Gets an Azure AD application. |

-|[Get-AzureADPolicy](/powershell/module/azuread/get-azureadpolicy?view=azureadps-2.0-preview&preserve-view=true) | Gets a policy in Azure AD. |

-|[Get-AzureADServicePrincipalPolicy](/powershell/module/azuread/get-azureadserviceprincipalpolicy?view=azureadps-2.0-preview&preserve-view=true) | Gets the policy of a service principal in Azure AD. |

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-description: PowerShell example that lists all Azure Active Directory (Azure AD) Application Proxy connector groups and connectors in your directory.

-This PowerShell script example lists all Azure Active Directory (Azure AD) Application Proxy connector groups and connectors in your directory.

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

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-description: PowerShell example that lists all Azure Active Directory (Azure AD) Application Proxy applications that are using custom domains but do not have a valid TLS/SSL certificate uploaded.

-This PowerShell script example lists all Azure Active Directory (Azure AD) Application Proxy apps that are using custom domains but do not have a valid TLS/SSL certificate uploaded.

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

-|[Get-AzureADApplication](/powershell/module/azuread/get-azureadapplication) | Gets an Azure AD application. |

-|[Get-AzureADApplicationProxyApplication](/powershell/module/azuread/get-azureadapplicationproxyapplication) | Retrieves an application configured for Application Proxy in Azure AD. |

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-description: PowerShell example that lists all Azure Active Directory (Azure AD) Application Proxy applications that are using custom domains and certificate information.

-This PowerShell script example lists all Azure Active Directory (Azure AD) Application Proxy applications that are using custom domains and lists the certificate information associated with the custom domains.

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

-|[Get-AzureADApplication](/powershell/module/azuread/get-azureadapplication) | Gets an Azure AD application. |

-|[Get-AzureADApplicationProxyApplication](/powershell/module/azuread/get-azureadapplicationproxyapplication) | Retrieves an application configured for Application Proxy in Azure AD. |

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-description: PowerShell example that lists all Azure Active Directory (Azure AD) Application Proxy applications that are using default domains (.msappproxy.net).

-This PowerShell script example lists all the Azure Active Directory (Azure AD) Application Proxy applications that are using default domains (.msappproxy.net).

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

-|[Get-AzureADApplication](/powershell/module/azuread/get-azureadapplication) | Gets an Azure AD application. |

-|[Get-AzureADApplicationProxyApplication](/powershell/module/azuread/get-azureadapplicationproxyapplication) | Retrieves an application configured for Application Proxy in Azure AD. |

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-description: PowerShell example that lists all Azure Active Directory (Azure AD) Application Proxy applications that are using wildcards.

-This PowerShell script example lists all Azure Active Directory (Azure AD) Application Proxy applications that are using wildcard publishing.

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

-|[Get-AzureADApplication](/powershell/module/azuread/get-azureadapplication) | Gets an Azure AD application. |

-|[Get-AzureADApplicationProxyApplication](/powershell/module/azuread/get-azureadapplicationproxyapplication) | Retrieves an application configured for Application Proxy in Azure AD. |

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-description: PowerShell example that lists all Azure Active Directory (Azure AD) Application Proxy applications that are published with the identical certificate.

-# Get all Azure Active Directory Application Proxy apps that are published with the identical certificate

-This PowerShell script example lists all Azure Active Directory (Azure AD) Application Proxy applications that are published with the identical certificate.

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

-|[Get-AzureADApplication](/powershell/module/azuread/get-azureadapplication) | Gets an Azure AD application. |

-|[Get-AzureADApplicationProxyApplication](/powershell/module/azuread/get-azureadapplicationproxyapplication) | Retrieves an application configured for Application Proxy in Azure AD. |

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-description: PowerShell example that bulk replaces a certificate across Azure Active Directory (Azure AD) Application Proxy applications.

-# Get all Azure Active Directory Application Proxy applications published with the identical certificate and replace it

-This PowerShell script example allows you to replace the certificate in bulk for all the Azure Active Directory (Azure AD) Application Proxy applications that are published with the identical certificate.

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

-|[Get-AzureADApplication](/powershell/module/azuread/get-azureadapplication) | Gets an Azure AD application. |

-|[Get-AzureADApplicationProxyApplication](/powershell/module/azuread/get-azureadapplicationproxyapplication) | Retrieves an application configured for Application Proxy in Azure AD. |

-|[Set-AzureADApplicationProxyApplicationCustomDomainCertificate](/powershell/module/azuread/set-azureadapplicationproxyapplicationcustomdomaincertificate) | Assigns a certificate to an application configured for Application Proxy in Azure AD. This command uploads the certificate and allows the application to use Custom Domains. |

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-description: Azure Active Directory (Azure AD) Application Proxy PowerShell example used to move all applications currently assigned to a connector group to a different connector group.

-# Move all Azure Active Directory Application Proxy apps assigned to a connector group to another connector group

-This PowerShell script example moves all Azure Active Directory (Azure AD) Application Proxy applications currently assigned to a connector group to a different connector group.

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

-|[Get-AzureADApplication](/powershell/module/azuread/get-azureadapplication) | Gets an Azure AD application. |

-For other PowerShell examples for Application Proxy, see [Azure AD PowerShell examples for Azure AD Application Proxy](../application-proxy-powershell-samples.md).

-# Using Azure AD Application Proxy to publish on-premises apps for remote users

-Azure Active Directory (Azure AD) offers many capabilities for protecting users, apps, and data in the cloud and on-premises. In particular, the Azure AD Application Proxy feature can be implemented by IT professionals who want to publish on-premises web applications externally. Remote users who need access to internal apps can then access them in a secure manner.

-Perhaps you're already using Azure AD to manage users in the cloud who need to access Microsoft 365 and other SaaS applications, as well as web apps hosted on-premises. If you already have Azure AD, you can leverage it as one control plane to allow seamless and secure access to your on-premises applications. Or, maybe you're still contemplating a move to the cloud. If so, you can begin your journey to the cloud by implementing Application Proxy and taking the first step towards building a strong identity foundation.

-This article explains how Azure AD and Application Proxy give remote users a single sign-on (SSO) experience. Users securely connect to on-premises apps without a VPN or dual-homed servers and firewall rules. This article helps you understand how Application Proxy brings the capabilities and security advantages of the cloud to your on-premises web applications. It also describes the architecture and topologies that are possible.

-In today's cloud-first world, Azure AD is best suited to control who and what gets into your network. Azure AD Application Proxy integrates with modern authentication and cloud-based technologies, like SaaS applications and identity providers. This integration enables users to access apps from anywhere. Not only is App Proxy more suited for today's digital workplace, it's more secure than VPN and reverse proxy solutions and easier to implement. Remote users can access your on-premises applications the same way they access Microsoft and other SaaS apps integrated with Azure AD. You don't need to change or update your applications to work with Application Proxy. Furthermore, App Proxy doesn't require you to open inbound connections through your firewall. With App Proxy, you simply set it and forget it.

-In today's digital workplace, users work anywhere with multiple devices and apps. The only constant is user identity. That's why the first step to a secure network today is to use [Azure AD's identity management](../../security/fundamentals/identity-management-overview.md) capabilities as your security control plane. A model that uses identity as your control plane is typically comprised of the following components:

-With Application Proxy, Azure AD keeps track of users who need to access web apps published on-premises and in the cloud. It provides a central management point for those apps. While not required, it's recommended you also enable Azure AD Conditional Access. By defining conditions for how users authenticate and gain access, you further ensure that the right people access your applications.

-> It's important to understand that Azure AD Application Proxy is intended as a VPN or reverse proxy replacement for roaming (or remote) users who need access to internal resources. It's not intended for internal users on the corporate network. Internal users who unnecessarily use Application Proxy can introduce unexpected and undesirable performance issues.

-

-Application Proxy is an Azure AD service you configure in the Microsoft Entra admin center. It enables you to publish an external public HTTP/HTTPS URL endpoint in the Azure Cloud, which connects to an internal application server URL in your organization. These on-premises web apps can be integrated with Azure AD to support single sign-on. Users can then access on-premises web apps in the same way they access Microsoft 365 and other SaaS apps.

-Components of this feature include the Application Proxy service, which runs in the cloud, the Application Proxy connector, which is a lightweight agent that runs on an on-premises server, and Azure AD, which is the identity provider. All three components work together to provide the user with a single sign-on experience to access on-premises web applications.

-

-* [**Forms- or password-based authentication**](./application-proxy-configure-single-sign-on-password-vaulting.md). With this authentication method, users sign on to the application with a username and password the first time they access it. After the first sign-on, Azure AD supplies the username and password to the application. In this scenario, authentication is handled by Azure AD.

-* [**SAML authentication**](./application-proxy-configure-single-sign-on-on-premises-apps.md). SAML-based single sign-on is supported for applications that use either SAML 2.0 or WS-Federation protocols. With SAML single sign-on, Azure AD authenticates to the application by using the user's Azure AD account.

-The remote access solution offered by Application Proxy and Azure AD support several security benefits customers may take advantage of, including:

-* **Security Analytics and Machine Learning (ML) based intelligence**. Because it's part of Azure Active Directory, Application Proxy can leverage [Azure AD Identity Protection](../identity-protection/overview-identity-protection.md) (requires [Premium P2 licensing](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing)). Azure AD Identity Protection combines machine-learning security intelligence with data feeds from Microsoft's [Digital Crimes Unit](https://news.microsoft.com/stories/cybercrime/https://docsupdatetracker.net/index.html) and [Microsoft Security Response Center](https://www.microsoft.com/msrc) to proactively identify compromised accounts. Identity Protection offers real-time protection from high-risk sign-ins. It takes into consideration factors like accesses from infected devices, through anonymizing networks, or from atypical and unlikely locations to increase the risk profile of a session. This risk profile is used for real-time protection. Many of these reports and events are already available through an API for integration with your SIEM systems.

-Another major benefit of implementing Application Proxy is extending Azure AD to your on-premises environment. In fact, implementing App Proxy is a key step in moving your organization and apps to the cloud. By moving to the cloud and away from on-premises authentication, you reduce your on-premises footprint and use Azure AD's identity management capabilities as your control plane. With minimal or no updates to existing applications, you have access to cloud capabilities such as single sign-on, multi-factor authentication, and central management. Installing the necessary components to App Proxy is a simple process for establishing a remote access framework. And by moving to the cloud, you have access to the latest Azure AD features, updates, and functionality, such as high availability and the disaster recovery.

-To learn more about migrating your apps to Azure AD, see the [Migrating Your Applications to Azure Active Directory](../manage-apps/migration-resources.md).

-The following diagram illustrates in general how Azure AD authentication services and Application Proxy work together to provide single sign-on to on-premises applications to users.

-

-1. After the user has accessed the application through an endpoint, the user is redirected to the Azure AD sign-in page. If you've configured Conditional Access policies, specific conditions are checked at this time to ensure that you comply with your organization's security requirements.

-2. After a successful sign-in, Azure AD sends a token to the user's client device.

-|Endpoint|The endpoint is a URL or an [user portal](../manage-apps/end-user-experiences.md). Users can reach applications while outside of your network by accessing an external URL. Users within your network can access the application through a URL or a user portal. When users go to one of these endpoints, they authenticate in Azure AD and then are routed through the connector to the on-premises application.|

-|Azure AD|Azure AD performs the authentication using the tenant directory stored in the cloud.|

-|Application Proxy service|This Application Proxy service runs in the cloud as part of Azure AD. It passes the sign-on token from the user to the Application Proxy Connector. Application Proxy forwards any accessible headers on the request and sets the headers as per its protocol, to the client IP address. If the incoming request to the proxy already has that header, the client IP address is added to the end of the comma-separated list that is the value of the header.|

-|Application Proxy connector|The connector is a lightweight agent that runs on a Windows Server inside your network. The connector manages communication between the Application Proxy service in the cloud and the on-premises application. The connector only uses outbound connections, so you don't have to open any inbound ports or put anything in the DMZ. The connectors are stateless and pull information from the cloud as necessary. For more information about connectors, like how they load-balance and authenticate, see [Understand Azure AD Application Proxy connectors](./application-proxy-connectors.md).|

-Azure AD Application Proxy consists of the cloud-based Application Proxy service and an on-premises connector. The connector listens for requests from the Application Proxy service and handles connections to the internal applications. It's important to note that all communications occur over TLS, and always originate at the connector to the Application Proxy service. That is, communications are outbound only. The connector uses a client certificate to authenticate to the Application Proxy service for all calls. The only exception to the connection security is the initial setup step where the client certificate is established. See the Application Proxy [Under the hood](./application-proxy-security.md#under-the-hood) for more details.

-

-1. The IT administrator opens ports 80 and 443 to outbound traffic and allows access to several URLs that are needed by the connector, the App Proxy service, and Azure AD.

-4. The admin adds the on-premises application to Azure AD and configures settings such as the URLs users need to connect to their apps.

-For more information, see [Plan an Azure AD Application Proxy deployment](./application-proxy-deployment-plan.md).

-For more information about choosing where to install your connectors and optimizing your network, see [Network topology considerations when using Azure Active Directory Application Proxy](application-proxy-network-topology.md).

-* **Securely publish REST APIs**. When you have business logic or APIs running on-premises or hosted on virtual machines in the cloud, Application Proxy provides a public endpoint for API access. API endpoint access lets you control authentication and authorization without requiring incoming ports. It provides additional security through Azure AD Premium features such as multi-factor authentication and device-based Conditional Access for desktops, iOS, MAC, and Android devices using Intune. To learn more, see [How to enable native client applications to interact with proxy applications](./application-proxy-configure-native-client-application.md) and [Protect an API by using OAuth 2.0 with Azure Active Directory and API Management](../../api-management/api-management-howto-protect-backend-with-aad.md).

-* **Enable native client applications to interact with proxy applications**. You can use Azure AD Application Proxy to publish web apps, but it also can be used to publish [native client applications](./application-proxy-configure-native-client-application.md) that are configured with Microsoft Authentication Library (MSAL). Native client applications differ from web apps because they're installed on a device, while web apps are accessed through a browser.

-Whether you're currently using Azure AD to manage users in a hybrid coexistence scenario or are interested in starting your journey to the cloud, implementing Azure AD Application Proxy can help reduce the size of your on-premises footprint by providing remote access as a service.

-* Cloud scale security where Azure AD leverages Microsoft 365 telemetry to prevent unauthorized access

-* For information about planning, operating, and managing Azure AD Application Proxy, see [Plan an Azure AD Application Proxy deployment](./application-proxy-deployment-plan.md).

-# Determine your security posture for external access with Azure Active Directory

-Levels of control can be accomplished through various methods, depending on your version of Azure AD and Microsoft 365.

-* [Azure AD plans and pricing](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing)

-* [What is Azure AD Privileged Identity Management?](../privileged-identity-management/pim-configure.md) - manage, control, and monitor access to resources in Azure AD, Azure, and other Microsoft Online Services such as Microsoft 365 or Microsoft Intune

-1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md) (You're here)

-4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

-5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

-6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

-8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

-9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

-10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

-description: Learn to convert local guests into Azure AD B2B guest accounts by identifying apps and local guest accounts, migration, and more.

-# Convert local guest accounts to Azure Active Directory B2B guest accounts

-With Azure Active Directory (Azure AD B2B), external users collaborate with their identities. Although organizations can issue local usernames and passwords to external users, this approach isn't recommended. Azure AD B2B has improved security, lower cost, and less complexity, compared to creating local accounts. In addition, if your organization issues local credentials that external users manage, you can use Azure AD B2B instead. Use the guidance in this document to make the transition.

-Learn more: [Plan an Azure AD B2B collaboration deployment](secure-external-access-resources.md)

-Before migrating local accounts to Azure AD B2B, confirm the applications and workloads external users can access. For example, for applications hosted on-premises, validate the application is integrated with Azure AD. On-premises applications are a good reason to create local accounts.

-Learn more: [Grant B2B users in Azure AD access to your on-premises applications](../external-identities/hybrid-cloud-to-on-premises.md)

-We recommend that external-facing applications have single-sign on (SSO) and provisioning integrated with Azure AD for the best end user experience.

-Identify the accounts to be migrated to Azure AD B2B. External identities in Active Directory are identifiable with an attribute-value pair. For example, making ExtensionAttribute15 = `External` for external users. If these users are set up with Azure AD Connect or Cloud Sync, configure synced external users to have the `UserType` attributes set to `Guest`. If the users are set up as cloud-only accounts, you can modify user attributes. Primarily, identify users to convert to B2B.

-## Migrate local guest accounts to Azure AD B2B

-After local accounts have user.mail attributes populated with the external identity and email, convert local accounts to Azure AD B2B by inviting the local account. You can use PowerShell or the Microsoft Graph API.

- - Invite external users in Azure AD

-1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

-4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

-5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

-6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

-8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

-9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md) (You're here)

-10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md) (You're here)

-description: Learn how to onboard external users to Line-of-business applications using Azure Active Directory B2B

-# Onboard external users to Line-of-business applications using Azure Active Directory B2B

-Application developers can use Azure Active Directory B2B (Azure AD B2B) to onboard and collaborate with external users within line-of-business (LOB) applications. Similar to the **Share** button in many Office 365 applications, application developers can create a one-click invitation experience within any LOB application that is integrated with Azure AD.

-To integrate LOB applications with Azure AD B2B, follow this pattern:

-| 3. | Microsoft Graph API provisions the guest user in Azure AD. |

-| 4. | Microsoft Graph API returns the success/failure status of the API call. If successful, the response includes the Azure AD user object ID and the invitation link that is sent to the invited userΓÇÖs email. You can optionally suppress the Microsoft email and send your own custom email. |

-| 6. | (Optional) Microsoft Graph API makes the desired updates to Azure AD.|

-If assignment is required to access the LOB application, the invited guest user must also be assigned to the application with an appropriate application role. This can be done as another API call adding the invited guest to a group (steps #5-7) or by automating group membership with Azure AD dynamic groups. Using dynamic groups wouldn't require another API call by the application. However, group membership wouldn't be updated as quickly compared to adding a user to a group immediately after user invitation.

-If the external user doesn't already exist in the directory, you can use Azure AD B2B to invite the user and onboard them to your Azure AD tenant. As an application developer, you need to determine what to include in the invitation request to Microsoft Graph API.

-Once the application has collected the required information and determined any other flags or information to include, the application must POST the request to the Microsoft Graph API invitation manager. Ensure the application registration has the appropriate permissions in Azure AD.

-Application developers can alternatively onboard external users using Azure AD Self-service sign-up or Entitlement management access packages. You can create your **invitation** button in your LOB application that triggers a custom email containing a predefined Self-service sign-up URL or access package URL. The invited user then self-service onboard and access the application.

-## Step 3: Write other attributes to Azure AD (optional)

-Your organization or the LOB application may require to store more information for future use, such as claims emittance in tokens or granular authorization policies. Your application can make another API call to update the external user after theyΓÇÖve been invited/created in Azure AD. Doing so requires your application to have extra API permissions and would require an extra call to the Microsoft Graph API.

-If user assignment is required in Azure AD for application access and/or role assignment, the user must be assigned to the application, or else the user is unable to gain access regardless of successful authentication. To achieve this, you should make another API call to add the invited external user to a specific group. The group can be assigned to the application and mapped to a specific application role.

-Alternatively, you can use Azure AD dynamic groups, which can automatically assign users to group based on the userΓÇÖs attributes. However, if end-user access is time-sensitive this wouldn't be the recommended approach as dynamic groups can take up to 24 hours to populate.

-Once the invited external user has been provisioned to Azure AD, the Microsoft Graph API returns a response with the necessary user information such as object ID and email. The LOB application can then provision the user to its own directory/database. Depending on the type of application and internal directory type the application uses, the actual implementation of this provisioning varies.

-With the external user provisioned in both Azure AD and the application, the LOB application can now notify the end user who initiated the invitation that the process has been successful. The invited user can get SSO with their own identity without the inviting organization needing to onboard and issue extra credentials. Azure AD can enforce authorization policies such as Conditional Access, Azure AD Multi-Factor Authentication, and risk-based Identity Protection.

-Learn more: [Determine your security posture for external access with Azure Active Directory](1-secure-access-posture.md)

-External users might be Azure AD B2B users with partner-managed credentials, or external users with locally provisioned credentials. Typically, these users are the Guest UserType. To learn about inviting guests users and sharing resources, see [B2B collaboration overview](../external-identities/what-is-b2b.md).

-Use the following tools to identify Azure AD B2B collaboration, external Azure AD tenants, and users accessing applications:

-With an inventory of external users and organizations, determine the access to grant to the users. You can use the Microsoft Graph API to determine Azure AD group membership or application assignment.

-1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

-4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

-5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

-6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

-8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

-9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

-10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

-* [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

- * See, [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

- * [Overview: Cross-tenant access with Azure AD External Identities](../external-identities/cross-tenant-access-overview.md)

-Some features, for example entitlement management, are available with an Azure AD Premium 2 (P2) license. Microsoft 365 E5 and Office 365 E5 licenses include Azure AD Premium P2 licenses. Learn more in the following entitlement management section.

-> Licenses are for one user. Therefore users, administrators, and business owners can have delegated access control. This scenario can occur with Azure AD Premium P2 or Microsoft 365 E5, and you don't have to enable licenses for all users. The first 50,000 external users are free. If you don't enable P2 licenses for other internal users, they can't use entitlement management.

-Other combinations of Microsoft 365, Office 365, and Azure AD have functionality to manage external users. See, [Microsoft 365 guidance for security & compliance](/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-365-security-compliance-licensing-guidance).

-## Govern access with Azure AD Premium P2 and Microsoft 365 or Office 365 E5

-Azure AD Premium P2, included in Microsoft 365 E5, has additional security and governance capabilities.

-| Azure AD B2B collaboration| Invite via email, one-time password (OTP), self-service|N/A| **Periodic partner review**| Remove account<br>Restrict sign-in |

-| Azure AD security groups|N/A| **Conditional Access policies**: Add external users to security groups as needed|N/A| N/A|

-| Azure AD security groups| **Conditional Access policies for access not included in access packages**|N/A|N/A|N/A|

-## Manage access with Azure AD P1, Microsoft 365, Office 365 E3

-| Azure AD B2B collaboration| **Invite by email, OTP, self-service**| Direct B2B federation| **Periodic partner review**| Remove account<br>Restrict sign-in |

-1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

-4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

-5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

-6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

-8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

-9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

-10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

-description: Azure Active Directory and Microsoft 365 Groups can be used to increase security when external users access your resources.

-# Secure external access with groups in Azure Active Directory and Microsoft 365

-Groups are part of an access control strategy. You can use Azure Active Directory (Azure AD) security groups and Microsoft 365 Groups as the basis for securing access to resources. Use groups for the following access-control mechanisms:

-* Tenant members can create Azure AD security groups

-* [Restrict your Azure AD app to a set of users in an Azure AD tenant](../develop/howto-restrict-your-app-to-a-set-of-users.md)

-* [Set up self-service group management in Azure Active Directory](../enterprise-users/groups-self-service-management.md)

-Learn more: [Create or update a dynamic group in Azure AD](../enterprise-users/groups-create-rule.md)

-You can create Azure AD security groups and Microsoft 365 Groups in the Azure portal or the Microsoft 365 Admin portal. Use either group type for securing external access.

-| Considerations |Manual and dynamic Azure AD security groups| Microsoft 365 Groups |

-## Azure AD security groups

-Azure AD security groups can have users or devices. Use these groups to manage access to:

-Use Azure AD security groups to assign:

- * See, [What is group-based licensing in Azure Active Directory?](../fundamentals/licensing-whatis-azure-portal.md)

- * See, [Use Azure AD groups to manage role assignments](../roles/groups-concept.md)

-* [Manage Azure AD groups and group membership](../fundamentals/how-to-manage-groups.md)

-* [Azure AD version 2 cmdlets for group management](../enterprise-users/groups-settings-v2-cmdlets.md).

-### Hybrid organizations and Azure AD security groups

-Hybrid organizations have infrastructure for on-premises and an Azure AD. Hybrid organizations that use Active Directory can create security groups on-premises and sync them to the cloud. Therefore, only users in the on-premises environment can be added to the security groups.

-1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

-4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md) (You're here)

-5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

-6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

-8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

-9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

-10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

-description: Move to governed collaboration with Azure Ad B2B collaboration by using controls, tools, and settings.

-# Transition to governed collaboration with Azure Active Directory B2B collaboration

-Understanding collaboration helps secure external access to your resources. Use the information in this article to move external collaboration into Azure Active Directory B2B (Azure AD B2B) collaboration.

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

-You can limit the organizations your users collaborate with (inbound and outbound), and who in your organization can invite guests. Most organizations permit business units to decide collaboration, and delegate approval and oversight. For example, organizations in government, education, and finance often don't permit open collaboration. You can use Azure AD features to control collaboration.

-If your users use Azure AD B2B, you can discover the external Azure AD tenants they're collaborating with, with the sign-in logs, PowerShell, or a workbook. Learn more:

-You can control inbound and outbound access using cross tenant access settings. In addition, you can trust multi-factor authentication (MFA), a compliant device, and hybrid Azure Active Directory joined device (HAAJD) claims from external Azure AD tenants. When you configure an organizational policy, it applies to the Azure AD tenant and applies to users in that tenant, regardless of domain suffix.

-> Cross tenant access settings apply to Azure AD tenants. To control access for partners not using Azure AD, use external collaboration settings.

-Use entitlement management to ensure automatic guest-lifecycle governance. Create access packages and publish them to external users or to connected organizations, which support Azure AD tenants and other domains. When you create an access package, restrict access to connected organizations.

-* [Azure AD B2B collaboration invitation redemption](../external-identities/redemption-experience.md)

-When you enable Azure AD B2B, you can invite guest users with links and email invitations. Self-service sign-up, and publishing access packages to the My Access portal, require more configuration.

- * Guest is the default Azure AD B2B user account

-Use Azure AD entitlement management to configure questions that external users answer. The questions appear to approvers to help them make a decision. You can configure sets of questions for each access package policy, so approvers have relevant information for access they approve. For example, ask vendors for their vendor contract number.

-### Troubleshoot invitation redemption to Azure AD users

-* The user isn't in the partner Azure AD tenant. For example, users at contoso.com are in Active Directory.

- * See, [Azure Active Directory B2B collaboration invitation redemption](../external-identities/redemption-experience.md)

- * Create a Conditional Access policy to block access to Azure AD-integrated applications for non-guest users

-Learn more: [Use Azure AD Identity Governance to review and remove external users who no longer have resource access](../governance/access-reviews-external-users.md)

-Evaluate external users with member accounts to determine access. You might have guest users not invited through entitlement management or Azure AD B2B.

-* [Use Azure AD Identity Governance to review and remove external users who no longer have resource access](../governance/access-reviews-external-users.md)

-## Transition current external users to Azure AD B2B

-If you don't use Azure AD B2B, you likely have non-employee users in your tenant. We recommend you transition these accounts to Azure AD B2B external user accounts and then change their UserType to Guest. Use Azure AD and Microsoft 365 to handle external users.

-1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

-4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

-5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md) (You're here)

-6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

-8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

-9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

-10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

-description: How to use Azure AD Entitlement Management as a part of your overall external access security plan.

-# Manage external access with Azure Active Directory entitlement management

-You can make access packages available, through the Azure AD My Access portal, to enable external users to request access. Policies determine who can request an access package. See, [Request access to an access package in entitlement management](../governance/entitlement-management-request-access.md).

-* [Working with the Azure AD entitlement management API](/graph/api/resources/entitlementmanagement-overview?view=graph-rest-1.0&preserve-view=true)

-* [Azure AD access reviews](/graph/api/resources/accessreviewsv2-overview?view=graph-rest-1.0&preserve-view=true)

-1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

-4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

-5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

-6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md) (You're here)

-8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

-9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

-10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

-If you canΓÇÖt use connected organizations in entitlement management, create an Azure AD security group, or Microsoft 365 Group for partner organizations. Assign users from that partner to the group. You can use the groups in Conditional Access policies.

-* [Manage Azure Active Directory groups and group membership](../fundamentals/how-to-manage-groups.md)

-Learn more: [Manage emergency access accounts in Azure AD](../roles/security-emergency-access.md)

-Before you begin, we recommend you create a security group, which contains external users who access resources. See, [Quickstart: Create a group with members and view all groups and members in Azure AD](../fundamentals/groups-view-azure-portal.md).

-Learn more: [Manage emergency access accounts in Azure AD](../roles/security-emergency-access.md)

-1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

-4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

-5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

-6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

-8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

-9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

-10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

-# Control external access to resources in Azure Active Directory with sensitivity labels

-* [Assign sensitivity labels to Microsoft 365 groups in Azure AD](../enterprise-users/groups-assign-sensitivity-labels.md)

-1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

-4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

-5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

-6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

-8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md) (You're here)

-9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md)

-10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

-# Secure external access to Microsoft Teams, SharePoint, and OneDrive with Azure Active Directory

-## External Identities settings and Azure Active Directory

-Sharing in Microsoft 365 is partially governed by the **External Identities, External collaboration settings** in Azure Active Directory (Azure AD). If external sharing is disabled or restricted in Azure AD, it overrides sharing settings configured in Microsoft 365. An exception is if Azure AD B2B integration isn't enabled. You can configure SharePoint and OneDrive to support ad-hoc sharing via one-time password (OTP). The following screenshot shows the External Identities, External collaboration settings dialog.

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

-1. Browse to **Azure Active Directory** > **External Identities** > **External collaboration settings**.

- * Ensures there are sufficient Azure AD Premium P2 licenses for the Microsoft 365 group owners who will review

-The External Identities collaboration feature in Azure AD controls permissions. You can increase restrictions in Teams, but restrictions can't be lower than Azure AD settings.

-### Integrating SharePoint and OneDrive with Azure AD B2B

-As a part of your strategy to govern external collaboration, it's recommended you enable SharePoint and OneDrive integration with Azure AD B2B. Azure AD B2B has guest-user authentication and management. With SharePoint and OneDrive integration, use one-time passcodes for external sharing of files, folders, list items, document libraries, and sites.

-* [SharePoint and OneDrive integration with Azure AD B2B](/sharepoint/sharepoint-azureb2b-integration)

-If you enable Azure AD B2B integration, then SharePoint and OneDrive sharing is subject to the Azure AD organizational relationships settings, such as **Members can invite** and **Guests can invite**.

- * Azure AD B2B integration enabled: new and current guests have an Azure AD B2B guest account you can manage with Azure AD policies

- * Azure AD B2B integration not enabled: new guests don't have an Azure AD B2B account, and can't be managed from Azure AD

- * Guests have an Azure AD B2B account, depending on how the guest was created

-* **Allow only users in specific security groups to share externally** - Use this setting to restrict who shares content in SharePoint and OneDrive. The setting in Azure AD applies to all applications. Use the restriction to direct users to training about secure sharing. Completion is the signal to add them to a sharing security group. If this setting is selected, and users can't become an approved sharer, they might find unapproved ways to share.

-With Azure AD B2B integration enabled, sharing files and folders with users outside the organization results in the creation of a B2B user.

-* [SharePoint and OneDrive integration with Azure AD B2B](/sharepoint/sharepoint-azureb2b-integration)

-1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md)

-4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)

-5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)

-6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)

-8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md)

-9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business with Azure AD](9-secure-access-teams-sharepoint.md) (You're here)

-10. [Convert local guest accounts to Azure Active Directory B2B guest accounts](10-secure-local-guest.md)

-description: Learn what an Azure Active Directory tenant is and how to manage Azure using Azure Active Directory.

-# What is the Azure Active Directory architecture?

-Azure Active Directory (Azure AD) enables you to securely manage access to Azure services and resources for your users. Included with Azure AD is a full suite of identity management capabilities. For information about Azure AD features, see [What is Azure Active Directory?](../fundamentals/whatis.md)

-With Azure AD, you can create and manage users and groups, and enable permissions to allow and deny access to enterprise resources. For information about identity management, see [The fundamentals of Azure identity management](../fundamentals/whatis.md).

-## Azure AD architecture

-Azure AD's geographically distributed architecture combines extensive monitoring, automated rerouting, failover, and recovery capabilities, which deliver company-wide availability and performance to customers.

-The most common way to build an accessible and usable, data-rich system is through independent building blocks or scale units. For the Azure AD data tier, scale units are called *partitions*.

-The components of Azure AD architecture include a primary replica and secondary replicas.

-Availability (or uptime) defines the ability of a system to perform uninterrupted. The key to Azure ADΓÇÖs high-availability is that the services can quickly shift traffic across multiple geographically distributed datacenters. Each datacenter is independent, which enables de-correlated failure modes. Through this high availability design, Azure AD requires no downtime for maintenance activities.

-Azure ADΓÇÖs partition design is simplified compared to the enterprise AD design, using a single-master design that includes a carefully orchestrated and deterministic primary replica failover process.

-Azure AD maintains a zero [Recovery Time Objective (RTO)](https://en.wikipedia.org/wiki/Recovery_time_objective) to not lose data on failovers. This includes:

-Azure ADΓÇÖs replicas are stored in datacenters located throughout the world. For more information, see [Azure global infrastructure](https://azure.microsoft.com/global-infrastructure/).

-Azure AD operates across datacenters with the following characteristics:

-Azure AD provides read-write consistency for applications targeting a secondary replica by routing its writes to the primary replica, and synchronously pulling the writes back to the secondary replica.

-Application writes using the Microsoft Graph API of Azure AD are abstracted from maintaining affinity to a directory replica for read-write consistency. The Microsoft Graph API service maintains a logical session, which has affinity to a secondary replica used for reads; affinity is captured in a ΓÇ£replica tokenΓÇ¥ that the service caches using a distributed cache in the secondary replica datacenter. This token is then used for subsequent operations in the same logical session. To continue using the same logical session, subsequent requests must be routed to the same Azure AD datacenter. It isn't possible to continue a logical session if the directory client requests are being routed to multiple Azure AD datacenters; if this happens then the client has multiple logical sessions that have independent read-write consistencies.

-Azure AD implements daily backup of directory data and can use these backups to restore data if there is any service-wide issue.

-Running a high availability service requires world-class metrics and monitoring capabilities. Azure AD continually analyzes and reports key service health metrics and success criteria for each of its services. There is also continuous development and tuning of metrics and monitoring and alerting for each scenario, within each Azure AD service and across all services.

-If any Azure AD service isn't working as expected, action is immediately taken to restore functionality as quickly as possible. The most important metric Azure AD tracks is how quickly live site issues can be detected and mitigated for customers. We invest heavily in monitoring and alerts to minimize time to detect (TTD Target: <5 minutes) and operational readiness to minimize time to mitigate (TTM Target: <30 minutes).

-[Azure Active Directory developer's guide](../develop/index.yml)

-description: Architectural guidance on achieving header-based authentication with Azure Active Directory.

-# Header-based authentication with Azure Active Directory

-Legacy applications commonly use Header-based authentication. In this scenario, a user (or message originator) authenticates to an intermediary identity solution. The intermediary solution authenticates the user and propagates the required Hypertext Transfer Protocol (HTTP) headers to the destination web service. Azure Active Directory (AD) supports this pattern via its Application Proxy service, and integrations with other network controller solutions.