Updates from: 03/05/2021 04:32:36
Service Microsoft Docs article Related commit history on GitHub Change details
active-directory-b2c Access Tokens https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/access-tokens.md
https://jwt.ms/?code=eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMC...
After successfully receiving the authorization code, you can use it to request an access token: ```http
-POST <tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token HTTP/1.1
+POST <tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token HTTP/1.1
Host: <tenant-name>.b2clogin.com Content-Type: application/x-www-form-urlencoded
active-directory-b2c Add Identity Provider https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/add-identity-provider.md
Previously updated : 01/14/2021 Last updated : 03/03/2021
You typically use only one identity provider in your applications, but you have
* [AD FS](identity-provider-adfs.md) * [Amazon](identity-provider-amazon.md)
+* [Apple](identity-provider-apple-id.md)
* [Azure AD (Single-tenant)](identity-provider-azure-ad-single-tenant.md) * [Azure AD (Multi-tenant)](identity-provider-azure-ad-multi-tenant.md) * [Azure AD B2C](identity-provider-azure-ad-b2c.md)
active-directory-b2c Add Password Reset Policy https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/add-password-reset-policy.md
Title: Set up a password reset flow
+ Title: Set up a password reset flow in Azure AD B2C
description: Learn how to set up a password reset flow in Azure Active Directory B2C.
Previously updated : 12/16/2020 Last updated : 03/02/2021 zone_pivot_groups: b2c-policy-type
zone_pivot_groups: b2c-policy-type
[!INCLUDE [active-directory-b2c-choose-user-flow-or-custom-policy](../../includes/active-directory-b2c-choose-user-flow-or-custom-policy.md)]
-## Password rest flow
+## Password reset flow
-Password reset policy allows users to reset their own forgotten password. The password reset flow involves following steps:
-1. From the sign-up and sign-in page, user clicks on the "Forgot your password?" link. Azure AD B2C returns the AADB2C90118 error code to your app. The app handles this error code by invoking the password reset policy.
-1. Users provide and verify their email with a Timed One Time Passcode.
-1. Enter a new password.
+The [sign-up and sign-in journey](add-sign-up-and-sign-in-policy.md) allows users to reset their own password using the **Forgot your password?** link. The password reset flow involves the following steps:
+
+1. From the sign-up and sign-in page, the user clicks the **Forgot your password?** link. Azure AD B2C initiates the password reset flow.
+2. The user provides and verifies their email address with a Timed One Time Passcode.
+3. The user can then enter a new password.
![Password reset flow](./media/add-password-reset-policy/password-reset-flow.png)
+The password reset flow applies to local accounts in Azure AD B2C that use an [email address](identity-provider-local.md#email-sign-in) or [username](identity-provider-local.md#username-sign-in) with a password for sign-in.
+
+A common practice after migrating users to Azure AD B2C with random passwords is to have the users verify their email addresses and reset their passwords during their first sign-in. It's also common to force the user to reset their password after an administrator changes their password; see [force password reset](force-password-reset.md) to enable this feature.
+ ## Prerequisites
-If you haven't already done so, [register a web application in Azure Active Directory B2C](tutorial-register-applications.md).
+
+## Self-service password reset (recommended)
+
+The new password reset experience is now part of the sign-up or sign-in policy. When the user selects the **Forgot your password?** link, they are immediately sent to the Forgot Password experience. Your application no longer needs to handle the [AADB2C90118 error code](#password-reset-policy-legacy), and you don't need a separate policy for password reset.
::: zone pivot="b2c-user-flow"
-## Create a password reset user flow
+The self-service password reset experience can be configured for the **Sign-in (Recommended)** or **Sign up and sign in (Recommended)** user flows. If you don't have such a user flow, create a [sign In and Sign Up](add-sign-up-and-sign-in-policy.md) user flow.
+
+To enable self-service password reset for the sign-up or sign-in user flow:
+
+1. Sign in to the [Azure portal](https://portal.azure.com).
+1. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
+1. In the Azure portal, search for and select **Azure AD B2C**.
+1. Select **User flows**.
+1. Select a sign-up or sign-in user flow (of type **Recommended**) that you want to customize.
+1. Under **Settings** in the left menu, select **Properties**.
+1. Under **Password complexity**, select **Self-service password reset**.
+1. Select **Save**.
+1. Under **Customize** in the left menu, select **Page layouts**.
+1. In the **Page Layout Version**, choose **2.1.2 - Current** or above.
+1. Select **Save**.
+++
+The following sections describe how to add a self-service password experience to a custom policy. The sample is based on the policy files included in the [custom policy starter pack](./custom-policy-get-started.md).
+
+> [!TIP]
+> You can find a complete sample of the "sign-up or sign-in with password reset" policy on [GitHub](https://github.com/azure-ad-b2c/samples/tree/master/policies/embedded-password-reset).
+
+### Indicate a user selected the Forgot your password? link
+
+To indicate to the policy that the user has selected the **Forgot your password?** link, define a boolean claim. This claim will be used to direct the user journey to the Forgot Password technical profile. This claim can also be issued to the token so the application is aware that the user signed in via the Forgot Password flow.
+
+You declare your claims in the [claims schema](claimsschema.md). Open the extensions file of your policy. For example, <em>`SocialAndLocalAccounts/`**`TrustFrameworkExtensions.xml`**</em>.
+
+1. Search for the [BuildingBlocks](buildingblocks.md) element. If the element doesn't exist, add it.
+1. Locate the [ClaimsSchema](claimsschema.md) element. If the element doesn't exist, add it.
+1. Add the following claim to the **ClaimsSchema** element.
+
+```XML
+<!--
+<BuildingBlocks>
+ <ClaimsSchema> -->
+ <ClaimType Id="isForgotPassword">
+ <DisplayName>isForgotPassword</DisplayName>
+ <DataType>boolean</DataType>
+ <AdminHelpText>Whether the user has selected Forgot your Password</AdminHelpText>
+ </ClaimType>
+ <!--
+ </ClaimsSchema>
+</BuildingBlocks> -->
+```
+
+### Upgrade the page layout version
+
+[Page layout version](contentdefinitions.md#migrating-to-page-layout) `2.1.2` is required to enable the self-service password reset flow within the sign-up or sign-in journey.
+
+1. Search for the [BuildingBlocks](buildingblocks.md) element. If the element doesn't exist, add it.
+1. Locate the [ContentDefinitions](contentdefinitions.md) element. If the element doesn't exist, add it.
+1. Modify the **DataURI** element within the **ContentDefinition** element with Id **api.signuporsignin** as shown below.
+
+```xml
+<!--
+<BuildingBlocks>
+ <ContentDefinitions> -->
+ <ContentDefinition Id="api.signuporsignin">
+ <DataUri>urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:2.1.2</DataUri>
+ </ContentDefinition>
+ <!--
+ </ContentDefinitions>
+</BuildingBlocks> -->
+```
+
+To initiate the `isForgotPassword` claim, a claims transformation technical profile is used. This technical profile will be referenced later. When invoked, it will set the value of the `isForgotPassword` claim to `true`. Find the `ClaimsProviders` element. If the element doesn't exist, add it. Then add the following claims provider:
+
+```xml
+<!--
+<ClaimsProviders> -->
+ <ClaimsProvider>
+ <DisplayName>Local Account</DisplayName>
+ <TechnicalProfiles>
+ <TechnicalProfile Id="ForgotPassword">
+ <DisplayName>Forgot your password?</DisplayName>
+ <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
+ <OutputClaims>
+ <OutputClaim ClaimTypeReferenceId="isForgotPassword" DefaultValue="true" AlwaysUseDefaultValue="true"/>
+ </OutputClaims>
+ </TechnicalProfile>
+ <TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
+ <Metadata>
+ <Item Key="setting.forgotPasswordLinkOverride">ForgotPasswordExchange</Item>
+ </Metadata>
+ </TechnicalProfile>
+ </TechnicalProfiles>
+ </ClaimsProvider>
+<!--
+</ClaimsProviders> -->
+```
+
+The `SelfAsserted-LocalAccountSignin-Email` technical profile `setting.forgotPasswordLinkOverride` definers the password reset claims exchange to be executed in your user journey.
+
+### Add the password reset sub journey
+
+Your journey will now include the capability for the user to sign in, sign up, and perform password reset. To better organize the user journey, a [sub journey](subjourneys.md) can be used to handle the password reset flow.
+
+The sub journey will be called from the user journey and will perform the specific steps to deliver the password reset experience to the user. Use the `Call` type sub journey so that once the sub journey completes, control is returned to the orchestration step that initiated the sub journey.
+
+Find the `SubJourneys` element. If the element doesn't exist, add it after the `User Journeys` element. Then add the following sub journey:
+
+```xml
+<!--
+<SubJourneys>-->
+ <SubJourney Id="PasswordReset" Type="Call">
+ <OrchestrationSteps>
+ <!-- Validate user's email address. -->
+ <OrchestrationStep Order="1" Type="ClaimsExchange">
+ <ClaimsExchanges>
+ <ClaimsExchange Id="PasswordResetUsingEmailAddressExchange" TechnicalProfileReferenceId="LocalAccountDiscoveryUsingEmailAddress" />
+ </ClaimsExchanges>
+ </OrchestrationStep>
+
+ <!-- Collect and persist a new password. -->
+ <OrchestrationStep Order="2" Type="ClaimsExchange">
+ <ClaimsExchanges>
+ <ClaimsExchange Id="NewCredentials" TechnicalProfileReferenceId="LocalAccountWritePasswordUsingObjectId" />
+ </ClaimsExchanges>
+ </OrchestrationStep>
+ </OrchestrationSteps>
+ </SubJourney>
+<!--
+</SubJourneys>-->
+```
+
+### Prepare your user journey
+
+You'll need to connect the **Forgot your password?** link to the Forgot Password sub journey. To do this, reference the Forgot Password sub journey Id within the **ClaimsProviderSelection** element of the **CombinedSignInAndSignUp** step.
-To enable users of your application to reset their password, you use a password reset user flow.
+If you don't have your own custom user journey with a **CombinedSignInAndSignUp** step, use the following procedure to duplicate an existing sign-up or sign-in user journey. Otherwise, continue to the next section.
+
+1. Open the *TrustFrameworkBase.xml* file from the starter pack.
+2. Find and copy the entire contents of the **UserJourney** element that includes `Id="SignUpOrSignIn"`.
+3. Open the *TrustFrameworkExtensions.xml* and find the **UserJourneys** element. If the element doesn't exist, add one.
+4. Create a child element of the **UserJourneys** element by pasting the entire contents of the **UserJourney** element you copied in step 2.
+5. Rename the Id of the user journey. For example, `Id="CustomSignUpSignIn"`.
+
+### Connect the Forgot Password Link to the Forgot Password sub journey
+
+In your user journey, you can represent the Forgot Password sub journey as a **ClaimsProviderSelection**. Adding this element connects the **Forgot your password?** link to the Forgot Password sub journey.
+
+1. In the user journey, find the orchestration step element that includes `Type="CombinedSignInAndSignUp"` or `Type="ClaimsProviderSelection"`. It's usually the first orchestration step. The **ClaimsProviderSelections** element contains a list of identity providers that a user can use to sign in. Add the following line:
+
+ ```xml
+ <ClaimsProviderSelection TargetClaimsExchangeId="ForgotPasswordExchange" />
+ ```
+
+1. In the next orchestration step, add a **ClaimsExchange** element. Add the following line:
+
+ ```xml
+ <ClaimsExchange Id="ForgotPasswordExchange" TechnicalProfileReferenceId="ForgotPassword" />
+ ```
+
+### Set the user journey to be executed
+
+Now that you've modified or created a user journey, in the **Relying Party** section specify the journey that Azure AD B2C will execute for this custom policy. Within the [RelyingParty](relyingparty.md) element, find the **DefaultUserJourney** element. Update the **DefaultUserJourney ReferenceId** to match the ID of the user journey in which you added the **ClaimsProviderSelections**.
+
+```xml
+<RelyingParty>
+ <DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
+ ...
+</RelyingParty>
+```
+
+### Indicate the Forgot Password flow to your App
+
+Your application might need to detect whether the user signed in via the Forgot Password user flow. The **isForgotPassword** claim contains a boolean value that indicates this, which can be issued in the token sent to your application. If necessary, add `isForgotPassword` to the output claims in the **Relying Party** section. Your application can check the `isForgotPassword` claim to determine if the user resets their password.
+
+```xml
+<RelyingParty>
+ <OutputClaims>
+ ...
+ <OutputClaim ClaimTypeReferenceId="isForgotPassword" DefaultValue="false" />
+ </OutputClaims>
+</RelyingParty>
+```
++
+### Upload the custom policy
+
+1. Sign in to the [Azure portal](https://portal.azure.com).
+1. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
+1. In the Azure portal, search for and select **Azure AD B2C**.
+1. Under **Policies**, select **Identity Experience Framework**.
+1. Select **Upload Custom Policy**, and then upload the two policy files that you changed in the following order:
+ 1. The extension policy, for example `TrustFrameworkExtensions.xml`.
+ 2. The relying party policy, for example `SignUpSignIn.xml`.
++
+### Test the password reset flow
+
+1. Select a sign-up or sign-in user flow (of type Recommended) that you want to test.
+1. Select **Run user flow**.
+1. For **Application**, select the web application named *webapp1* that you previously registered. The **Reply URL** should show `https://jwt.ms`.
+1. Select **Run user flow**.
+1. From the sign-up or sign-in page, select **Forgot your password?**.
+1. Verify the email address of the account that you previously created, and then select **Continue**.
+1. You now have the opportunity to change the password for the user. Change the password and select **Continue**. The token is returned to `https://jwt.ms` and should be displayed to you.
+1. Check the return token's `isForgotPassword` claim value. If exists and is set to true, this indicates the user has reset the password.
+
+## Password reset policy (legacy)
+
+If the [self-service password reset](#self-service-password-reset-recommended) experience is not enabled, clicking this link doesn't automatically trigger a password reset user flow. Instead, the error code `AADB2C90118` is returned to your application. Your application needs to handle this error code by reinitializing the authentication library to authenticate an Azure AD B2C password reset user flow.
+
+In the following diagram:
+
+1. From the application, the user clicks on sign-in. The app initiates an authorization request, and takes the user to Azure AD B2C to finish signing in. The authorization request specifies the sign-up or sign-in policy name, such as **B2C_1_signup_signin**.
+1. The user selects the **Forgot your password?** link. Azure AD B2C returns the AADB2C90118 error code to the application.
+1. The application handles the error code and initiates a new authorization request. The authorization request specifies the password reset policy name, such as **B2C_1_pwd_reset**.
+
+![Password reset flow](./media/add-password-reset-policy/password-reset-flow-legacy.png)
+
+To see an example, take a look at a [simple ASP.NET sample](https://github.com/AzureADQuickStarts/B2C-WebApp-OpenIDConnect-DotNet-SUSI), which demonstrates the linking of user flows.
++
+### Create a password reset user flow
+
+To let users of your application reset their password, you create a password reset user flow.
1. In the Azure AD B2C tenant overview menu, select **User flows**, and then select **New user flow**. 1. On the **Create a user flow** page, select the **Password reset** user flow. 1. Under **Select a version**, select **Recommended**, and then select **Create**. 1. Enter a **Name** for the user flow. For example, *passwordreset1*. 1. For **Identity providers**, enable **Reset password using email address**.
-2. Under Application claims, click **Show more** and choose the claims that you want returned in the authorization tokens sent back to your application. For example, select **User's Object ID**.
-3. Click **OK**.
-4. Click **Create** to add the user flow. A prefix of *B2C_1* is automatically appended to the name.
+1. Under **Application claims**, select **Show more** and choose the claims you want returned in the authorization tokens sent back to your application. For example, select **User's Object ID**.
+1. Select **OK**.
+1. Select **Create** to add the user flow. A prefix of *B2C_1* is automatically appended to the name.
### Test the user flow
-1. Select the user flow you created to open its overview page, then select **Run user flow**.
+1. Select the user flow you created to open its overview page, and then select **Run user flow**.
1. For **Application**, select the web application named *webapp1* that you previously registered. The **Reply URL** should show `https://jwt.ms`.
-1. Click **Run user flow**, verify the email address of the account that you previously created, and select **Continue**.
-1. You now have the opportunity to change the password for the user. Change the password and select **Continue**. The token is returned to `https://jwt.ms` and should be displayed to you.
+1. Click **Run user flow**, verify the email address of the account that you previously created, and then select **Continue**.
+1. You can now change the password for the user. Change the password and select **Continue**. The token is returned to `https://jwt.ms` and should be displayed to you.
::: zone-end ::: zone pivot="b2c-custom-policy"
-## Create a password reset policy
+### Create a password reset policy
Custom policies are a set of XML files you upload to your Azure AD B2C tenant to define user journeys. We provide starter packs with several pre-built policies including: sign-up and sign-in, password reset, and profile editing policy. For more information, see [Get started with custom policies in Azure AD B2C](custom-policy-get-started.md).
Custom policies are a set of XML files you upload to your Azure AD B2C tenant to
## Next steps
-Set up a [profile editing flow](add-profile-editing-policy.md).
+Set up a [force password reset](force-password-reset.md).
active-directory-b2c Add Sign In Policy https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/add-sign-in-policy.md
Previously updated : 01/12/2021 Last updated : 03/04/2021 zone_pivot_groups: b2c-policy-type
The sign-in policy lets users:
* Users can sign in with an Azure AD B2C Local Account * Sign-up or sign-in with a social account * Password reset
-* Users cannot sign up for an Azure AD B2C Local Account - To create an account, an Administrator can use [MS Graph API](microsoft-graph-operations.md).
+* Users cannot sign up for an Azure AD B2C Local Account. To create an account, an administrator can use [Azure portal](manage-users-portal.md#create-a-consumer-user), or [MS Graph API](microsoft-graph-operations.md).
![Profile editing flow](./media/add-sign-in-policy/sign-in-user-flow.png)
The **SelfAsserted-LocalAccountSignin-Email** technical profile is a [self-asser
1. Add the following claims provider to the `ClaimsProviders` element: ```xml
- <ClaimsProvider>
- <DisplayName>Local Account</DisplayName>
- <TechnicalProfiles>
- <TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
- <Metadata>
- <Item Key="setting.showSignupLink">false</Item>
- </Metadata>
- </TechnicalProfile>
- </TechnicalProfiles>
- </ClaimsProvider>
+ <!--
+ <ClaimsProviders> -->
+ <ClaimsProvider>
+ <DisplayName>Local Account</DisplayName>
+ <TechnicalProfiles>
+ <TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
+ <Metadata>
+ <Item Key="setting.showSignupLink">false</Item>
+ </Metadata>
+ </TechnicalProfile>
+ </TechnicalProfiles>
+ </ClaimsProvider>
+ <!--
+ </ClaimsProviders> -->
``` 1. Within `<BuildingBlocks>` element, add the following [ContentDefinition](contentdefinitions.md) to reference the version 1.2.0, or newer data URI: ```XML
- <ContentDefinitions>
- <ContentDefinition Id="api.localaccountsignup">
- <DataUri>urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:1.2.0</DataUri>
- </ContentDefinition>
- </ContentDefinitions>
+ <!--
+ <BuildingBlocks>
+ <ContentDefinitions>-->
+ <ContentDefinition Id="api.localaccountsignup">
+ <DataUri>urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:1.2.0</DataUri>
+ </ContentDefinition>
+ <!--
+ </ContentDefinitions>
+ </BuildingBlocks> -->
``` ## Update and test your policy
The **SelfAsserted-LocalAccountSignin-Email** technical profile is a [self-asser
1. Make sure you're using the directory that contains your Azure AD tenant by selecting the **Directory + subscription** filter in the top menu and choosing the directory that contains your Azure AD tenant. 1. Choose **All services** in the top-left corner of the Azure portal, and then search for and select **App registrations**. 1. Select **Identity Experience Framework**.
-1. Select **Upload Custom Policy**, and then upload the two policy files that you changed.
+1. Select **Upload Custom Policy**, and then upload the policy file that you changed, *TrustFrameworkExtensions.xml*.
1. Select the sign-in policy that you uploaded, and click the **Run now** button. 1. You should be able to sign in with the account that you created (using MS Graph API), without the sign-up link.
active-directory-b2c Analytics With Application Insights https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/analytics-with-application-insights.md
To disable Application Insights logs, change the `DisableTelemetry` metadata to
## Next steps
-Learn how to [create custom KPI dashboards using Azure Application Insights](../azure-monitor/learn/tutorial-app-dashboards.md).
+Learn how to [create custom KPI dashboards using Azure Application Insights](../azure-monitor/app/tutorial-app-dashboards.md).
active-directory-b2c Azure Ad External Identities Videos https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/azure-ad-external-identities-videos.md
+
+ Title: Microsoft Azure Active Directory B2C videos
+
+description: Microsoft Azure Active Directory B2C Video Series
+++++++ Last updated : 02/09/2021++++
+# Microsoft Azure Active Directory External Identities videos
+
+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 Active Directory B2C architecture deep dive series
+
+Get a deeper view into the features and technical aspects of the Azure AD B2C service.
++
+| Video title | | Video title | |
+|:|:|:|:|
+|[Azure AD B2C sign-up sign-in](https://www.youtube.com/watch?v=c8rN1ZaR7wk&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=6&t=2s) 10:25 | [![image](./media/external-identities-videos/customer-sign-up-sign-in.png)](https://www.youtube.com/watch?v=c8rN1ZaR7wk&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=6) | [Azure AD B2C single sign on and self service password reset](https://www.youtube.com/watch?v=kRV-7PSLK38&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=7) 8:40 | [![image](./media/external-identities-videos/single-sign-on.png)](https://www.youtube.com/watch?v=kRV-7PSLK38&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=7) |
+| [Application and identity migration to Azure AD B2C](https://www.youtube.com/watch?v=Xw_YwSJmhIQ&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=9) 10:34 | [![image](./media/external-identities-videos/identity-migration-aad-b2c.png)](https://www.youtube.com/watch?v=Xw_YwSJmhIQ&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=9) | [Build resilient and scalable flows using Azure AD B2C](https://www.youtube.com/watch?v=8f_Ozpw9yTs&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=12) 16:47 | [![image](./media/external-identities-videos/b2c-scalable-flows.png)](https://www.youtube.com/watch?v=8f_Ozpw9yTs&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=12) |
+| [Building a custom CIAM solution with Azure AD B2C and ISV alliances](https://www.youtube.com/watch?v=UZjiGDD0wa8&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=8) 10:01 | [![image](./media/external-identities-videos/build-custom-b2c-solution.png)](https://www.youtube.com/watch?v=UZjiGDD0wa8&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=8) | [Protecting Web APIs with Azure AD B2C](https://www.youtube.com/watch?v=wuUu71RcsIo&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=10) 19:03 | [![image](./media/external-identities-videos/protecting-web-apis.png)](https://www.youtube.com/watch?v=wuUu71RcsIo&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=10) |
+| [Integration of SAML with Azure AD B2C](https://www.youtube.com/watch?v=r2TIVBCm7v4&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=11) 9:09 | [![image](./media/external-identities-videos/saml-integration.png)](https://www.youtube.com/watch?v=r2TIVBCm7v4&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=11) |
+
+## Azure Active Directory B2C how to series
+
+Learn how to perform various use cases in Azure AD B2C.
+
+| Video title | | Video title | |
+|:|:|:|:|
+|[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](./media/external-identities-videos/monitoring-reporting-aad-b2c.png)](https://www.youtube.com/watch?v=Mu9GQy-CbXI&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=1) | [Azure AD B2C user migration using Microsoft Graph API](https://www.youtube.com/watch?v=9BRXBtkBzL4&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=5) 7:09 | [![image](./media/external-identities-videos/user-migration-msgraph-api.png)](https://www.youtube.com/watch?v=9BRXBtkBzL4list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=5) |
+| [Azure AD B2C user migration strategies](https://www.youtube.com/watch?v=lCWR6PGUgz0&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=2) 8:22 | [![image](./media/external-identities-videos/user-migration-stratagies.png)](https://www.youtube.com/watch?v=lCWR6PGUgz0&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=2) | [How to localize or customize language using Azure AD B2C](https://www.youtube.com/watch?v=yqrX5_tA7Ms&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=13) 20:41 | [![image](./media/external-identities-videos/language-localization.png)](https://www.youtube.com/watch?v=yqrX5_tA7Ms&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=13) |
active-directory-b2c Claim Resolver Overview https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/claim-resolver-overview.md
Previously updated : 10/28/2020 Last updated : 03/04/2021
The following sections list available claim resolvers.
| {Context:CorrelationId} | The correlation ID. | 00000000-0000-0000-0000-000000000000 | | {Context:DateTimeInUtc} |The date time in UTC. | 10/10/2018 12:00:00 PM | | {Context:DeploymentMode} |The policy deployment mode. | Production |
+| {Context:HostName} | The host name of the current request. | contoso.b2clogin.com |
| {Context:IPAddress} | The user IP address. | 11.111.111.11 | | {Context:KMSI} | Indicates whether [Keep me signed in](session-behavior.md?pivots=b2c-custom-policy#enable-keep-me-signed-in-kmsi) checkbox is selected. | true |
You can use claims resolvers with the following elements:
|[OpenID Connect](openid-connect-technical-profile.md) technical profile| `InputClaim`, `OutputClaim`| 1, 2| |[Claims transformation](claims-transformation-technical-profile.md) technical profile| `InputClaim`, `OutputClaim`| 1, 2| |[RESTful provider](restful-technical-profile.md) technical profile| `InputClaim`| 1, 2|
-|[SAML identity provider](saml-identity-provider-technical-profile.md) technical profile| `OutputClaim`| 1, 2|
+|[SAML identity provider](identity-provider-generic-saml.md) technical profile| `OutputClaim`| 1, 2|
|[Self-Asserted](self-asserted-technical-profile.md) technical profile| `InputClaim`, `OutputClaim`| 1, 2| |[ContentDefinition](contentdefinitions.md)| `LoadUri`| | |[ContentDefinitionParameters](relyingparty.md#contentdefinitionparameters)| `Parameter` | |
active-directory-b2c Code Samples https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/code-samples.md
The following tables provide links to samples for applications including iOS, An
|--| -- | | [ios-swift-native-msal](https://github.com/Azure-Samples/active-directory-b2c-ios-swift-native-msal) | An iOS sample in Swift that authenticates Azure AD B2C users and calls an API using OAuth 2.0 | | [android-native-msal](https://github.com/Azure-Samples/ms-identity-android-java#b2cmodefragment-class) | A simple Android app showcasing how to use MSAL to authenticate users via Azure Active Directory B2C, and access a Web API with the resulting tokens. |
-| [ios-native-appauth](https://github.com/Azure-Samples/active-directory-b2c-ios-native-appauth) | A sample that shows how you can use a third party library to build an iOS application in Objective-C that authenticates Microsoft identity users to our Azure AD B2C identity service. |
-| [android-native-appauth](https://github.com/Azure-Samples/active-directory-b2c-android-native-appauth) | A sample that shows how you can use a third party library to build an Android application that authenticates Microsoft identity users to our B2C identity service and calls a web API using OAuth 2.0 access tokens. |
+| [ios-native-appauth](https://github.com/Azure-Samples/active-directory-b2c-ios-native-appauth) | A sample that shows how you can use a third-party library to build an iOS application in Objective-C that authenticates Microsoft identity users to our Azure AD B2C identity service. |
+| [android-native-appauth](https://github.com/Azure-Samples/active-directory-b2c-android-native-appauth) | A sample that shows how you can use a third-party library to build an Android application that authenticates Microsoft identity users to our B2C identity service and calls a web API using OAuth 2.0 access tokens. |
| [dotnet-desktop](https://github.com/Azure-Samples/active-directory-b2c-dotnet-desktop) | A sample that shows how a Windows Desktop .NET (WPF) application can sign in a user using Azure AD B2C, get an access token using MSAL.NET and call an API. | | [xamarin-native](https://github.com/Azure-Samples/active-directory-b2c-xamarin-native) | A simple Xamarin Forms app showcasing how to use MSAL to authenticate users via Azure Active Directory B2C, and access a Web API with the resulting tokens. |
The following tables provide links to samples for applications including iOS, An
| Sample | Description | |--| -- |
-| [ms-identity-b2c-javascript-spa](https://github.com/Azure-Samples/ms-identity-b2c-javascript-spa) | A single page application (SPA) calling a Web API. Authentication is done with Azure AD B2C by using MSAL.js. This sample uses the authorization code flow with PKCE. |
-| [javascript-msal-singlepageapp](https://github.com/Azure-Samples/active-directory-b2c-javascript-msal-singlepageapp) | A single page application (SPA) calling a Web API. Authentication is done with Azure AD B2C by using MSAL.js. This samples uses the implicit flow.|
+| [ms-identity-b2c-javascript-spa](https://github.com/Azure-Samples/ms-identity-b2c-javascript-spa) | A single page application (SPA) calling a web API. Authentication is done with Azure AD B2C by using MSAL.js. This sample uses the authorization code flow with PKCE. |
+| [javascript-nodejs-management](https://github.com/Azure-Samples/ms-identity-b2c-javascript-nodejs-management/tree/main/Chapter1) | A single page application (SPA) calling Microsoft Graph to manage users in a B2C directory. Authentication is done with Azure AD B2C by using MSAL.js. This sample uses the authorization code flow with PKCE.|
+| [javascript-msal-singlepageapp](https://github.com/Azure-Samples/active-directory-b2c-javascript-msal-singlepageapp) | A single page application (SPA) calling a web API. Authentication is done with Azure AD B2C by using MSAL.js. This sample uses the implicit flow.|
+
+## Console/Daemon apps
+
+| Sample | Description |
+|--| -- |
+| [javascript-nodejs-management](https://github.com/Azure-Samples/ms-identity-b2c-javascript-nodejs-management/tree/main/Chapter2) | A Node.js and express console daemon application calling Microsoft Graph with its own identity to manage users in a B2C directory. Authentication is done with Azure AD B2C by using MSAL Node. This sample uses the authorization code flow.|
+| [dotnetcore-b2c-account-management](https://github.com/Azure-Samples/ms-identity-dotnetcore-b2c-account-management) | A .NET Core console application calling Microsoft Graph with its own identity to manage users in a B2C directory. Authentication is done with Azure AD B2C by using MSAL.NET. This sample uses the authorization code flow.|
## SAML test application
The following tables provide links to code samples for leveraging web APIs in yo
### Automated fraud protection services & CAPTCHA | Sample | Description | | -- | |
-| [Arkose Labs fraud and abuse protection](https://github.com/Azure-Samples/active-directory-b2c-node-sign-up-user-flow-arkose) | This sample shows how to protect your user sign-ups using using the Arkose Labs fraud and abuse protection service. |
-| [reCAPTCHA](https://github.com/Azure-Samples/active-directory-b2c-node-sign-up-user-flow-captcha) | This sample shows how to protect your user sign-ups using using a reCAPTCHA challenge to prevent automated abuse. |
+| [Arkose Labs fraud and abuse protection](https://github.com/Azure-Samples/active-directory-b2c-node-sign-up-user-flow-arkose) | This sample shows how to protect your user sign-ups using the Arkose Labs fraud and abuse protection service. |
+| [reCAPTCHA](https://github.com/Azure-Samples/active-directory-b2c-node-sign-up-user-flow-captcha) | This sample shows how to protect your user sign-ups using a reCAPTCHA challenge to prevent automated abuse. |
### Identity verification
active-directory-b2c Conditional Access Identity Protection Overview https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/conditional-access-identity-protection-overview.md
Previously updated : 09/01/2020 Last updated : 03/03/2021
Identity Protection and Conditional Access in Azure AD B2C generally work the sa
- In Azure AD B2C tenants, Identity Protection risk detections are available for local B2C accounts only, and not for social identities like Google or Facebook. -- In Azure AD B2C tenants, a subset of the Identity Protection risk detections is available. See [Set up Identity Protection](conditional-access-identity-protection-setup.md#set-up-identity-protection).
+- In Azure AD B2C tenants, a subset of the Identity Protection risk detections is available. See [Investigate risk with Identity Protection](identity-protection-investigate-risk.md), and [Add Conditional Access to user flows](conditional-access-user-flow.md).
- The Conditional Access device compliance feature isn't available in Azure AD B2C tenants. ## Integrate Conditional Access with user flows and custom policies
-In Azure AD B2C, you can trigger Conditional Access conditions from built-in user flows. You can also incorporate Conditional Access into custom policies. As with other aspects of the B2C user flow, end-user experience messaging can be customized according to your organization's voice, brand, and mitigation alternatives. See [Define a Conditional Access technical profile](conditional-access-technical-profile.md).
+In Azure AD B2C, you can trigger Conditional Access conditions from built-in user flows. You can also incorporate Conditional Access into custom policies. As with other aspects of the B2C user flow, end-user experience messaging can be customized according to your organization's voice, brand, and mitigation alternatives. See [Add Conditional Access to user flows](conditional-access-user-flow.md).
## Microsoft Graph API
-You can also manage Conditional Access policies in Azure AD B2C with Microsoft Graph API. For details, see the [Conditional Access documentation](../active-directory/conditional-access/overview.md) and the [Microsoft Graph reference](/graph/api/resources/conditionalaccesspolicy?view=graph-rest-beta).
+You can also manage Conditional Access policies in Azure AD B2C with Microsoft Graph API. For details, see the [Conditional Access documentation](../active-directory/conditional-access/overview.md) and the [Microsoft Graph operations](microsoft-graph-operations.md#conditional-access).
## Next steps -- [Set up Identity Protection and Conditional Access for Azure AD B2C](conditional-access-identity-protection-setup.md)
+- [Add Conditional Access to user flows](conditional-access-user-flow.md)
- [Learn about Identity Protection in Azure AD](../active-directory/identity-protection/overview-identity-protection.md) - [Learn about Conditional Access](../active-directory/conditional-access/overview.md)
active-directory-b2c Conditional Access Identity Protection Setup https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/conditional-access-identity-protection-setup.md
- Title: Set up Identity Protection and Conditional Access in Azure AD B2C
-description: Learn how configure Identity Protection and Conditional Access for you Azure AD B2C tenant to view risky sign-in and other risk events and create policies based on risk detections.
----- Previously updated : 09/01/2020-------
-# Set up Identity Protection and Conditional Access in Azure AD B2C
--
-Identity Protection provides ongoing risk detection for your Azure AD B2C tenant. If your Azure AD B2C tenant pricing tier is Premium P2, you can view detailed Identity Protection risk events in the Azure portal. You can also use [Conditional Access](../active-directory/conditional-access/overview.md) policies based on these risk detections to determine actions and enforce organizational policies.
-
-## Prerequisites
--- Your Azure AD B2C tenant must be [linked to an Azure AD subscription](billing.md#link-an-azure-ad-b2c-tenant-to-a-subscription).-- Azure AD B2C Premium P2 is required to use sign-in and user risk-based Conditional Access. If necessary, [change your Azure AD B2C pricing tier to Premium P2](./billing.md). -- To manage Identity Protection and Conditional Access in your B2C tenant, you'll need an account that is assigned the Global Administrator role or the Security administrator role.-- To use these features in your tenant, you first need to switch to the Azure AD B2C Premium P2 pricing tier.-
-## Set up Identity Protection
-
-Identity Protection is on by default. To be able to view Identity Protection risk events in your Azure AD B2C tenant, simply link your Azure AD B2C tenant to an Azure AD subscription and select the Azure AD B2C Premium P2 pricing tier. You can view detailed risk event reports in the Azure portal.
-
-### Supported Identity Protection risk detections
-
-The following risk detections are currently supported for Azure AD B2C:
-
-|Risk detection type |Description |
-|||
-| Atypical travel | Sign in from an atypical location based on the user's recent sign-ins. |
-|Anonymous IP address | Sign in from an anonymous IP address (for example: Tor browser, anonymizer VPNs). |
-|Malware linked IP address | Sign in from a malware linked IP address. |
-|Unfamiliar sign-in properties | Sign in with properties we've not seen recently for the given user. |
-|Admin confirmed user compromised | An admin has indicated that a user was compromised. |
-|Password spray | Sign in through a password spray attack. |
-|Azure AD threat intelligence | Microsoft's internal and external threat intelligence sources have identified a known attack pattern. |
-
-## View risk events for your Azure AD B2C tenant
-
-1. Sign in to the [Azure portal](https://portal.azure.com/).
-
-1. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
-
-1. In the Azure portal, search for and select **Azure AD B2C**.
-
-1. Under **Security**, select **Risky users (Preview)**.
-
- ![Risky users](media/conditional-access-identity-protection-setup/risky-users.png)
-
-1. Under **Security**, select **Risk detections (Preview)**.
-
- ![Risk detections](media/conditional-access-identity-protection-setup/risk-detections.png)
-
-## Add a Conditional Access policy
-
-To add a Conditional Access policy based on the Identity Protection risk detections, make sure security defaults are disabled for your Azure AD B2C tenant, and then create Conditional Access policies.
-
-### To disable security defaults
-
-1. Sign in to the [Azure portal](https://portal.azure.com/).
-
-2. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
-
-3. In the Azure portal, search for and select **Azure Active Directory**.
-
-4. Select **Properties**, and then select **Manage Security defaults**.
-
- ![Disable the security defaults](media/conditional-access-identity-protection-setup/disable-security-defaults.png)
-
-5. Under Enable Security defaults, select No.
-
- ![Set the Enable security defaults toggle to No](media/conditional-access-identity-protection-setup/enable-security-defaults-toggle.png)
-
-### To create a Conditional Access policy
-
-1. Sign in to the [Azure portal](https://portal.azure.com/).
-
-1. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
-
-1. In the Azure portal, search for and select **Azure AD B2C**.
-
-1. Under **Security**, select **Conditional Access (Preview)**. The **Conditional Access Policies** page opens.
-
-1. Select **New policy** and follow the Azure AD Conditional Access documentation to create a new policy. For risk-based policies, you will need to configure separate policies based on [user risk](../active-directory/conditional-access/howto-conditional-access-policy-risk-user.md#enable-with-conditional-access-policy) or [sign-in risk](../active-directory/conditional-access/howto-conditional-access-policy-risk.md#enable-with-conditional-access-policy) depending on which type of risk you want to use as a condition. We do not recommend using both risk types in a single policy.
-
- > [!IMPORTANT]
- > When selecting the users you want to apply the policy to, don't select **All users** only, or you could block yourself from signing in.
-
-## Test the Conditional Access Policy
-
-1. Create a Conditional Access policy as noted above, with the following settings:
-
- - For **Users and groups**, select the test user. Don't select **All users** or you'll block yourself from signing in.
- - For **Cloud apps or actions**, choose **Select apps**, and then choose your relying party application.
- - For Conditions, select **Sign-in risk** and **High**, **Medium**, and **Low** risk levels.
- - For **Grant**, choose **Block access**.
-
- ![Choose Block access](media/conditional-access-identity-protection-setup/test-conditional-access-policy.png)
-
-1. Enable your test Conditional Access policy by selecting **Create**.
-
-1. Simulate a risky sign-in by using the [Tor browser](https://www.torproject.org/download/).
-
-1. In the jwt.ms decoded token for the attempted sign-in, you should see that the sign-in was blocked:
-
- ![Test a blocked sign-in](media/conditional-access-identity-protection-setup/test-blocked-sign-in.png)
-
-## Review Conditional Access Outcomes in the Audit Report
-
-To review the result of a Conditional Access event:
-
-1. Sign in to the [Azure portal](https://portal.azure.com/).
-
-2. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
-
-3. In the Azure portal, search for and select **Azure AD B2C**.
-
-4. Under **Activities**, select **Audit logs**.
-
-5. Filter the audit log by setting **Category** to **B2C** and setting **Activity Resource Type** to **IdentityProtection**. Then select **Apply**.
-
-6. Review audit activity for up to the last 7 days. The following types of activity are included:
-
- - **Evaluate conditional access policies**: This audit log entry indicates that a Conditional Access evaluation was performed during an authentication.
- - **Remediate user**: This entry indicates that the grant or requirements of a Conditional Access policy were met by the end user, and this activity was reported to the risk engine to reduce the risk of (mitigate) the user.
-
-7. Select an **Evaluate conditional access policy** log entry in the list to open the **Activity Details: Audit log** page, which shows the audit log identifiers, along with this information in the **Additional Details** section:
-
- - ConditionalAccessResult: The grant required by the conditional policy evaluation.
- - AppliedPolicies: A list of all the Conditional Access policies where the conditions were met and the policies are ON.
- - ReportingPolicies: A list of the Conditional Access policies that were set to report-only mode and where the conditions were met.
-
-## Next steps
-
-[Add Conditional Access to a user flow](conditional-access-user-flow.md).
active-directory-b2c Conditional Access Technical Profile https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/conditional-access-technical-profile.md
- Title: Conditional Access technical profiles in custom policies-
-description: Custom policy reference for Conditional Access technical profiles in Azure AD B2C.
------- Previously updated : 10/14/2020----
-# Define a Conditional Access technical profile in an Azure Active Directory B2C custom policy
--
-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.
--
-## Protocol
-
-The **Name** attribute of the **Protocol** element needs to be set to `Proprietary`. The **handler** attribute must contain the fully qualified name of the protocol handler assembly that is used by Azure AD B2C:
-
-```
-Web.TPEngine.Providers.ConditionalAccessProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
-```
-
-The following example shows a Conditional Access technical profile:
-
-```XML
-<TechnicalProfile Id="ConditionalAccessEvaluation">
- <DisplayName>Conditional Access Provider</DisplayName>
- <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ConditionalAccessProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
- <Metadata>
- <Item Key="OperationType">Evaluation</Item>
- </Metadata>
-```
-
-## Conditional Access evaluation
-
-For every sign-in, Azure AD B2C evaluates all policies and ensures all requirements are met before granting the user access. "Block access" overrides all other configuration settings. The **Evaluation** mode of the Conditional Access technical profile evaluates the signals collected by Azure AD B2C during the sign-in with a local account. The outcome of the Conditional Access technical profile is a set of claims that result from Conditional Access evaluation. The Azure AD B2C policy uses these claims in a next orchestration step to take an action, such as block the user or challenge the user with multi-factor authentication. The following options can be configured for this mode.
-
-### Metadata
-
-| Attribute | Required | Description |
-| | -- | -- |
-| OperationType | Yes | Must be **Evaluation**. |
-
-### Input claims
-
-The **InputClaims** element contains a list of claims to send to Conditional Access. You can also map the name of your claim to the name defined in the Conditional Access technical profile.
-
-| ClaimReferenceId | Required | Data Type | Description |
-| | -- | -- |-- |
-| UserId | Yes | string | The identifier of the user who signs in. |
-| AuthenticationMethodsUsed | Yes |stringCollection | The list of methods the user used to sign in. Possible values: `Password`, and `OneTimePasscode`. |
-| IsFederated | Yes |boolean | Indicates whether or not a user signed in with a federated account. The value must be `false`. |
-| IsMfaRegistered | Yes |boolean | Indicates whether the user already enrolled a phone number for multi-factor authentication. |
--
-The **InputClaimsTransformations** element may contain a collection of **InputClaimsTransformation** elements that are used to modify the input claims or generate new ones before sending them to the Conditional Access service.
-
-### Output claims
-
-The **OutputClaims** element contains a list of claims generated by the ConditionalAccessProtocolProvider. You can also map the name of your claim to the name defined below.
-
-| ClaimReferenceId | Required | Data Type | Description |
-| | -- | -- |-- |
-| Challenges | Yes |stringCollection | List of actions to remediate the identified threat. Possible values: `block` |
-| MultiConditionalAccessStatus | Yes | stringCollection | |
-
-The **OutputClaimsTransformations** element may contain a collection of **OutputClaimsTransformation** elements that are used to modify the output claims or generate new ones.
-
-### Example: Evaluation
-
-The following example shows a Conditional Access technical profile that is used to evaluate the sign-in threat.
-
-```XML
-<TechnicalProfile Id="ConditionalAccessEvaluation">
- <DisplayName>Conditional Access Provider</DisplayName>
- <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ConditionalAccessProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
- <Metadata>
- <Item Key="OperationType">Evaluation</Item>
- </Metadata>
- <InputClaimsTransformations>
- <InputClaimsTransformation ReferenceId="IsMfaRegisteredCT" />
- </InputClaimsTransformations>
- <InputClaims>
- <InputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="UserId" />
- <InputClaim ClaimTypeReferenceId="AuthenticationMethodsUsed" />
- <InputClaim ClaimTypeReferenceId="IsFederated" DefaultValue="false" />
- <InputClaim ClaimTypeReferenceId="IsMfaRegistered" />
- </InputClaims>
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="conditionalAccessClaimCollection" PartnerClaimType="Challenges" />
- <OutputClaim ClaimTypeReferenceId="ConditionalAccessStatus" PartnerClaimType="MultiConditionalAccessStatus" />
- </OutputClaims>
-</TechnicalProfile>
-```
-
-## Remediation
-
-The **Remediation** mode of the Conditional Access technical profile informs Azure AD B2C that the sign-in identified threat is remediated. The following options can be configured for the remediation mode.
-
-### Metadata
-
-| Attribute | Required | Description |
-| | -- | -- |
-| OperationType | Yes | Must be **Remediation**. |
-
-### Input claims
-
-The **InputClaims** element contains a list of claims to send to Conditional Access. You can also map the name of your claim to the name defined in the Conditional Access technical profile.
-
-| ClaimReferenceId | Required | Data Type | Description |
-| | -- | -- |-- |
-| ChallengesSatisfied | Yes | stringCollection| The list of satisfied challenges to remediate the identified threat as return from the evaluation mode, challenges claim.|
--
-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 Conditional Access service.
-
-### Output claims
-
-The Conditional Access protocol provider doesn't return any **OutputClaims**, so there's no need to specify output claims. You can, however, include claims that aren't returned by the Conditional Access protocol provider as long as you set the `DefaultValue` attribute.
-
-The **OutputClaimsTransformations** element may contain a collection of **OutputClaimsTransformation** elements that are used to modify the output claims or generate new ones.
--
-### Example: Remediation
-
-The following example shows a Conditional Access technical profile used to remediate the identified threat:
-
-```XML
-<TechnicalProfile Id="ConditionalAccessRemediation">
- <DisplayName>Conditional Access Remediation</DisplayName>
- <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ConditionalAccessProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
- <Metadata>
- <Item Key="OperationType">Remediation</Item>
- </Metadata>
- <InputClaims>
- <InputClaim ClaimTypeReferenceId="conditionalAccessClaimCollection" PartnerClaimType="ChallengesSatisfied" />
- </InputClaims>
-</TechnicalProfile>
-```
-
-To get the example working, add the claims shown in the following example to the ClaimsSchema section in your extensions file:
-
-```XML
-<!-- Conditional Access claims -->
- <ClaimType Id="conditionalAccessClaimCollection">
- <DisplayName>Conditional Access claims</DisplayName>
- <DataType>stringCollection</DataType>
- <AdminHelpText>The list of claims which are the result of CA check</AdminHelpText>
- </ClaimType>
- <ClaimType Id="ConditionalAccessStatus">
- <DisplayName>The status of CA evaluation</DisplayName>
- <DataType>stringCollection</DataType>
- <AdminHelpText>The status of CA evaluation</AdminHelpText>
- </ClaimType>
- <ClaimType Id="AuthenticationMethodsUsed">
- <DisplayName>Authentication methods used</DisplayName>
- <DataType>stringCollection</DataType>
- <AdminHelpText>The list of authentication methods used</AdminHelpText>
- </ClaimType>
- <ClaimType Id="AuthenticationMethodUsed">
- <DisplayName>Authentication method used</DisplayName>
- <DataType>string</DataType>
- <AdminHelpText>The authentication method used</AdminHelpText>
- </ClaimType>
- <ClaimType Id="IsFederated">
- <DisplayName>IsFederated</DisplayName>
- <DataType>boolean</DataType>
- <AdminHelpText>Is user authenticated via an external identity provider</AdminHelpText>
- </ClaimType>
- <ClaimType Id="IsMfaRegistered">
- <DisplayName>IsMfaRegistered</DisplayName>
- <DataType>boolean</DataType>
- <AdminHelpText>Is user registered for MFA</AdminHelpText>
- </ClaimType>
- <ClaimType Id="CAChallengeIsMfa">
- <DisplayName>CAChallengeIsMfa</DisplayName>
- <DataType>boolean</DataType>
- </ClaimType>
- <ClaimType Id="CAChallengeIsChgPwd">
- <DisplayName>CAChallengeIsChgPwd</DisplayName>
- <DataType>boolean</DataType>
- </ClaimType>
- <ClaimType Id="CAChallengeIsBlock">
- <DisplayName>CAChallengeIsBlock</DisplayName>
- <DataType>boolean</DataType>
- </ClaimType>
- <ClaimType Id="responseMsg">
- <DisplayName>responseMsg</DisplayName>
- <DataType>string</DataType>
- <AdminHelpText>A claim responsible for holding response messages to send to the relying party</AdminHelpText>
- <UserHelpText>A claim responsible for holding response messages to send to the relying party</UserHelpText>
- <UserInputType>Paragraph</UserInputType>
- </ClaimType>
-<!-- End of Conditional Access claims -->
-```
-
-Add the following claims transformations:
-
-```xml
-<!--Conditional Access Transformations-->
- <ClaimsTransformation Id="AddToAuthenticationMethodsUsed" TransformationMethod="AddItemToStringCollection">
- <InputClaims>
- <InputClaim ClaimTypeReferenceId="AuthenticationMethodUsed" TransformationClaimType="item" />
- <InputClaim ClaimTypeReferenceId="AuthenticationMethodsUsed" TransformationClaimType="collection" />
- </InputClaims>
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="AuthenticationMethodsUsed" TransformationClaimType="collection" />
- </OutputClaims>
- </ClaimsTransformation>
- <ClaimsTransformation Id="CreatePasswordAuthenticationMethodClaim" TransformationMethod="CreateStringClaim">
- <InputParameters>
- <InputParameter Id="value" DataType="string" Value="Password" />
- </InputParameters>
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="AuthenticationMethodUsed" TransformationClaimType="createdClaim" />
- </OutputClaims>
- </ClaimsTransformation>
- <ClaimsTransformation Id="CreateOneTimePasscodeAuthenticationMethodClaim" TransformationMethod="CreateStringClaim">
- <InputParameters>
- <InputParameter Id="value" DataType="string" Value="OneTimePasscode" />
- </InputParameters>
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="AuthenticationMethodUsed" TransformationClaimType="createdClaim" />
- </OutputClaims>
- </ClaimsTransformation>
- <ClaimsTransformation Id="IsMfaRegisteredCT" TransformationMethod="DoesClaimExist">
- <InputClaims>
- <InputClaim ClaimTypeReferenceId="strongAuthenticationPhoneNumber" TransformationClaimType="inputClaim" />
- </InputClaims>
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="IsMfaRegistered" TransformationClaimType="outputClaim" />
- </OutputClaims>
- </ClaimsTransformation>
- <ClaimsTransformation Id="SetCAChallengeIsMfa" TransformationMethod="StringCollectionContains">
- <InputClaims>
- <InputClaim ClaimTypeReferenceId="conditionalAccessClaimCollection" TransformationClaimType="inputClaim" />
- </InputClaims>
- <InputParameters>
- <InputParameter Id="item" DataType="string" Value="mfa" />
- <InputParameter Id="ignoreCase" DataType="string" Value="true" />
- </InputParameters>
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="CAChallengeIsMfa" TransformationClaimType="outputClaim" />
- </OutputClaims>
- </ClaimsTransformation>
- <ClaimsTransformation Id="SetCAChallengeIsChgPwd" TransformationMethod="StringCollectionContains">
- <InputClaims>
- <InputClaim ClaimTypeReferenceId="conditionalAccessClaimCollection" TransformationClaimType="inputClaim" />
- </InputClaims>
- <InputParameters>
- <InputParameter Id="item" DataType="string" Value="chg_pwd" />
- <InputParameter Id="ignoreCase" DataType="string" Value="true" />
- </InputParameters>
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="CAChallengeIsChgPwd" TransformationClaimType="outputClaim" />
- </OutputClaims>
- </ClaimsTransformation>
- <ClaimsTransformation Id="SetCAChallengeIsBlock" TransformationMethod="StringCollectionContains">
- <InputClaims>
- <InputClaim ClaimTypeReferenceId="conditionalAccessClaimCollection" TransformationClaimType="inputClaim" />
- </InputClaims>
- <InputParameters>
- <InputParameter Id="item" DataType="string" Value="block" />
- <InputParameter Id="ignoreCase" DataType="string" Value="true" />
- </InputParameters>
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="CAChallengeIsBlock" TransformationClaimType="outputClaim" />
- </OutputClaims>
- </ClaimsTransformation>
-```
-
-Add the following technical profile:
-
-```xml
-<TechnicalProfile Id="GenerateCAClaimFlags">
- <DisplayName>GenerateCAClaimFlags</DisplayName>
- <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="CAChallengeIsMfa" />
- <OutputClaim ClaimTypeReferenceId="CAChallengeIsChgPwd" />
- <OutputClaim ClaimTypeReferenceId="CAChallengeIsBlock" />
- </OutputClaims>
- <OutputClaimsTransformations>
- <OutputClaimsTransformation ReferenceId="SetCAChallengeIsMfa" />
- <OutputClaimsTransformation ReferenceId="SetCAChallengeIsChgPwd" />
- <OutputClaimsTransformation ReferenceId="SetCAChallengeIsBlock" />
- </OutputClaimsTransformations>
-</TechnicalProfile>
-
-<!--This is a self-asserted technical profile that we will use to show a block screen-->
-<TechnicalProfile Id="ShowBlockPage">
- <DisplayName>Show Block message</DisplayName>
- <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
- <Metadata>
- <Item Key="ContentDefinitionReferenceId">api.selfasserted.profileupdate</Item>
- <Item Key="TokenLifeTimeInSeconds">3600</Item>
- <Item Key="AllowGenerationOfClaimsWithNullValues">true</Item>
- <Item Key="setting.showContinueButton">false</Item>
- <Item Key="setting.showCancelButton">false</Item>
- </Metadata>
- <CryptographicKeys>
- <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
- </CryptographicKeys>
- <InputClaims>
- <InputClaim ClaimTypeReferenceId="responseMsg" DefaultValue="The user is blocked due to conditional access check." />
- </InputClaims>
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="responseMsg" />
- </OutputClaims>
- <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
- <EnabledForUserJourneys>Always</EnabledForUserJourneys>
-</TechnicalProfile>
-
-```
-
-In your TrustFrameworkPolicy element, add these SubJourneys as shown in the following example:
-
-```xml
- <SubJourneys>
- <SubJourney Id="ConditionalAccess_Evaluation" Type="Call">
- <OrchestrationSteps>
- <OrchestrationStep Order="1" Type="ClaimsExchange">
- <ClaimsExchanges>
- <ClaimsExchange Id="ConditionalAccessEvaluation" TechnicalProfileReferenceId="ConditionalAccessEvaluation" />
- </ClaimsExchanges>
- </OrchestrationStep>
- <OrchestrationStep Order="2" Type="ClaimsExchange">
- <Preconditions>
- <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
- <Value>conditionalAccessClaimCollection</Value>
- <Action>SkipThisOrchestrationStep</Action>
- </Precondition>
- </Preconditions>
- <ClaimsExchanges>
- <ClaimsExchange Id="GenerateCAClaimFlags" TechnicalProfileReferenceId="GenerateCAClaimFlags" />
- </ClaimsExchanges>
- </OrchestrationStep>
- </OrchestrationSteps>
- </SubJourney>
-
- <SubJourney Id="ConditionalAccess_Remediation" Type="Call">
- <OrchestrationSteps>
- <OrchestrationStep Order="1" Type="ClaimsExchange">
- <Preconditions>
- <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
- <Value>conditionalAccessClaimCollection</Value>
- <Action>SkipThisOrchestrationStep</Action>
- </Precondition>
- </Preconditions>
- <ClaimsExchanges>
- <ClaimsExchange Id="ConditionalAccessRemediation" TechnicalProfileReferenceId="ConditionalAccessRemediation" />
- </ClaimsExchanges>
- </OrchestrationStep>
- </OrchestrationSteps>
- </SubJourney>
- </SubJourneys>
-
-```
-
-Add a user journey that uses the new claims, as shown in the following example:
-
-```xml
- <UserJourneys>
- <UserJourney Id="SignUpOrSignInWithCA">
- <OrchestrationSteps>
- <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
- <ClaimsProviderSelections>
- <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
-
- </ClaimsProviderSelections>
- <ClaimsExchanges>
- <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
- </ClaimsExchanges>
- </OrchestrationStep>
- <!-- Check if the user has selected to sign in using one of the social providers -->
- <OrchestrationStep Order="2" Type="ClaimsExchange">
- <Preconditions>
- <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
- <Value>objectId</Value>
- <Action>SkipThisOrchestrationStep</Action>
- </Precondition>
- </Preconditions>
- <ClaimsExchanges>
- <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
- </ClaimsExchanges>
- </OrchestrationStep>
-
- <!-- For social IDP authentication, attempt to find the user account in the directory. -->
- <OrchestrationStep Order="3" Type="ClaimsExchange">
- <Preconditions>
- <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
- <Value>authenticationSource</Value>
- <Value>socialIdpAuthentication</Value>
- <Action>SkipThisOrchestrationStep</Action>
- </Precondition>
- </Preconditions>
- <ClaimsExchanges>
- <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
- </ClaimsExchanges>
- </OrchestrationStep>
-
- <OrchestrationStep Order="4" Type="InvokeSubJourney">
- <JourneyList>
- <Candidate SubJourneyReferenceId="ConditionalAccess_Evaluation" />
- </JourneyList>
- </OrchestrationStep>
-
- <!--MFA based on Conditional Access-->
- <OrchestrationStep Order="5" Type="ClaimsExchange">
- <Preconditions>
- <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
- <Value>CAChallengeIsMfa</Value>
- <Action>SkipThisOrchestrationStep</Action>
- </Precondition>
- <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
- <Value>CAChallengeIsMfa</Value>
- <Value>False</Value>
- <Action>SkipThisOrchestrationStep</Action>
- </Precondition>
- </Preconditions>
- <ClaimsExchanges>
- <ClaimsExchange Id="PhoneFactor-Verify" TechnicalProfileReferenceId="PhoneFactor-InputOrVerify" />
- </ClaimsExchanges>
- </OrchestrationStep>
-
- <!--Save MFA phone number: The precondition verifies whether the user provided a new number in the previous step. If so, the phone number is stored in the directory for future authentication requests.-->
- <OrchestrationStep Order="6" Type="ClaimsExchange">
- <Preconditions>
- <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
- <Value>newPhoneNumberEntered</Value>
- <Action>SkipThisOrchestrationStep</Action>
- </Precondition>
- </Preconditions>
- <ClaimsExchanges>
- <ClaimsExchange Id="AADUserWriteWithObjectId" TechnicalProfileReferenceId="AAD-UserWritePhoneNumberUsingObjectId" />
- </ClaimsExchanges>
- </OrchestrationStep>
-
- <OrchestrationStep Order="7" Type="ClaimsExchange" >
- <Preconditions>
- <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
- <Value>CAChallengeIsBlock</Value>
- <Action>SkipThisOrchestrationStep</Action>
- </Precondition>
- <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
- <Value>CAChallengeIsBlock</Value>
- <Value>True</Value>
- <Action>SkipThisOrchestrationStep</Action>
- </Precondition>
- </Preconditions>
- <ClaimsExchanges>
- <ClaimsExchange Id="ShowBlockPage" TechnicalProfileReferenceId="ShowBlockPage" />
- </ClaimsExchanges>
- </OrchestrationStep>
-
- <!--If a user has reached this point, this means a remediation was applied-->
- <!-- You can add a precondition here to call remediation only if a Conditional Access challenge was issued-->
- <OrchestrationStep Order="8" Type="InvokeSubJourney">
- <JourneyList>
- <Candidate SubJourneyReferenceId="ConditionalAccess_Remediation" />
- </JourneyList>
- </OrchestrationStep>
- <OrchestrationStep Order="9" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
- </OrchestrationSteps>
- <ClientDefinition ReferenceId="DefaultWeb" />
- </UserJourney>
- </UserJourneys>
-
-```
-
-The following is an example of a relying party file that references this UserJourney:
-
-```xml
-<TrustFrameworkPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xmlns:xsd="http://www.w3.org/2001/XMLSchema"
- xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
- PolicySchemaVersion="0.3.0.0" TenantId="contoso.onmicrosoft.com"
- PolicyId="ha-sam-signup_signin-CA"
- PublicPolicyUri="http://contoso.onmicrosoft.com/B2C_1A_signup_signin_CA"
- DeploymentMode="Development"
- UserJourneyRecorderEndpoint="urn:journeyrecorder:applicationinsights"
- <BasePolicy>
- <TenantId>contoso.onmicrosoft.com</TenantId>
- <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
- </BasePolicy>
- <RelyingParty>
- <DefaultUserJourney ReferenceId="SignUpOrSignInWithCA" />
- <UserJourneyBehaviors>
- <SingleSignOn Scope="Tenant" />
- <SessionExpiryType>Absolute</SessionExpiryType>
- <SessionExpiryInSeconds>604800</SessionExpiryInSeconds>
- <JourneyInsights TelemetryEngine="ApplicationInsights" InstrumentationKey="<add your app insights instrumentation key" DeveloperMode="true" ClientEnabled="false" ServerEnabled="true" TelemetryVersion="1.0.0" />
- </UserJourneyBehaviors>
- <TechnicalProfile Id="PolicyProfile">
- <DisplayName>PolicyProfile</DisplayName>
- <Protocol Name="OpenIdConnect" />
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="email" />
- <OutputClaim ClaimTypeReferenceId="signInName" />
- <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub" />
- <OutputClaim ClaimTypeReferenceId="CAChallengeIsMfa" />
- <OutputClaim ClaimTypeReferenceId="CAChallengeIsBlock" />
- <OutputClaim ClaimTypeReferenceId="conditionalAccessClaimCollection" />
- </OutputClaims>
- <SubjectNamingInfo ClaimType="sub" />
- </TechnicalProfile>
- </RelyingParty>
-</TrustFrameworkPolicy>
-```
-
-## Next steps
--- You can find an example of a conditional access policy on [GitHub](https://github.com/azure-ad-b2c/samples/tree/master/policies/conditional-access).
active-directory-b2c Conditional Access User Flow https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/conditional-access-user-flow.md
Previously updated : 12/14/2020 Last updated : 03/03/2021 - zone_pivot_groups: b2c-policy-type # Add Conditional Access to user flows in Azure Active Directory B2C +
+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.
+
+![Conditional access flow](media/conditional-access-user-flow/conditional-access-flow.png)
+
+Automating risk assessment with policy conditions means risky sign-ins are identified immediately and then either remediated or blocked.
+ [!INCLUDE [b2c-public-preview-feature](../../includes/active-directory-b2c-public-preview.md)]
-Conditional Access can be added to your Azure Active Directory B2C user flows to manage risky sign-ins to your applications. The integration of Identity Protection and Conditional Access in Azure AD B2C lets you set up policies that identify risky sign-in behavior and enforce policies that require further action from the user or administrator. These are the components that enable Conditional Access in Azure AD B2C user flows:
+## Service overview
+
+Azure AD B2C evaluates each sign-in event and ensures that all policy requirements are met before granting the user access. During this **Evaluation** phase, the Conditional Access service evaluates the signals collected by Identity Protection risk detections during sign-in events. The outcome of this evaluation process is a set of claims that indicates whether the sign-in should be granted or blocked. The Azure AD B2C policy uses these claims to take an action within the user flow, such as blocking access or challenging the user with a specific remediation like multi-factor authentication (MFA). ΓÇ£Block accessΓÇ¥ overrides all other settings.
+
+The following example shows a Conditional Access technical profile that is used to evaluate the sign-in threat.
+
+```XML
+<TechnicalProfile Id="ConditionalAccessEvaluation">
+ <DisplayName>Conditional Access Provider</DisplayName>
+ <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ConditionalAccessProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
+ <Metadata>
+ <Item Key="OperationType">Evaluation</Item>
+ </Metadata>
+ ...
+</TechnicalProfile>
+```
++
+In the **Remediation** phase that follows, the user is challenged with MFA. Once complete, Azure AD B2C informs Identity Protection that the identified sign-in threat has been remediated and by which method. In this example, Azure AD B2C signals that the user has successfully completed the multi-factor authentication challenge.
++
+The following example shows a Conditional Access technical profile used to remediate the identified threat:
+
+```XML
+<TechnicalProfile Id="ConditionalAccessRemediation">
+ <DisplayName>Conditional Access Remediation</DisplayName>
+ <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ConditionalAccessProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
+ <Metadata>
+ <Item Key="OperationType">Remediation</Item>
+ </Metadata>
+ ...
+</TechnicalProfile>
+```
++
+## Components of the solution
-- **User flow**. Create a user flow that guides the user through the sign-in and sign-up process. In the user flow settings, indicate whether to activate Conditional Access policies when a user follows the user flow.-- **Application that directs users to the user flow**. Configure your app to direct users to the appropriate sign-up and sign-in user flow by specifying the user flow endpoint in the app.-- **Conditional Access policy**. [Create a Conditional Access policy](conditional-access-identity-protection-setup.md) and specify the apps you want the policy to apply to. When the user follows the sign-in or sign-up user flow for your app, the Conditional Access policy uses Identity Protection signals to identify risky sign-ins, and presents the appropriate remediation action if necessary.
+These are the components that enable Conditional Access in Azure AD B2C:
-Conditional Access is supported in the latest versions of user flows. You can add Conditional Access policies to new user flows as you create them, or you can add them to existing user flows as long as the version supports Conditional Access. When adding Conditional Access to an existing user flow, there are two settings you'll need to review:
+- **User flow** or **custom policy** that guides the user through the sign-in and sign-up process.
+- **Conditional Access policy** that brings signals together to make decisions and enforce organizational policies. When a user signs into your application via an Azure AD B2C policy, the Conditional Access policy uses Azure AD Identity Protection signals to identify risky sign-ins and presents the appropriate remediation action.
+- **Registered application** that directs users to the appropriate Azure AD B2C user flow or custom policy.
+- [TOR Browser](https://www.torproject.org/download/) to simulate a risky sign-in.
-- **Multi-factor authentication (MFA)**: Users can now use a one-time code via SMS or voice, or a one-time password via email for multi-factor authentication. MFA settings are independent from Conditional Access settings. You can set MFA to **Always On** so that MFA is always required regardless of your Conditional Access setup. Or, you can set MFA to **Conditional** so that MFA is required only when an active Conditional Access Policy requires it.
+## Service limitations and considerations
-- **Conditional Access**: This setting should always be **On**. Typically you would only turn this setting **Off** during troubleshooting or migration, or for legacy implementations.
+When using the Azure AD Conditional Access, consider the following:
+
+- Identity Protection is available for both local and social identities, such as Google or Facebook. For social identities, you need to manually activate Conditional Access. Detection is limited because social account credentials are managed by the external identity provider.
+- In Azure AD B2C tenants, only a subset of [Azure AD Conditional Access](../active-directory/conditional-access/overview.md) policies are available.
-Learn more about [Identity Protection and Conditional Access](conditional-access-identity-protection-overview.md) in Azure AD B2C, or see [how to set it up](conditional-access-identity-protection-setup.md).
## Prerequisites -- Azure AD B2C Premium 2 is required to create risky sign-in policies. Premium P1 tenants can create location, app, or group-based policies.-- For testing purposes, you can [register the test web application](tutorial-register-applications.md) `https://jwt.ms`, which is a Microsoft-owned web application that displays the decoded contents of a token (the contents of the token never leave your browser). -- To simulate a risky sign-in, download the TOR Browser and attempt to sign in to the user flow endpoint.-- Using the following settings, [create a Conditional Access policy](conditional-access-identity-protection-setup.md):
-
- - For **Users and groups**, select the test user (don't select **All users** or you could block yourself from signing in).
- - For **Cloud apps or actions**, choose **Select apps**, and then choose your relying party application.
- - For Conditions, select **Sign-in risk** and **High**, **Medium**, and **Low** risk levels.
- - For **Grant**, choose **Block access**.
- ![Risk detections](media/conditional-access-identity-protection-setup/test-conditional-access-policy.png)
+## Pricing tier
+Azure AD B2C **Premium P2** is required to create risky sign-in policies. **Premium P1** tenants can create a policy that is based on location, application, user-based, or group-based policies. For more information, see [Change your Azure AD B2C pricing tier](billing.md#change-your-azure-ad-pricing-tier)
-## Add Conditional Access to a new user flow
+## Prepare your Azure AD B2C tenant
-1. Sign in to the [Azure portal](https://portal.azure.com).
-1. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
-1. In the Azure portal, search for and select **Azure AD B2C**.
-1. Under **Policies**, select **User flows**, and then select **New user flow**.
-1. On the **Create a user flow** page, select the user flow type.
-1. Under **Select a version**, select **Recommended**, and then select **Create**. ([Learn more](user-flow-versions.md) about user flow versions.)
+To add a Conditional Access policy, disable security defaults:
+
+1. Sign in to the [Azure portal](https://portal.azure.com/).
+2. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
+3. Under **Azure services**, select **Azure AD B2C**. Or use the search box to find and select **Azure AD B2C**.
+4. Select **Properties**, and then select **Manage Security defaults**.
- ![Create user flow page in Azure portal with properties highlighted](./media/tutorial-create-user-flows/select-version.png)
+ ![Disable the security defaults](media/conditional-access-user-flow/disable-security-defaults.png)
-1. Enter a **Name** for the user flow. For example, *signupsignin1*.
-1. In the **Identity providers** section, select the identity providers you want to allow for this user flow.
-2. In the **Multifactor authentication** section, select the desired **MFA method**, and then under **MFA enforcement** select **Conditional (Recommended)**.
+5. Under **Enable Security defaults**, select **No**.
+
+ ![Set the Enable security defaults toggle to No](media/conditional-access-user-flow/enable-security-defaults-toggle.png)
+
+## Add a Conditional Access policy
+
+A Conditional Access policy is an if-then statement of assignments and access controls. A Conditional Access policy brings signals together to make decisions and enforce organizational policies. The logical operator between the assignments is *And*. The operator in each assignment is *Or*.
+
+![Conditional access assignments](media/conditional-access-user-flow/conditional-access-assignments.png)
+
+To add a Conditional Access policy:
+
+1. In the Azure portal, search for and select **Azure AD B2C**.
+1. Under **Security**, select **Conditional Access (Preview)**. The **Conditional Access Policies** page opens.
+1. Select **+ New policy**.
+1. Enter a name for the policy, such as *Block risky sign-in*.
+1. Under **Assignments**, choose **Users and groups**, and then select the one of the following supported configurations:
+
+ |Include |License | Notes |
+ ||||
+ |**All users** | P1, P2 |If you choose to include **All Users**, this policy will affect all of your users. To be sure not to lock yourself out, exclude your administrative account by choosing **Exclude**, selecting **Directory roles**, and then selecting **Global Administrator** in the list. You can also select **Users and Groups** and then select your account in the **Select excluded users** list. |
- ![Configure multifactor authentication](media/conditional-access-user-flow/configure-mfa.png)
+1. Select **Cloud apps or actions**, and then **Select apps**. Browse for your [relying party application](tutorial-register-applications.md).
+
+1. Select **Conditions**, and then select from the following conditions. For example, select **Sign-in risk** and **High**, **Medium**, and **Low** risk levels.
+
+ |Condition |License |Notes |
+ ||||
+ |**User risk**|P2|User risk represents the probability that a given identity or account is compromised.|
+ |**Sign-in risk**|P2|Sign-in risk represents the probability that a given authentication request isn't authorized by the identity owner.|
+ |**Device platforms**|Not supported| Characterized by the operating system that runs on a device. For more information, see [Device platforms](../active-directory/conditional-access/concept-conditional-access-conditions.md#device-platforms).|
+ |**Locations**|P1, P2|Named locations may include the public IPv4 network information, country or region, or unknown areas that don't map to specific countries or regions. For more information, see [Locations](../active-directory/conditional-access/concept-conditional-access-conditions.md#locations). |
+
+1. Under **Access controls**, select **Grant**. Then select whether to block or grant access:
+
+ |Option |License |Note |
+ ||||
+ |**Block access**|P1, P2| Prevents access based on the conditions specified in this conditional access policy.|
+ |**Grant access** with **Require multi-factor authentication**|P1, P2|Based on the conditions specified in this conditional access policy, the user is required to go through Azure AD B2C multi-factor authentication.|
-1. In the **Conditional Access** section, select the **Enforce conditional access policies** check box.
+1. Under **Enable policy**, select one of the following:
+
+ |Option |License |Note |
+ ||||
+ |**Report-only**|P1, P2| Report-only allows administrators to evaluate the impact of Conditional Access policies before enabling them in their environment. We recommend you check policy with this state, and determine the impact to end users without requiring multi-factor authentication or blocking users. For more information, see [Review Conditional Access outcomes in the audit report](#review-conditional-access-outcomes-in-the-audit-report)|
+ | **On**| P1, P2| The access policy is evaluated and not enforced. |
+ | **Off** | P1, P2| The access policy is not activated and has no affect on the users. |
+
+1. Enable your test Conditional Access policy by selecting **Create**.
+
+## Add Conditional Access to a user flow
- ![Configure Conditional Access settings](media/conditional-access-user-flow/configure-conditional-access.png)
+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. In the **User attributes and claims** section, choose the claims and attributes that you want to collect and send from the user during sign-up. For example, select **Show more**, and then choose attributes and claims for **Country/Region** and **Display Name**. Select **OK**.
+Multiple Conditional Access policies may apply to an individual user at any time. In this case, the most strict access control policy takes precedence. For example, if one policy requires multi-factor authentication (MFA), while the other blocks access, the user will be blocked.
- ![Attributes and claims selection page with three claims selected](./media/conditional-access-user-flow/configure-user-attributes-claims.png)
+## Enable multi-factor authentication (optional)
-1. Click **Create** to add the user flow. A prefix of *B2C_1* is automatically prepended to the name.
+When adding Conditional Access to a user flow, consider the use of **Multi-factor authentication (MFA)**. Users can use a one-time code via SMS or voice, or a one-time password via email for multi-factor authentication. MFA settings are independent from Conditional Access settings. You can set MFA to **Always On** so that MFA is always required regardless of your Conditional Access setup. Or, you can set MFA to **Conditional** so that MFA is required only when an active Conditional Access Policy requires it.
-## Add Conditional Access to an existing user flow
+> [!IMPORTANT]
+> If your Conditional Access policy grants access with MFA but the user hasn't enrolled a phone number, the user may be blocked.
-> [!NOTE]
-> The existing user flow must be a version that supports Conditional Access. These user flow versions are labeled **Recommended**.
+
+To enable Conditional Access for a user flow, make sure the version supports Conditional Access. These user flow versions are labeled **Recommended**.
1. Sign in to the [Azure portal](https://portal.azure.com). 1. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
-1. In the Azure portal, search for and select **Azure AD B2C**.
+1. Under **Azure services**, select **Azure AD B2C**. Or use the search box to find and select **Azure AD B2C**.
1. Under **Policies**, select **User flows**. Then select the user flow.
-1. Select **Properties** and make sure the user flow supports Conditional Access by selecting **Properties** and looking for the setting labeled **Conditional Access**.
+1. Select **Properties** and make sure the user flow supports Conditional Access by looking for the setting labeled **Conditional Access**.
![Configure MFA and Conditional Access in Properties](media/conditional-access-user-flow/add-conditional-access.png)
-1. In the **Multifactor authentication** section, select the desired **MFA method**, and then under **MFA enforcement** select **Conditional (Recommended)**.
+1. In the **Multi-factor authentication** section, select the desired **MFA method**, and then under **MFA enforcement**, select **Conditional (Recommended)**.
1. In the **Conditional Access** section, select the **Enforce conditional access policies** check box. 1. Select **Save**.
-## Test the user flow
-To test Conditional Access in your user flow, [create a Conditional Access policy](conditional-access-identity-protection-setup.md) and enable Conditional Access in your user flow as described above.
-### Run the user flow
+## Add Conditional Access to your policy
-1. Select the user flow you created to open its overview page, then select **Run user flow**. Under **Application**, select *webapp1*. The **Reply URL** should show `https://jwt.ms`.
+1. Get the example of a conditional access policy on [GitHub](https://github.com/azure-ad-b2c/samples/tree/master/policies/conditional-access).
+1. In each file, replace the string `yourtenant` with the name of your Azure AD B2C tenant. For example, if the name of your B2C tenant is *contosob2c*, all instances of `yourtenant.onmicrosoft.com` become `contosob2c.onmicrosoft.com`.
+1. Upload the policy files.
- ![Run user flow page in portal with Run user flow button highlighted](./media/tutorial-create-user-flows/signup-signin-run-now.PNG)
+## Test your custom policy
+1. Select the `B2C_1A_signup_signin_with_ca` or `B2C_1A_signup_signin_with_ca_whatif` policy to open its overview page. Then select **Run user flow**. Under **Application**, select *webapp1*. The **Reply URL** should show `https://jwt.ms`.
1. Copy the URL under **Run user flow endpoint**.
-1. To simulate a risky sign-in, open the [Tor Browser](https://www.torproject.org/download/) and use the URL you copied in the preview step to sign in to the registered app.
+1. To simulate a risky sign-in, open the [Tor Browser](https://www.torproject.org/download/) and use the URL you copied in the previous step to sign in to the registered app.
-1. Enter the requested information in the sign-in page, and then attempt to sign in. The token is returned to `https://jwt.ms` and should be displayed to you. In the jwt.ms decoded token, you should see that the sign-in was blocked:
-
- ![Test a blocked sign-in](media/conditional-access-identity-protection-setup/test-blocked-sign-in.png)
+1. Enter the requested information in the sign-in page, and then attempt to sign in. The token is returned to `https://jwt.ms` and should be displayed to you. In the jwt.ms decoded token, you should see that the sign-in was blocked.
::: zone-end
-## Add Conditional Access to your policy
+## Test your user flow
-You can find an example of a conditional access policy on [GitHub](https://github.com/azure-ad-b2c/samples/tree/master/policies/conditional-access).
+1. Select the user flow you created to open its overview page, and then select **Run user flow**. Under **Application**, select *webapp1*. The **Reply URL** should show `https://jwt.ms`.
+
+1. Copy the URL under **Run user flow endpoint**.
+
+1. To simulate a risky sign-in, open the [Tor Browser](https://www.torproject.org/download/) and use the URL you copied in the previous step to sign in to the registered app.
+
+1. Enter the requested information in the sign-in page, and then attempt to sign in. The token is returned to `https://jwt.ms` and should be displayed to you. In the jwt.ms decoded token, you should see that the sign-in was blocked.
::: zone-end
+## Review Conditional Access outcomes in the audit report
+
+To review the result of a Conditional Access event:
+
+1. Sign in to the [Azure portal](https://portal.azure.com/).
+
+2. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
+
+3. Under **Azure services**, select **Azure AD B2C**. Or use the search box to find and select **Azure AD B2C**.
+
+4. Under **Activities**, select **Audit logs**.
+
+5. Filter the audit log by setting **Category** to **B2C** and setting **Activity Resource Type** to **IdentityProtection**. Then select **Apply**.
+
+6. Review audit activity for up to the last seven days. The following types of activity are included:
+
+ - **Evaluate conditional access policies**: This audit log entry indicates that a Conditional Access evaluation was performed during an authentication.
+ - **Remediate user**: This entry indicates that the grant or requirements of a Conditional Access policy were met by the end user, and this activity was reported to the risk engine to mitigate (reduce the risk of) the user.
+
+7. Select an **Evaluate conditional access policy** log entry in the list to open the **Activity Details: Audit log** page, which shows the audit log identifiers, along with this information in the **Additional Details** section:
+
+ - **ConditionalAccessResult**: The grant required by the conditional policy evaluation.
+ - **AppliedPolicies**: A list of all the Conditional Access policies where the conditions were met and the policies are ON.
+ - **ReportingPolicies**: A list of the Conditional Access policies that were set to report-only mode and where the conditions were met.
+ ## Next steps [Customize the user interface in an Azure AD B2C user flow](customize-ui-with-html.md)
active-directory-b2c Configure Tokens https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/configure-tokens.md
The following diagram shows the refresh token sliding window lifetime behavior.
![Refresh token lifetime](./media/configure-tokens/refresh-token-lifetime.png) > [!NOTE]
-> Single-page applications using the authorization code flow with PKCE always have a refresh token lifetime of 24 hours. [Learn more about the security implications of refresh tokens in the browser](../active-directory/develop/reference-third-party-cookies-spas.md#security-implications-of-refresh-tokens-in-the-browser).
+> >Single-page applications using the authorization code flow with PKCE always have a refresh token lifetime of 24 hours while mobile apps, desktop apps, and web apps do not experience this limitation. [Learn more about the security implications of refresh tokens in the browser](../active-directory/develop/reference-third-party-cookies-spas.md#security-implications-of-refresh-tokens-in-the-browser).
+ ## Configure token lifetime
active-directory-b2c Configure User Input https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/configure-user-input.md
Previously updated : 12/10/2020 Last updated : 03/04/2021
To collect the city claim during sign-up, it must be added as an output claim to
</ClaimsProvider> ```
-To collect the city claim after initial sign-in with a federated account, it must be added as an output claim to the `SelfAsserted-Social` technical profile. For local and federated account users to be able to edit their profile data later, add the output claim to the `SelfAsserted-ProfileUpdate` technical profile. Override these technical profiles in the extension file. Specify the entire list of the output claims to control the order the claims are presented on the screen. Find the **ClaimsProviders** element. Add a new ClaimsProviders as follows:
+To collect the city claim after initial sign-in with a federated account, it must be added as an output claim to the `SelfAsserted-Social` technical profile. For local and federated account users to be able to edit their profile data later, add the input and output claims to the `SelfAsserted-ProfileUpdate` technical profile. Override these technical profiles in the extension file. Specify the entire list of the output claims to control the order the claims are presented on the screen. Find the **ClaimsProviders** element. Add a new ClaimsProviders as follows:
```xml <ClaimsProvider>
To collect the city claim after initial sign-in with a federated account, it mus
<TechnicalProfiles> <!--Federated account first-time sign-in page--> <TechnicalProfile Id="SelfAsserted-Social">
+ <InputClaims>
+ <InputClaim ClaimTypeReferenceId="city" />
+ </InputClaims>
<OutputClaims> <OutputClaim ClaimTypeReferenceId="displayName"/> <OutputClaim ClaimTypeReferenceId="givenName"/>
To collect the city claim after initial sign-in with a federated account, it mus
</TechnicalProfile> <!--Edit profile page--> <TechnicalProfile Id="SelfAsserted-ProfileUpdate">
+ <InputClaims>
+ <InputClaim ClaimTypeReferenceId="city" />
+ </InputClaims>
<OutputClaims> <OutputClaim ClaimTypeReferenceId="displayName"/> <OutputClaim ClaimTypeReferenceId="givenName" />
The token sent back to your application includes the `city` claim.
- Learn more about the [ClaimsSchema](claimsschema.md) element in the IEF reference. - Learn how to [use custom attributes in Azure AD B2C](user-flow-custom-attributes.md).
active-directory-b2c Connect With Saml Service Providers https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/connect-with-saml-service-providers.md
- Title: Configure Azure AD B2C as a SAML IdP to your applications
-title-suffix: Azure AD B2C
-description: How to configure Azure AD B2C to provide SAML protocol assertions to your applications (service providers). Azure AD B2C will act as the single identity provider (IdP) to your SAML application.
------- Previously updated : 01/17/2021-----
-# Register a SAML application in Azure AD B2C
-
-In this article, you learn how to configure Azure Active Directory B2C (Azure AD B2C) to act as a Security Assertion Markup Language (SAML) identity provider (IdP) to your applications.
-
-## Scenario overview
-
-Organizations that use Azure AD B2C as their customer identity and access management solution might require interaction with identity providers or applications that are configured to authenticate using the SAML protocol.
-
-Azure AD B2C achieves SAML interoperability in one of two ways:
-
-* By acting as an *identity provider* (IdP) and achieving single-sign-on (SSO) with SAML-based service providers (your applications)
-* By acting as a *service provider* (SP) and interacting with SAML-based identity providers like Salesforce and ADFS
-
-![Diagram with B2C as identity provider on left and B2C as service provider on right](media/saml-identity-provider/saml-idp-diagram-01.jpg)
-
-Summarizing the two non-exclusive core scenarios with SAML:
-
-| Scenario | Azure AD B2C role | How-to |
-| -- | -- | - |
-| My application expects a SAML assertion to complete an authentication. | **Azure AD B2C acts as the identity provider (IdP)**<br />Azure AD B2C acts as a SAML IdP to the applications. | This article. |
-| My users need single-sign-on with a SAML-compliant identity provider like ADFS, Salesforce, or Shibboleth. | **Azure AD B2C acts as the service provider (SP)**<br />Azure AD B2C acts as a service provider when connecting to the SAML identity provider. It's a federation proxy between your application and the SAML identity provider. | <ul><li>[Set up sign-in with ADFS as a SAML IdP using custom policies](identity-provider-adfs.md)</li><li>[Set up sign-in with a Salesforce SAML provider using custom policies](identity-provider-salesforce-saml.md)</li></ul> |
-
-## Prerequisites
-
-* Complete the steps in [Get started with custom policies in Azure AD B2C](custom-policy-get-started.md). You need the *SocialAndLocalAccounts* custom policy from the custom policy starter pack discussed in the article.
-* Basic understanding of the Security Assertion Markup Language (SAML) protocol.
-* A web application configured as a SAML service provider (SP). For this tutorial, you can use a [SAML test application][samltest] that we provide.
-
-## Components of the solution
-
-There are three main components required for this scenario:
-
-* SAML **service provider** with the ability to send SAML requests, and receive, decode, and respond to SAML assertions from Azure AD B2C. Service provider is also known as the relying party application.
-* Publicly available SAML **metadata endpoint** for your service provider.
-* [Azure AD B2C tenant](tutorial-create-tenant.md)
-
-If you don't yet have a SAML service provider and an associated metadata endpoint, you can use this sample SAML application that we've made available for testing:
-
-[SAML Test Application][samltest]
-
-## 1. Set up certificates
-
-To build a trust relationship between your service provider and Azure AD B2C, you need to provide the web app X509 certificates.
-
-* **Service provider certificates**
- * Certificate with a private key stored in your Web App. This certificate is used by your service provider to sign the SAML request sent to Azure AD B2C. Azure AD B2C reads the public key from the service provider metadata to validate the signature.
- * (Optional) Certificate with a private key stored in your Web App. Azure AD B2C reads the public key from the service provider metadata to encrypt the SAML assertion. The service provider then uses the private key to decrypt the assertion.
-* **Azure AD B2C certificates**
- * Certificate with a private key in Azure AD B2C. This certificate is used by Azure AD B2C to sign the SAML response sent to your service provider. Your service provider reads the Azure AD B2C metadata public key to validate the signature of the SAML response.
-
-You can use a certificate issued by a public certificate authority or, for this tutorial, a self-signed certificate.
-
-### 1.1 Create a self-signed certificate
--
-### 1.2 Upload the certificate
-
-Next, upload the SAML assertion and response signing certificate to Azure AD B2C.
-
-1. Sign in to the [Azure portal](https://portal.azure.com) and browse to your Azure AD B2C tenant.
-1. Under **Policies**, select **Identity Experience Framework** and then **Policy keys**.
-1. Select **Add**, and then select **Options** > **Upload**.
-1. Enter a **Name**, for example *SamlIdpCert*. The prefix *B2C_1A_* is automatically added to the name of your key.
-1. Upload your certificate using the upload file control.
-1. Enter the certificate's password.
-1. Select **Create**.
-1. Verify that the key appears as expected. For example, *B2C_1A_SamlIdpCert*.
-
-## 2. Prepare your policy
-
-### 2.1 Create the SAML token issuer
-
-Now, add the capability for your tenant to issue SAML tokens, using [SAML token issuer](saml-issuer-technical-profile.md) and [SAML session provider](custom-policy-reference-sso.md#samlssosessionprovider) technical profiles.
-
-Open `SocialAndLocalAccounts\`**`TrustFrameworkExtensions.xml`** in the custom policy starter pack.
-
-Locate the `<ClaimsProviders>` section and add the following XML snippet.
-
-You can change the value of the `IssuerUri` metadata. This is the issuer URI that is returned in the SAML response from Azure AD B2C. Your relying party application should be configured to accept an issuer URI during SAML assertion validation.
-
-```xml
-<ClaimsProvider>
- <DisplayName>Token Issuer</DisplayName>
- <TechnicalProfiles>
-
- <!-- SAML Token Issuer technical profile -->
- <TechnicalProfile Id="Saml2AssertionIssuer">
- <DisplayName>Token Issuer</DisplayName>
- <Protocol Name="SAML2"/>
- <OutputTokenFormat>SAML2</OutputTokenFormat>
- <Metadata>
- <!-- The issuer contains the policy name; it should be the same name as configured in the relying party application. B2C_1A_signup_signin_SAML is used below. -->
- <!--<Item Key="IssuerUri">https://tenant-name.b2clogin.com/tenant-name.onmicrosoft.com/B2C_1A_signup_signin_saml</Item>-->
- </Metadata>
- <CryptographicKeys>
- <Key Id="MetadataSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
- <Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
- <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
- </CryptographicKeys>
- <InputClaims/>
- <OutputClaims/>
- <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer"/>
- </TechnicalProfile>
-
- <!-- Session management technical profile for SAML based tokens -->
- <TechnicalProfile Id="SM-Saml-issuer">
- <DisplayName>Session Management Provider</DisplayName>
- <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
- </TechnicalProfile>
-
- </TechnicalProfiles>
-</ClaimsProvider>
-```
-
-## 3. Add the SAML relying party policy
-
-Now that your tenant can issue SAML assertions, you need to create the SAML relying party policy, and modify the user journey so that it issues a SAML assertion instead of a JWT.
-
-### 3.1 Create sign-up or sign-in policy
-
-1. Create a copy of the *SignUpOrSignin.xml* file in your starter pack working directory and save it with a new name. For example, *SignUpOrSigninSAML.xml*. This is your relying party policy file.
-
-1. Open the *SignUpOrSigninSAML.xml* file in your preferred editor.
-
-1. Change the `PolicyId` and `PublicPolicyUri` of the policy to _B2C_1A_signup_signin_saml_ and `http://tenant-name.onmicrosoft.com/B2C_1A_signup_signin_saml` as seen below.
-
- ```xml
- <TrustFrameworkPolicy
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xmlns:xsd="http://www.w3.org/2001/XMLSchema"
- xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
- PolicySchemaVersion="0.3.0.0"
- TenantId="tenant-name.onmicrosoft.com"
- PolicyId="B2C_1A_signup_signin_saml"
- PublicPolicyUri="http://tenant-name.onmicrosoft.com/B2C_1A_signup_signin_saml">
- ```
-
-1. Add following XML snippet just before the `<RelyingParty>` element. This XML overwrites orchestration step number 7 of the _SignUpOrSignIn_ user journey. If you started from a different folder in the starter pack, or customized your user journey by adding or removing orchestration steps, make sure the number (in the `order` element) is aligned with the one specified in the user journey for the token issuer step (for example, in the other starter pack folders it's step number 4 for `LocalAccounts`, 6 for `SocialAccounts` and 9 for `SocialAndLocalAccountsWithMfa`).
-
- ```xml
- <UserJourneys>
- <UserJourney Id="SignUpOrSignIn">
- <OrchestrationSteps>
- <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="Saml2AssertionIssuer"/>
- </OrchestrationSteps>
- </UserJourney>
- </UserJourneys>
- ```
-
-1. Replace the entire `<TechnicalProfile>` element in the `<RelyingParty>` element with the following technical profile XML.
-
- ```xml
- <TechnicalProfile Id="PolicyProfile">
- <DisplayName>PolicyProfile</DisplayName>
- <Protocol Name="SAML2"/>
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="displayName" />
- <OutputClaim ClaimTypeReferenceId="givenName" />
- <OutputClaim ClaimTypeReferenceId="surname" />
- <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
- <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
- <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
- </OutputClaims>
- <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
- </TechnicalProfile>
- ```
-
-1. Update `tenant-name` with the name of your Azure AD B2C tenant.
-
-Your final relying party policy file should look like the following XML code:
-
-```xml
-<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
-<TrustFrameworkPolicy
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xmlns:xsd="http://www.w3.org/2001/XMLSchema"
- xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
- PolicySchemaVersion="0.3.0.0"
- TenantId="contoso.onmicrosoft.com"
- PolicyId="B2C_1A_signup_signin_saml"
- PublicPolicyUri="http://contoso.onmicrosoft.com/B2C_1A_signup_signin_saml">
-
- <BasePolicy>
- <TenantId>contoso.onmicrosoft.com</TenantId>
- <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
- </BasePolicy>
-
- <UserJourneys>
- <UserJourney Id="SignUpOrSignIn">
- <OrchestrationSteps>
- <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="Saml2AssertionIssuer"/>
- </OrchestrationSteps>
- </UserJourney>
- </UserJourneys>
-
- <RelyingParty>
- <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
- <TechnicalProfile Id="PolicyProfile">
- <DisplayName>PolicyProfile</DisplayName>
- <Protocol Name="SAML2"/>
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="displayName" />
- <OutputClaim ClaimTypeReferenceId="givenName" />
- <OutputClaim ClaimTypeReferenceId="surname" />
- <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
- <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
- <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
- </OutputClaims>
- <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
- </TechnicalProfile>
- </RelyingParty>
-</TrustFrameworkPolicy>
-```
-
-> [!NOTE]
-> When implementing other types of user flows (for example sign-in, password reset, or profile editing), the process is essentially the same as described in this section. In step 4 above, you'll change the last step of the user journey from `JWTIssuer` to `Saml2AssertionIssuer`. And in step 6 above, in the relying party section, you'll change the **Protocol** from `OpenIdConnect` to `SAML2`.
-
-### 3.2 Upload and test your policy metadata
-
-Save your changes and upload the new policy file. After you've uploaded both policies (the extension and the relying party files), open a web browser and navigate to the policy metadata.
-
-Azure AD B2C policy IDP metadata is information used in the SAML protocol to expose the configuration of a SAML identity provider. Metadata defines the location of the services, such as sign-in and sign-out, certificates, sign-in method, and more. The Azure AD B2C policy metadata is available at the following URL. Replace `tenant-name` with the name of your Azure AD B2C tenant, and `policy-name` with the name (ID) of the policy for example, .../B2C_1A_signup_signin_saml/samlp/metadata:
-
-`https://tenant-name.b2clogin.com/tenant-name.onmicrosoft.com/policy-name/Samlp/metadata`
-
-Your custom policy and Azure AD B2C tenant are now ready. Next, create an application registration in Azure AD B2C.
-
-## 4. Setup application in the Azure AD B2C Directory
-
-### 4.1 Register your application in Azure AD B2C
-
-1. Sign in to the [Azure portal](https://portal.azure.com).
-1. Select the **Directory + subscription** filter in the top menu, and then select the directory that contains your Azure AD B2C tenant.
-1. In the left menu, select **Azure AD B2C**. Or, select **All services** and search for and select **Azure AD B2C**.
-1. Select **App registrations**, and then select **New registration**.
-1. Enter a **Name** for the application. For example, *SAMLApp1*.
-1. Under **Supported account types**, select **Accounts in this organizational directory only**
-1. Under **Redirect URI**, select **Web**, and then enter `https://localhost`. You modify this value later in the application registration's manifest.
-1. Select **Register**.
-
-### 4.2 Update the app manifest
-
-For SAML apps, there are several properties you need to configure in the application registration's manifest.
-
-1. In the [Azure portal](https://portal.azure.com), navigate to the application registration that you created in the previous section.
-1. Under **Manage**, select **Manifest** to open the manifest editor. You modify several properties in the following sections.
-
-#### identifierUris
-
-The `identifierUris` is a string collection containing user-defined URI(s) that uniquely identify a Web app within its Azure AD B2C tenant. The URI must match the SAML request's `Issuer` name. The user-defined URI is typically the same value as the service provider metadata `entityID`.
-
-#### samlMetadataUrl
-
-This property represents service provider's publicly available metadata URL. The metadata URL can point to a metadata file uploaded to any anonymously accessible endpoint, for example blob storage.
-
-The metadata is information used in the SAML protocol to expose the configuration of a SAML party, such as a service provider. Metadata defines the location of the services like sign-in and sign-out, certificates, sign-in method, and more. Azure AD B2C reads the service provider metadata and acts accordingly. The metadata is not required. You can also specify some of attributes like the reply URI and logout URI directly in the app manifest.
-
-If there are properties specified in *both* the SAML metadata URL and in the application registration's manifest, they are **merged**. The properties specified in the metadata URL are processed first and take precedence.
-
-For this tutorial, which uses the SAML test application, use the following value for `samlMetadataUrl`:
-
-```json
-"samlMetadataUrl":"https://samltestapp2.azurewebsites.net/Metadata",
-```
-
-#### replyUrlsWithType (Optional)
-
-If you do not provide a metadata URI, you can explicitly specify the reply URL. This optional property represents the `AssertionConsumerServiceUrl` (`SingleSignOnService` URL in the service provider metadata) and the `BindingType` is assumed to be `HTTP POST`.
-
-If you choose to configure the reply URL and logout URL in the application manifest without using the service provider metadata, Azure AD B2C will not validate the SAML request signature, nor encrypt the SAML response.
-
-For this tutorial, in which you use the SAML test application, set the `url` property of `replyUrlsWithType` to the value shown in the following JSON snippet.
-
-```json
-"replyUrlsWithType":[
- {
- "url":"https://samltestapp2.azurewebsites.net/SP/AssertionConsumer",
- "type":"Web"
- }
-],
-```
-
-#### logoutUrl (Optional)
-
-This optional property represents the `Logout` URL (`SingleLogoutService` URL in the relying party metadata), and the `BindingType` for this is assumed to be `Http-Redirect`.
-
-For this tutorial, which uses the SAML test application, leave `logoutUrl` set to `https://samltestapp2.azurewebsites.net/logout`:
-
-```json
-"logoutUrl": "https://samltestapp2.azurewebsites.net/logout",
-```
-
-## 5. Update your application code
-
-The last step is to enable Azure AD B2C as a SAML IdP in your SAML relying party application. Each application is different and the steps to do so vary. Consult your app's documentation for details.
-
-The metadata can be configured in your service provider as "Static Metadata" or "Dynamic Metadata". In static mode, you copy all or part of the metadata from the Azure AD B2C policy metadata. In dynamic mode, you set the URL to the metadata and let our application read the metadata dynamically.
-
-Some or all the following are typically required:
-
-* **Metadata**: `https://tenant-name.b2clogin.com/tenant-name.onmicrosoft.com/policy-name/Samlp/metadata`
-* **Issuer**: The SAML request `issuer` value must match one of the URIs configured in the `identifierUris` element of the application registration manifest. If the SAML request `issuer` name doesn't exist in the `identifierUris` element, [add it to the application registration manifest](#identifieruris). For example, `https://contoso.onmicrosoft.com/app-name`.
-* **Login Url/SAML endpoint/SAML Url**: Check the value in the Azure AD B2C SAML policy metadata file for the `<SingleSignOnService>` XML element
-* **Certificate**: This is *B2C_1A_SamlIdpCert*, but without the private key. To get the public key of the certificate:
-
- 1. Go to the metadata URL specified above.
- 1. Copy the value in the `<X509Certificate>` element.
- 1. Paste it into a text file.
- 1. Save the text file as a *.cer* file.
-
-### 5.1 Test with the SAML Test App (optional)
-
-To complete this tutorial using our [SAML Test Application][samltest]:
-
-* Update the tenant name
-* Update policy name, for example *B2C_1A_signup_signin_saml*
-* Specify this issuer URI. Use one of the URIs found in the `identifierUris` element in the application registration manifest, for example `https://contoso.onmicrosoft.com/app-name`.
-
-Select **Login** and you should be presented with a user sign-in screen. Upon sign-in, a SAML assertion is issued back to the sample application.
-
-## Enable Encrypted Assertions (Optional)
-
-To Encrypt SAML Assertions sent back to the Service Provider, Azure AD B2C will use the Service providers public key certificate. The public key must exist in the SAML Metadata outlined in the above ["samlMetadataUrl"](#samlmetadataurl) as a KeyDescriptor with a use of 'Encryption'.
-
-The following XML code is an example of the SAML metadata KeyDescriptor with a use set to Encryption:
-
-```xml
-<KeyDescriptor use="encryption">
- <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
- <X509Data>
- <X509Certificate>valid certificate</X509Certificate>
- </X509Data>
- </KeyInfo>
-</KeyDescriptor>
-```
-
-To enable Azure AD B2C to send encrypted assertions, set the **WantsEncryptedAssertion** metadata item to `true` in the [relying party technical profile](relyingparty.md#technicalprofile). You can also configure the algorithm used to encrypt the SAML assertion. For more information, see [relying party technical profile metadata](relyingparty.md#metadata).
-
-```xml
-<RelyingParty>
- <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
- <TechnicalProfile Id="PolicyProfile">
- <DisplayName>PolicyProfile</DisplayName>
- <Protocol Name="SAML2"/>
- <Metadata>
- <Item Key="WantsEncryptedAssertions">true</Item>
- </Metadata>
- ..
- </TechnicalProfile>
-</RelyingParty>
-```
-
-## Enable identity provider initiated flow (Optional)
-
-In identity provider initiated flow, the sign-in process is initiated by the identity provider (Azure AD B2C), which sends an unsolicited SAML response to the service provider (your relying party application). We don't currently support scenarios where the initiating identity provider is an external identity provider, for example [AD-FS](identity-provider-adfs.md), or [Salesforce](identity-provider-salesforce-saml.md).
-
-To enable identity provider (Azure AD B2C) initiated flow, set the **IdpInitiatedProfileEnabled** metadata item to `true` in the [relying party technical profile](relyingparty.md#technicalprofile).
-
-```xml
-<RelyingParty>
- <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
- <TechnicalProfile Id="PolicyProfile">
- <DisplayName>PolicyProfile</DisplayName>
- <Protocol Name="SAML2"/>
- <Metadata>
- <Item Key="IdpInitiatedProfileEnabled">true</Item>
- </Metadata>
- ..
- </TechnicalProfile>
-</RelyingParty>
-```
-
-To sign in or sign up a user through identity provider initiated flow, use the following URL:
-
-```
-https://tenant-name.b2clogin.com/tenant-name.onmicrosoft.com/policy-name/generic/login?EntityId=app-identifier-uri
-```
-
-Replace the following values:
-
-* **tenant-name** with your tenant name
-* **policy-name** with your SAML relying party policy name
-* **app-identifier-uri** with the `identifierUris` in the metadata file, such as `https://contoso.onmicrosoft.com/app-name`
-## Sample policy
-
-We provide a complete sample policy that you can use for testing with the SAML Test App.
-
-1. Download the [SAML-SP-initiated login sample policy](https://github.com/azure-ad-b2c/saml-sp/tree/master/policy/SAML-SP-Initiated)
-1. Update `TenantId` to match your tenant name, for example *contoso.b2clogin.com*
-1. Keep the policy name of *B2C_1A_signup_signin_saml*
-
-## Supported and unsupported SAML modalities
-
-The following SAML relying party (RP) scenarios are supported via your own metadata endpoint:
-
-* Multiple logout URLs or POST binding for logout URL in application/service principal object.
-* Specify signing key to verify RP requests in application/service principal object.
-* Specify token encryption key in application/service principal object.
-* Identity Provider initiated sign on, where the Identity Provider is Azure AD B2C.
-
-## SAML token
-
-A SAML token is a security token that is issued by Azure AD B2C after a successful sign-in. It contains information about the user, the service provider for which the token is intended, signature, and validity time. The following table lists the claims and properties that you can expect in a SAML token issued by Azure AD B2C.
-
-|Element  |Property  |Notes  |
-||||
-|`<Response>`| `ID` | An auto-generated unique identifier of the response. |
-|`<Response>`| `InResponseTo` | The ID of the SAML request that this message is in response to. |
-|`<Response>` | `IssueInstant` | The time instant of issue of the response. The time value is encoded in UTC.  To change the settings on your token lifetimes, set the `TokenNotBeforeSkewInSeconds` [metadata](saml-issuer-technical-profile.md#metadata) of the SAML token issuer technical profile. |
-|`<Response>` | `Destination`| A URI reference indicating the address to which this response has been sent. The value is identical to the SAML request `AssertionConsumerServiceURL`. |
-|`<Response>` `<Issuer>` | |Identifies the token issuer. This is an arbitrary URI defined by the SAML token issue's `IssuerUri` [metadata](saml-issuer-technical-profile.md#metadata)     |
-|`<Response>` `<Assertion>` `<Subject>` `<NameID>`     |         |The principal about which the token asserts information, such as the user object ID. This value is immutable and cannot be reassigned or reused. It can be used to perform authorization checks safely, such as when the token is used to access a resource. By default, the subject claim is populated with the object ID of the user in the directory.|
-|`<Response>` `<Assertion>` `<Subject>` `<NameID>`     | `Format` | A URI reference representing the classification of string-based identifier information. By default this property is omitted. You can set the relying party [SubjectNamingInfo](relyingparty.md#subjectnaminginfo) to specify the `NameID` format, such as `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`. |
-|`<Response>` `<Assertion>` `<Subject>` `<Conditions>` |`NotBefore` |The time at which the token becomes valid. The time value is encoded in UTC. Your application should use this claim to verify the validity of the token lifetime. To change the settings on your token lifetimes, set the `TokenNotBeforeSkewInSeconds` [metadata](saml-issuer-technical-profile.md#metadata) of the SAML token issue technical profile. |
-|`<Response>` `<Assertion>` `<Subject>` `<Conditions>` | `NotOnOrAfter` | The time at which the token becomes invalid. Your application should use this claim to verify the validity of the token lifetime. The default value is 5 minutes after the `NotBefore` and can be updated by adding the `TokenLifeTimeInSeconds` [metadata](saml-issuer-technical-profile.md#metadata) of the SAML token issue technical profile.|
-|`<Response>` `<Assertion>` `<Conditions>` `<AudienceRestriction>` `<Audience>` | |A URI reference that identifies an intended audience. It identifies the intended recipient of the token. The value is identical to the SAML request `AssertionConsumerServiceURL`.|
-|`<Response>` `<Assertion>` `<AttributeStatement>` collection of `<Attribute>` | | Assertions collection (claims), as configured in the [relying party technical profile](relyingparty.md#technicalprofile) output claims. You can configure the name of the assertion by setting the `PartnerClaimType` of the output claim. |
-
-## Next steps
--- You can find more information about the [SAML protocol on the OASIS website](https://www.oasis-open.org/).-- Get the SAML test web app from [Azure AD B2C GitHub community repo](https://github.com/azure-ad-b2c/saml-sp-tester).-
-<!-- LINKS - External -->
-[samltest]: https://aka.ms/samltestapp
active-directory-b2c Custom Policy Developer Notes https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/custom-policy-developer-notes.md
Custom policy capabilities are under constant development. The following table i
| [OAuth2 implicit flow](implicit-flow-single-page-application.md) | | | X | | | [OAuth2 resource owner password credentials](ropc-custom.md) | | X | | | | [OIDC Connect](openid-connect.md) | | | X | |
-| [SAML2](connect-with-saml-service-providers.md) | | |X | POST and Redirect bindings. |
+| [SAML2](saml-service-provider.md) | | |X | POST and Redirect bindings. |
| OAuth1 | | | | Not supported. | | WSFED | X | | | |
Custom policy capabilities are under constant development. The following table i
| [OpenID Connect](openid-connect-technical-profile.md) | | | X | For example, Google+. | | [OAuth2](oauth2-technical-profile.md) | | | X | For example, Facebook. | | [OAuth1](oauth1-technical-profile.md) | | X | | For example, Twitter. |
-| [SAML2](saml-identity-provider-technical-profile.md) | | | X | For example, Salesforce, ADFS. |
+| [SAML2](identity-provider-generic-saml.md) | | | X | For example, Salesforce, ADFS. |
| WSFED| X | | | |
active-directory-b2c Custom Policy Reference Sso https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/custom-policy-reference-sso.md
This provider is used for managing the Azure AD B2C sessions between a OAuth2 or
### SamlSSOSessionProvider
-This provider is used for managing the Azure AD B2C SAML sessions between a relying party application or a federated SAML identity provider. When using the SSO provider for storing a SAML identity provider session, the `RegisterServiceProviders` must be set to `false`. The following `SM-Saml-idp` technical profile is used by the [SAML identity provider technical profile](saml-identity-provider-technical-profile.md).
+This provider is used for managing the Azure AD B2C SAML sessions between a relying party application or a federated SAML identity provider. When using the SSO provider for storing a SAML identity provider session, the `RegisterServiceProviders` must be set to `false`. The following `SM-Saml-idp` technical profile is used by the [SAML identity provider](identity-provider-generic-saml.md).
```xml <TechnicalProfile Id="SM-Saml-idp">
This provider is used for managing the Azure AD B2C SAML sessions between a rely
When using the provider for storing the B2C SAML session, the `RegisterServiceProviders` must set to `true`. SAML session logout requires the `SessionIndex` and `NameID` to complete.
-The following `SM-Saml-issuer` technical profile is used by [SAML issuer technical profile](saml-issuer-technical-profile.md)
+The following `SM-Saml-issuer` technical profile is used by [SAML issuer technical profile](saml-service-provider.md)
```xml <TechnicalProfile Id="SM-Saml-issuer">
active-directory-b2c Force Password Reset https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/force-password-reset.md
+
+ Title: Configure a force password reset flow in Azure AD B2C
+
+description: Learn how to set up a forced password reset flow in Azure Active Directory B2C.
+++++++ Last updated : 03/03/2021++
+zone_pivot_groups: b2c-policy-type
++
+# Set up a force password reset flow in Azure Active Directory B2C
++
+As an administrator, you can [reset a user's password](manage-users-portal.md#reset-a-users-password) if the user forgets their password. Or you would like to force them to reset the password. In this article, you'll learn how to force a password reset in these scenarios.
+
+## Overview
+
+When an administrator resets a user's password via the Azure portal, the value of the [forceChangePasswordNextSignIn](user-profile-attributes.md#password-profile-property) attribute is set to `true`.
+
+The [sign-in and sign-up journey](add-sign-up-and-sign-in-policy.md) checks the value of this attribute. After the user completes the sign-in, if the attribute is set to `true`, the user must reset their password. Then the value of the attribute is set to back `false`.
+
+![Force password reset flow](./media/force-password-reset/force-password-reset-flow.png)
+
+The password reset flow is applicable to local accounts in Azure AD B2C that use an [email address](identity-provider-local.md#email-sign-in) or [username](identity-provider-local.md#username-sign-in) with a password for sign-in.
+
+### Force a password reset after 90 days
+
+As an administrator, you can set a user's password expiration to 90 days, using [MS Graph](microsoft-graph-operations.md). After 90 days, the value of [forceChangePasswordNextSignIn](user-profile-attributes.md#password-profile-property) attribute is automatically set to `true`. For more information on how to set a user's password expiration policy, see [Password policy attribute](user-profile-attributes.md#password-policy-attribute).
+
+Once a password expiration policy has been set, you must also configure force password reset flow, as described in this article.
+
+## Prerequisites
++
+## Configure your policy
++
+To enable the **Forced password reset** setting in a sign-up or sign-in user flow:
+
+1. Sign in to the [Azure portal](https://portal.azure.com).
+1. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
+1. In the Azure portal, search for and select **Azure AD B2C**.
+1. Select **User flows**.
+1. Select the sign-up and sign-in, or sign-in user flow (of type **Recommended**) that you want to customize.
+1. In the left menu under **Settings**, select **Properties**.
+1. Under **Password complexity**, select **Forced password reset**.
+1. Select **Save**.
+
+### Test the user flow
+
+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).
+1. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
+1. In the Azure portal, search for and select **Azure AD B2C**.
+1. Select **Users**. Search for and select the user you'll use to test the password reset, and then select **Reset Password**.
+1. In the Azure portal, search for and select **Azure AD B2C**.
+1. Select **User flows**.
+1. Select a sign-up or sign-in user flow (of type **Recommended**) that you want to test.
+1. Select **Run user flow**.
+1. For **Application**, select the web application named *webapp1* that you previously registered. The **Reply URL** should show `https://jwt.ms`.
+1. Select **Run user flow**.
+1. Sign in with the user account for which you reset the password.
+1. You now must change the password for the user. Change the password and select **Continue**. The token is returned to `https://jwt.ms` and should be displayed to you.
+++
+1. Get the example of a force password reset on [GitHub](https://github.com/azure-ad-b2c/samples/tree/master/policies/force-password-reset).
+1. In each file, replace the string `yourtenant` with the name of your Azure AD B2C tenant. For example, if the name of your B2C tenant is *contosob2c*, all instances of `yourtenant.onmicrosoft.com` become `contosob2c.onmicrosoft.com`.
+1. Upload the policy files in the following order: the extension policy `TrustFrameworkExtensionsCustomForcePasswordReset.xml`, then the relying party policy `SignUpOrSigninCustomForcePasswordReset.xml`.
+
+### Test the policy
+
+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).
+1. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
+1. In the Azure portal, search for and select **Azure AD B2C**.
+1. Select **Users**. Search for and select the user you'll use to test the password reset, and then select **Reset Password**.
+1. In the Azure portal, search for and select **Azure AD B2C**.
+1. Under **Policies**, select **Identity Experience Framework**.
+1. Select the `B2C_1A_signup_signin_Custom_ForcePasswordReset` policy to open it.
+1. For **Application**, select a web application that you [previously registered](troubleshoot-custom-policies.md#troubleshoot-the-runtime). The **Reply URL** should show `https://jwt.ms`.
+1. Select the **Run now** button.
+1. Sign in with the user account for which you reset the password.
+1. You now must change the password for the user. Change the password and select **Continue**. The token is returned to `https://jwt.ms` and should be displayed to you.
++
+## Next steps
+
+Set up a [self-service password reset](add-password-reset-policy.md).
active-directory-b2c Identity Protection Investigate Risk https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/identity-protection-investigate-risk.md
+
+ Title: Investigate risk with Azure Active Directory B2C Identity Protection
+description: Learn how to investigate risky users, and detections in Azure AD B2C Identity Protection
+++++ Last updated : 03/03/2021+++++
+zone_pivot_groups: b2c-policy-type
+
+# Investigate risk with Identity Protection in Azure AD B2C
++
+Identity Protection provides ongoing risk detection for your Azure AD B2C tenant. It allows organizations to discover, investigate, and remediate identity-based risks. Identity Protection comes with risk reports that can be used to investigate identity risks in Azure AD B2C tenants. In this article, you learn how to investigate and mitigate risks.
+
+## Overview
+
+Azure AD B2C Identity Protection provides two reports. The *Risky users* report is where administrators can find which users are at risk and details about detections. The *risk detections* report provides information about each risk detection, including type, other risks triggered at the same time, sign-in attempt location, and more.
+
+Each report launches with a list of all detections for the period shown at the top of the report. Reports can be filtered using the filters across the top of the report. Administrators can choose to download the data, or use [MS Graph API and Microsoft Graph PowerShell SDK](../active-directory/identity-protection/howto-identity-protection-graph-api.md) to continuously export the data.
+
+## Service limitations and considerations
+
+When using Identity Protection, consider the following:
+
+- Identity Protection is on by default.
+- Identity Protection is available for both local and social identities, such as Google or Facebook. For social identities, Conditional Access must be activated. Detection is limited because the social account credentials are managed by the external identity provider.
+- In Azure AD B2C tenants, only a subset of the [Azure AD Identity Protection risk detections](../active-directory/identity-protection/overview-identity-protection.md) is available. The following risk detections are supported by Azure AD B2C:
+
+|Risk detection type |Description |
+|||
+| Atypical travel | Sign-in from an atypical location based on the user's recent sign-ins. |
+|Anonymous IP address | Sign-in from an anonymous IP address (for example: Tor browser, anonymizer VPNs). |
+|Malware linked IP address | Sign-in from a malware linked IP address. |
+|Unfamiliar sign-in properties | Sign-in with properties we've not seen recently for the given user. |
+|Admin confirmed user compromised | An admin has indicated that a user was compromised. |
+|Password spray | Sign-in through a password spray attack. |
+|Azure AD threat intelligence | Microsoft's internal and external threat intelligence sources have identified a known attack pattern. |
+
+## Pricing tier
+
+Azure AD B2C Premium P2 is required for some Identity Protection features. If necessary, [change your Azure AD B2C pricing tier to Premium P2](./billing.md). The following table summarizes Identity Protection features and the required pricing tier.
+
+|Feature |P1 |P2|
+|-|:--:|::|
+|Risky users report |&#x2713; |&#x2713; |
+|Risky users report details | |&#x2713; |
+|Risky users report remediation | &#x2713; |&#x2713; |
+|Risk detections report |&#x2713;|&#x2713;|
+|Risk detections report details ||&#x2713;|
+|Report download | &#x2713;| &#x2713;|
+|MS Graph API access | &#x2713;| &#x2713;|
+
+## Prerequisites
++
+## Investigate risky users
+
+With the information provided by the risky users report, administrators can find:
+
+- Which users are at risk, have had risk remediated, or have had risk dismissed?
+- Details about detections
+- History of all risky sign-ins
+- Risk history
+
+Administrators can then choose to take action on these events. Administrators can choose to:
+
+- Reset the user password
+- Confirm user compromise
+- Dismiss user risk
+- Block user from signing in
+- Investigate further using Azure ATP
+
+### Navigating the risky users report
+
+1. Sign in to the [Azure portal](https://portal.azure.com/).
+
+1. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
+
+1. Under **Azure services**, select **Azure AD B2C**. Or use the search box to find and select **Azure AD B2C**.
+
+1. Under **Security**, select **Risky users (Preview)**.
+
+ ![Risky users](media/identity-protection-investigate-risk/risky-users.png)
+
+ Selecting individual entries expands a details window below the detections. The details view allows administrators to investigate and perform actions on each detection.
+
+ ![Risky users actions](media/identity-protection-investigate-risk/risky-users-report-actions.png)
++
+## Risk detections report
+
+The risk detections report contains filterable data for up to the past 90 days (three months).
+
+With the information provided by the risk detections report, administrators can find:
+
+- Information about each risk detection including type.
+- Other risks triggered at the same time.
+- Sign-in attempt location.
+
+Administrators can then choose to return to the user's risk or sign-ins report to take actions based on information gathered.
+
+### Navigating the risk detections report
+
+1. In the Azure portal, search for and select **Azure AD B2C**.
+1. Under **Security**, select **Risk detections (Preview)**.
+
+ ![Risk detections](media/identity-protection-investigate-risk/risk-detections.png)
++
+## Next steps
+
+- [Add Conditional Access to a user flow](conditional-access-user-flow.md).
active-directory-b2c Identity Provider Adfs https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/identity-provider-adfs.md
zone_pivot_groups: b2c-policy-type
[!INCLUDE [active-directory-b2c-advanced-audience-warning](../../includes/active-directory-b2c-advanced-audience-warning.md)]
-This article shows you how to enable sign-in for an AD FS user account by using [custom policies](custom-policy-overview.md) in Azure Active Directory B2C (Azure AD B2C). You enable sign-in by adding a [SAML identity provider technical profile](saml-identity-provider-technical-profile.md) to a custom policy.
+This article shows you how to enable sign-in for an AD FS user account by using [custom policies](custom-policy-overview.md) in Azure Active Directory B2C (Azure AD B2C). You enable sign-in by adding a [SAML identity provider](identity-provider-generic-saml.md) to a custom policy.
## Prerequisites
You need to store your certificate in your Azure AD B2C tenant.
If you want users to sign in using an AD FS account, you need to define the account 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 an AD FS account as a claims provider by adding it to the **ClaimsProviders** element in the extension file of your policy. For more information, see [define a SAML identity provider technical profile](saml-identity-provider-technical-profile.md).
+You can define an AD FS account as a claims provider by adding it to the **ClaimsProviders** element in the extension file of your policy. For more information, see [define a SAML identity provider](identity-provider-generic-saml.md).
1. Open the *TrustFrameworkExtensions.xml*. 1. Find the **ClaimsProviders** element. If it does not exist, add it under the root element.
This error indicates that the SAML request sent by Azure AD B2C is not signed wi
#### Option 1: Set the signature algorithm in Azure AD B2C
-You can configure how to sign the SAML request in Azure AD B2C. The [XmlSignatureAlgorithm](saml-identity-provider-technical-profile.md#metadata) metadata controls the value of the `SigAlg` parameter (query string or post parameter) in the SAML request. The following example configures Azure AD B2C to use the `rsa-sha256` signature algorithm.
+You can configure how to sign the SAML request in Azure AD B2C. The [XmlSignatureAlgorithm](identity-provider-generic-saml.md) metadata controls the value of the `SigAlg` parameter (query string or post parameter) in the SAML request. The following example configures Azure AD B2C to use the `rsa-sha256` signature algorithm.
```xml <Metadata>
active-directory-b2c Identity Provider Apple Id https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/identity-provider-apple-id.md
+
+ Title: Set up sign-up and sign-in with an Apple ID
+
+description: Provide sign-up and sign-in to customers with Apple ID in your applications using Azure Active Directory B2C.
+++++++ Last updated : 03/03/2021+++
+zone_pivot_groups: b2c-policy-type
++
+# Set up sign-up and sign-in with an Apple ID using Azure Active Directory B2C (Preview)
+++++
+## Prerequisites
++
+## Create an Apple ID application
+
+To enable sign-in for users with an Apple ID in Azure Active Directory B2C (Azure AD B2C), you need to create an application in [https://developer.apple.com](https://developer.apple.com). For more information, see [Sign in with Apple](https://developer.apple.com/sign-in-with-apple/get-started/). If you don't already have an Apple developer account, you can sign up at [Apple Developer Program](https://developer.apple.com/programs/enroll/).
+
+1. Sign in to the [Apple Developer Portal](https://developer.apple.com/account) with your account credentials.
+1. From the menu, select **Certificates, IDs, & Profiles**, and then select **(+)**.
+1. For **Register a New Identifier**, select **App IDs**, and then select **Continue**.
+1. For **Select a type**, select **App**, and then select **Continue**.
+1. For **Register an App ID**:
+ 1. Enter a **Description**
+ 1. Enter the **Bundle ID**, such as `com.contoso.azure-ad-b2c`.
+ 1. For **Capabilities**, select **Sign in with Apple** from the capabilities list.
+ 1. Take note of your App ID Prefix (Team ID) from this step. You'll need it later.
+ 1. Select **Continue** and then **Register**.
+1. From the menu, select **Certificates, IDs, & Profiles**, and then select **(+)**.
+1. For **Register a New Identifier**, select **Services IDs**, and then select **Continue**.
+1. For **Register a Services ID**:
+ 1. Enter a **Description**. The description is shown to the user on the consent screen.
+ 1. Enter the **Identifier**, such as `com.consoto.azure-ad-b2c-service`. The identifier is your client ID for the OpenID Connect flow.
+ 1. Select **Continue**, and then select **Register**.
+1. From **Identifiers**, select the identifier you created.
+1. Select **Sign In with Apple**, and then select **Configure**.
+ 1. Select the **Primary App ID** you want to configure Sign in with Apple with.
+ 1. In **Domains and Subdomains**, enter `your-tenant-name.b2clogin.com`. Replace your-tenant-name with the name of your tenant.
+ 1. In **Return URLs**, enter `https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/oauth2/authresp`. Replace your-tenant-name with the name of your tenant.
+ 1. Select **Next**, and then select **Done**.
+ 1. When the pop-up window is closed, select **Continue**, and then select **Save**.
+
+## Creating an Apple client secret
+
+1. From the Apple Developer portal menu, select **Keys**, and then select **(+)**.
+1. For **Register a New Key**:
+ 1. Type a **Key Name**.
+ 1. Select **Sign in with Apple**, and then select **Configure**.
+ 1. For the **Primary App ID**, select the app you created previously, and the select **Save**.
+ 1. Select **Configure**, and then select **Register** to finish the key registration process.
+1. For **Download Your Key**, select **Download** to download a .p8 file that contains your key.
+++
+## Configure Apple as an identity provider
+
+1. Sign in to the [Azure portal](https://portal.azure.com/) as a global administrator of your Azure AD B2C tenant.
+1. Select the **Directory + subscription** filter in the top menu and choose the directory that contains your Azure AD B2C tenant.
+1. Under **Azure services**, select **Azure AD B2C**. Or use the search box to find and select **Azure AD B2C**.
+1. Select **Identity providers**, then select **Apple (Preview)**.
+1. Enter a **Name**. For example, *Apple*.
+1. Enter the **Apple developer ID (Team ID)**.
+1. Enter the **Apple service ID (client ID)**.
+1. Enter the **Apple key ID**.
+1. Select and upload the **Apple certificate data**.
+1. Select **Save**.
++
+> [!IMPORTANT]
+> - Sign in with Apple requires the Admin to renew their client secret every 6 months.
+> - During the public preview of this feature, you'll need to manually renew the Apple client secret if it expires. A warning will appear in advance on Apple identity providers Configure social IDP page, but we recommend you set your own reminder.
+> - If you need to renew the secret, open Azure AD B2C in the Azure portal, go to **Identity providers** > **Apple**, and select **Renew secret**.
+
+## Add the Apple identity provider to a user flow
+
+To enable users to sign in using an Apple ID, you need to add the Apple identity provider to a user flow. Sign in with Apple can be configured only for the **recommended** version of user flows. To add the Apple identity provider to a user flow:
+
+1. In your Azure AD B2C tenant, select **User flows**.
+1. Select a user flow for which you want to add the Apple identity provider.
+1. Under **Social identity providers**, select **Apple (Preview)**.
+1. Select **Save**.
+1. To test your policy, select **Run user flow**.
+1. For **Application**, select the web application named *testapp1* that you previously registered. The **Reply URL** should show `https://jwt.ms`.
+1. Select **Run user flow**.
+++
+## Signing the client secret
+
+Use the .p8 file you downloaded previously to sign the client secret into a JWT token. There are many libraries that can create and sign the JWT for you. Use the [Azure Function that creates a token](https://github.com/azure-ad-b2c/samples/tree/master/policies/sign-in-with-apple/azure-function) for you.
+
+1. Create an [Azure Function](../azure-functions/functions-create-function-app-portal.md).
+1. Under **Developer**, select **Code + Test**.
+1. Copy the content of the [run.csx](https://github.com/azure-ad-b2c/samples/blob/master/policies/sign-in-with-apple/azure-function/run.csx) file, and paste it in the editor.
+1. Select **Save**.
+1. Make an HTTP `POST` request, and provide the following information:
+
+ - **appleTeamId**: Your Apple Developer Team ID
+ - **appleServiceId**: The Apple Service ID (also the client ID)
+ - **p8key**: The PEM format key. You can obtain this by opening the .p8 file in a text editor and copying everything between
+ `--BEGIN PRIVATE KEY--` and `--END PRIVATE KEY--` without line breaks.
+
+The following json is an example of a call to the Azure function:
+
+```json
+{
+ "appleTeamId": "ABC123DEFG",
+ "appleKeyId": "URKEYID001",
+ "appleServiceId": "com.yourcompany.app1",
+ "p8key": "MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQg+s07NiAcuGEu8rxsJBG7ttupF6FRe3bXdHxEipuyK82gCgYIKoZIzj0DAQehRANCAAQnR1W/KbbaihTQayXH3tuAXA8Aei7u7Ij5OdRy6clOgBeRBPy1miObKYVx3ki1msjjG2uGqRbrc1LvjLHINWRD"
+}
+```
+
+The Azure function responds with a properly formatted and signed client secret JWT in a response, for example:
+
+```json
+{
+ "token": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJjb20ueW91cmNvbXBhbnkuYXBwMSIsIm5iZiI6MTU2MDI2OTY3NSwiZXhwIjoxNTYwMzU2MDc1LCJpc3MiOiJBQkMxMjNERUZHIiwiYXVkIjoiaHR0cHM6Ly9hcHBsZWlkLmFwcGxlLmNvbSJ9.Dt9qA9NmJ_mk6tOqbsuTmfBrQLFqc9BnSVKR6A-bf9TcTft2XmhWaVODr7Q9w1PP3QOYShFXAnNql5OdNebB4g"
+}
+```
+
+## Create a policy key
+
+You need to store the client secret that you previously recorded in your Azure AD B2C tenant.
+
+1. Sign in to the [Azure portal](https://portal.azure.com/).
+1. Select the **Directory + subscription** filter in the top menu and choose the directory that contains your Azure AD B2C tenant.
+2. Under **Azure services**, select **Azure AD B2C**. Or use the search box to find and select **Azure AD B2C**.
+1. On the **Overview** page, select **Identity Experience Framework**.
+1. Select **Policy Keys**, and then select **Add**.
+1. For **Options**, choose **Manual**.
+1. Enter a **Name** for the policy key. For example, "AppleSecret". The prefix "B2C_1A_" is added automatically to the name of your key.
+1. In **Secret**, enter the value of a token returned by the Azure Function (a JWT token).
+1. For **Key usage**, select **Signature**.
+1. Select **Create**.
+
+> [!IMPORTANT]
+> - Sign in with Apple requires the Admin to renew their client secret every 6 months.
+> - You'll need to manually renew the Apple client secret if it expires and store the new value in the policy key.
+> - We recommend you set your own reminder within 6 months to generate a new client secret.
+
+## Configure Apple as an identity provider
+
+To enable users to sign in using an Apple ID, you need to define the account 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 is authenticated.
+
+You can define an Apple ID as a claims provider by adding it to the **ClaimsProviders** element in the extension file of your policy.
+
+1. Open the *TrustFrameworkExtensions.xml*.
+2. Find the **ClaimsProviders** element. If it does not exist, add it under the root element.
+3. Add a new **ClaimsProvider** as follows:
+
+ ```xml
+ <ClaimsProvider>
+ <Domain>apple.com</Domain>
+ <DisplayName>Apple</DisplayName>
+ <TechnicalProfiles>
+ <TechnicalProfile Id="Apple-OIDC">
+ <DisplayName>Apple</DisplayName>
+ <Protocol Name="OpenIdConnect" />
+ <Metadata>
+ <Item Key="ProviderName">apple</Item>
+ <Item Key="authorization_endpoint">https://appleid.apple.com/auth/authorize</Item>
+ <Item Key="AccessTokenEndpoint">https://appleid.apple.com/auth/token</Item>
+ <Item Key="JWKS">https://appleid.apple.com/auth/keys</Item>
+ <Item Key="issuer">https://appleid.apple.com</Item>
+ <Item Key="scope">name email openid</Item>
+ <Item Key="HttpBinding">POST</Item>
+ <Item Key="response_types">code</Item>
+ <Item Key="external_user_identity_claim_id">sub</Item>
+ <Item Key="response_mode">form_post</Item>
+ <Item Key="ReadBodyClaimsOnIdpRedirect">user.name.firstName user.name.lastName user.email</Item>
+ <Item Key="client_id">You Apple ID</Item>
+ <Item Key="UsePolicyInRedirectUri">false</Item>
+ </Metadata>
+ <CryptographicKeys>
+ <Key Id="client_secret" StorageReferenceId="B2C_1A_AppleSecret"/>
+ </CryptographicKeys>
+ <OutputClaims>
+ <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
+ <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="https://appleid.apple.com" AlwaysUseDefaultValue="true" />
+ <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
+ <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="user.name.firstName"/>
+ <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="user.name.lastName"/>
+ <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="user.email"/>
+ </OutputClaims>
+ <OutputClaimsTransformations>
+ <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
+ <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
+ <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
+ <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
+ </OutputClaimsTransformations>
+ <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
+ </TechnicalProfile>
+ </TechnicalProfiles>
+ </ClaimsProvider>
+ ```
+
+4. Set **client_id** to the service identifier. For example, `com.consoto.azure-ad-b2c-service`.
+5. Save the file.
+++
+```xml
+<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
+ <ClaimsProviderSelections>
+ ...
+ <ClaimsProviderSelection TargetClaimsExchangeId="AppleExchange" />
+ </ClaimsProviderSelections>
+ ...
+</OrchestrationStep>
+
+<OrchestrationStep Order="2" Type="ClaimsExchange">
+ ...
+ <ClaimsExchanges>
+ <ClaimsExchange Id="AppleExchange" TechnicalProfileReferenceId="Apple-OIDC" />
+ </ClaimsExchanges>
+</OrchestrationStep>
+```
+++
active-directory-b2c Identity Provider Azure Ad Single Tenant https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/identity-provider-azure-ad-single-tenant.md
Previously updated : 01/27/2021 Last updated : 03/04/2021
If you want to get the `family_name` and `given_name` claims from Azure AD, you
1. For **Client ID**, enter the application ID that you previously recorded. 1. For **Client secret**, enter the client secret that you previously recorded.
-1. For the **Scope**, enter the `openid profile`.
+1. For **Scope**, enter `openid profile`.
1. Leave the default values for **Response type**, and **Response mode**. 1. (Optional) For the **Domain hint**, enter `contoso.com`. For more information, see [Set up direct sign-in using Azure Active Directory B2C](direct-signin.md#redirect-sign-in-to-a-social-provider). 1. Under **Identity provider claims mapping**, select the following claims:
When working with custom policies, you might sometimes need additional informati
To help diagnose issues, you can temporarily put the policy into "developer mode" and collect logs with Azure Application Insights. Find out how in [Azure Active Directory B2C: Collecting Logs](troubleshoot-with-application-insights.md).
active-directory-b2c Identity Provider Generic Saml Options https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/identity-provider-generic-saml-options.md
+
+ Title: Set sign-in with SAML identity provider options
+
+description: Configure sign-in SAML identity provider (IdP) options in Azure Active Directory B2C.
+++++++ Last updated : 03/04/2021+++
+zone_pivot_groups: b2c-policy-type
+++
+# Configure SAML identity provider options with Azure Active Directory B2C
+
+Azure Active Directory B2C (Azure AD B2C) supports federation with SAML 2.0 identity providers. This article describes the configuration options that are available when enabling sign-in with a SAML identity provider.
++++++
+## Claims mapping
+
+The **OutputClaims** element contains a list of claims returned by the SAML identity provider. You need to map the name of the claim defined in your policy to the name defined in the identity provider. Check your identity provider for the list of claims (assertions). You can also check the content of the SAML response your identity provider returns. For more information, see [Debug the SAML messages](#debug-saml-protocol). To add a claim, first [define a claim](claimsschema.md), then add the claim to the output claims collection.
+
+You can also include claims that aren't returned by the identity provider, as long as you set the `DefaultValue` attribute. The default value can be static or dynamic, using [context claims](#enable-use-of-context-claims).
+
+The output claim element contains the following attributes:
+
+- **ClaimTypeReferenceId** is the reference to a claim type.
+- **PartnerClaimType** is the name of the property that appears SAML assertion.
+- **DefaultValue** is a predefined default value. If the claim is empty, the default value will be used. You can also use a [claim resolvers](claim-resolver-overview.md) with a contextual value, such as the correlation ID, or the user IP address.
+
+### Subject name
+
+To read the SAML assertion **NameId** in the **Subject** as a normalized claim, set the claim **PartnerClaimType** to the value of the `SPNameQualifier` attribute. If the `SPNameQualifier`attribute is not presented, set the claim **PartnerClaimType** to value of the `NameQualifier` attribute.
+
+SAML assertion:
+
+```xml
+<saml:Subject>
+ <saml:NameID SPNameQualifier="http://your-idp.com/unique-identifier" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">david@contoso.com</saml:NameID>
+ <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
+ <SubjectConfirmationData InResponseTo="_cd37c3f2-6875-4308-a9db-ce2cf187f4d1" NotOnOrAfter="2020-02-15T16:23:23.137Z" Recipient="https://<your-tenant>.b2clogin.com/<your-tenant>.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" />
+ </SubjectConfirmation>
+ </saml:SubjectConfirmation>
+</saml:Subject>
+```
+
+Output claim:
+
+```xml
+<OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="http://your-idp.com/unique-identifier" />
+```
+
+If both `SPNameQualifier` or `NameQualifier` attributes are not presented in the SAML assertion, set the claim **PartnerClaimType** to `assertionSubjectName`. Make sure the **NameId** is the first value in assertion XML. When you define more than one assertion, Azure AD B2C picks the subject value from the last assertion.
++
+## Configure SAML protocol bindings
+
+The SAML requests are sent to the identity provider as specified in the identity provider's metadata `SingleSignOnService` element. Most of the identity providers' authorization requests are carried directly in the URL query string of an HTTP GET request (as the messages are relatively short). Refer to your identity provider documentation for how to configure the bindings for both SAML requests.
+
+The following 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.
+
+```xml
+<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
+ ...
+ <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2"/>
+ <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2"/>
+</IDPSSODescriptor>
+```
+
+SAML responses are transmitted to Azure AD B2C via HTTP POST binding. Azure AD B2C policy metadata sets the `AssertionConsumerService` binding to `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`.
+
+The following is an example of an Azure AD B2C policy metadata assertion consumer service element.
+
+```xml
+<SPSSODescriptor AuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
+ ...
+ <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://your-tenant.b2clogin.com/your-tenant/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" index="0" isDefault="true"/>
+</SPSSODescriptor>
+```
+
+## Configure the SAML request signature
+
+Azure AD B2C signs all outgoing authentication requests using the **SamlMessageSigning** cryptographic key. To disable the SAML request signature, set the **WantsSignedRequests** to `false`. If the metadata is set to `false`, the **SigAlg** and **Signature** parameters (query string or post parameter) are omitted from the request.
+
+This metadata also controls the **AuthnRequestsSigned** attribute, which is included with the metadata of the Azure AD B2C technical profile that is shared with the identity provider. Azure AD B2C doesn't sign the request if the value of **WantsSignedRequests** in the technical profile metadata is set to `false` and the identity provider metadata **WantAuthnRequestsSigned** is set to `false` or not specified.
+
+The following example removes the signature from the SAML request.
+
+```xml
+<Metadata>
+ ...
+ <Item Key="WantsSignedRequests">false</Item>
+</Metadata>
+```
+
+### Signature algorithm
+
+Azure AD B2C uses `Sha1` to sign the SAML request. Use the **XmlSignatureAlgorithm** metadata to configure the algorithm to be used. Possible values are `Sha256`, `Sha384`, `Sha512`, or `Sha1` (default). This metadata controls the value of the **SigAlg** parameter (query string or post parameter) in the SAML request. Make sure you configure the signature algorithm on both sides with same value. Use only the algorithm that your certificate supports.
+
+### Include key info
+
+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 will not include the public key of the certificate.
+
+```xml
+<Metadata>
+ ...
+ <Item Key="IncludeKeyInfo">false</Item>
+</Metadata>
+```
+
+## Configure SAML request name ID
+
+The SAML authorization request `<NameID>` element indicates the SAML name identifier format. This section describes the default configuration and how to customize the name ID element.
+
+## Preferred username
+
+During a sign-in user journey, a relying party application may target a specific user. Azure AD B2C allows you to send a preferred username to the SAML identity provider. The **InputClaims** element is used to send a **NameId** within the **Subject** of the SAML authorization request.
+
+To include the subject name ID within the authorization request, add the following `<InputClaims>` element immediately after the `<CryptographicKeys>`. The **PartnerClaimType** must be set to `subject`.
+
+```xml
+<InputClaims>
+ <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="subject" />
+</InputClaims>
+```
+
+In this example, Azure AD B2C sends the value of the **signInName** claim with **NameId** within the **Subject** of the SAML authorization request.
+
+```xml
+<samlp:AuthnRequest ... >
+ ...
+ <saml:Subject>
+ <saml:NameID>sam@contoso.com</saml:NameID>
+ </saml:Subject>
+</samlp:AuthnRequest>
+```
+
+You can use [context claims](claim-resolver-overview.md), such as `{OIDC:LoginHint}` to populate the claim value.
+
+```xml
+<Metadata>
+ ...
+ <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>
+</Metadata>
+ ...
+<InputClaims>
+ <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="subject" DefaultValue="{OIDC:LoginHint}" AlwaysUseDefaultValue="true" />
+</InputClaims>
+```
+
+### Name ID policy format
+
+By default, the SAML authorization request specifies the `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified` policy. This indicates that any type of identifier supported by the identity provider for the requested subject can be used.
+
+To change this behavior, refer to your identity providerΓÇÖs documentation for guidance about which name ID policies are supported. Then add the `NameIdPolicyFormat` metadata in the corresponding policy format. For example:
+
+```xml
+<Metadata>
+ ...
+ <Item Key="NameIdPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</Item>
+</Metadata>
+```
+
+The following SAML authorization request contains the name ID policy.
+
+```xml
+<samlp:AuthnRequest ... >
+ ...
+ <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
+</samlp:AuthnRequest>
+```
+
+### Allow creating new accounts
+
+If you specify the [Name ID policy format](#name-id-policy-format), you can also specify the `AllowCreate` property of **NameIDPolicy** to indicate whether the identity provider is allowed to create a new account during the sign-in flow. Refer to your identity providerΓÇÖs documentation for guidance.
+
+Azure AD B2C omits the `AllowCreate` property by default. You can change this behavior using the `NameIdPolicyAllowCreate` metadata. The value of this metadata is `true` or `false`.
+
+The following example demonstrates how to set `AllowCreate` property of `NameIDPolicy` to `true`.
+
+```xml
+<Metadata>
+ ...
+ <Item Key="NameIdPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</Item>
+ <Item Key="NameIdPolicyAllowCreate">true</Item>
+</Metadata>
+```
++
+The following example demonstrates an authorization request with **AllowCreate** of the **NameIDPolicy** element in the authorization request.
++
+```xml
+<samlp:AuthnRequest ... >
+ ...
+ <samlp:NameIDPolicy
+ Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
+ AllowCreate="true" />
+</samlp:AuthnRequest>
+```
+
+### Include authentication context class references
+
+A SAML authorization request may contain a **AuthnContext** element, which specifies the context of an authorization request. The element can contain an authentication context class reference, which tells the SAML identity provider which authentication mechanism to present to the user.
+
+To configure the authentication context class references, add **IncludeAuthnContextClassReferences** metadata. In the value, specify one or more URI references identifying authentication context classes. Specify multiple URIs as a comma-delimited list. Refer to your identity providerΓÇÖs documentation for guidance on the **AuthnContextClassRef** URIs that are supported.
+
+The following example allows users to sign in with both username and password, and to sign in with username and password over a protected session (SSL/TLS).
+
+```xml
+<Metadata>
+ ...
+ <Item Key="IncludeAuthnContextClassReferences">urn:oasis:names:tc:SAML:2.0:ac:classes:Password,urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</Item>
+</Metadata>
+```
+
+The following SAML authorization request contains the authentication context class references.
+
+```xml
+<samlp:AuthnRequest ... >
+ ...
+ <samlp:RequestedAuthnContext>
+ <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
+ <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
+ </samlp:RequestedAuthnContext>
+</samlp:AuthnRequest>
+```
+
+## Include custom data in the authorization request
+
+You can optionally include protocol message extension elements that are agreed to by both Azure AD BC and your identity provider. The extension is presented in XML format. You include extension elements by adding XML data inside the CDATA element `<![CDATA[Your IDP metadata]]>`. Check your identity providerΓÇÖs documentation to see if the extensions element is supported.
+
+The following example illustrates the use of extension data:
+
+```xml
+<Metadata>
+ ...
+ <Item Key="AuthenticationRequestExtensions"><![CDATA[
+ <ext:MyCustom xmlns:ext="urn:ext:custom">
+ <ext:AssuranceLevel>1</ext:AssuranceLevel>
+ <ext:AssuranceDescription>Identity verified to level 1.</ext:AssuranceDescription>
+ </ext:MyCustom>]]></Item>
+</Metadata>
+```
+
+When using the SAML protocol message extension, the SAML response will look like the following example:
+
+```xml
+<samlp:AuthnRequest ... >
+ ...
+ <samlp:Extensions>
+ <ext:MyCustom xmlns:ext="urn:ext:custom">
+ <ext:AssuranceLevel>1</ext:AssuranceLevel>
+ <ext:AssuranceDescription>Identity verified to level 1.</ext:AssuranceDescription>
+ </ext:MyCustom>
+ </samlp:Extensions>
+</samlp:AuthnRequest>
+```
+
+## Require signed SAML responses
+
+Azure AD B2C requires all incoming assertions to be signed. You can remove this requirement by setting the **WantsSignedAssertions** to `false`. The identity provider shouldnΓÇÖt sign the assertions in this case, but even if it does, Azure AD B2C wonΓÇÖt validate the signature.
+
+The **WantsSignedAssertions** metadata controls the SAML metadata flag **WantAssertionsSigned**, which is included in the metadata of the Azure AD B2C technical profile that is shared with the identity provider.
+
+```xml
+<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
+```
+
+If you disable the assertions validation, you might also want to disable the response message signature validation. Set the **ResponsesSigned** metadata to `false`. The identity provider shouldnΓÇÖt sign the SAML response message in this case, but even if it does, Azure AD B2C wonΓÇÖt validate the signature.
+
+The following example removes both the message and the assertion signature:
+
+```xml
+<Metadata>
+ ...
+ <Item Key="WantsSignedAssertions">false</Item>
+ <Item Key="ResponsesSigned">false</Item>
+</Metadata>
+```
+
+## Require encrypted SAML responses
+
+To require all incoming assertions to be encrypted, set the **WantsEncryptedAssertions** metadata. When encryption is required, the identity provider uses a public key of an encryption certificate in an Azure AD B2C technical profile. Azure AD B2C decrypts the response assertion using the private portion of the encryption certificate.
+
+If you enable the assertions encryption, you might also need to disable the response signature validation (for more information, see [Require signed SAML responses](#require-signed-saml-responses).
+
+When the **WantsEncryptedAssertions** metadata is set to `true`, the metadata of the Azure AD B2C technical profile includes the **encryption** section. The identity provider reads the metadata and encrypts the SAML response assertion with the public key that is provided in the metadata of the Azure AD B2C technical profile.
+
+The following example shows the Key Descriptor section of the SAML metadata used for encryption:
+
+```xml
+<SPSSODescriptor AuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
+ <KeyDescriptor use="encryption">
+ <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
+ <X509Data>
+ <X509Certificate>valid certificate</X509Certificate>
+ </X509Data>
+ </KeyInfo>
+ </KeyDescriptor>
+ ...
+</SPSSODescriptor>
+```
+
+To encrypt the SAML response assertion:
+
+1. [Create a policy key](identity-provider-generic-saml.md#create-a-policy-key) with a unique identifier. For example, `B2C_1A_SAMLEncryptionCert`.
+2. In your SAML technical profile **CryptographicKeys** collection. Set the **StorageReferenceId** to the name of the policy key you created in the first step. The `SamlAssertionDecryption` ID indicates the use of the cryptographic key to encrypt and decrypt the assertion of the SAML response.
+
+ ```xml
+ <CryptographicKeys>
+ ...
+ <Key Id="SamlAssertionDecryption" StorageReferenceId="B2C_1A_SAMLEncryptionCert"/>
+ </CryptographicKeys>
+ ```
+
+3. Set the technical profile metadata **WantsEncryptedAssertions** to `true`.
+
+ ```xml
+ <Metadata>
+ ...
+ <Item Key="WantsEncryptedAssertions">true</Item>
+ </Metadata>
+ ```
+
+4. Update your identity provider with the new Azure AD B2C technical profile metadata. You should see the **KeyDescriptor** with the **use** property set to `encryption` containing the public key of your certificate.
+
+## Enable use of context claims
+
+In the input and output claims collection, you can include claims that aren't returned by the identity provider as long as you set the `DefaultValue` attribute. You can also use [context claims](claim-resolver-overview.md) to be included in the technical profile. To use a context claim:
+
+1. Add a claim type to the [ClaimsSchema](claimsschema.md) element within [BuildingBlocks](buildingblocks.md).
+2. Add an output claim to the input or output collection. In the following example, the first claim sets the value of the identity provider. The second claim uses the user IP address [context claims](claim-resolver-overview.md).
+
+ ```xml
+ <OutputClaims>
+ <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="contoso.com" AlwaysUseDefaultValue="true" />
+ <OutputClaim ClaimTypeReferenceId="IpAddress" DefaultValue="{Context:IPAddress}" AlwaysUseDefaultValue="true" />
+ </OutputClaims>
+ ```
+
+## Disable single logout
+
+Upon an application sign-out request, Azure AD B2C attempts to sign out from your SAML identity provider. For more information, see [Azure AD B2C session sign-out](session-behavior.md#sign-out). To disable the single logout behavior, set the **SingleLogoutEnabled** metadata to `false`.
+
+```xml
+<Metadata>
+ ...
+ <Item Key="SingleLogoutEnabled">false</Item>
+</Metadata>
+```
+
+## Debug SAML protocol
+
+To help configure and debug federation with a SAML identity provider, you can use a browser extension for the SAML protocol, such as [SAML DevTools extension](https://chrome.google.com/webstore/detail/saml-devtools-extension/jndllhgbinhiiddokbeoeepbppdnhhio) for Chrome, [SAML-tracer](https://addons.mozilla.org/es/firefox/addon/saml-tracer/) for FireFox, or [Edge or IE Developer tools](https://techcommunity.microsoft.com/t5/microsoft-sharepoint-blog/gathering-a-saml-token-using-edge-or-ie-developer-tools/ba-p/320957).
+
+Using these tools, you can check the integration between Azure AD B2C and your SAML identity provider. For example:
+
+* Check if the SAML request contains a signature and determine what algorithm is used to sign in the authorization request.
+* Get the claims (assertions) under the `AttributeStatement` section.
+* Check if the identity provider returns an error message.
+* Check if the assertion section is encrypted.
+
+## Next steps
+
+- Learn how to diagnose problems with your custom policies, using [Application Insights](troubleshoot-with-application-insights.md).
+
active-directory-b2c Identity Provider Generic Saml https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/identity-provider-generic-saml.md
+
+ Title: Set up sign-up and sign-in with SAML identity provider
+
+description: Set up sign-up and sign-in with any SAML identity provider (IdP) in Azure Active Directory B2C.
+++++++ Last updated : 03/03/2021+++
+zone_pivot_groups: b2c-policy-type
+++
+# Set up sign-up and sign-in with SAML identity provider using Azure Active Directory B2C
+
+Azure Active Directory B2C (Azure AD B2C) supports federation with SAML 2.0 identity providers. This article shows you how to enable sign-in with a SAML identity provider user account, allowing users to sign in with their existing social or enterprise identities, such as [ADFS](identity-provider-adfs2016-custom.md) and [Salesforce](identity-provider-salesforce-saml.md).
++++++
+## Scenario overview
+
+You can configure Azure AD B2C to allow users to sign in to your application with credentials from external social or enterprise SAML identity providers (IdP). When Azure AD B2C federates with a SAML identity provider, it acts as a **service provider** initiating a SAML request to the SAML **identity provider**, and waiting for a SAML response. In the following diagram:
+
+1. The application initiates an authorization request to Azure AD B2C. The application can be an [OAuth 2.0](protocols-overview.md) or [OpenId Connect](openid-connect.md) application, or a [SAML service provider](saml-service-provider.md).
+1. In the Azure AD B2C sign-in page, the user chooses to sign-in with a SAML identity provider account (for example, *Contoso*). Azure AD B2C initiates a SAML authorization request and takes the user to the SAML identity provider to complete the sign-in.
+1. The SAML identity provider returns a SAML response.
+1. Azure AD B2C validates the SAML token, extracts claims, issues its own token, and takes the user back to the application.
+
+![Sign in with SAML identity provider flow](./media/identity-provider-generic-saml/sign-in-with-saml-identity-provider-flow.png)
+
+## Prerequisites
++
+## Components of the solution
+
+The following components required are for this scenario:
+
+* A SAML **identity provider** with the ability to receive, decode, and respond to SAML requests from Azure AD B2C.
+* A publicly available SAML **metadata endpoint** for your identity provider.
+* An [Azure AD B2C tenant](tutorial-create-tenant.md).
+
+
+## Create a policy key
+
+To establish trust between Azure AD B2C and your SAML identity provider, you need to provide a valid X509 certificate with the private key. Azure AD B2C signs the SAML requests, using the private key of the certificate. The identity provider validates the request using the public key of the certificate. The public key is accessible through technical profile metadata. Alternatively, you can manually upload the .cer file to your SAML identity provider.
+
+A self-signed certificate is acceptable for most scenarios. For production environments, it is recommended to use an X509 certificate that is issued by a certificate authority. Also, as described later in this document, for a non-production environment you can disable the SAML signing on both sides.
+
+### Obtain a certificate
++
+### Upload the certificate
+
+You need to store your certificate in your Azure AD B2C tenant.
+
+1. Sign in to the [Azure portal](https://portal.azure.com/).
+1. Make sure you're using the directory that contains your Azure AD B2C tenant. Select the **Directory + subscription** filter in the top menu and choose the directory that contains your tenant.
+1. Choose **All services** in the top-left corner of the Azure portal, and then search for and select **Azure AD B2C**.
+1. On the Overview page, select **Identity Experience Framework**.
+1. Select **Policy Keys** and then select **Add**.
+1. For **Options**, choose `Upload`.
+1. Enter a **Name** for the policy key. For example, `SAMLSigningCert`. The prefix `B2C_1A_` is added automatically to the name of your key.
+1. Browse to and select your certificate .pfx file with the private key.
+1. Click **Create**.
+
+## Configure the SAML technical profile
+
+Define the SAML identity provider by adding it to the **ClaimsProviders** element in the extension file of your policy. The claims providers contains a SAML technical profile that determines the endpoints and the protocols needed to communicate with the SAML identity provider. To add a claims provider with a SAML technical profile:
+
+1. Open the *TrustFrameworkExtensions.xml*.
+1. Find the **ClaimsProviders** element. If it does not exist, add it under the root element.
+1. Add a new **ClaimsProvider** as follows:
+
+ ```xml
+ <ClaimsProvider>
+ <Domain>Contoso.com</Domain>
+ <DisplayName>Contoso</DisplayName>
+ <TechnicalProfiles>
+ <TechnicalProfile Id="Contoso-SAML2">
+ <DisplayName>Contoso</DisplayName>
+ <Description>Login with your SAML identity provider account</Description>
+ <Protocol Name="SAML2"/>
+ <Metadata>
+ <Item Key="PartnerEntity">https://your-AD-FS-domain/federationmetadata/2007-06/federationmetadata.xml</Item>
+ </Metadata>
+ <CryptographicKeys>
+ <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SAMLSigningCert"/>
+ </CryptographicKeys>
+ <OutputClaims>
+ <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="assertionSubjectName" />
+ <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="first_name" />
+ <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="last_name" />
+ <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="http://schemas.microsoft.com/identity/claims/displayname" />
+ <OutputClaim ClaimTypeReferenceId="email" />
+ <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="contoso.com" />
+ <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" />
+ </OutputClaims>
+ <OutputClaimsTransformations>
+ <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
+ <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
+ <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
+ <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
+ </OutputClaimsTransformations>
+ <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-idp"/>
+ </TechnicalProfile>
+ </TechnicalProfiles>
+ </ClaimsProvider>
+ ```
+
+Update the following XML elements with the relevant value:
+
+|XML element |Value |
+|||
+|ClaimsProvider\Domain | The domain name that is used for [direct sign-in](direct-signin.md?pivots=b2c-custom-policy#redirect-sign-in-to-a-social-provider). Enter the domain name you want to use in the direct sign-in. For example, *Contoso.com*. |
+|TechnicalProfile\DisplayName|This value will be displayed on the sign-in button on your sign-in screen. For example, *Contoso*. |
+|Metadata\PartnerEntity|URL of the metadata of the SAML identity provider. Or you can copy the identity provider metadata and add it inside the CDATA element `<![CDATA[Your IDP metadata]]>`.|
+
+## Map the claims
+
+The **OutputClaims** element contains a list of claims returned by the SAML identity provider. Map the name of the claim defined in your policy to the assertion name defined in the identity provider. Check your identity provider for the list of claims (assertions). For more information, see [claims-mapping](identity-provider-generic-saml-options.md#claims-mapping).
+
+In the example above, *Contoso-SAML2* includes the claims returned by a SAML identity provider:
+
+* The **issuerUserId** claim is mapped to the **assertionSubjectName** claim.
+* The **first_name** claim is mapped to the **givenName** claim.
+* The **last_name** claim is mapped to the **surname** claim.
+* The **displayName** claim is mapped to the `http://schemas.microsoft.com/identity/claims/displayname` claim.
+* The **email** claim without name mapping.
+
+The technical profile also returns claims that aren't returned by the identity provider:
+
+* The **identityProvider** claim that contains the name of the identity provider.
+* The **authenticationSource** claim with a default value of **socialIdpAuthentication**.
+
+### Add the SAML session technical profile
+
+If you don't already have the `SM-Saml-idp` SAML session technical profile, add one to your extension policy. Locate the `<ClaimsProviders>` section and add the following XML snippet. If your policy already contains the `SM-Saml-idp` technical profile, skip to the next step. For more information, see [single sign-on session management](custom-policy-reference-sso.md).
+
+```xml
+<ClaimsProvider>
+ <DisplayName>Session Management</DisplayName>
+ <TechnicalProfiles>
+ <TechnicalProfile Id="SM-Saml-idp">
+ <DisplayName>Session Management Provider</DisplayName>
+ <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
+ <Metadata>
+ <Item Key="IncludeSessionIndex">false</Item>
+ <Item Key="RegisterServiceProviders">false</Item>
+ </Metadata>
+ </TechnicalProfile>
+ </TechnicalProfiles>
+</ClaimsProvider>
+```
+++
+```xml
+<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
+ <ClaimsProviderSelections>
+ ...
+ <ClaimsProviderSelection TargetClaimsExchangeId="ContosoExchange" />
+ </ClaimsProviderSelections>
+ ...
+</OrchestrationStep>
+
+<OrchestrationStep Order="2" Type="ClaimsExchange">
+ ...
+ <ClaimsExchanges>
+ <ClaimsExchange Id="ContosoExchange" TechnicalProfileReferenceId="Contoso-SAML2" />
+ </ClaimsExchanges>
+</OrchestrationStep>
+```
++
+## Configure your SAML identity provider
+
+After your policy is configured, you need to configure your SAML identity provider with the Azure AD B2C SAML metadata. The SAML metadata is information used in the SAML protocol to expose the configuration of your policy, the **service provider**. It defines the location of the services, such as sign-in and sign-out, certificates, sign-in method, and more.
+
+Each SAML identity provider has different steps for setting a service provider. Some SAML identity providers ask for the Azure AD B2C metadata, while others require you to go through the metadata file manually and provide the information. Refer to your identity providerΓÇÖs documentation for guidance.
+
+The following example shows a URL address for the SAML metadata of an Azure AD B2C technical profile:
+
+```
+https://<your-tenant-name>.b2clogin.com/<your-tenant-name>.onmicrosoft.com/<your-policy>/samlp/metadata?idptp=<your-technical-profile>
+```
+
+Replace the following values:
+
+- **your-tenant** with your tenant name, such as your-tenant.onmicrosoft.com.
+- **your-policy** with your policy name. For example, B2C_1A_signup_signin_adfs.
+- **your-technical-profile** with the name of your SAML identity provider technical profile. For example, Contoso-SAML2.
+
+Open a browser and navigate to the URL. Make sure you type the correct URL and that you have access to the XML metadata file.
+
+## Test your custom policy
+
+1. Sign in to the [Azure portal](https://portal.azure.com).
+1. Select the **Directory + Subscription** icon in the portal toolbar, and then select the directory that contains your Azure AD B2C tenant.
+1. In the Azure portal, search for and select **Azure AD B2C**.
+1. Under **Policies**, select **Identity Experience Framework**
+1. Select your relying party policy, for example `B2C_1A_signup_signin`.
+1. For **Application**, select a web application that you [previously registered](troubleshoot-custom-policies.md#troubleshoot-the-runtime). The **Reply URL** should show `https://jwt.ms`.
+1. Select the **Run now** button.
+
+If the sign-in process is successful, your browser is redirected to `https://jwt.ms`, which displays the contents of the token returned by Azure AD B2C.
+
+## Next steps
+
+- [Configure SAML identity provider options with Azure Active Directory B2C](identity-provider-generic-saml-options.md)
+
active-directory-b2c Identity Provider Microsoft Account https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/identity-provider-microsoft-account.md
You've now configured your policy so that Azure AD B2C knows how to communicate
<OrchestrationStep Order="2" Type="ClaimsExchange"> ... <ClaimsExchanges>
- <ClaimsExchange Id="MicrosoftAccountExchange" TechnicalProfileReferenceId="MicrosoftAccount-OpenIdConnect" />
+ <ClaimsExchange Id="MicrosoftAccountExchange" TechnicalProfileReferenceId="MSA-MicrosoftAccount-OpenIdConnect" />
</ClaimsExchanges> </OrchestrationStep> ```
You've now configured your policy so that Azure AD B2C knows how to communicate
[!INCLUDE [active-directory-b2c-test-relying-party-policy](../../includes/active-directory-b2c-test-relying-party-policy-user-journey.md)]
active-directory-b2c Identity Provider Salesforce Saml https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/identity-provider-salesforce-saml.md
zone_pivot_groups: b2c-policy-type
[!INCLUDE [active-directory-b2c-advanced-audience-warning](../../includes/active-directory-b2c-advanced-audience-warning.md)]
-This article shows you how to enable sign-in for users from a Salesforce organization using [custom policies](custom-policy-overview.md) in Azure Active Directory B2C (Azure AD B2C). You enable sign-in by adding a [SAML identity provider technical profile](saml-identity-provider-technical-profile.md) to a custom policy.
+This article shows you how to enable sign-in for users from a Salesforce organization using [custom policies](custom-policy-overview.md) in Azure Active Directory B2C (Azure AD B2C). You enable sign-in by adding a [SAML identity provider](identity-provider-generic-saml.md) to a custom policy.
## Prerequisites
You need to store the certificate that you created in your Azure AD B2C tenant.
If you want users to sign in using a Salesforce account, you need to define the account 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 a Salesforce account as a claims provider by adding it to the **ClaimsProviders** element in the extension file of your policy. For more information, see [define a SAML identity provider technical profile](saml-identity-provider-technical-profile.md).
+You can define a Salesforce account as a claims provider by adding it to the **ClaimsProviders** element in the extension file of your policy. For more information, see [define a SAML identity provider](identity-provider-generic-saml.md).
1. Open the *TrustFrameworkExtensions.xml*. 1. Find the **ClaimsProviders** element. If it does not exist, add it under the root element.
active-directory-b2c Json Transformations https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/json-transformations.md
Previously updated : 10/13/2020 Last updated : 03/04/2021
The following claims transformation outputs a JSON string claim that will be the
- Input claims : - **email**, transformation claim type **customerEntity.email**: "john.s@contoso.com" - **objectId**, transformation claim type **customerEntity.userObjectId** "01234567-89ab-cdef-0123-456789abcdef"
- - **objectId**, transformation claim type **customerEntity.firstName** "John"
- - **objectId**, transformation claim type **customerEntity.lastName** "Smith"
+ - **givenName**, transformation claim type **customerEntity.firstName** "John"
+ - **surname**, transformation claim type **customerEntity.lastName** "Smith"
- Input parameter: - **customerEntity.role.name**: "Administrator" - **customerEntity.role.id** 1
active-directory-b2c Jwt Issuer Technical Profile https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/jwt-issuer-technical-profile.md
Previously updated : 10/12/2020 Last updated : 03/04/2021
The following example shows a technical profile for `JwtIssuer`:
```xml <TechnicalProfile Id="JwtIssuer"> <DisplayName>JWT Issuer</DisplayName>
- <Protocol Name="None" />
+ <Protocol Name="OpenIdConnect" />
<OutputTokenFormat>JWT</OutputTokenFormat> <Metadata> <Item Key="client_id">{service:te}</Item>
active-directory-b2c Language Customization https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/language-customization.md
If you want to change the string for a custom user attribute, or you want to add
"Value": "<ExtensionAttributeValue>" } [...]
+ ]
} ```
If you want to provide a set list of values for responses, you need to create a
```json { "LocalizedStrings": [...],
- "LocalizedCollections": [{
+ "LocalizedCollections": [
+ {
"ElementType":"ClaimType", "ElementId":"<UserAttribute>", "TargetCollection":"Restriction", "Override": true, "Items":[
- {
- "Name":"<Response1>",
- "Value":"<Value1>"
- },
- {
- "Name":"<Response2>",
- "Value":"<Value2>"
- }
- ]
- }]
+ {
+ "Name":"<Response1>",
+ "Value":"<Value1>"
+ },
+ {
+ "Name":"<Response2>",
+ "Value":"<Value2>"
+ }
+ ]
+ }
+ ]
} ```
https://wingtiptoysb2c.blob.core.windows.net/fr/wingtip/unified.html
## Add custom languages
-You can also add languages that Microsoft currently does not provide translations for. You'll need to provide the translations for all the strings in the user flow. Language and locale codes are limited to those in the ISO 639-1 standard. The locale code format should be "ISO_639-1_code"-"CountryCode" For Eg: en-GB. For more information on locale ID formats, please refer to https://docs.microsoft.com/openspecs/office_standards/ms-oe376/6c085406-a698-4e12-9d4d-c3b0ee3dbc4a
+You can also add languages that Microsoft currently does not provide translations for. You'll need to provide the translations for all the strings in the user flow. Language and locale codes are limited to those in the ISO 639-1 standard. The locale code format should be "ISO_639-1_code"-"CountryCode", for example `en-GB`. For more information on locale ID formats, please refer to https://docs.microsoft.com/openspecs/office_standards/ms-oe376/6c085406-a698-4e12-9d4d-c3b0ee3dbc4a
1. In your Azure AD B2C tenant, select **User flows**. 2. Click the user flow where you want to add custom languages, and then click **Languages**.
The [LocalizedResources](localization.md#localizedresources) of the `Localizatio
You configure localized resources elements for the content definition and any language you want to support. To customize the unified sign-up or sign-in pages for English and Spanish, you add the following `LocalizedResources` elements after the close of the `</SupportedLanguages>` element. > [!NOTE]
-> In the following sample we added the pound `#` symbol at the begging of each line, so you can easly find the localized labels on the screen.
+> In the following sample we added the pound `#` symbol at the beginning of each line, so you can easily find the localized labels on the screen.
```xml <!--Local account sign-up or sign-in page English-->
active-directory-b2c Localization https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/localization.md
description: Specify the Localization element of a custom policy in Azure Active
- Last updated 10/15/2020 + # Localization element
The UxElement value is used to localize one of the user interface elements. The
### DisplayControl
-The DisplayControl value is used to localize one of the [display Control](display-controls.md) user interface elements. The following example shows how to localize the send and verify buttons.
+The DisplayControl value is used to localize one of the [display Control](display-controls.md) user interface elements. When enabled, the display control localizedStrings takes the ***precedence*** over some of the **UxElement** StringIDs like **ver_but_send**, **ver_but_edit**, **ver_but_resend** and **ver_but_verify**. The following example shows how to localize the send and verify buttons.
```xml <LocalizedString ElementType="DisplayControl" ElementId="emailVerificationControl" StringId="but_send_code">Send verification code</LocalizedString>
active-directory-b2c Manage Users Portal https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/manage-users-portal.md
Previously updated : 11/09/2019 Last updated : 03/03/2021
There might be scenarios in which you want to manually create consumer accounts
To add or delete users, your account must be assigned the *User administrator* or *Global administrator* role. - ## Types of user accounts As described in [Overview of user accounts in Azure AD B2C](user-overview.md), there are three types of user accounts that can be created in an Azure AD B2C directory:
This article focuses on working with **consumer accounts** in the Azure portal.
1. Choose a **Sign in method** and enter either an **Email** address or a **Username** for the new user. The sign in method you select here must match the setting you've specified for your Azure AD B2C tenant's *Local account* identity provider (see **Manage** > **Identity providers** in your Azure AD B2C tenant). 1. Enter a **Name** for the user. This is typically the full name (given and surname) of the user. 1. (Optional) You can **Block sign in** if you wish to delay the ability for the user to sign in. You can enable sign in later by editing the user's **Profile** in the Azure portal.
-1. Choose **Auto-generate password** or **Let me create password**.
+1. Choose **Autogenerate password** or **Let me create password**.
1. Specify the user's **First name** and **Last name**. 1. Select **Create**. Unless you've selected **Block sign in**, the user can now sign in using the sign in method (email or username) that you specified.
+## Reset a user's password
+
+As an administrator, you can reset a user's password, if the user forgets their password. When you reset the user's password, a temporary password is autogenerated for the user. The temporary password never expires. The next time the user signs in, the password will still work, regardless how much time has passed since the temporary password was generated. Then user must reset password to a permanent one.
+
+> [!IMPORTANT]
+> Before you reset a user's password, [set up a force password reset flow in Azure Active Directory B2C](force-password-reset.md), otherwise the user won't be able to sign-in.
+
+To reset a user's password:
+
+1. In your Azure AD B2C directory, select **Users**, and then select the user you want to reset the password.
+1. Search for and select the user that needs the reset, and then select **Reset Password**.
+
+ The **Alain Charon - Profile** page appears with the **Reset password** option.
+
+ ![User's profile page, with Reset password option highlighted](media/manage-users-portal/user-profile-reset-password-link.png)
+
+1. In the **Reset password** page, select **Reset password**.
+1. Copy the password and give it to the user. The user will be required to change the password during the next sign-in process.
++ ## Delete a consumer user 1. In your Azure AD B2C directory, select **Users**, and then select the user you want to delete.
active-directory-b2c Microsoft Graph Operations https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/microsoft-graph-operations.md
Azure AD B2C provides a directory that can hold 100 custom attributes per user.
For more information about accessing Azure AD B2C audit logs, see [Accessing Azure AD B2C audit logs](view-audit-logs.md).
+## Conditional Access
+
+- [List all of the Conditional Access policies](/graph/api/resources/conditionalaccessroot-list-policies)
+- [Read properties and relationships of a Conditional Access policy](/graph/api/conditionalaccesspolicy-get)
+- [Create a new Conditional Access policy](/graph/api/resources/application)
+- [Update a Conditional Access policy](/graph/api/conditionalaccesspolicy-update)
+- [Delete a Conditional Access policy](/graph/api/conditionalaccesspolicy-delete)
+ ## Code sample: How to programmatically manage user accounts This code sample is a .NET Core console application that uses the [Microsoft Graph SDK](/graph/sdks/sdks-overview) to interact with Microsoft Graph API. Its code demonstrates how to call the API to programmatically manage users in an Azure AD B2C tenant.
active-directory-b2c Multi Factor Authentication https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/multi-factor-authentication.md
This feature helps applications handle scenarios such as:
1. In the **Multifactor authentication** section, select the desired **MFA method**, and then under **MFA enforcement** select **Always on**, or **Conditional (Recommended)**. > [!NOTE] >
- > - If you select **Conditional (Recommended)**, you'll also need to [add a Conditional Access policy](conditional-access-identity-protection-setup.md#add-a-conditional-access-policy) and specify the apps you want the policy to apply to.
+ > - If you select **Conditional (Recommended)**, you'll also need to [add Conditional Access to user flows](conditional-access-user-flow.md), and specify the apps you want the policy to apply to.
> - 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. 1. Select **Save**. MFA is now enabled for this user flow.
active-directory-b2c Openid Connect Technical Profile https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/openid-connect-technical-profile.md
Previously updated : 12/01/2020 Last updated : 03/04/2021
The technical profile also returns claims that aren't returned by the identity p
| token_endpoint_auth_method | No | Specifies how Azure AD B2C sends the authentication header to the token endpoint. Possible values: `client_secret_post` (default), and `client_secret_basic` (public preview). For more information, see [OpenID Connect client authentication section](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication). | | token_signing_algorithm | No | The signing algorithm used for client assertions when the **token_endpoint_auth_method** metadata is set to `private_key_jwt`. Possible values: `RS256` (default). | | SingleLogoutEnabled | No | Indicates whether during sign-in the technical profile attempts to sign out from federated identity providers. For more information, see [Azure AD B2C session sign-out](./session-behavior.md#sign-out). Possible values: `true` (default), or `false`. |
+|ReadBodyClaimsOnIdpRedirect| No| Set to `true` to read claims from response body on identity provider redirect. This metadata is used with [Apple ID](identity-provider-apple-id.md), where claims return in the response payload.|
```xml <Metadata>
Examples:
- [Add Microsoft Account (MSA) as an identity provider using custom policies](identity-provider-microsoft-account.md) - [Sign in by using Azure AD accounts](identity-provider-azure-ad-single-tenant.md)-- [Allow users to sign in to a multi-tenant Azure AD identity provider using custom policies](identity-provider-azure-ad-multi-tenant.md)
+- [Allow users to sign in to a multi-tenant Azure AD identity provider using custom policies](identity-provider-azure-ad-multi-tenant.md)
active-directory-b2c Page Layout https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/page-layout.md
Previously updated : 08/24/2020 Last updated : 03/04/2021
Page layout packages are periodically updated to include fixes and improvements
**2.1.2** - Fixed the localization encoding issue for languages such as Spanish and French.-- Allowing the "forgot password" link to use as claims exchange like social IDP.
+- Allowing the "forgot password" link to use as claims exchange. For more information, see [Self-service password reset](add-password-reset-policy.md#self-service-password-reset-recommended).
**2.1.1** - Added a UXString `heading` in addition to `intro` to display on the page as a title. This is hidden by default.
active-directory-b2c Partner Arkose Labs https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/partner-arkose-labs.md
Title: Arkose Labs with Azure Active Directory B2C
+ Title: Tutorial to configure Azure Active Directory B2C with Arkose Labs
-description: Learn how to integrate Azure AD B2C authentication with Arkose Labs to help protect against bot attacks, account takeover attacks, and fraudulent account openings.
+description: Tutorial to configure Azure Active Directory B2C with Arkose Labs to identify risky and fraudulent users
--++ Previously updated : 06/08/2020- Last updated : 02/18/2021+
-# Tutorial for configuring Arkose Labs with Azure Active Directory B2C
+# Tutorial: Configure Arkose Labs with Azure Active Directory B2C
-In this tutorial, learn how to integrate Azure AD B2C authentication with Arkose Labs. Arkose Labs help organizations against bot attacks, account takeover attacks, and fraudulent account openings.
+In this tutorial, learn how to integrate Azure Active Directory (AD) B2C authentication with [Arkose Labs](https://www.arkoselabs.com/). Arkose Labs help organizations against bot attacks, account takeover attacks, and fraudulent account openings.
## Prerequisites To get started, you'll need:
-* An Azure AD subscription. If you don't have a subscription, you can get a [free account](https://azure.microsoft.com/free/).
-* [An Azure AD B2C tenant](tutorial-create-tenant.md) that is linked to your Azure subscription.
+- An Azure subscription. If you don't have a subscription, you can get a [free account](https://azure.microsoft.com/free/).
+
+- [An Azure AD B2C tenant](tutorial-create-tenant.md) that is linked to your Azure subscription.
+
+- An [Arkose Labs](https://www.arkoselabs.com/book-a-demo/) account.
## Scenario description
+Arkose Labs integration includes the following components:
+
+- **Arkose Labs** - A fraud and abuse service for protecting against bots and other automated abuse.
+
+- **Azure AD B2C sign-up user flow** - The sign-up experience that will be using the Arkose Labs service. Will use the custom HTML and JavaScript, and API connectors to integrate with the Arkose Labs service.
+
+- **Azure functions** - API endpoint hosted by you that works with the API connectors feature. This API is responsible for doing the server-side validation of the Arkose Labs session token.
+ The following diagram describes how Arkose Labs integrates with Azure AD B2C.
-![Arkose Labs architecture diagram](media/partner-arkose-labs/arkose-architecture-diagram.png)
+![Image shows Arkose Labs architecture diagram](media/partner-arkose-labs/arkose-labs-architecture-diagram.png)
| Step | Description | |||
-|1 | A user signs in with a previously created account. When the user selects submit, an Arkose Labs Enforcement challenge appears. After the user completes the challenge, the status is sent to Arkose Labs to generate a token. |
-|2 | Arkose Labs sends the token back to Azure AD B2C. |
-|3 | Before the sign-in form is submitted, the token is sent to Arkose Labs for verification. |
-|4 | Arkose sends back a success or failure result from the challenge. |
-|5 | If the challenge is successfully completed, a sign-in form is submitted to Azure AD B2C, and Azure AD B2C completes the authentication. |
-| | |
+|1 | A user signs-up and creates an account. When the user selects submit, an Arkose Labs enforcement challenge appears. |
+|2 | After the user completes the challenge, Azure AD B2C sends the status to Arkose Labs to generate a token. |
+|3 | Arkose Labs generates a token and sends it back to Azure AD B2C. |
+|4 | Azure AD B2C calls an intermediate web API to pass the sign-up form. |
+|5 | The intermediate web API sends the sign-up form to Arkose Lab for token verification. |
+|6 | Arkose Lab processes and sends the verification results back to the intermediate web API.|
+|7 | The intermediate web API sends the success or failure result from the challenge to Azure AD B2C. |
+|8 | If the challenge is successfully completed, a sign-up form is submitted to Azure AD B2C, and Azure AD B2C completes the authentication.|
## Onboard with Arkose Labs
-1. Start by contacting [Arkose Labs](https://www.arkoselabs.com/book-a-demo/) and creating an account.
+1. Contact [Arkose](https://www.arkoselabs.com/book-a-demo/) and create an account.
-2. Once your account is created, navigate to https://dashboard.arkoselabs.com/login.
+2. Once the account is created, navigate to https://dashboard.arkoselabs.com/login
-3. Within the dashboard, navigate to site settings to find your public key and private key. This information will be needed later to configure Azure AD B2C.
+3. Within the dashboard, navigate to site settings to find your public key and private key. This information will be needed later to configure Azure AD B2C. The values of public and private keys are referred to as `ARKOSE_PUBLIC_KEY` and `ARKOSE_PRIVATE_KEY` in the [sample code](https://github.com/Azure-Samples/active-directory-b2c-node-sign-up-user-flow-arkose).
## Integrate with Azure AD B2C
-### Part 1 ΓÇô Create blob storage to store the custom HTML
+### Part 1 ΓÇô Create a ArkoseSessionToken custom attribute
+
+To create a custom attribute, follow these steps:
+
+1. Go to **Azure portal** > **Azure AD B2C**
+
+2. Select **User attributes**
+
+3. Select **Add**
+
+4. Enter **ArkoseSessionToken** as the attribute Name
+
+5. Select **Create**
+
+Learn more about [custom attributes](https://docs.microsoft.com/azure/active-directory-b2c/user-flow-custom-attributes?pivots=b2c-user-flow).
+
+### Part 2 - Create a user flow
+
+The user flow can be either for **sign-up** and **sign in** or just **sign-up**. The Arkose Labs user flow will only be shown during sign-up.
+
+1. See the [instructions](https://docs.microsoft.com/azure/active-directory-b2c/tutorial-create-user-flows) to create a user flow. If using an existing user flow, it must be of the **Recommended (next-generation preview)** version type.
+
+2. In the user flow settings, go to **User attributes** and select the **ArkoseSessionToken** claim.
+
+![Image shows how to select custom attributes](media/partner-arkose-labs/select-custom-attribute.png)
+
+### Part 3 - Configure custom HTML, JavaScript, and page layouts
-To create a storage account, follow these steps:
+Go to the provided [HTML script](https://github.com/Azure-Samples/active-directory-b2c-node-sign-up-user-flow-arkose/blob/main/Assets/selfAsserted.html). The file contains an HTML template with JavaScript `<script>` tags that will do three things:
-1. Sign in to the Azure portal.
+1. Load the Arkose Labs script, which renders the Arkose Labs widget and does client-side Arkose Labs validation.
-2. Make sure to use the directory that contains your Azure subscription. Select theΓÇ»**Directory + Subscription** filter in the top menu and choose the directory that contains your subscription. This directory is different than the one that contains your Azure B2C tenant.
+2. Hide the `extension_ArkoseSessionToken` input element and label, corresponding to the `ArkoseSessionToken` custom attribute, from the UI shown to the user.
-3. Choose **All services** in the top-left corner of the Azure portal, and then search for and select ΓÇ»**Storage accounts**.
+3. When a user completes the Arkose Labs challenge, Arkose Labs verifies the user's response and generates a token. The callback `arkoseCallback` in the custom JavaScript sets the value of `extension_ArkoseSessionToken` to the generated token value. This value will be submitted to the API endpoint as described in the next section.
-4. SelectΓÇ»**Add**.
+ See [this article](https://arkoselabs.atlassian.net/wiki/spaces/DG/pages/214176229/Standard+Setup) to learn about Arkose Labs client-side validation.
-5. UnderΓÇ»**Resource group**, selectΓÇ»**Create new**, enter a name for the new resource group, and then select **OK**.
+Follow the steps mentioned to use the custom HTML and JavaScript for your user flow.
-6. Enter a name for the storage account. The name you choose must be unique across Azure, must be between 3 and 24 characters in length, and may contain numbers and lowercase letters only.
+1. Modify [selfAsserted.html](https://github.com/Azure-Samples/active-directory-b2c-node-sign-up-user-flow-arkose/blob/main/Assets/selfAsserted.html) file so that `<ARKOSE_PUBLIC_KEY>` matches the value you generated for the client-side validation, and used to load the Arkose Labs script for your account.
-7. Select the location of the storage account or accept the default location.
+2. Host the HTML page on a Cross-origin Resource Sharing (CORS) enabled web endpoint. [Create an Azure blob storage account](https://docs.microsoft.com/azure/storage/common/storage-account-create?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.json&tabs=azure-portal) and [configure CORS](https://docs.microsoft.com/rest/api/storageservices/cross-origin-resource-sharing--cors--support-for-the-azure-storage-services).
-8. Accept all other default values, selectΓÇ» **Review & create** > **Create**.
+ >[!NOTE]
+ >If you have your own custom HTML, copy and paste the `<script>` elements onto your HTML page.
-9. After the storage account is created, select ΓÇ»**Go to resource**.
+3. Follow these steps to configure the page layouts
-#### Create a container
+ a. From the Azure portal, go to **Azure AD B2C**
-1. On the overview page of the storage account, selectΓÇ» **Blobs**.
+ b. Navigate to **User flows** and select your user flow
-2. SelectΓÇ» **Container**, enter a name for the container, chooseΓÇ» **Blob** (anonymous read access for blobs only), and then select **OK**.
+ c. Select **Page layouts**
-#### Enable Cross-origin resource sharing (CORS)
+ d. Select **Local account sign up page layout**
-Azure AD B2C code in a browser uses a modern and standard approach to load custom content from a URL that you specify in a user flow. CORS allows restricted resources on a web page to be requested from other domains.
+ e. Toggle **Use custom page content** to **YES**
-1. In the menu, selectΓÇ» **CORS**.
+ f. Paste the URI where your custom HTML lives in **Use custom page content**
-2. For  **Allowed origins**, enter `https://your-tenant-name.b2clogin.com`. Replace your-tenant-name with the name of your Azure AD B2C tenant. For example, `https://fabrikam.b2clogin.com`. Use all lowercase letters when entering your tenant name.
+ g. If you're using social Identity providers, repeat **step e** and **f** for **Social account sign-up page** layout.
-3. ForΓÇ»**Allowed Methods**, selectΓÇ»**GET**, **PUT**, andΓÇ»**OPTIONS**.
+ ![image showing page layouts](media/partner-arkose-labs/page-layouts.png)
-4. For **Allowed Headers**, enter an asterisk (*).
+4. From your user flow, go to **Properties** and select **Enable JavaScript** enforcing page layout (preview). See this [article](https://docs.microsoft.com/azure/active-directory-b2c/javascript-and-page-layout?pivots=b2c-user-flow) to learn more.
-5. ForΓÇ»**Exposed Headers**, enter an asterisk (*).
+### Part 4 - Create and deploy your API
-6. For **Max age**, enter 200.
+Install the [Azure Functions extension](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azurefunctions) for Visual Studio Code.
- ![Arkose Labs sign-up and sign-in](media/partner-arkose-labs/signup-signin-arkose.png)
+>[!Note]
+>Steps mentioned in this section assumes you are using Visual Studio Code to deploy the Azure Function. You can also use Azure portal, terminal or command prompt, or any other code editor to deploy.
-7. Select **Save**.
+#### Run the API locally
-### Part 2 ΓÇô Set up a back-end server
+1. Navigate to the Azure extension in Visual Studio code on the left navigation bar. Select **Local Project** folder representing your local Azure Function.
-Download Git Bash and follow the steps below:
+2. Press **F5** or use the **Debug** > **Start Debugging** menu to launch the debugger and attach to the Azure Functions host. This command automatically uses the single debug configuration that Azure Function created.
-1. Follow the instructions to [create a web app](../app-service/quickstart-php.md), up until the message “Congratulations! You've deployed your first PHP app to App Service” displays.
+3. The Azure Function extension will automatically generate a few files for local development, install dependencies, and install the Function Core tools if not already present. These tools help with the debugging experience.
-2. Open your local folder and rename the **index.php** file to **verify-token.php**.
+4. Output from the Function Core tool appears in the Visual Studio Code **Terminal** panel. Once the host has started, **Alt+click** the local URL shown in the output to open the browser and run the function. In the Azure Functions explorer, right-click on the function to see the url of the locally hosted function.
-3. Open the newly renamed file verify-token.php file and:
+To redeploy the local instance during testing, repeat steps 1 to 4.
- a. Replace the content with the content from the verify-token.php file found in the [GitHub repository](https://github.com/ArkoseLabs/Azure-AD-B2C).
+#### Add environment variables
- b. Replace <private_key> on line 3 with your private key obtained from the Arkose Labs dashboard.
+This sample protects the web API endpoint using [HTTP Basic authentication](https://tools.ietf.org/html/rfc7617).
-4. In the local terminal window, commit your changes in Git, and then push the code changes to Azure by typing the following in Git Bash:
+Username and password are stored as environment variables and not as part of the repository. See [local.settings.json](https://docs.microsoft.com/azure/azure-functions/functions-run-local?tabs=macos%2Ccsharp%2Cbash#local-settings-file) file for more information.
- ``git commit -am "updated output"``
+1. Create a local.settings.json file in your root folder
- ``git push azure main``
+2. Copy and paste the below code onto the file:
-### Part 3 ΓÇô Final setup
+```
+{
+ "IsEncrypted": false,
+ "Values": {
+ "AzureWebJobsStorage": "",
+ "FUNCTIONS_WORKER_RUNTIME": "node",
+ "BASIC_AUTH_USERNAME": "<USERNAME>",
+ "BASIC_AUTH_PASSWORD": "<PASSWORD>",
+ "ARKOSE_PRIVATE_KEY": "<ARKOSE_PRIVATE_KEY>",
+ "B2C_EXTENSIONS_APP_ID": "<B2C_EXTENSIONS_APP_ID>"
+ }
+}
+```
+The **BASIC_AUTH_USERNAME** and **BASIC_AUTH_PASSWORD** values are going to be the credentials used to authenticate the API call to your Azure Function. Choose your desired values.
-#### Store the custom HTML
+The `<ARKOSE_PRIVATE_KEY>` is the server-side secret you generated in the Arkose Labs service. It's used to call the [Arkose Labs server-side validation API](https://arkoselabs.atlassian.net/wiki/spaces/DG/pages/266214758/Server-Side+Instructions) to validate the value of the `ArkoseSessionToken` generated by the front end.
-1. Open the https://docsupdatetracker.net/index.html file stored in the [GitHub repository](https://github.com/ArkoseLabs/Azure-AD-B2C).
+The `<B2C_EXTENSIONS_APP_ID>` is the application ID of the app used by Azure AD B2C to store custom attributes in the directory. You can find this application ID by navigating to App registrations, searching for b2c-extensions-app, and copying the Application (client) ID from the **Overview** pane. Remove the `-` characters.
-2. Replace all instances of `<tenantname>` with your b2C tenant name (in other words, `<tenantname>.b2clogin.com`). There should be four instances.
+![Image shows search by app id](media/partner-arkose-labs/search-app-id.png)
-3. Replace the `<appname>` with the app name that you created in Part 2, step 1.
+#### Deploy the application to the web
- ![Screenshot showing Arkose Labs Azure CLI](media/partner-arkose-labs/arkose-azure-cli.png)
+1. Follow the steps mentioned in [this](https://docs.microsoft.com/azure/javascript/tutorial-vscode-serverless-node-04) guide to deploy your Azure Function to the cloud. Copy the endpoint web URL of your Azure Function.
-4. Replace the `<public_key>` on line 64 with the public key you obtained from the Arkose Labs dashboard.
+2. Once deployed, select the **Upload settings** option. It will upload your environment variables onto the [Application settings](https://docs.microsoft.com/azure/azure-functions/functions-develop-vs-code?tabs=csharp#application-settings-in-azure) of the App service. These application settings can also be configured or [managed via the Azure portal.](https://docs.microsoft.com/azure/azure-functions/functions-how-to-use-azure-function-app-settings)
-5. Upload the https://docsupdatetracker.net/index.html file into the blob storage created above.
+See [this article](https://docs.microsoft.com/azure/azure-functions/functions-develop-vs-code?tabs=csharp#republish-project-files) to learn more about Visual Studio Code development for Azure Functions.
-6. Go to **Storage** > **Container** > **Upload**.
+#### Configure and enable the API connector
-#### Set up Azure AD B2C
+[Create an API connector](https://docs.microsoft.com/azure/active-directory-b2c/add-api-connector) and enable it for your user flow.
+Your API connector configuration should look like:
-> [!NOTE]
-> If you don't have one already, [create an Azure AD B2C tenant](tutorial-create-tenant.md) that is linked to your Azure subscription.
+![Image shows search by app id](media/partner-arkose-labs/configure-api-connector.png)
-1. Create a user flow based on the information [here](tutorial-create-user-flows.md). Stop when you reach the section **Test the user flow**.
+- **Endpoint URL** - is the Function URL you copied earlier while you deployed Azure Function.
-2. Enable JavaScript in your [user flow](javascript-and-page-layout.md).
+- **Username and Password** - are the Username and Password you defined as environment variables earlier.
-3. In the same user flow page, enable custom page URL: Go to
-**User flow** > **page layout** > **use custom page content** = **yes** > **insert custom page URL**.
-This custom page URL is obtained from the location of the https://docsupdatetracker.net/index.html file inside the blob storage
+To enable the API connector, in the **API connector** settings for your user flow, select the API connector to be invoked at the **Before creating the user** step. This will invoke the API when a user selects **Create** in the sign-up flow. The API will do a server-side validation of the `ArkoseSessionToken` value, which was set by the callback of the Arkose widget `arkoseCallback`.
- ![Screenshot showing Arkose Labs storage url](media/partner-arkose-labs/arkose-storage-url.png)
+![Image shows enabling api connector](media/partner-arkose-labs/enable-api-connector.png)
## Test the user flow
-1. Open the Azure AD B2C tenant, and under **Policies**, select **User flows**.
+1. Open the Azure AD B2C tenant and under Policies select **User flows**.
2. Select your previously created User Flow. 3. Select **Run user flow** and select the settings:
- a. **Application** - Select the registered app (sample is JWT).
+ a. Application: select the registered app (sample is JWT)
- b. **Reply URL** - Select the redirect URL.
+ b. Reply URL: select the redirect URL
c. Select **Run user flow**.
-4. Go through the sign-up flow and create an account.
+4. Go through the sign-up flow and create an account
-5. Sign out.
+5. Sign out
-6. Go through the sign-in flow.
+6. Go through the sign-in flow
7. An Arkose Labs puzzle will appear after you select **continue**.
-## Next steps
+## Additional resources
-For additional information, review the following articles:
+- [Sample codes](https://github.com/Azure-Samples/active-directory-b2c-node-sign-up-user-flow-arkose) for Azure AD B2C sign-up user flow
-- [Custom policies in Azure AD B2C](custom-policy-overview.md)
+- [Custom policies in Azure AD B2C](https://docs.microsoft.com/azure/active-directory-b2c/custom-policy-overview)
-- [Get started with custom policies in Azure AD B2C](custom-policy-get-started.md?tabs=applications)
+- [Get started with custom policies in Azure AD B2C](https://docs.microsoft.com/azure/active-directory-b2c/custom-policy-get-started?tabs=applications)
active-directory-b2c Partner Dynamics 365 Fraud Protection https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/partner-dynamics-365-fraud-protection.md
- Title: Tutorial to configure Azure Active Directory B2C with Microsoft Dynamics 365 Fraud Protection-
-description: Tutorial to configure Azure Active Directory B2C with Microsoft Dynamics 365 Fraud Protection to identify risky and fraudulent account
------- Previously updated : 02/10/2021----
-# Tutorial: Configure Microsoft Dynamics 365 Fraud Protection with Azure Active Directory B2C
-
-In this sample tutorial, we provide guidance on how to integrate [Microsoft Dynamics 365 Fraud Protection](https://docs.microsoft.com/dynamics365/fraud-protection/overview) (DFP) with the Azure Active Directory (AD) B2C.
-
-Microsoft DFP provides clients with the capability to assess if the risk of attempts to create new accounts and attempts to login to clientΓÇÖs ecosystem are fraudulent. Microsoft DFP assessment can be used by the customer to block or challenge suspicious attempts to create new fake accounts or to compromise existing accounts. Account protection includes artificial intelligence empowered device fingerprinting, APIs for real-time risk assessment, rule and list experience to optimize risk strategy as per clientΓÇÖs business needs, and a scorecard to monitor fraud protection effectiveness and trends in clientΓÇÖs ecosystem.
-
-In this sample, we'll be integrating the account protection features of Microsoft DFP with an Azure AD B2C user flow. The service will externally fingerprint every sign-in or sign up attempt and watch for any past or present suspicious behavior. Azure AD B2C invokes a decision endpoint from Microsoft DFP, which returns a result based on all past and present behavior from the identified user, and also the custom rules specified within the Microsoft DFP service. Azure AD B2C makes an approval decision based on this result and passes the same back to Microsoft DFP.
-
-## Prerequisites
-
-To get started, you'll need:
--- An Azure subscription. If you don't have a subscription, you can get a [free account](https://azure.microsoft.com/free/).--- An [Azure AD B2C tenant](https://docs.microsoft.com/azure/active-directory-b2c/tutorial-create-tenant). Tenant is linked to your Azure subscription.--- Get a Microsoft DFP [subscription](https://dynamics.microsoft.com/pricing/#Sales). You can set up a [trial client version](https://dynamics.microsoft.com/ai/fraud-protection/signin/?RU=https%3A%2F%2Fdfp.microsoft.com%2Fsignin) as well.-
-## Scenario description
-
-Microsoft DFP integration includes the following components:
--- **Azure AD B2C tenant**: Authenticates the user and acts as a client of Microsoft DFP. Hosts a fingerprinting script collecting identification and diagnostic data of every user that executes a target policy. Later blocks or challenges sign-in or sign-up attempts if Microsoft DFP finds them suspicious.--- **Custom app service**: A web application that serves two purposes.-
- - Serves HTML pages to be used as Identity Experience Framework's UI. Responsible for embedding the Microsoft Dynamics 365 fingerprinting script.
-
- - An API controller with RESTful endpoints that connects Microsoft DFP to Azure AD B2C. Handle's data processing, structure, and adheres to the security requirements of both.
--- **Microsoft DFP fingerprinting service**: Dynamically embedded script, which logs device telemetry and self-asserted user details to create a uniquely identifiable fingerprint for the user to be used later in the decision-making process.--- **Microsoft DFP API endpoints**: Provides the decision result and accepts a final status reflecting the operation undertaken by the client application. Azure AD B2C doesn't communicate with the endpoints directly because of varying security and API payload requirements, instead uses the app service as an intermediate.-
-The following architecture diagram shows the implementation.
-
-![Image shows microsoft dynamics365 fraud protection architecture diagram](./media/partner-dynamics365-fraud-protection/microsoft-dynamics-365-fraud-protection-diagram.png)
-
-|Step | Description |
-|:--| :--|
-| 1. | The user arrives at a login page. Users select sign-up to create a new account and enter information into the page. Azure AD B2C collects user attributes.
-| 2. | Azure AD B2C calls the middle layer API and passes on the user attributes.
-| 3. | Middle layer API collects user attributes and transforms it into a format that Microsoft DFP API could consume. Then after sends it to Microsoft DFP API.
-| 4. | After Microsoft DFP API consumes the information and processes it, it returns the result to the middle layer API.
-| 5. | The middle layer API processes the information and sends back relevant information to Azure AD B2C.
-| 6. | Azure AD B2C receives information back from the middle layer API. If it shows a Failure response, an error message is displayed to the user. If it shows a Success response, the user is authenticated and written into the directory.
-
-## Set up the solution
-
-1. [Create a Facebook application](https://docs.microsoft.com/azure/active-directory-b2c/identity-provider-facebook#create-a-facebook-application) configured to allow federation to Azure AD B2C.
-2. [Add the Facebook secret](https://docs.microsoft.com/azure/active-directory-b2c/custom-policy-get-started#create-the-facebook-key) you created as an Identity Experience Framework policy key.
-
-## Configure your application under Microsoft DFP
-
-[Set up your Azure AD tenant](https://docs.microsoft.com/dynamics365/fraud-protection/integrate-real-time-api) to use Microsoft DFP.
-
-## Deploy to the web application
-
-### Implement Microsoft DFP service fingerprinting
-
-[Microsoft DFP device fingerprinting](https://docs.microsoft.com/dynamics365/fraud-protection/device-fingerprinting) is a requirement for Microsoft DFP account protection.
-
->[!NOTE]
->In addition to Azure AD B2C UI pages, customer may also implement the fingerprinting service inside app code for more comprehensive device profiling. Fingerprinting service in app code is not included in this sample.
-
-### Deploy the Azure AD B2C API code
-
-Deploy the [provided API code](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/Dynamics-Fraud-Protection/API) to an Azure service. The code can be [published from Visual Studio](https://docs.microsoft.com/visualstudio/deployment/quickstart-deploy-to-azure?view=vs-2019).
-
-Set-up CORS, add **Allowed Origin** `https://{your_tenant_name}.b2clogin.com`
-
->[!NOTE]
->You'll later need the URL of the deployed service to configure Azure AD with the required settings.
-
-See [App service documentation](https://docs.microsoft.com/azure/app-service/app-service-web-tutorial-rest-api) to learn more.
-
-### Add context-dependent configuration settings
-
-Configure the application settings in the [App service in Azure](https://docs.microsoft.com/azure/app-service/configure-common#configure-app-settings). This allows settings to be securely configured without checking them into a repository. The Rest API needs the following settings provided:
-
-| Application settings | Source | Notes |
-| :-- | :| :--|
-|FraudProtectionSettings:InstanceId | Microsoft DFP Configuration | |
-|FraudProtectionSettings:DeviceFingerprintingCustomerId | Your Microsoft device fingerprinting customer ID | |
-| FraudProtectionSettings:ApiBaseUrl | Your Base URL from Microsoft DFP Portal | Remove '-int' to call the production API instead
-| TokenProviderConfig: Resource | https://api.dfp.dynamics-int.com | Remove '-int' to call the production API instead |
-| TokenProviderConfig:ClientId |Your Fraud Protection merchant Azure AD client app ID | |
-| TokenProviderConfig:Authority | https://login.microsoftonline.com/<directory_ID> | Your Fraud Protection merchant Azure AD tenant authority |
-| TokenProviderConfig:CertificateThumbprint* | The thumbprint of the certificate to use to authenticate against your merchant Azure AD client app |
-| TokenProviderConfig:ClientSecret* | The secret for your merchant Azure AD client app | Recommended to use a secrets manager |
-
-*Only set 1 of the 2 marked parameters depending on if you authenticate with a certificate or a secret such as a password.
-
-## Azure AD B2C configuration
-
-### Replace the configuration values
-
-In the provided [custom policies](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/Dynamics-Fraud-Protection/Policies), find the following placeholders and replace them with the corresponding values from your instance.
-
-| Placeholder | Replace with | Notes |
-| :-- | :| :--|
-|{your_tenant_name} | Your tenant short name | ΓÇ£yourtenantΓÇ¥ from yourtenant.onmicrosoft.com |
-|{your_tenantId} | Tenant ID of your Azure AD B2C tenant | 01234567-89ab-cdef-0123-456789abcdef |
-| {your_tenant_IdentityExperienceFramework_appid} | App ID of the IdentityExperienceFramework app configured in your Azure AD B2C tenant | 01234567-89ab-cdef-0123-456789abcdef |
-| {your_tenant_ ProxyIdentityExperienceFramework _appid} | App ID of the ProxyIdentityExperienceFramework app configured in your Azure AD B2C tenant | 01234567-89ab-cdef-0123-456789abcdef |
-| {your_tenant_extensions_appid} | App ID of your tenantΓÇÖs storage application | 01234567-89ab-cdef-0123-456789abcdef |
-| {your_tenant_extensions_app_objectid} | Object ID of your tenantΓÇÖs storage application | 01234567-89ab-cdef-0123-456789abcdef |
-| {your_app_insights_instrumentation_key} | Instrumentation key of your app insights instance* | 01234567-89ab-cdef-0123-456789abcdef |
-| {your_ui_base_url} | Endpoint in your app service from where your UI files are served | https://yourapp.azurewebsites.net/B2CUI/GetUIPage |
-| {your_app_service_url} | URL of your app service | https://yourapp.azurewebsites.net |
-| {your-facebook-app-id} | App ID of the facebook app you configured for federation with Azure AD B2C | 000000000000000 |
-| {your-facebook-app-secret} | Name of the policy key you've saved facebook's app secret as | B2C_1A_FacebookAppSecret |
-
-*App insights can be in a different tenant. This step is optional. Remove the corresponding TechnicalProfiles and OrechestrationSteps if not needed.
-
-### Call Microsoft DFP label API
-
-Customers need to [implement label API](https://docs.microsoft.com/dynamics365/fraud-protection/integrate-ap-api). See [Microsoft DFP API](https://apidocs.microsoft.com/services/dynamics365fraudprotection#/AccountProtection/v1.0) to learn more.
-
-`URI: < API Endpoint >/v1.0/label/account/create/<userId>`
-
-The value of the userID needs to be the same as the one in the corresponding Azure AD B2C configuration value (ObjectID).
-
->[!NOTE]
->Add consent notification to the attribute collection page. Notify that the users' telemetry and user identity information will be recorded for account protection purposes.
-
-## Configure the Azure AD B2C policy
-
-1. Go to the [Azure AD B2C policy](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/Dynamics-Fraud-Protection/Policies) in the Policies folder.
-
-2. Follow this [document](https://docs.microsoft.com/azure/active-directory-b2c/custom-policy-get-started?tabs=applications#custom-policy-starter-pack) to download [LocalAccounts starter pack](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/tree/master/LocalAccounts)
-
-3. Configure the policy for the Azure AD B2C tenant.
-
->[!NOTE]
->Update the policies provided to relate to your specific tenant.
-
-## Test the user flow
-
-1. Open the Azure AD B2C tenant and under Policies select **Identity Experience Framework**.
-
-2. Select your previously created **SignUpSignIn**.
-
-3. Select **Run user flow** and select the settings:
-
- a. **Application**: select the registered app (sample is JWT)
-
- b. **Reply URL**: select the **redirect URL**
-
- c. Select **Run user flow**.
-
-4. Go through sign-up flow and create an account
-
-5. Microsoft DFP service will be called during the flow, after user attribute is created. If the flow is incomplete, check that the user isn't saved in the directory.
-
->[!NOTE]
->Update rules directly in Microsoft DFP Portal if using [Microsoft DFP rule engine](https://docs.microsoft.com/dynamics365/fraud-protection/rules).
-
-## Next steps
-
-For additional information, review the following articles:
--- [Microsoft DFP samples](https://github.com/Microsoft/Dynamics-365-Fraud-Protection-Samples)--- [Custom policies in Azure AD B2C](https://docs.microsoft.com/azure/active-directory-b2c/custom-policy-overview)--- [Get started with custom policies in Azure AD B2C](https://docs.microsoft.com/azure/active-directory-b2c/custom-policy-get-started?tabs=applications)+
+ Title: Tutorial to configure Azure Active Directory B2C with Microsoft Dynamics 365 Fraud Protection
+
+description: Tutorial to configure Azure Active Directory B2C with Microsoft Dynamics 365 Fraud Protection to identify risky and fraudulent account
+++++++ Last updated : 02/10/2021++++
+# Tutorial: Configure Microsoft Dynamics 365 Fraud Protection with Azure Active Directory B2C
+
+In this sample tutorial, we provide guidance on how to integrate [Microsoft Dynamics 365 Fraud Protection](/dynamics365/fraud-protection/overview) (DFP) with the Azure Active Directory (AD) B2C.
+
+Microsoft DFP provides clients with the capability to assess if the risk of attempts to create new accounts and attempts to login to clientΓÇÖs ecosystem are fraudulent. Microsoft DFP assessment can be used by the customer to block or challenge suspicious attempts to create new fake accounts or to compromise existing accounts. Account protection includes artificial intelligence empowered device fingerprinting, APIs for real-time risk assessment, rule and list experience to optimize risk strategy as per clientΓÇÖs business needs, and a scorecard to monitor fraud protection effectiveness and trends in clientΓÇÖs ecosystem.
+
+In this sample, we'll be integrating the account protection features of Microsoft DFP with an Azure AD B2C user flow. The service will externally fingerprint every sign-in or sign up attempt and watch for any past or present suspicious behavior. Azure AD B2C invokes a decision endpoint from Microsoft DFP, which returns a result based on all past and present behavior from the identified user, and also the custom rules specified within the Microsoft DFP service. Azure AD B2C makes an approval decision based on this result and passes the same back to Microsoft DFP.
+
+## Prerequisites
+
+To get started, you'll need:
+
+- An Azure subscription. If you don't have a subscription, you can get a [free account](https://azure.microsoft.com/free/).
+
+- An [Azure AD B2C tenant](./tutorial-create-tenant.md). Tenant is linked to your Azure subscription.
+
+- Get a Microsoft DFP [subscription](https://dynamics.microsoft.com/pricing/#Sales). You can set up a [trial client version](https://dynamics.microsoft.com/ai/fraud-protection/signin/?RU=https%3A%2F%2Fdfp.microsoft.com%2Fsignin) as well.
+
+## Scenario description
+
+Microsoft DFP integration includes the following components:
+
+- **Azure AD B2C tenant**: Authenticates the user and acts as a client of Microsoft DFP. Hosts a fingerprinting script collecting identification and diagnostic data of every user that executes a target policy. Later blocks or challenges sign-in or sign-up attempts if Microsoft DFP finds them suspicious.
+
+- **Custom app service**: A web application that serves two purposes.
+
+ - Serves HTML pages to be used as Identity Experience Framework's UI. Responsible for embedding the Microsoft Dynamics 365 fingerprinting script.
+
+ - An API controller with RESTful endpoints that connects Microsoft DFP to Azure AD B2C. Handle's data processing, structure, and adheres to the security requirements of both.
+
+- **Microsoft DFP fingerprinting service**: Dynamically embedded script, which logs device telemetry and self-asserted user details to create a uniquely identifiable fingerprint for the user to be used later in the decision-making process.
+
+- **Microsoft DFP API endpoints**: Provides the decision result and accepts a final status reflecting the operation undertaken by the client application. Azure AD B2C doesn't communicate with the endpoints directly because of varying security and API payload requirements, instead uses the app service as an intermediate.
+
+The following architecture diagram shows the implementation.
+
+![Image shows microsoft dynamics365 fraud protection architecture diagram](./media/partner-dynamics365-fraud-protection/microsoft-dynamics-365-fraud-protection-diagram.png)
+
+|Step | Description |
+|:--| :--|
+| 1. | The user arrives at a login page. Users select sign-up to create a new account and enter information into the page. Azure AD B2C collects user attributes.
+| 2. | Azure AD B2C calls the middle layer API and passes on the user attributes.
+| 3. | Middle layer API collects user attributes and transforms it into a format that Microsoft DFP API could consume. Then after sends it to Microsoft DFP API.
+| 4. | After Microsoft DFP API consumes the information and processes it, it returns the result to the middle layer API.
+| 5. | The middle layer API processes the information and sends back relevant information to Azure AD B2C.
+| 6. | Azure AD B2C receives information back from the middle layer API. If it shows a Failure response, an error message is displayed to the user. If it shows a Success response, the user is authenticated and written into the directory.
+
+## Set up the solution
+
+1. [Create a Facebook application](./identity-provider-facebook.md#create-a-facebook-application) configured to allow federation to Azure AD B2C.
+2. [Add the Facebook secret](./custom-policy-get-started.md#create-the-facebook-key) you created as an Identity Experience Framework policy key.
+
+## Configure your application under Microsoft DFP
+
+[Set up your Azure AD tenant](/dynamics365/fraud-protection/integrate-real-time-api) to use Microsoft DFP.
+
+## Deploy to the web application
+
+### Implement Microsoft DFP service fingerprinting
+
+[Microsoft DFP device fingerprinting](/dynamics365/fraud-protection/device-fingerprinting) is a requirement for Microsoft DFP account protection.
+
+>[!NOTE]
+>In addition to Azure AD B2C UI pages, customer may also implement the fingerprinting service inside app code for more comprehensive device profiling. Fingerprinting service in app code is not included in this sample.
+
+### Deploy the Azure AD B2C API code
+
+Deploy the [provided API code](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/Dynamics-Fraud-Protection/API) to an Azure service. The code can be [published from Visual Studio](/visualstudio/deployment/quickstart-deploy-to-azure?view=vs-2019).
+
+Set-up CORS, add **Allowed Origin** `https://{your_tenant_name}.b2clogin.com`
+
+>[!NOTE]
+>You'll later need the URL of the deployed service to configure Azure AD with the required settings.
+
+See [App service documentation](../app-service/app-service-web-tutorial-rest-api.md) to learn more.
+
+### Add context-dependent configuration settings
+
+Configure the application settings in the [App service in Azure](../app-service/configure-common.md#configure-app-settings). This allows settings to be securely configured without checking them into a repository. The Rest API needs the following settings provided:
+
+| Application settings | Source | Notes |
+| :-- | :| :--|
+|FraudProtectionSettings:InstanceId | Microsoft DFP Configuration | |
+|FraudProtectionSettings:DeviceFingerprintingCustomerId | Your Microsoft device fingerprinting customer ID | |
+| FraudProtectionSettings:ApiBaseUrl | Your Base URL from Microsoft DFP Portal | Remove '-int' to call the production API instead
+| TokenProviderConfig: Resource | https://api.dfp.dynamics-int.com | Remove '-int' to call the production API instead |
+| TokenProviderConfig:ClientId |Your Fraud Protection merchant Azure AD client app ID | |
+| TokenProviderConfig:Authority | https://login.microsoftonline.com/<directory_ID> | Your Fraud Protection merchant Azure AD tenant authority |
+| TokenProviderConfig:CertificateThumbprint* | The thumbprint of the certificate to use to authenticate against your merchant Azure AD client app |
+| TokenProviderConfig:ClientSecret* | The secret for your merchant Azure AD client app | Recommended to use a secrets manager |
+
+*Only set 1 of the 2 marked parameters depending on if you authenticate with a certificate or a secret such as a password.
+
+## Azure AD B2C configuration
+
+### Replace the configuration values
+
+In the provided [custom policies](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/Dynamics-Fraud-Protection/Policies), find the following placeholders and replace them with the corresponding values from your instance.
+
+| Placeholder | Replace with | Notes |
+| :-- | :| :--|
+|{your_tenant_name} | Your tenant short name | ΓÇ£yourtenantΓÇ¥ from yourtenant.onmicrosoft.com |
+|{your_tenantId} | Tenant ID of your Azure AD B2C tenant | 01234567-89ab-cdef-0123-456789abcdef |
+| {your_tenant_IdentityExperienceFramework_appid} | App ID of the IdentityExperienceFramework app configured in your Azure AD B2C tenant | 01234567-89ab-cdef-0123-456789abcdef |
+| {your_tenant_ ProxyIdentityExperienceFramework _appid} | App ID of the ProxyIdentityExperienceFramework app configured in your Azure AD B2C tenant | 01234567-89ab-cdef-0123-456789abcdef |
+| {your_tenant_extensions_appid} | App ID of your tenantΓÇÖs storage application | 01234567-89ab-cdef-0123-456789abcdef |
+| {your_tenant_extensions_app_objectid} | Object ID of your tenantΓÇÖs storage application | 01234567-89ab-cdef-0123-456789abcdef |
+| {your_app_insights_instrumentation_key} | Instrumentation key of your app insights instance* | 01234567-89ab-cdef-0123-456789abcdef |
+| {your_ui_base_url} | Endpoint in your app service from where your UI files are served | https://yourapp.azurewebsites.net/B2CUI/GetUIPage |
+| {your_app_service_url} | URL of your app service | https://yourapp.azurewebsites.net |
+| {your-facebook-app-id} | App ID of the facebook app you configured for federation with Azure AD B2C | 000000000000000 |
+| {your-facebook-app-secret} | Name of the policy key you've saved facebook's app secret as | B2C_1A_FacebookAppSecret |
+
+*App insights can be in a different tenant. This step is optional. Remove the corresponding TechnicalProfiles and OrechestrationSteps if not needed.
+
+### Call Microsoft DFP label API
+
+Customers need to [implement label API](/dynamics365/fraud-protection/integrate-ap-api). See [Microsoft DFP API](https://apidocs.microsoft.com/services/dynamics365fraudprotection#/AccountProtection/v1.0) to learn more.
+
+`URI: < API Endpoint >/v1.0/label/account/create/<userId>`
+
+The value of the userID needs to be the same as the one in the corresponding Azure AD B2C configuration value (ObjectID).
+
+>[!NOTE]
+>Add consent notification to the attribute collection page. Notify that the users' telemetry and user identity information will be recorded for account protection purposes.
+
+## Configure the Azure AD B2C policy
+
+1. Go to the [Azure AD B2C policy](https://github.com/azure-ad-b2c/partner-integrations/tree/master/samples/Dynamics-Fraud-Protection/Policies) in the Policies folder.
+
+2. Follow this [document](./custom-policy-get-started.md?tabs=applications#custom-policy-starter-pack) to download [LocalAccounts starter pack](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/tree/master/LocalAccounts)
+
+3. Configure the policy for the Azure AD B2C tenant.
+
+>[!NOTE]
+>Update the policies provided to relate to your specific tenant.
+
+## Test the user flow
+
+1. Open the Azure AD B2C tenant and under Policies select **Identity Experience Framework**.
+
+2. Select your previously created **SignUpSignIn**.
+
+3. Select **Run user flow** and select the settings:
+
+ a. **Application**: select the registered app (sample is JWT)
+
+ b. **Reply URL**: select the **redirect URL**
+
+ c. Select **Run user flow**.
+
+4. Go through sign-up flow and create an account
+
+5. Microsoft DFP service will be called during the flow, after user attribute is created. If the flow is incomplete, check that the user isn't saved in the directory.
+
+>[!NOTE]
+>Update rules directly in Microsoft DFP Portal if using [Microsoft DFP rule engine](/dynamics365/fraud-protection/rules).
+
+## Next steps
+
+For additional information, review the following articles:
+
+- [Microsoft DFP samples](https://github.com/Microsoft/Dynamics-365-Fraud-Protection-Samples)
+
+- [Custom policies in Azure AD B2C](./custom-policy-overview.md)
+
+- [Get started with custom policies in Azure AD B2C](./custom-policy-get-started.md?tabs=applications)
active-directory-b2c Partner Keyless https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/partner-keyless.md
To get started, you'll need:
- An Azure subscription. If you don't have a subscription, you can get a [free account](https://azure.microsoft.com/free/). -- An [Azure AD B2C tenant](https://docs.microsoft.com/azure/active-directory-b2c/tutorial-create-tenant). Tenant must be linked to your Azure subscription.
+- An [Azure AD B2C tenant](./tutorial-create-tenant.md). Tenant must be linked to your Azure subscription.
- A Keyless cloud tenant, get a free [trial account](https://keyless.io/go).
You should now see Keyless as a new OIDC Identity provider listed within your B2
For additional information, review the following articles: -- [Custom policies in Azure AD B2C](https://docs.microsoft.com/azure/active-directory-b2c/custom-policy-overview)
+- [Custom policies in Azure AD B2C](./custom-policy-overview.md)
-- [Get started with custom policies in Azure AD B2C](https://docs.microsoft.com/azure/active-directory-b2c/custom-policy-get-started?tabs=applications)
+- [Get started with custom policies in Azure AD B2C](./custom-policy-get-started.md?tabs=applications)
active-directory-b2c Partner Ping Identity https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/partner-ping-identity.md
To get started, you'll need:
- An Azure subscription. If you don't have one, get a [free account](https://azure.microsoft.com/free/). -- An [Azure AD B2C tenant](https://docs.microsoft.com/azure/active-directory-b2c/tutorial-create-tenant) that is linked to your Azure subscription.
+- An [Azure AD B2C tenant](./tutorial-create-tenant.md) that is linked to your Azure subscription.
- PingAccess and PingFederate deployed in Docker containers or directly on Azure VMs.
To follow this convention, update the Azure AD B2C issuer update using the polic
![image shows the token settings](./media/partner-ping/token-setting.png)
-In the advanced policies, this can be configured using the **IssuanceClaimPattern** metadata element to **AuthorityWithTfp** value in the [JWT token issuer technical profile](https://docs.microsoft.com/azure/active-directory-b2c/jwt-issuer-technical-profile).
+In the advanced policies, this can be configured using the **IssuanceClaimPattern** metadata element to **AuthorityWithTfp** value in the [JWT token issuer technical profile](./jwt-issuer-technical-profile.md).
## Configure PingAccess/PingFederate
Follow these steps to create a web session:
7. In the **Client Secret** field, enter the **Key** you generated for the application in Azure AD.
-8. Optional - You can create and use custom claims with the Microsoft Graph API. If you choose to do so, select **Advanced** and deselect the **Request Profile** and **Refresh User Attributes** options. For more information on using custom claims, see [use a custom claim](https://docs.microsoft.com/azure/active-directory/application-proxy-ping-access#optionaluse-a-custom-claim).
+8. Optional - You can create and use custom claims with the Microsoft Graph API. If you choose to do so, select **Advanced** and deselect the **Request Profile** and **Refresh User Attributes** options. For more information on using custom claims, see [use a custom claim](../active-directory/manage-apps/application-proxy-configure-single-sign-on-with-headers.md).
9. Select **Save**
Configure the PingFederate authentication policy to federate to the multiple IdP
For additional information, review the following articles -- [Custom policies in Azure AD B2C](https://docs.microsoft.com/azure/active-directory-b2c/custom-policy-overview)
+- [Custom policies in Azure AD B2C](./custom-policy-overview.md)
-- [Get started with custom policies in Azure AD B2C](https://docs.microsoft.com/azure/active-directory-b2c/custom-policy-get-started?tabs=applications)
+- [Get started with custom policies in Azure AD B2C](./custom-policy-get-started.md?tabs=applications)
active-directory-b2c Partner Zscaler https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/partner-zscaler.md
To configure custom policies on your Azure AD B2C tenant, see [Get started with
### Step 3: Register ZPA as a SAML application in Azure AD B2C
-To configure a SAML application in Azure AD B2C, see [Register a SAML application in Azure AD B2C](./connect-with-saml-service-providers.md).
+To configure a SAML application in Azure AD B2C, see [Register a SAML application in Azure AD B2C](./saml-service-provider.md).
-In step ["3.2 Upload and test your policy metadata"](./connect-with-saml-service-providers.md#32-upload-and-test-your-policy-metadata), copy or note the IdP SAML metadata URL that's used by Azure AD B2C. You'll need it later.
+In step ["Upload your policy"](./saml-service-provider.md#upload-your-policy), copy or note the IdP SAML metadata URL that's used by Azure AD B2C. You'll need it later.
-Follow the instructions through step ["4.2 Update the app manifest"](./connect-with-saml-service-providers.md#42-update-the-app-manifest). In step 4.2, update the app manifest properties as follows:
+Follow the instructions through step ["Configure your application in Azure AD B2C"](./saml-service-provider.md#configure-your-application-in-azure-ad-b2c). In step 4.2, update the app manifest properties as follows:
- For **identifierUris**: Use the Service Provider Entity ID that you copied or noted earlier in "Step 1.6.b". - For **samlMetadataUrl**: Skip this property, because ZPA doesn't host a SAML metadata URL.
Go to a ZPA user portal or a browser-access application, and test the sign-up or
For more information, review the following articles: - [Get started with custom policies in Azure AD B2C](./custom-policy-get-started.md)-- [Register a SAML application in Azure AD B2C](./connect-with-saml-service-providers.md)
+- [Register a SAML application in Azure AD B2C](./saml-service-provider.md)
- [Step-by-step configuration guide for ZPA](https://help.zscaler.com/zpa/step-step-configuration-guide-zpa) - [Configure an IdP for single sign-on](https://help.zscaler.com/zpa/configuring-idp-single-sign)
active-directory-b2c Phone Based Mfa https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/phone-based-mfa.md
Take the following actions to help mitigate fraudulent sign-ups.
- Use the **Recommended** versions of user flows to do the following: - [Enable the email one-time passcode feature (OTP)](phone-authentication-user-flows.md) for MFA (applies to both sign-up and sign-in flows).
- - [Configure a Conditional Access policy](conditional-access-identity-protection-setup.md) to block sign-ins based on location (applies to sign-in flows only, not sign-up flows).
+ - [Configure a Conditional Access policy](conditional-access-user-flow.md) to block sign-ins based on location (applies to sign-in flows only, not sign-up flows).
- Use API connectors to [integrate with an anti-bot solution like reCAPTCHA](https://github.com/Azure-Samples/active-directory-b2c-node-sign-up-user-flow-captcha) (applies to sign-up flows). - Remove country codes that aren't relevant to your organization from the drop-down menu where the user verifies their phone number (this change will apply to future sign-ups):
active-directory-b2c Relyingparty https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/relyingparty.md
Previously updated : 12/14/2020 Last updated : 03/04/2021
The **SingleSignOn** element contains in the following attribute:
| Attribute | Required | Description | | | -- | -- | | Scope | Yes | The scope of the single sign-on behavior. Possible values: `Suppressed`, `Tenant`, `Application`, or `Policy`. The `Suppressed` value indicates that the behavior is suppressed, and the user is always prompted for an identity provider selection. The `Tenant` value indicates that the behavior is applied to all policies in the tenant. For example, a user navigating through two policy journeys for a tenant is not prompted for an identity provider selection. The `Application` value indicates that the behavior is applied to all policies for the application making the request. For example, a user navigating through two policy journeys for an application is not prompted for an identity provider selection. The `Policy` value indicates that the behavior only applies to a policy. For example, a user navigating through two policy journeys for a trust framework is prompted for an identity provider selection when switching between policies. |
-| KeepAliveInDays | Yes | Controls how long the user remains signed in. Setting the value to 0 turns off KMSI functionality. For more information, see [Keep me signed in](session-behavior.md?pivots=b2c-custom-policy#enable-keep-me-signed-in-kmsi). |
+| KeepAliveInDays | No | Controls how long the user remains signed in. Setting the value to 0 turns off KMSI functionality. For more information, see [Keep me signed in](session-behavior.md?pivots=b2c-custom-policy#enable-keep-me-signed-in-kmsi). |
|EnforceIdTokenHintOnLogout| No| Force to pass a previously issued ID token to the logout endpoint as a hint about the end user's current authenticated session with the client. Possible values: `false` (default), or `true`. For more information, see [Web sign-in with OpenID Connect](openid-connect.md). |
The **Protocol** element contains the following attribute:
| | -- | -- | | Name | Yes | The name of a valid protocol supported by Azure AD B2C that is used as part of the technical profile. Possible values: `OpenIdConnect` or `SAML2`. The `OpenIdConnect` value represents the OpenID Connect 1.0 protocol standard as per OpenID foundation specification. The `SAML2` represents the SAML 2.0 protocol standard as per OASIS specification. |
-### Metadata
-
-When the protocol is `SAML`, a metadata element contains the following elements.
-
-| Attribute | Required | Description |
-| | -- | -- |
-| IdpInitiatedProfileEnabled | No | Indicates whether the IDP initiated flow is supported. Possible values: `true` or `false` (default). |
-| XmlSignatureAlgorithm | No | The method that Azure AD B2C uses to sign the SAML Response. Possible values: `Sha256`, `Sha384`, `Sha512`, or `Sha1`. Make sure you configure the signature algorithm on both sides with same value. Use only the algorithm that your certificate supports. To configure the SAML Assertion, see [SAML issuer technical profile metadata](saml-issuer-technical-profile.md#metadata). |
-| DataEncryptionMethod | No | Indicates the method that Azure AD B2C uses to encrypt the data, using Advanced Encryption Standard (AES) algorithm. The metadata controls the value of the `<EncryptedData>` element in the SAML response. Possible values: `Aes256` (default), `Aes192`, `Sha512`, or ` Aes128`. |
-| KeyEncryptionMethod| No | Indicates the method that Azure AD B2C uses to encrypt the copy of the key that was used to encrypt the data. The metadata controls the value of the `<EncryptedKey>` element in the SAML response. Possible values: ` Rsa15` (default) - RSA Public Key Cryptography Standard (PKCS) Version 1.5 algorithm, ` RsaOaep` - RSA Optimal Asymmetric Encryption Padding (OAEP) encryption algorithm. |
-| UseDetachedKeys | No | Possible values: `true`, or `false` (default). When the value is set to `true`, Azure AD B2C changes the format of the encrypted assertions. Using detached keys adds the encrypted assertion as a child of the EncrytedAssertion as opposed to the EncryptedData. |
-| WantsSignedResponses| No | Indicates whether Azure AD B2C signs the `Response` section of the SAML response. Possible values: `true` (default) or `false`. |
-| RemoveMillisecondsFromDateTime| No | Indicates whether the millisconds will be removed from datetime values within the SAML response (these include IssueInstant, NotBefore, NotOnOrAfter and AuthnInstant). Possible values: `false` (default) or `true`. |
- ### OutputClaims The **OutputClaims** element contains the following element:
active-directory-b2c Saml Issuer Technical Profile https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/saml-issuer-technical-profile.md
The **InputClaims**, **OutputClaims**, and **PersistClaims** elements are empty
| Attribute | Required | Description | | | -- | -- | | IssuerUri | No | The issuer name that appears in the SAML response. The value should be the same name as configured in the relying party application. |
-| XmlSignatureAlgorithm | No | The method that Azure AD B2C uses to sign the SAML Assertion. Possible values: `Sha256`, `Sha384`, `Sha512`, or `Sha1`. Make sure you configure the signature algorithm on both sides with same value. Use only the algorithm that your certificate supports. To configure the SAML Response, see [Relying party SAML metadata](relyingparty.md#metadata)|
+| XmlSignatureAlgorithm | No | The method that Azure AD B2C uses to sign the SAML Assertion. Possible values: `Sha256`, `Sha384`, `Sha512`, or `Sha1`. Make sure you configure the signature algorithm on both sides with same value. Use only the algorithm that your certificate supports. To configure the SAML Response, see [Options for registering a SAML application](saml-service-provider.md)|
|TokenNotBeforeSkewInSeconds| No| Specifies the skew, as an integer, for the time stamp that marks the beginning of the validity period. The higher this number is, the further back in time the validity period begins with respect to the time that the claims are issued for the relying party. For example, when the TokenNotBeforeSkewInSeconds is set to 60 seconds, if the token is issued at 13:05:10 UTC, the token is valid from 13:04:10 UTC. The default value is 0. The maximum value is 3600 (one hour). |
-|TokenLifeTimeInSeconds| No| Specifies the life of the SAML Assertion. This value is in seconds from the NotBefore value refernced above.The default value is 300 seconds (5 Min). |
+|TokenLifeTimeInSeconds| No| Specifies the life of the SAML Assertion. This value is in seconds from the NotBefore value referenced above.The default value is 300 seconds (5 Min). |
## Cryptographic keys
To configure the Azure AD B2C SAML sessions between a relying party application,
See the following article for example of using a SAML issuer technical profile: -- [Register a SAML application in Azure AD B2C](connect-with-saml-service-providers.md)
+- [Register a SAML application in Azure AD B2C](saml-service-provider.md)
active-directory-b2c Saml Service Provider Options https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/saml-service-provider-options.md
+
+ Title: Configure SAML service provider options
+title-suffix: Azure Active Directory B2C
+description: How to configure Azure Active Directory B2C SAML service provider options
+++++++ Last updated : 03/03/2021+++
+zone_pivot_groups: b2c-policy-type
++
+# Options for registering a SAML application in Azure AD B2C
+
+This article describes the configuration options that are available when connecting Azure Active Directory (Azure AD B2C) with your SAML application.
++++++
+## Encrypted SAML assertions
+
+When your application expects SAML assertions to be in an encrypted format, need to make sure that encryption is enabled in the Azure AD B2C policy.
+
+Azure AD B2C uses the service provider's public key certificate to encrypt the SAML assertion. The public key must exist in the SAML application's metadata endpoint with the KeyDescriptor 'use' set to 'Encryption', as shown in the following example:
+
+```xml
+<KeyDescriptor use="encryption">
+ <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
+ <X509Data>
+ <X509Certificate>valid certificate</X509Certificate>
+ </X509Data>
+ </KeyInfo>
+</KeyDescriptor>
+```
+
+To enable Azure AD B2C to send encrypted assertions, set the **WantsEncryptedAssertion** metadata item to `true` in the [relying party technical profile](relyingparty.md#technicalprofile). You can also configure the algorithm used to encrypt the SAML assertion.
+
+```xml
+<RelyingParty>
+ <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
+ <TechnicalProfile Id="PolicyProfile">
+ <DisplayName>PolicyProfile</DisplayName>
+ <Protocol Name="SAML2"/>
+ <Metadata>
+ <Item Key="WantsEncryptedAssertions">true</Item>
+ </Metadata>
+ ..
+ </TechnicalProfile>
+</RelyingParty>
+```
+
+## Identity provider-initiated flow
+
+When your application expects to receive a SAML assertion without first sending a SAML AuthN request to the identity provider, you must configure Azure AD B2C for identity provider-initiated flow.
+
+In identity provider-initiated flow, the sign-in process is initiated by the identity provider (Azure AD B2C), which sends an unsolicited SAML response to the service provider (your relying party application).
+
+We don't currently support scenarios where the initiating identity provider is an external identity provider federated with Azure AD B2C, for example [AD-FS](identity-provider-adfs.md), or [Salesforce](identity-provider-salesforce-saml.md). It is only supported for Azure AD B2C local account authentication.
+
+To enable identity provider-initiated flow, set the **IdpInitiatedProfileEnabled** metadata item to `true` in the [relying party technical profile](relyingparty.md#technicalprofile).
+
+```xml
+<RelyingParty>
+ <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
+ <TechnicalProfile Id="PolicyProfile">
+ <DisplayName>PolicyProfile</DisplayName>
+ <Protocol Name="SAML2"/>
+ <Metadata>
+ <Item Key="IdpInitiatedProfileEnabled">true</Item>
+ </Metadata>
+ ..
+ </TechnicalProfile>
+</RelyingParty>
+```
+
+To sign in or sign up a user through identity provider-initiated flow, use the following URL:
+
+```
+https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/generic/login?EntityId=app-identifier-uri
+```
+
+Replace the following values:
+
+* **tenant-name** with your tenant name
+* **policy-name** with your SAML relying party policy name
+* **app-identifier-uri** with the `identifierUris` in the metadata file, such as `https://contoso.onmicrosoft.com/app-name`
+
+### Sample policy
+
+We provide a complete sample policy that you can use for testing with the SAML test app.
+
+1. Download the [SAML-SP-initiated login sample policy](https://github.com/azure-ad-b2c/saml-sp/tree/master/policy/SAML-SP-Initiated).
+1. Update `TenantId` to match your tenant name, for example *contoso.b2clogin.com*.
+1. Keep the policy name *B2C_1A_signup_signin_saml*.
+
+## SAML response signature algorithm
+
+You can configure the signature algorithm used to sign the SAML assertion. Possible values are `Sha256`, `Sha384`, `Sha512`, or `Sha1`. Make sure the technical profile and application use the same signature algorithm. Use only the algorithm that your certificate supports.
+
+Configure the signature algorithm using the `XmlSignatureAlgorithm` metadata key within the RelyingParty metadata node.
+
+```xml
+<RelyingParty>
+ <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
+ <TechnicalProfile Id="PolicyProfile">
+ <DisplayName>PolicyProfile</DisplayName>
+ <Protocol Name="SAML2"/>
+ <Metadata>
+ <Item Key="XmlSignatureAlgorithm">Sha256</Item>
+ </Metadata>
+ ..
+ </TechnicalProfile>
+</RelyingParty>
+```
+
+## SAML response lifetime
+
+You can configure the length of time the SAML response remains valid. Set the lifetime using the `TokenLifeTimeInSeconds` metadata item within the SAML Token Issuer technical profile. This value is the number of seconds that can elapse from the `NotBefore` timestamp calculated at the token issuance time. Automatically, the time picked for this is your current time. The default lifetime is 300 seconds (5 minutes).
+
+```xml
+<ClaimsProvider>
+ <DisplayName>Token Issuer</DisplayName>
+ <TechnicalProfiles>
+ <TechnicalProfile Id="Saml2AssertionIssuer">
+ <DisplayName>Token Issuer</DisplayName>
+ <Protocol Name="SAML2"/>
+ <OutputTokenFormat>SAML2</OutputTokenFormat>
+ <Metadata>
+ <Item Key="TokenLifeTimeInSeconds">400</Item>
+ </Metadata>
+ ...
+ </TechnicalProfile>
+```
+
+## SAML response valid from skew
+
+You can configure the time skew applied to the SAML response `NotBefore` timestamp. This configuration ensures that if the times between two platforms aren't in sync, the SAML assertion will still be deemed valid when within this time skew.
+
+Set the time skew using the `TokenNotBeforeSkewInSeconds` metadata item within the SAML Token Issuer technical profile. The skew value is given in seconds, with a default value of 0. The maximum value is 3600 (one hour).
+
+For example, when the `TokenNotBeforeSkewInSeconds` is set to `120` seconds:
+
+- The token is issued at 13:05:10 UTC
+- The token is valid from 13:03:10 UTC
+
+```xml
+<ClaimsProvider>
+ <DisplayName>Token Issuer</DisplayName>
+ <TechnicalProfiles>
+ <TechnicalProfile Id="Saml2AssertionIssuer">
+ <DisplayName>Token Issuer</DisplayName>
+ <Protocol Name="SAML2"/>
+ <OutputTokenFormat>SAML2</OutputTokenFormat>
+ <Metadata>
+ <Item Key="TokenNotBeforeSkewInSeconds">120</Item>
+ </Metadata>
+ ...
+ </TechnicalProfile>
+```
+
+## Azure AD B2C issuer ID
+
+If you have multiple SAML applications that depend on different `entityID` values, you can override the `issueruri` value in your relying party file. To override the issuer URI, copy the technical profile with the "Saml2AssertionIssuer" ID from the base file and override the `issueruri` value.
+
+> [!TIP]
+> Copy the `<ClaimsProviders>` section from the base and preserve these elements within the claims provider: `<DisplayName>Token Issuer</DisplayName>`, `<TechnicalProfile Id="Saml2AssertionIssuer">`, and `<DisplayName>Token Issuer</DisplayName>`.
+
+Example:
+
+```xml
+ <ClaimsProviders>
+ <ClaimsProvider>
+ <DisplayName>Token Issuer</DisplayName>
+ <TechnicalProfiles>
+ <TechnicalProfile Id="Saml2AssertionIssuer">
+ <DisplayName>Token Issuer</DisplayName>
+ <Metadata>
+ <Item Key="IssuerUri">customURI</Item>
+ </Metadata>
+ </TechnicalProfile>
+ </TechnicalProfiles>
+ </ClaimsProvider>
+ </ClaimsProviders>
+ <RelyingParty>
+ <DefaultUserJourney ReferenceId="SignUpInSAML" />
+ <TechnicalProfile Id="PolicyProfile">
+ <DisplayName>PolicyProfile</DisplayName>
+ <Protocol Name="SAML2" />
+ <Metadata>
+ …
+```
+
+## Session management
+
+You can manage the session between Azure AD B2C and the SAML relying party application using the `UseTechnicalProfileForSessionManagement` element and the [SamlSSOSessionProvider](custom-policy-reference-sso.md#samlssosessionprovider).
+
+## Debug the SAML protocol
+
+To help configure and debug the integration with your service provider, you can use a browser extension for the SAML protocol, for example, [SAML DevTools extension](https://chrome.google.com/webstore/detail/saml-devtools-extension/jndllhgbinhiiddokbeoeepbppdnhhio) for Chrome, [SAML-tracer](https://addons.mozilla.org/es/firefox/addon/saml-tracer/) for FireFox, or [Edge or IE Developer tools](https://techcommunity.microsoft.com/t5/microsoft-sharepoint-blog/gathering-a-saml-token-using-edge-or-ie-developer-tools/ba-p/320957).
+
+Using these tools, you can check the integration between your application and Azure AD B2C. For example:
+
+* Check whether the SAML request contains a signature and determine what algorithm is used to sign in the authorization request.
+* Check if Azure AD B2C returns an error message.
+* Check it the assertion section is encrypted.
+
+## Next steps
+
+- Find more information about the [SAML protocol on the OASIS website](https://www.oasis-open.org/).
+- Get the SAML test web app from the [Azure AD B2C GitHub community repo](https://github.com/azure-ad-b2c/saml-sp-tester).
+
+<!-- LINKS - External -->
+[samltest]: https://aka.ms/samltestapp
+
active-directory-b2c Saml Service Provider https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/saml-service-provider.md
+
+ Title: Configure Azure Active Directory B2C as a SAML IdP to your applications
+title-suffix: Azure Active Directory B2C
+description: How to configure Azure Active Directory B2C to provide SAML protocol assertions to your applications (service providers). Azure AD B2C will act as the single identity provider (IdP) to your SAML application.
+++++++ Last updated : 03/03/2021+++
+zone_pivot_groups: b2c-policy-type
++
+# Register a SAML application in Azure AD B2C
+
+In this article, learn how to connect your Security Assertion Markup Language (SAML) applications (service providers) to Azure Active Directory B2C (Azure AD B2C) for authentication.
++++++
+## Overview
+
+Organizations that use Azure AD B2C as their customer identity and access management solution might require integration with applications that authenticate using the SAML protocol. The following diagram shows how Azure AD B2C serves as an *identity provider* (IdP) to achieve single-sign-on (SSO) with SAML-based applications.
+
+![Diagram with B2C as identity provider on left and B2C as service provider on right.](media/saml-service-provider/saml-service-provider-integration.png)
+
+1. The application creates a SAML AuthN Request that is sent to Azure AD B2C's SAML login endpoint.
+2. The user can use an Azure AD B2C local account or any other federated identity provider (if configured) to authenticate.
+3. If the user signs in using a federated identity provider, a token response is sent to Azure AD B2C.
+4. Azure AD B2C generates a SAML assertion and sends it to the application.
+
+## Prerequisites
+
+* Complete the steps in [Get started with custom policies in Azure AD B2C](custom-policy-get-started.md). You need the *SocialAndLocalAccounts* custom policy from the custom policy starter pack discussed in the article.
+* Basic understanding of the SAML protocol and familiarity with the application's SAML implementation.
+* A web application configured as a SAML application. For this tutorial, you can use a [SAML test application][samltest] that we provide.
+
+## Components
+
+There are three main components required for this scenario:
+
+* A SAML **application** with the ability to send SAML AuthN requests and receive, decode, and verify SAML responses from Azure AD B2C. The SAML application is also known as the relying party application or service provider.
+* The SAML application's publicly available SAML **metadata endpoint** or XML document.
+* An [Azure AD B2C tenant](tutorial-create-tenant.md)
+
+If you don't yet have a SAML application and an associated metadata endpoint, you can use this sample SAML application that we've made available for testing:
+
+[SAML Test Application][samltest]
+
+## Set up certificates
+
+To build a trust relationship between your application and Azure AD B2C, both services must be able to create and validate each other's signatures. You configure a configure X509 certificates in Azure AD B2C, and your application.
+
+**Application certificates**
+
+| Usage | Required | Description |
+| | -- | -- |
+| SAML request signing | No | A certificate with a private key stored in your web app, used by your application to sign SAML requests sent to Azure AD B2C. The web app must expose the public key through its SAML metadata endpoint. Azure AD B2C validates the SAML request signature by using the public key from the application metadata.|
+| SAML assertion encryption | No | A certificate with a private key stored in your web app. The web app must expose the public key through its SAML metadata endpoint. Azure AD B2C can encrypt assertions to your application using the public key. The application uses the private key to decrypt the assertion.|
+
+**Azure AD B2C certificates**
+
+| Usage | Required | Description |
+| | -- | -- |
+| SAML response signing | Yes | A certificate with a private key stored in Azure AD B2C. This certificate is used by Azure AD B2C to sign the SAML response sent to your application. Your application reads the Azure AD B2C metadata public key to validate the signature of the SAML response. |
+
+In a production environment, we recommend using certificates issued by a public certificate authority. However, you can also complete this procedure with self-signed certificates.
+
+### Prepare a self-signed certificate for SAML response signing
+
+You must create a SAML response signing certificate so that your application can trust the assertion from Azure AD B2C.
++
+## Enable your policy to connect with a SAML application
+
+To connect to your SAML application, Azure AD B2C must be able to create SAML responses.
+
+Open `SocialAndLocalAccounts\`**`TrustFrameworkExtensions.xml`** in the custom policy starter pack.
+
+Locate the `<ClaimsProviders>` section and add the following XML snippet to implement your SAML response generator.
+
+```xml
+<ClaimsProvider>
+ <DisplayName>Token Issuer</DisplayName>
+ <TechnicalProfiles>
+
+ <!-- SAML Token Issuer technical profile -->
+ <TechnicalProfile Id="Saml2AssertionIssuer">
+ <DisplayName>Token Issuer</DisplayName>
+ <Protocol Name="SAML2"/>
+ <OutputTokenFormat>SAML2</OutputTokenFormat>
+ <Metadata>
+ <Item Key="IssuerUri">https://issuerUriMyAppExpects</Item>
+ </Metadata>
+ <CryptographicKeys>
+ <Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
+ </CryptographicKeys>
+ <InputClaims/>
+ <OutputClaims/>
+ <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer"/>
+ </TechnicalProfile>
+
+ <!-- Session management technical profile for SAML based tokens -->
+ <TechnicalProfile Id="SM-Saml-issuer">
+ <DisplayName>Session Management Provider</DisplayName>
+ <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
+ </TechnicalProfile>
+
+ </TechnicalProfiles>
+</ClaimsProvider>
+```
+
+#### Configure the IssuerUri of the SAML response
+
+You can change the value of the `IssuerUri` metadata item in the SAML token issuer technical profile. This change will be reflected in the `issuerUri` attribute returned in the SAML response from Azure AD B2C. Your application should be configured to accept the same `issuerUri` during SAML response validation.
+
+```xml
+<ClaimsProvider>
+ <DisplayName>Token Issuer</DisplayName>
+ <TechnicalProfiles>
+ <!-- SAML Token Issuer technical profile -->
+ <TechnicalProfile Id="Saml2AssertionIssuer">
+ <DisplayName>Token Issuer</DisplayName>
+ <Protocol Name="SAML2"/>
+ <OutputTokenFormat>SAML2</OutputTokenFormat>
+ <Metadata>
+ <Item Key="IssuerUri">https://issuerUriMyAppExpects</Item>
+ </Metadata>
+ ...
+ </TechnicalProfile>
+```
+
+#### Sign the Azure AD B2C IdP SAML Metadata (optional)
+
+You can instruct Azure AD B2C to sign its SAML IdP metadata document, if required by the application. To do so, generate and upload a SAML IdP metadata signing policy key as shown in [Prepare a self-signed certificate for SAML response signing](#prepare-a-self-signed-certificate-for-saml-response-signing). Then configure the `MetadataSigning` metadata item in the SAML token issuer technical profile. The `StorageReferenceId` must reference the policy key name.
+
+```xml
+<ClaimsProvider>
+ <DisplayName>Token Issuer</DisplayName>
+ <TechnicalProfiles>
+ <!-- SAML Token Issuer technical profile -->
+ <TechnicalProfile Id="Saml2AssertionIssuer">
+ <DisplayName>Token Issuer</DisplayName>
+ <Protocol Name="SAML2"/>
+ <OutputTokenFormat>SAML2</OutputTokenFormat>
+ ...
+ <CryptographicKeys>
+ <Key Id="MetadataSigning" StorageReferenceId="B2C_1A_SamlMetadataCert"/>
+ ...
+ </CryptographicKeys>
+ ...
+ </TechnicalProfile>
+```
+
+#### Sign the Azure AD B2C IdP SAML response element (optional)
+
+You can specify a certificate to be used to sign the SAML messages. The message is the `<samlp:Response>` element within the SAML response sent to the application.
+
+To specify a certificate, generate and upload a policy key as shown in [Prepare a self-signed certificate for SAML response signing](#prepare-a-self-signed-certificate-for-saml-response-signing). Then configure the `SamlMessageSigning` Metadata item in the SAML Token Issuer technical profile. The `StorageReferenceId` must reference the Policy Key name.
+
+```xml
+<ClaimsProvider>
+ <DisplayName>Token Issuer</DisplayName>
+ <TechnicalProfiles>
+ <!-- SAML Token Issuer technical profile -->
+ <TechnicalProfile Id="Saml2AssertionIssuer">
+ <DisplayName>Token Issuer</DisplayName>
+ <Protocol Name="SAML2"/>
+ <OutputTokenFormat>SAML2</OutputTokenFormat>
+ ...
+ <CryptographicKeys>
+ <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SamlMessageCert"/>
+ ...
+ </CryptographicKeys>
+ ...
+ </TechnicalProfile>
+```
+## Configure your policy to issue a SAML Response
+
+Now that your policy can create SAML responses, you must configure the policy to issue a SAML response instead of the default JWT response to your application.
+
+### Create a sign-up or sign-in policy configured for SAML
+
+1. Create a copy of the *SignUpOrSignin.xml* file in your starter pack working directory and save it with a new name. For example, *SignUpOrSigninSAML.xml*. This file is your relying party policy file, and it is configured to issue a JWT response by default.
+
+1. Open the *SignUpOrSigninSAML.xml* file in your preferred editor.
+
+1. Change the `PolicyId` and `PublicPolicyUri` of the policy to _B2C_1A_signup_signin_saml_ and `http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml` as seen below.
+
+ ```xml
+ <TrustFrameworkPolicy
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+ xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
+ PolicySchemaVersion="0.3.0.0"
+ TenantId="tenant-name.onmicrosoft.com"
+ PolicyId="B2C_1A_signup_signin_saml"
+ PublicPolicyUri="http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml">
+ ```
+
+1. At the end of the User Journey, Azure AD B2C contains a `SendClaims` step. This step references the Token Issuer Technical Profile. To issue a SAML response rather than the default JWT response, modify the `SendClaims` step to reference the new SAML Token issuer technical profile, `Saml2AssertionIssuer`.
+
+Add the following XML snippet just before the `<RelyingParty>` element. This XML overwrites orchestration step number 7 in the _SignUpOrSignIn_ user journey. If you started from a different folder in the starter pack or you customized the user journey by adding or removing orchestration steps, make sure the number in the `order` element corresponds to the number specified in the user journey for the token issuer step. For example, in the other starter pack folders, the corresponding step number is 4 for `LocalAccounts`, 6 for `SocialAccounts` and 9 for `SocialAndLocalAccountsWithMfa`).
+
+```xml
+<UserJourneys>
+ <UserJourney Id="SignUpOrSignIn">
+ <OrchestrationSteps>
+ <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="Saml2AssertionIssuer"/>
+ </OrchestrationSteps>
+ </UserJourney>
+</UserJourneys>
+```
+
+The relying party element determines which protocol your application uses. The default is `OpenId`. The `Protocol` element must be changed to `SAML`. The Output Claims will create the claims mapping to the SAML assertion.
+
+Replace the entire `<TechnicalProfile>` element in the `<RelyingParty>` element with the following technical profile XML. Update `tenant-name` with the name of your Azure AD B2C tenant.
+
+```xml
+ <TechnicalProfile Id="PolicyProfile">
+ <DisplayName>PolicyProfile</DisplayName>
+ <Protocol Name="SAML2"/>
+ <OutputClaims>
+ <OutputClaim ClaimTypeReferenceId="displayName" />
+ <OutputClaim ClaimTypeReferenceId="givenName" />
+ <OutputClaim ClaimTypeReferenceId="surname" />
+ <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
+ <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
+ <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
+ </OutputClaims>
+ <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
+ </TechnicalProfile>
+```
+
+Your final relying party policy file should look like the following XML code:
+
+```xml
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<TrustFrameworkPolicy
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+ xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
+ PolicySchemaVersion="0.3.0.0"
+ TenantId="contoso.onmicrosoft.com"
+ PolicyId="B2C_1A_signup_signin_saml"
+ PublicPolicyUri="http://contoso.onmicrosoft.com/B2C_1A_signup_signin_saml">
+
+ <BasePolicy>
+ <TenantId>contoso.onmicrosoft.com</TenantId>
+ <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
+ </BasePolicy>
+
+ <UserJourneys>
+ <UserJourney Id="SignUpOrSignIn">
+ <OrchestrationSteps>
+ <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="Saml2AssertionIssuer"/>
+ </OrchestrationSteps>
+ </UserJourney>
+ </UserJourneys>
+
+ <RelyingParty>
+ <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
+ <TechnicalProfile Id="PolicyProfile">
+ <DisplayName>PolicyProfile</DisplayName>
+ <Protocol Name="SAML2"/>
+ <OutputClaims>
+ <OutputClaim ClaimTypeReferenceId="displayName" />
+ <OutputClaim ClaimTypeReferenceId="givenName" />
+ <OutputClaim ClaimTypeReferenceId="surname" />
+ <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
+ <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
+ <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
+ </OutputClaims>
+ <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
+ </TechnicalProfile>
+ </RelyingParty>
+</TrustFrameworkPolicy>
+```
+
+> [!NOTE]
+> You can follow this same process to implement other types of user flows (for example sign-in, password reset, or profile editing flows).
+
+### Upload your policy
+
+Save your changes and upload the new **TrustFrameworkExtensions.xml** and **SignUpOrSigninSAML.xml** policy files to the Azure portal.
+
+### Test the Azure AD B2C IdP SAML Metadata
+
+After the policy files are uploaded, Azure AD B2C uses the configuration information to generate the identity providerΓÇÖs SAML metadata document to be used by the application. The SAML metadata document contains the locations of services, such as sign-in and logout methods, certificates, and so on.
+
+The Azure AD B2C policy metadata is available at the following URL:
+
+`https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/samlp/metadata`
+
+Replace `<tenant-name>` with the name of your Azure AD B2C tenant and `<policy-name>` with the name (ID) of the policy, for example:
+
+`https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata`
+
+## Register your SAML application in Azure AD B2C
+
+For Azure AD B2C to trust your application, you create an Azure AD B2C application registration, which contains configuration information such as the application's metadata endpoint.
+
+1. Sign in to the [Azure portal](https://portal.azure.com).
+1. Select the **Directory + subscription** filter in the top menu, and then select the directory that contains your Azure AD B2C tenant.
+1. In the left menu, select **Azure AD B2C**. Or, select **All services** and search for and select **Azure AD B2C**.
+1. Select **App registrations**, and then select **New registration**.
+1. Enter a **Name** for the application. For example, *SAMLApp1*.
+1. Under **Supported account types**, select **Accounts in this organizational directory only**.
+1. Under **Redirect URI**, select **Web**, and then enter `https://localhost`. You'll modify this value later in the application registration's manifest.
+1. Select **Register**.
+
+### Configure your application in Azure AD B2C
+
+For SAML apps, you'll need to configure several properties in the application registration's manifest.
+
+1. In the [Azure portal](https://portal.azure.com), navigate to the application registration that you created in the previous section.
+1. Under **Manage**, select **Manifest** to open the manifest editor, and then modify the properties described in the following sections.
+
+#### Add the identifier
+
+When your SAML application makes a request to Azure AD B2C, the SAML AuthN request includes an `Issuer` attribute, which is typically the same value as the application's metadata `entityID`. Azure AD B2C uses this value to look up the application registration in the directory and read the configuration. For this lookup to succeed, the `identifierUri` in the application registration must be populated with a value that matches the `Issuer` attribute.
+
+In the registration manifest, locate the `identifierURIs` parameter and add the appropriate value. This value will be same value that is configured in the SAML AuthN requests for EntityId at the application, and the `entityID` value in the application's metadata.
+
+The following example shows the `entityID` in the SAML metadata:
+
+```xml
+<EntityDescriptor ID="id123456789" entityID="https://samltestapp2.azurewebsites.net" validUntil="2099-12-31T23:59:59Z" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
+```
+
+The `identifierUris` property will only accept URLs on the domain `tenant-name.onmicrosoft.com`.
+
+```json
+"identifierUris":"https://samltestapp2.azurewebsites.net",
+```
+
+#### Share the application's metadata with Azure AD B2C
+
+After the application registration has been loaded by its `identifierUri`, Azure AD B2C uses the application's metadata to validate the SAML AuthN request and determine how to respond.
+
+It's recommended that your application exposes a publicly accessible metadata endpoint.
+
+If there are properties specified in *both* the SAML metadata URL and the application registration's manifest, they are *merged*. The properties specified in the metadata URL are processed first and take precedence.
+
+Using the SAML test application as an example, you'd use the following value for `samlMetadataUrl` in the application manifest:
+
+```json
+"samlMetadataUrl":"https://samltestapp2.azurewebsites.net/Metadata",
+```
+
+#### Override or set the assertion consumer URL (optional)
+
+You can configure the reply URL to which Azure AD B2C sends SAML responses. Reply URLs can be configured within the application manifest. This configuration is useful when your application doesn't expose a publicly accessible metadata endpoint.
+
+The reply URL for a SAML application is the endpoint at which the application expects to receive SAML responses. The application usually provides this URL in the metadata document under the `AssertionConsumerServiceUrl` attribute, as shown below:
+
+```xml
+<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
+ ...
+ <AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://samltestapp2.azurewebsites.net/SP/AssertionConsumer" />
+</SPSSODescriptor>
+```
+
+If you want to override the metadata provided in the `AssertionConsumerServiceUrl` attribute or the URL isn't present in the metadata document, you can configure the URL in the manifest under the `replyUrlsWithType` property. The `BindingType` will be set to `HTTP POST`.
+
+Using the SAML test application as an example, you'd set the `url` property of `replyUrlsWithType` to the value shown in the following JSON snippet.
+
+```json
+"replyUrlsWithType":[
+ {
+ "url":"https://samltestapp2.azurewebsites.net/SP/AssertionConsumer",
+ "type":"Web"
+ }
+],
+```
+
+#### Override or set the logout URL (optional)
+
+You can configure the logout URL to which Azure AD B2C will send the user after a logout request. Reply URLs can be configured within the Application Manifest.
+
+If you want to override the metadata provided in the `SingleLogoutService` attribute or the URL isn't present in the metadata document, you can configure it in the manifest under the `Logout` property. The `BindingType` will be set to `Http-Redirect`.
+
+The application usually provides this URL in the metadata document under the `AssertionConsumerServiceUrl` attribute, as shown below:
+
+```xml
+<IDPSSODescriptor WantAuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
+ <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://samltestapp2.azurewebsites.net/logout" ResponseLocation="https://samltestapp2.azurewebsites.net/logout" />
+
+</IDPSSODescriptor>
+```
+
+Using the SAML test application as an example, you'd, leave `logoutUrl` set to `https://samltestapp2.azurewebsites.net/logout`:
+
+```json
+"logoutUrl": "https://samltestapp2.azurewebsites.net/logout",
+```
+
+> [!NOTE]
+> If you choose to configure the reply URL and logout URL in the application manifest without populating the application's metadata endpoint via the `samlMetadataUrl` property, Azure AD B2C will not validate the SAML request signature, nor will it encrypt the SAML response.
+
+## Configure Azure AD B2C as a SAML IdP in your SAML application
+
+The last step is to enable Azure AD B2C as a SAML IdP in your SAML application. Each application is different and the steps vary. Consult your app's documentation for details.
+
+The metadata can be configured in your application as *static metadata* or *dynamic metadata*. In static mode, copy all or part of the metadata from the Azure AD B2C policy metadata. In dynamic mode, provide the URL to the metadata and to allow your application to read the metadata dynamically.
+
+Some or all the following are typically required:
+
+* **Metadata**: Use the format `https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/Samlp/metadata`.
+* **Issuer**: The SAML request `issuer` value must match one of the URIs configured in the `identifierUris` element of the application registration manifest. If the SAML request `issuer` name doesn't exist in the `identifierUris` element, [add it to the application registration manifest](#add-the-identifier). For example, `https://contoso.onmicrosoft.com/app-name`.
+* **Login Url/SAML endpoint/SAML Url**: Check the value in the Azure AD B2C SAML policy metadata file for the `<SingleSignOnService>` XML element.
+* **Certificate**: This certificate is *B2C_1A_SamlIdpCert*, but without the private key. To get the public key of the certificate:
+
+ 1. Go to the metadata URL specified above.
+ 1. Copy the value in the `<X509Certificate>` element.
+ 1. Paste it into a text file.
+ 1. Save the text file as a *.cer* file.
+
+### Test with the SAML test app
+
+You can use our [SAML Test Application][samltest] to test your configuration:
+
+* Update the tenant name.
+* Update the policy name, for example *B2C_1A_signup_signin_saml*.
+* Specify this issuer URI. Use one of the URIs found in the `identifierUris` element in the application registration manifest, for example `https://contoso.onmicrosoft.com/app-name`.
+
+Select **Login** and you should be presented with a user sign-in screen. Upon sign-in, a SAML response is issued back to the sample application.
+
+## Supported and unsupported SAML modalities
+
+The following SAML application scenarios are supported via your own metadata endpoint:
+
+* Multiple logout URLs or POST binding for logout URL in the application/service principal object.
+* Specify a signing key to verify relying party (RP) requests in the application/service principal object.
+* Specify a token encryption key in the application/service principal object.
+* Identity provider-initiated sign-on, where the identity provider is Azure AD B2C.
+
+## Next steps
+
+- Get the SAML test web app from [Azure AD B2C GitHub community repo](https://github.com/azure-ad-b2c/saml-sp-tester).
+- See the [options for registering a SAML application in Azure AD B2C](saml-service-provider-options.md)
+
+<!-- LINKS - External -->
+[samltest]: https://aka.ms/samltestapp
+
active-directory-b2c Session Behavior https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/session-behavior.md
Previously updated : 12/14/2020 Last updated : 03/04/2021
The application session can be a cookie-based session stored under the applicati
You can configure the Azure AD B2C session behavior, including: -- **Web app session lifetime (minutes)** - The amount of time the Azure AD B2C session cookie is stored on the user's browser after successful authentication. You can set the session life time to a value from 15 to 720 minutes.
+- **Web app session lifetime (minutes)** - The amount of time the Azure AD B2C session cookie is stored on the user's browser after successful authentication. You can set the session lifetime up to 24 hours.
-- **Web app session timeout** - Indicates how a session is extended by the session life time setting or the keep me signed-in setting.
+- **Web app session timeout** - Indicates how a session is extended by the session lifetime setting or the Keep me signed in (KMSI) setting.
- **Rolling** - Indicates that the session is extended every time the user performs a cookie-based authentication (default). - **Absolute** - Indicates that the user is forced to re-authenticate after the time period specified.
You can configure the Azure AD B2C session behavior, including:
- **Application** - This setting allows you to maintain a user session exclusively for an application, independent of other applications. For example, you can use this setting if you want the user to sign in to Contoso Pharmacy regardless of whether the user is already signed into Contoso Groceries. - **Policy** - This setting allows you to maintain a user session exclusively for a user flow, independent of the applications using it. For example, if the user has already signed in and completed a multi-factor authentication (MFA) step, the user can be given access to higher-security parts of multiple applications, as long as the session tied to the user flow doesn't expire. - **Disabled** - This setting forces the user to run through the entire user flow upon every execution of the policy.-- **Keep me signed-in** - extends the session life time through the use of a persistent cookie. The session remains active after the user closes and reopens the browser. The session is revoked only when a user signs out. The Keep me signed-in feature only applies to sign-in with local accounts. The Keep me signed-in feature takes precedence over the session life time. If the Keep me signed-in feature is enabled and the user selects it, this feature dictates when the session will expire.
+- **Keep me signed in (KMSI)** - Extends the session lifetime through the use of a persistent cookie. If this feature is enabled and the user selects it, the session remains active even after the user closes and reopens the browser. The session is revoked only when the user signs out. The KMSI feature only applies to sign-in with local accounts. The KMSI feature takes precedence over the session lifetime.
::: zone pivot="b2c-user-flow"
To change your session behavior and SSO configurations, you add a **UserJourneyB
<SessionExpiryInSeconds>86400</SessionExpiryInSeconds> </UserJourneyBehaviors> ``` ## Enable Keep me signed in (KMSI)
-You can enable Keep Me Signed In functionality for users of your web and native applications that have local accounts in your Azure Active Directory B2C (Azure AD B2C) directory. This feature grants access to users returning to your application without prompting them to reenter their username and password. This access is revoked when a user signs out.
+You can enable the KMSI feature for users of your web and native applications who have local accounts in your Azure AD B2C directory. When you enable the feature, users can opt to stay signed in so the session remains active after they close the browser. Then they can reopen the browser without being prompted to reenter their username and password. This access is revoked when a user signs out.
![Example sign-up sign-in page showing a Keep me signed in checkbox](./media/session-behavior/keep-me-signed-in.png) ++
+KMSI is configurable at the individual user flow level. Before enabling KMSI for your user flows, consider the following:
+
+- KMSI is supported only for the **Recommended** versions of sign-up and sign-in (SUSI), sign-in, and profile editing user flows. If you currently have **Standard** or **Legacy preview - v2** versions of these user flows and want to enable KMSI, you'll need to create new, **Recommended** versions of these user flows.
+- KMSI is not supported with password reset or sign-up user flows.
+- If you want to enable KMSI for all applications in your tenant, we recommend that you enable KMSI for all user flows in your tenant. Because a user can be presented with multiple policies during a session, it's possible they could encounter one that doesn't have KMSI enabled, which would remove the KMSI cookie from the session.
+- KMSI should not be enabled on public computers.
+
+### Configure KMSI for a user flow
+
+To enable KMSI for your user flow:
+
+1. Sign in to the [Azure portal](https://portal.azure.com).
+2. Make sure you're using the directory that contains your Azure AD B2C tenant. Select the **Directory + subscription** filter in the top menu and choose the directory that contains your Azure AD B2C tenant.
+3. Choose **All services** in the top-left corner of the Azure portal, and then search for and select **Azure AD B2C**.
+4. SelectΓÇ»**User flows (policies)**.
+5. Open the user flow that you previously created.
+6. SelectΓÇ»**Properties**.
+
+7. UnderΓÇ»**Session behavior**, select **Enable keep me signed in session**. Next to **Keep me signed in session (days)**, enter a value from 1 to 90 to specify the number of days a session can remain open.
++
+ ![Enable keep me signed in session](media/session-behavior/enable-keep-me-signed-in.png)
+++ Users should not enable this option on public computers. ### Configure the page identifier
To add the KMSI checkbox to the sign-up and sign-in page, set the `setting.enabl
### Configure a relying party file
-Update the relying party (RP) file that initiates the user journey that you created.
+Update the relying party (RP) file that initiates the user journey that you created. The keepAliveInDays parameter allows you to configure how the long the keep me signed in (KMSI) session cookie should persist. For example, if you set the value to 30, then KMSI session cookie will persist for 30 days. The range for the value is from 1 to 90 days.
1. Open your custom policy file. For example, *SignUpOrSignin.xml*. 1. If it doesn't already exist, add a `<UserJourneyBehaviors>` child node to the `<RelyingParty>` node. It must be located immediately after `<DefaultUserJourney ReferenceId="User journey Id" />`, for example: `<DefaultUserJourney ReferenceId="SignUpOrSignIn" />`.
Upon a sign-out request, Azure AD B2C:
3. Attempts to sign out from federated identity providers: - OpenId Connect - If the identity provider well-known configuration endpoint specifies an `end_session_endpoint` location. - OAuth2 - If the [identity provider metadata](oauth2-technical-profile.md#metadata) contains the `end_session_endpoint` location.
- - SAML - If the [identity provider metadata](saml-identity-provider-technical-profile.md#metadata) contains the `SingleLogoutService` location.
+ - SAML - If the [identity provider metadata](identity-provider-generic-saml.md) contains the `SingleLogoutService` location.
4. Optionally, signs-out from other applications. For more information, see the [Single sign-out](#single-sign-out) section. > [!NOTE]
active-directory-b2c String Transformations https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/string-transformations.md
Previously updated : 11/03/2020 Last updated : 03/04/2021
Use this claims transformation to set a string ClaimType value.
- Output claims: - **createdClaim**: The TOS ClaimType contains the "Contoso terms of service..." value.
+## CopyClaimIfPredicateMatch
+
+Copy value of a claim to another if the value of the input claim matches the output claim predicate.
+
+| Item | TransformationClaimType | Data Type | Notes |
+| - | -- | | -- |
+| InputClaim | inputClaim | string | The claim type, which is to be copied. |
+| OutputClaim | outputClaim | string | The claim type that is produced after this claims transformation has been invoked. The value of the input claim is checked against this claim predicate. |
+
+The following example copies the signInName claim value to phoneNumber claim, only if the signInName is a phone number. For the complete sample, see [Phone number or email sign-in](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/blob/master/scenarios/phone-number-passwordless/Phone_Email_Base.xml) starter pack policy.
+
+```xml
+<ClaimsTransformation Id="SetPhoneNumberIfPredicateMatch" TransformationMethod="CopyClaimIfPredicateMatch">
+ <InputClaims>
+ <InputClaim ClaimTypeReferenceId="signInName" TransformationClaimType="inputClaim" />
+ </InputClaims>
+ <OutputClaims>
+ <OutputClaim ClaimTypeReferenceId="phoneNumber" TransformationClaimType="outputClaim" />
+ </OutputClaims>
+</ClaimsTransformation>
+```
+
+### Example 1
+
+- Input claims:
+ - **inputClaim**: bob@contoso.com
+- Output claims:
+ - **outputClaim**: The output claim won't be changed from its original value.
+
+### Example 2
+
+- Input claims:
+ - **inputClaim**: +11234567890
+- Output claims:
+ - **outputClaim**: +11234567890
+ ## CompareClaims Determine whether one string claim is equal to another. The result is a new boolean ClaimType with a value of `true` or `false`.
The claims transformation looks up the text of the item and returns its value. I
<InputClaim ClaimTypeReferenceId="responseCode" TransformationClaimType="mapFromClaim" /> </InputClaims> <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="responseMsg" TransformationClaimType="restrictionValueClaim" />        
+ <OutputClaim ClaimTypeReferenceId="responseMsg" TransformationClaimType="restrictionValueClaim" />
</OutputClaims> </ClaimsTransformation> ```
active-directory-b2c Stringcollection Transformations https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/stringcollection-transformations.md
Previously updated : 04/21/2020 Last updated : 03/04/2021
Adds a string claim to a new unique values stringCollection claim.
| Item | TransformationClaimType | Data Type | Notes | | - | -- | | -- | | InputClaim | item | string | The ClaimType to be added to the output claim. |
-| InputClaim | collection | stringCollection | [Optional] If specified, the claims transformation copies the items from this collection, and adds the item to the end of the output collection claim. |
+| InputClaim | collection | stringCollection | The string collection to be added to the output claim. If the collection contains items, the claims transformation copies the items, and adds the item to the end of the output collection claim. |
| OutputClaim | collection | stringCollection | The ClaimType that is produced after this claims transformation has been invoked, with the value specified in the input claim. | Use this claims transformation to add a string to a new or existing stringCollection. It's commonly used in a **AAD-UserWriteUsingAlternativeSecurityId** technical profile. Before a new social account is created, **CreateOtherMailsFromEmail** claims transformation reads the ClaimType and adds the value to the **otherMails** ClaimType.
Adds a string parameter to a new unique values stringCollection claim.
| Item | TransformationClaimType | Data Type | Notes | | - | -- | | -- |
-| InputClaim | collection | stringCollection | [Optional] If specified, the claims transformation copies the items from this collection, and adds the item to the end of the output collection claim. |
+| InputClaim | collection | stringCollection | The string collection to be added to the output claim. If the collection contains items, the claims transformation copies the items, and adds the item to the end of the output collection claim. |
| InputParameter | item | string | The value to be added to the output claim. | | OutputClaim | collection | stringCollection | The ClaimType that is produced after this claims transformation has been invoked, with the value specified in the input parameter. |
The following example reads the **otherMails** claim and return the first item i
## StringCollectionContains
-Checks if a StringCollection claim type contains an element
+Checks if a StringCollection claim type contains an element.
| Item | TransformationClaimType | Data Type | Notes | | - | -- | | -- |
active-directory-b2c Technical Overview https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/technical-overview.md
Learn more about custom policies in [Custom policies in Azure Active Directory B
## Protocols and tokens -- For applications, Azure AD B2C supports the [OAuth 2.0](protocols-overview.md), [OpenID Connect](openid-connect.md), and [SAML protocols](connect-with-saml-service-providers.md) for user journeys. Your application starts the user journey by issuing authentication requests to Azure AD B2C. The result of a request to Azure AD B2C is a security token, such as an [ID token, access token](tokens-overview.md), or SAML token. This security token defines the user's identity within the application.
+- For applications, Azure AD B2C supports the [OAuth 2.0](protocols-overview.md), [OpenID Connect](openid-connect.md), and [SAML protocols](saml-service-provider.md) for user journeys. Your application starts the user journey by issuing authentication requests to Azure AD B2C. The result of a request to Azure AD B2C is a security token, such as an [ID token, access token](tokens-overview.md), or SAML token. This security token defines the user's identity within the application.
- For external identities, Azure AD B2C supports federation with any OAuth 1.0, OAuth 2.0, OpenID Connect, and SAML identity providers.
active-directory-b2c Technicalprofiles https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/technicalprofiles.md
Previously updated : 12/11/2020 Last updated : 03/04/2021
A technical profile enables these types of scenarios:
- [OpenID Connect](openid-connect-technical-profile.md) - Federation with any OpenID Connect protocol identity provider. - [Phone factor](phone-factor-technical-profile.md) - Support for enrolling and verifying phone numbers. - [RESTful provider](restful-technical-profile.md) - Call to REST API services, such as validate user input, enrich user data, or integrate with line-of-business applications.-- [SAML identity provider](saml-identity-provider-technical-profile.md) - Federation with any SAML protocol identity provider.-- [SAML token issuer](saml-issuer-technical-profile.md) - Emits a SAML token that is returned back to the relying party application.
+- [SAML identity provider](identity-provider-generic-saml.md) - Federation with any SAML protocol identity provider.
+- [SAML token issuer](saml-service-provider.md) - Emits a SAML token that is returned back to the relying party application.
- [Self-Asserted](self-asserted-technical-profile.md) - Interact with the user. For example, collect the user's credential to sign in, render the sign-up page, or password reset. - [Session management](custom-policy-reference-sso.md) - Handle different types of sessions.
The following example illustrates the use of metadata relevant to [REST API tech
To establish trust with the services it integrates with, Azure AD B2C stores secrets and certificates in the form of [policy keys](policy-keys-overview.md). During the technical profile executing, Azure AD B2C retrieves the cryptographic keys from Azure AD B2C policy keys. Then uses the keys establish trust, encrypt or sign a token. These trusts consist of: -- Federation with [OAuth1](oauth1-technical-profile.md#cryptographic-keys), [OAuth2](oauth2-technical-profile.md#cryptographic-keys), and [SAML](saml-identity-provider-technical-profile.md#cryptographic-keys) identity providers
+- Federation with [OAuth1](oauth1-technical-profile.md#cryptographic-keys), [OAuth2](oauth2-technical-profile.md#cryptographic-keys), and [SAML](identity-provider-generic-saml.md) identity providers
- Secure the connecting with [REST API services](secure-rest-api.md)-- Signing and encryption the [JWT](jwt-issuer-technical-profile.md#cryptographic-keys) and [SAML](saml-issuer-technical-profile.md#cryptographic-keys) tokens
+- Signing and encryption the [JWT](jwt-issuer-technical-profile.md#cryptographic-keys) and [SAML](saml-service-provider.md) tokens
The **CryptographicKeys** element contains the following element:
The **UseTechnicalProfileForSessionManagement** element reference to [Single sig
## Enabled for user journeys
-The [ClaimsProviderSelections](userjourneys.md#claimsproviderselection) in a user journey defines the list of claims provider selection options and their order. With the **EnabledForUserJourneys** element you filter, which claims provider is available to the user. The **EnabledForUserJourneys** element contains one of the following values:
+The [ClaimsProviderSelections](userjourneys.md#claims-provider-selection) in a user journey defines the list of claims provider selection options and their order. With the **EnabledForUserJourneys** element you filter, which claims provider is available to the user. The **EnabledForUserJourneys** element contains one of the following values:
- **Always**, execute the technical profile. - **Never**, skip the technical profile.
active-directory-b2c Tutorial Create Tenant https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/tutorial-create-tenant.md
If you don't have an Azure subscription, create a [free account](https://azure.m
![Create tenant form in with example values in Azure portal](media/tutorial-create-tenant/review-and-create-tenant.png) 1. Select **Review + create**.
-1. Review your directory settings. Then select **Create**. For [troubleshooting deployment errors](https://docs.microsoft.com/azure/azure-resource-manager/templates/common-deployment-errors).
+1. Review your directory settings. Then select **Create**. For [troubleshooting deployment errors](../azure-resource-manager/templates/common-deployment-errors.md).
You can link multiple Azure AD B2C tenants to a single Azure subscription for billing purposes. To link a tenant, you must be an admin in the Azure AD B2C tenant and be assigned at least a Contributor role within the Azure subscription. See [Link an Azure AD B2C tenant to a subscription](billing.md#link-an-azure-ad-b2c-tenant-to-a-subscription).
In this article, you learned how to:
Next, learn how to register a web application in your new tenant. > [!div class="nextstepaction"]
-> [Register your applications >](tutorial-register-applications.md)
+> [Register your applications >](tutorial-register-applications.md)
active-directory-b2c User Flow Custom Attributes https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/user-flow-custom-attributes.md
Previously updated : 12/14/2020 Last updated : 03/04/2021
To enable custom attributes in your policy, provide **Application ID** and Appli
1. Open the extensions file of your policy. For example, <em>`SocialAndLocalAccounts/`**`TrustFrameworkExtensions.xml`**</em>. 1. Find the ClaimsProviders element. Add a new ClaimsProvider to the ClaimsProviders element.
-1. Replace `ApplicationObjectId` with the Object ID that you previously recorded. Then replace `ClientId` with the Application ID that you previously recorded in the below snippet.
+1. Insert the **Application ID** that you previously recorded, between the opening `<Item Key="ClientId">` and closing `</Item>` elements.
+1. Insert the **Application ObjectID** that you previously recorded, between the opening `<Item Key="ApplicationObjectId">` and closing `</Item>` elements.
```xml
- <ClaimsProvider>
- <DisplayName>Azure Active Directory</DisplayName>
- <TechnicalProfiles>
- <TechnicalProfile Id="AAD-Common">
- <Metadata>
- <!--Insert b2c-extensions-app application ID here, for example: 11111111-1111-1111-1111-111111111111-->
- <Item Key="ClientId"></Item>
- <!--Insert b2c-extensions-app application ObjectId here, for example: 22222222-2222-2222-2222-222222222222-->
- <Item Key="ApplicationObjectId"></Item>
- </Metadata>
- </TechnicalProfile>
- </TechnicalProfiles>
- </ClaimsProvider>
+ <!--
+ <ClaimsProviders> -->
+ <ClaimsProvider>
+ <DisplayName>Azure Active Directory</DisplayName>
+ <TechnicalProfiles>
+ <TechnicalProfile Id="AAD-Common">
+ <Metadata>
+ <!--Insert b2c-extensions-app application ID here, for example: 11111111-1111-1111-1111-111111111111-->
+ <Item Key="ClientId"></Item>
+ <!--Insert b2c-extensions-app application ObjectId here, for example: 22222222-2222-2222-2222-222222222222-->
+ <Item Key="ApplicationObjectId"></Item>
+ </Metadata>
+ </TechnicalProfile>
+ </TechnicalProfiles>
+ </ClaimsProvider>
+ <!--
+ </ClaimsProviders> -->
``` ## Upload your custom policy
The following example demonstrates the use of a custom attribute in Azure AD B2C
## Next steps
-Follow the guidance for how to [add claims and customize user input using custom policies](configure-user-input.md). This sample uses a built-in claim 'city'. To use a custom attribute, replace 'city' with your own custom attributes.
+Follow the guidance for how to [add claims and customize user input using custom policies](configure-user-input.md). This sample uses a built-in claim 'city'. To use a custom attribute, replace 'city' with your own custom attributes.
active-directory-b2c User Overview https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/user-overview.md
The consumer user can sign in to applications secured by Azure AD B2C, but canno
You can specify the data that is collected when a consumer user account is created. For more information, see [Add user attributes and customize user input](configure-user-input.md).
-For more information about managing consumer accounts, see [Manage Azure AD B2C user accounts with Microsoft Graph](manage-user-accounts-graph-api.md).
+For more information about managing consumer accounts, see [Manage Azure AD B2C user accounts with Microsoft Graph](./microsoft-graph-operations.md).
### Migrate consumer user accounts
-You might have a need to migrate existing consumer user accounts from any identity provider to Azure AD B2C. For more information, see [Migrate users to Azure AD B2C](user-migration.md).
+You might have a need to migrate existing consumer user accounts from any identity provider to Azure AD B2C. For more information, see [Migrate users to Azure AD B2C](user-migration.md).
active-directory-b2c User Profile Attributes https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/user-profile-attributes.md
Previously updated : 01/13/2021 Last updated : 03/04/2021
A customer account, which could be a consumer, partner, or citizen, can be assoc
- **Local** identity - The username and password are stored locally in the Azure AD B2C directory. We often refer to these identities as "local accounts." - **Federated** identity - Also known as a *social* or *enterprise* accounts, the identity of the user is managed by a federated identity provider like Facebook, Microsoft, ADFS, or Salesforce.
-A user with a customer account can sign in with multiple identities. For example, username, email, employee ID, government ID, and others. A single account can have multiple identities, both local and social, with the same password.
+A user with a customer account can sign in with multiple identities. For example, username, email, employee ID, government ID, and others. A single account can have multiple identities, both local and social, with the same password.
-In the Microsoft Graph API, both local and federated identities are stored in the user `identities` attribute, which is of type [objectIdentity][graph-objectIdentity]. The `identities` collection represents a set of identities used to sign in to a user account. This collection enables the user to sign in to the user account with any of its associated identities.
+In the Microsoft Graph API, both local and federated identities are stored in the user `identities` attribute, which is of type [objectIdentity](/graph/api/resources/objectidentity). The `identities` collection represents a set of identities used to sign in to a user account. This collection enables the user to sign in to the user account with any of its associated identities. The identities attribute can contain up to ten [objectIdentity](/graph/api/resources/objectidentity) objects. Each object contains the following properties:
| Name | Type |Description| |:|:--|:-|
For federated identities, depending on the identity provider, the **issuerAssign
## Password profile property
-For a local identity, the **passwordProfile** attribute is required, and contains the user's password. The `forceChangePasswordNextSignIn` attribute must set to `false`.
+For a local identity, the **passwordProfile** attribute is required, and contains the user's password. The `forceChangePasswordNextSignIn` attribute indicates whether a user must reset the password at the next sign-in. To handle a forced password reset, [set up forced password reset flow](force-password-reset.md).
For a federated (social) identity, the **passwordProfile** attribute is not required.
The following data types are supported when defining an attribute in a schema ex
Learn more about extension attributes: - [Schema extensions](/graph/extensibility-overview#schema-extensions)-- [Define custom attributes](user-flow-custom-attributes.md)
+- [Define custom attributes](user-flow-custom-attributes.md)
active-directory-b2c Userinfo Endpoint https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/userinfo-endpoint.md
Previously updated : 12/14/2020 Last updated : 03/04/2021
The user info UserJourney specifies:
1. Add the following claims provider: ```xml
- <ClaimsProvider>
- <DisplayName>Token Issuer</DisplayName>
- <TechnicalProfiles>
- <TechnicalProfile Id="UserInfoIssuer">
- <DisplayName>JSON Issuer</DisplayName>
- <Protocol Name="None" />
- <OutputTokenFormat>JSON</OutputTokenFormat>
- <CryptographicKeys>
- <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
- </CryptographicKeys>
- <!-- The Below claims are what will be returned on the UserInfo Endpoint if in the Claims Bag-->
- <InputClaims>
- <InputClaim ClaimTypeReferenceId="objectId"/>
- <InputClaim ClaimTypeReferenceId="givenName"/>
- <InputClaim ClaimTypeReferenceId="surname"/>
- <InputClaim ClaimTypeReferenceId="displayName"/>
- <InputClaim ClaimTypeReferenceId="signInNames.emailAddress"/>
- </InputClaims>
- <OutputClaims />
- </TechnicalProfile>
- <TechnicalProfile Id="UserInfoAuthorization">
- <DisplayName>UserInfo authorization</DisplayName>
- <Protocol Name="None" />
- <InputTokenFormat>JWT</InputTokenFormat>
- <Metadata>
- <!-- Update the Issuer and Audience below -->
- <!-- Audience is optional, Issuer is required-->
- <Item Key="issuer">https://yourtenant.b2clogin.com/11111111-1111-1111-1111-111111111111/v2.0/</Item>
- <Item Key="audience">[ "22222222-2222-2222-2222-222222222222", "33333333-3333-3333-3333-333333333333" ]</Item>
- <Item Key="client_assertion_type">urn:ietf:params:oauth:client-assertion-type:jwt-bearer</Item>
- </Metadata>
- <CryptographicKeys>
- <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
- </CryptographicKeys>
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
- <!-- Optional claims to read from the access token -->
- <!-- <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name"/>
+ <!--
+ <ClaimsProviders> -->
+ <ClaimsProvider>
+ <DisplayName>Token Issuer</DisplayName>
+ <TechnicalProfiles>
+ <TechnicalProfile Id="UserInfoIssuer">
+ <DisplayName>JSON Issuer</DisplayName>
+ <Protocol Name="None" />
+ <OutputTokenFormat>JSON</OutputTokenFormat>
+ <CryptographicKeys>
+ <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
+ </CryptographicKeys>
+ <!-- The Below claims are what will be returned on the UserInfo Endpoint if in the Claims Bag-->
+ <InputClaims>
+ <InputClaim ClaimTypeReferenceId="objectId"/>
+ <InputClaim ClaimTypeReferenceId="givenName"/>
+ <InputClaim ClaimTypeReferenceId="surname"/>
+ <InputClaim ClaimTypeReferenceId="displayName"/>
+ <InputClaim ClaimTypeReferenceId="signInNames.emailAddress"/>
+ </InputClaims>
+ </TechnicalProfile>
+ <TechnicalProfile Id="UserInfoAuthorization">
+ <DisplayName>UserInfo authorization</DisplayName>
+ <Protocol Name="None" />
+ <InputTokenFormat>JWT</InputTokenFormat>
+ <Metadata>
+ <!-- Update the Issuer and Audience below -->
+ <!-- Audience is optional, Issuer is required-->
+ <Item Key="issuer">https://yourtenant.b2clogin.com/11111111-1111-1111-1111-111111111111/v2.0/</Item>
+ <Item Key="audience">[ "22222222-2222-2222-2222-222222222222", "33333333-3333-3333-3333-333333333333" ]</Item>
+ <Item Key="client_assertion_type">urn:ietf:params:oauth:client-assertion-type:jwt-bearer</Item>
+ </Metadata>
+ <CryptographicKeys>
+ <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
+ </CryptographicKeys>
+ <OutputClaims>
+ <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
+ <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" PartnerClaimType="email"/>
+ <!-- Optional claims to read from the access token. -->
+ <!-- <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name"/>
<OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="family_name"/> <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name"/> -->
- </OutputClaims>
- </TechnicalProfile>
- </TechnicalProfiles>
- </ClaimsProvider>
+ </OutputClaims>
+ </TechnicalProfile>
+ </TechnicalProfiles>
+ </ClaimsProvider>
+ <!--
+ </ClaimsProviders> -->
```
-1. The outputClaims section within the UserInfoIssuer technical profile specifies the attributes you want to return. The UserInfoIssuer technical profile is called at the end of the user journey.
-1. The UserInfoAuthorization technical profile validates the signature, issuer name, and token audience, and extracts the claim from the inbound token. Change following metadata to reflect your environment:
+1. The InputClaims section within the **UserInfoIssuer** technical profile specifies the attributes you want to return. The UserInfoIssuer technical profile is called at the end of the user journey.
+1. The **UserInfoAuthorization** technical profile validates the signature, issuer name, and token audience, and extracts the claim from the inbound token. Change following metadata to reflect your environment:
1. **issuer** - This value must be identical to the `iss` claim within the access token claim. Tokens issued by Azure AD B2C use an issuer in the format `https://yourtenant.b2clogin.com/your-tenant-id/v2.0/`. Learn more about [token customization](configure-tokens.md). 1. **IdTokenAudience** - Must be identical to the `aud` claim within the access token claim. In Azure AD B2C the `aud` claim is the ID of your relying party application. This value is a collection and supports multiple values using a comma delimiter.
-In the following access token, the `iss` claim value is `https://contoso.b2clogin.com/11111111-1111-1111-1111-111111111111/v2.0/`. The `aud` claim value is `22222222-2222-2222-2222-222222222222`.
+ In the following access token, the `iss` claim value is `https://contoso.b2clogin.com/11111111-1111-1111-1111-111111111111/v2.0/`. The `aud` claim value is `22222222-2222-2222-2222-222222222222`.
+
+ ```json
+ {
+ "exp": 1605549468,
+ "nbf": 1605545868,
+ "ver": "1.0",
+ "iss": "https://contoso.b2clogin.com/11111111-1111-1111-1111-111111111111/v2.0/",
+ "sub": "44444444-4444-4444-4444-444444444444",
+ "aud": "22222222-2222-2222-2222-222222222222",
+ "acr": "b2c_1a_signup_signin",
+ "nonce": "defaultNonce",
+ "iat": 1605545868,
+ "auth_time": 1605545868,
+ "name": "John Smith",
+ "given_name": "John",
+ "family_name": "Smith",
+ "tid": "11111111-1111-1111-1111-111111111111"
+ }
+ ```
+
+1. The OutputClaims element of the **UserInfoAuthorization** technical profile specifies the attributes you want to read from the access token. The **ClaimTypeReferenceId** is the reference to a claim type. The optional **PartnerClaimType** is the name of the of the claim defined in the access token.
+
-```json
-{
- "exp": 1605549468,
- "nbf": 1605545868,
- "ver": "1.0",
- "iss": "https://contoso.b2clogin.com/11111111-1111-1111-1111-111111111111/v2.0/",
- "sub": "44444444-4444-4444-4444-444444444444",
- "aud": "22222222-2222-2222-2222-222222222222",
- "acr": "b2c_1a_signup_signin",
- "nonce": "defaultNonce",
- "iat": 1605545868,
- "auth_time": 1605545868,
- "name": "John Smith",
- "given_name": "John",
- "family_name": "Smith",
- "tid": "11111111-1111-1111-1111-111111111111"
-}
-```
### 2. Add the UserJourney element The [UserJourney](userjourneys.md) element defines the path that the user takes when interacting with your application. Add the **UserJourneys** element if it doesn't exist with the **UserJourney** identified as `UserInfoJourney`: ```xml
-<UserJourney Id="UserInfoJourney" DefaultCpimIssuerTechnicalProfileReferenceId="UserInfoIssuer">
- <Authorization>
- <AuthorizationTechnicalProfiles>
- <AuthorizationTechnicalProfile ReferenceId="UserInfoAuthorization" />
- </AuthorizationTechnicalProfiles>
- </Authorization>
- <OrchestrationSteps >
- <OrchestrationStep Order="1" Type="ClaimsExchange">
- <Preconditions>
- <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
- <Value>objectId</Value>
- <Action>SkipThisOrchestrationStep</Action>
- </Precondition>
- </Preconditions>
- <ClaimsExchanges UserIdentity="false">
- <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
- </ClaimsExchanges>
- </OrchestrationStep>
- <OrchestrationStep Order="2" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="UserInfoIssuer" />
- </OrchestrationSteps>
-</UserJourney>
+<!--
+<UserJourneys> -->
+ <UserJourney Id="UserInfoJourney" DefaultCpimIssuerTechnicalProfileReferenceId="UserInfoIssuer">
+ <Authorization>
+ <AuthorizationTechnicalProfiles>
+ <AuthorizationTechnicalProfile ReferenceId="UserInfoAuthorization" />
+ </AuthorizationTechnicalProfiles>
+ </Authorization>
+ <OrchestrationSteps >
+ <OrchestrationStep Order="1" Type="ClaimsExchange">
+ <Preconditions>
+ <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
+ <Value>objectId</Value>
+ <Action>SkipThisOrchestrationStep</Action>
+ </Precondition>
+ </Preconditions>
+ <ClaimsExchanges UserIdentity="false">
+ <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
+ </ClaimsExchanges>
+ </OrchestrationStep>
+ <OrchestrationStep Order="2" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="UserInfoIssuer" />
+ </OrchestrationSteps>
+ </UserJourney>
+<!--
+</UserJourneys> -->
``` ### 3. Include the endpoint to the relying party policy
A successful response would look like:
- You can find an example of a UserInfo endpoint policy on [GitHub](https://github.com/azure-ad-b2c/samples/tree/master/policies/user-info-endpoint).
active-directory-b2c Userjourneys https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/userjourneys.md
Previously updated : 12/14/2020 Last updated : 03/04/2021
The following example shows a user journey element with authorization technical
A user journey is represented as an orchestration sequence that must be followed through for a successful transaction. If any step fails, the transaction fails. These orchestration steps reference both the building blocks and the claims providers allowed in the policy file. Any orchestration step that is responsible to show or render a user experience also has a reference to the corresponding content definition identifier.
-Orchestration steps can be conditionally executed based on preconditions defined in the orchestration step element. For example, you can check to perform an orchestration step only if a specific claims exists, or if a claim is equal or not to the specified value.
+Orchestration steps can be conditionally executed based on preconditions defined in the orchestration step element. For example, you can check to perform an orchestration step only if a specific claim exists, or if a claim is equal or not to the specified value.
To specify the ordered list of orchestration steps, an **OrchestrationSteps** element is added as part of the policy. This element is required.
The **Preconditions** element contains the following element:
#### Precondition
+Orchestration steps can be conditionally executed based on preconditions defined in the orchestration step. There are two types of preconditions:
+ 
+- **Claims exist** - Specifies that the actions should be performed if the specified claims exist in the user's current claim bag.
+- **Claim equals** - Specifies that the actions should be performed if the specified claim exists, and its value is equal to the specified value. The check performs a case-sensitive ordinal comparison. When checking Boolean claim type, use `True`, or `False`.
+ The **Precondition** element contains the following attributes: | Attribute | Required | Description | | | -- | -- | | `Type` | Yes | The type of check or query to perform for this precondition. The value can be **ClaimsExist**, which specifies that the actions should be performed if the specified claims exist in the user's current claim set, or **ClaimEquals**, which specifies that the actions should be performed if the specified claim exists and its value is equal to the specified value. |
-| `ExecuteActionsIf` | Yes | Use a true or false test to decide if the actions in the precondition should be performed. |
+| `ExecuteActionsIf` | Yes | Use a `true` or `false` test to decide if the actions in the precondition should be performed. |
The **Precondition** elements contains the following elements: | Element | Occurrences | Description | | - | -- | -- |
-| Value | 1:n | A ClaimTypeReferenceId to be queried for. Another value element contains the value to be checked.</li></ul>|
+| Value | 1:2 | The identifier of a claim type. The claim is already defined in the claims schema section in the policy file, or parent policy file. When the precondition is type of `ClaimEquals`, a second `Value` element contains the value to be checked. |
| Action | 1:1 | The action that should be performed if the precondition check within an orchestration step is true. If the value of the `Action` is set to `SkipThisOrchestrationStep`, the associated `OrchestrationStep` should not be executed. | #### Preconditions examples
Preconditions can check multiple preconditions. The following example checks whe
</OrchestrationStep> ```
-## ClaimsProviderSelection
+## Claims provider selection
+
+Identity provider selection lets users select an action from a list of options. The identity provider selection consists of a pair of two orchestration steps:
-An orchestration step of type `ClaimsProviderSelection` or `CombinedSignInAndSignUp` may contain a list of claims providers that a user can sign in with. The order of the elements inside the `ClaimsProviderSelections` elements controls the order of the identity providers presented to the user.
+1. **Buttons** - It starts with type of `ClaimsProviderSelection`, or `CombinedSignInAndSignUp` that contains a list of options a user can choose from. The order of the options inside the `ClaimsProviderSelections` element controls the order of the buttons presented to the user.
+2. **Actions** - Followed by type of `ClaimsExchange`. The ClaimsExchange contains list of actions. The action is a reference to a technical profile, such as [OAuth2](oauth2-technical-profile.md), [OpenID Connect](openid-connect-technical-profile.md), [claims transformation](claims-transformation-technical-profile.md), or [self-asserted](self-asserted-technical-profile.md). The When a user clicks on one of the buttons, the corresponding action is executed.
The **ClaimsProviderSelections** element contains the following element:
The **ClaimsProviderSelection** element contains the following attributes:
| TargetClaimsExchangeId | No | The identifier of the claims exchange, which is executed in the next orchestration step of the claims provider selection. This attribute or the ValidationClaimsExchangeId attribute must be specified, but not both. | | ValidationClaimsExchangeId | No | The identifier of the claims exchange, which is executed in the current orchestration step to validate the claims provider selection. This attribute or the TargetClaimsExchangeId attribute must be specified, but not both. |
-### ClaimsProviderSelection example
+### Claims provider selection example
In the following orchestration step, the user can choose to sign in with Facebook, LinkedIn, Twitter, Google, or a local account. If the user selects one of the social identity providers, the second orchestration step executes with the selected claim exchange specified in the `TargetClaimsExchangeId` attribute. The second orchestration step redirects the user to the social identity provider to complete the sign-in process. If the user chooses to sign in with the local account, Azure AD B2C stays on the same orchestration step (the same sign-up page or sign-in page) and skips the second orchestration step.
In the following orchestration step, the user can choose to sign in with Faceboo
<ClaimsExchanges> <ClaimsExchange Id="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" /> <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
- <ClaimsExchange Id="GoogleExchange" TechnicalProfileReferenceId="Google-OAUTH" />
+ <ClaimsExchange Id="GoogleExchange" TechnicalProfileReferenceId="Google-OAUTH" />
<ClaimsExchange Id="LinkedInExchange" TechnicalProfileReferenceId="LinkedIn-OAUTH" /> <ClaimsExchange Id="TwitterExchange" TechnicalProfileReferenceId="Twitter-OAUTH1" /> </ClaimsExchanges>
active-directory-domain-services Alert Service Principal https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-domain-services/alert-service-principal.md
To recreate the Azure AD application used for credential synchronization, use Az
2. Now delete the old application and object using the following PowerShell cmdlets: ```powershell
- $app = Get-AzureADApplication -Filter "IdentifierUris eq 'https://sync.aaddc.activedirectory.windowsazure.com'"
+ $app = Get-AzureADApplication -Filter "IdentifierUris eq 'https://sync.aaddc.activedirectory.windowsazure.com'"
Remove-AzureADApplication -ObjectId $app.ObjectId $spObject = Get-AzureADServicePrincipal -Filter "DisplayName eq 'Azure AD Domain Services Sync'" Remove-AzureADServicePrincipal -ObjectId $spObject
active-directory-domain-services Compare Identity Solutions https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-domain-services/compare-identity-solutions.md
The following table outlines some of the features you may need for your organiza
| **Secure LDAP (LDAPS)** | **&#x2713;** | **&#x2713;** | | **LDAP read** | **&#x2713;** | **&#x2713;** | | **LDAP write** | **&#x2713;** (within the managed domain) | **&#x2713;** |
-| **Geo-distributed deployments** | **&#x2715;** | **&#x2713;** |
+| **Geo-distributed deployments** | **&#x2713;** | **&#x2713;** |
## Azure AD DS and Azure AD
active-directory-domain-services Concepts Replica Sets https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-domain-services/concepts-replica-sets.md
Previously updated : 07/16/2020 Last updated : 02/26/2021
-# Replica sets concepts and features for Azure Active Directory Domain Services (preview)
+# 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.
-Replica sets are currently in preview.
- > [!NOTE] > Replica sets don't let you deploy multiple unique managed domains in a single Azure tenant. Each replica set contains the same data.
The following example shows a managed domain with three replica sets to further
The default SKU for a managed domain is the *Enterprise* SKU, which supports multiple replica sets. To create additional replica sets if you changed to the *Standard* SKU, [upgrade the managed domain](change-sku.md) to *Enterprise* or *Premium*.
-The maximum number of replica sets supported during preview is four, including the first replica created when you created the managed domain.
+The supported maximum number of replica sets is four, including the first replica created when you created the managed domain.
Billing for each replica set is based on the domain configuration SKU. For example, if you have a managed domain that uses the *Enterprise* SKU and you have three replica sets, your subscription is billed per hour for each of the three replica sets. ## Frequently asked questions
-### Can I use my production managed domain with this preview?
-
-Replica sets are a public preview feature in Azure AD Domain Services. You can use a production managed domain, but please be aware of the support differences that exist for features still in preview. For more information about previews, [Azure Active Directory Preview SLA](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
- ### Can I create a replica set in subscription different from my managed domain? No. Replica sets must be in the same subscription as the managed domain. ### How many replica sets can I create?
-The preview is limited to a maximum of four replica sets - the initial replica set for the managed domain, plus three additional replica sets.
+You can create a maximum of four replica setsΓÇöthe initial replica set for the managed domain, plus three additional replica sets.
### How does user and group information get synchronized to my replica sets?
active-directory-domain-services Tutorial Configure Ldaps https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-domain-services/tutorial-configure-ldaps.md
Previously updated : 07/06/2020 Last updated : 03/04/2021 #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)
To use secure LDAP, the network traffic is encrypted using public key infrastruc
* A **private** key is applied to the managed domain. * This private key is used to *decrypt* the secure LDAP traffic. The private key should only be applied to the managed domain and not widely distributed to client computers. * A certificate that includes the private key uses the *.PFX* file format.
- * The encryption algorithm for the certificate must be *TripleDES-SHA1*.
+ * When exporting the certificate, you must specify the *TripleDES-SHA1* encryption algorithm. This is applicable to the .pfx file only and does not impact the algorithm used by the certificate itself. Note that the *TripleDES-SHA1* option is available only beginning with Windows Server 2016.
* A **public** key is applied to the client computers. * This public key is used to *encrypt* the secure LDAP traffic. The public key can be distributed to client computers. * Certificates without the private key use the *.CER* file format.
Before you can use the digital certificate created in the previous step with you
1. As this certificate is used to decrypt data, you should carefully control access. A password can be used to protect the use of the certificate. Without the correct password, the certificate can't be applied to a service. On the **Security** page, choose the option for **Password** to protect the *.PFX* certificate file. The encryption algorithm must be *TripleDES-SHA1*. Enter and confirm a password, then select **Next**. This password is used in the next section to enable secure LDAP for your managed domain.+
+ If you export using the [PowerShell export-pfxcertificate cmdlet](https://docs.microsoft.com/powershell/module/pkiclient/export-pfxcertificate?view=win10-ps), you need to pass the *-CryptoAlgorithmOption* flag using TripleDES_SHA1.
+
+ ![Screenshot of how to encrypt the password](./media/tutorial-configure-ldaps/encrypt.png)
+ 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. 1. On the review page, select **Finish** to export the certificate to a *.PFX* certificate file. A confirmation dialog is displayed when the certificate has been successfully exported. 1. Leave the MMC open for use in the following section.
active-directory-domain-services Tutorial Create Replica Set https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-domain-services/tutorial-create-replica-set.md
Previously updated : 07/16/2020 Last updated : 02/26/2021 #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 (preview)
+# 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.
-Replica sets are a public preview feature in Azure AD Domain Services. Please be aware of the support differences that exist for features still in preview. For more information about previews, [Azure Active Directory Preview SLA](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
- In this tutorial, you learn how to: > [!div class="checklist"]
To create an additional replica set, complete the following steps:
1. In the Azure portal, search for and select **Azure AD Domain Services**. 1. Choose your managed domain, such as *aaddscontoso.com*.
-1. On the left-hand side, select **Replica sets (preview)**. Each managed domain includes one initial replica set in the selected region, as shown in the following example screenshot:
+1. On the left-hand side, select **Replica sets**. Each managed domain includes one initial replica set in the selected region, as shown in the following example screenshot:
![Example screenshot to view and add a replica set in the Azure portal](./media/tutorial-create-replica-set/replica-set-list.png)
To delete a replica set, complete the following steps:
1. In the Azure portal, search for and select **Azure AD Domain Services**. 1. Choose your managed domain, such as *aaddscontoso.com*.
-1. On the left-hand side, select **Replica sets (preview)**. From the list of replica sets, select the **...** context menu next to the replica set you want to delete.
+1. On the left-hand side, select **Replica sets**. From the list of replica sets, select the **...** context menu next to the replica set you want to delete.
1. Select **Delete** from the context menu, then confirm you want to delete the replica set. > [!NOTE]
active-directory Plan Auto User Provisioning https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-provisioning/plan-auto-user-provisioning.md
Refer to the following links to troubleshoot any issues that may turn up during
* [Keep up to date on what's new with Azure AD](https://azure.microsoft.com/updates/?product=active-directory)
-* [Microsoft Q&A Azure AD forum](https://docs.microsoft.com/answers/topics/azure-active-directory.html)
+* [Microsoft Q&A Azure AD forum](/answers/topics/azure-active-directory.html)
## Next steps * [Configure Automatic User Provisioning](../app-provisioning/configure-automatic-user-provisioning-portal.md) * [Export or import your provisioning configuration by using Microsoft Graph API](../app-provisioning/export-import-provisioning-configuration.md)
-* [Writing expressions for attribute mappings in Azure Active directory](../app-provisioning/functions-for-customizing-application-data.md)
+* [Writing expressions for attribute mappings in Azure Active directory](../app-provisioning/functions-for-customizing-application-data.md)
active-directory Use Scim To Build Users And Groups Endpoints https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-provisioning/use-scim-to-build-users-and-groups-endpoints.md
In this tutorial, you learn how to:
## Deploy your SCIM endpoint in Azure
-The steps here deploy the SCIM endpoint to a service by using [Visual Studio 2019](https://visualstudio.microsoft.com/downloads/) and [Azure App Service](https://docs.microsoft.com/azure/app-service/). The SCIM reference code can also be run locally, hosted by an on-premises server, or deployed to another external service.
+The steps here deploy the SCIM endpoint to a service by using [Visual Studio 2019](https://visualstudio.microsoft.com/downloads/) and [Azure App Service](../../app-service/index.yml). The SCIM reference code can also be run locally, hosted by an on-premises server, or deployed to another external service.
1. Go to the [reference code](https://github.com/AzureAD/SCIMReferenceCode) from GitHub and select **Clone or download**.
The steps here deploy the SCIM endpoint to a service by using [Visual Studio 201
1. Select the resource group to use and select **Publish**.
+ ![Screenshot that shows publishing a new app service.](media/use-scim-to-build-users-and-groups-endpoints/cloud-publish-4.png)
+ 1. 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`. ![Screenshot that shows the Application settings window.](media/use-scim-to-build-users-and-groups-endpoints/app-service-settings.png)
To develop a SCIM-compliant user and group endpoint with interoperability for a
> [!div class="nextstepaction"] > [Tutorial: Develop and plan provisioning for a SCIM endpoint](use-scim-to-provision-users-and-groups.md)
-> [Tutorial: Configure provisioning for a gallery app](configure-automatic-user-provisioning-portal.md)
+> [Tutorial: Configure provisioning for a gallery app](configure-automatic-user-provisioning-portal.md)
active-directory Use Scim To Provision Users And Groups https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-provisioning/use-scim-to-provision-users-and-groups.md
In the sample code, requests are authenticated using the Microsoft.AspNetCore.Au
A bearer token is also required to use of the provided [postman tests](https://github.com/AzureAD/SCIMReferenceCode/wiki/Test-Your-SCIM-Endpoint) and perform local debugging using localhost. The sample code uses ASP.NET Core environments to change the authentication options during development stage and enable the use a self-signed token.
-For more information on multiple environments in ASP.NET Core, see [Use multiple environments in ASP.NET Core](https://docs.microsoft.com/aspnet/core/fundamentals/environments).
+For more information on multiple environments in ASP.NET Core, see [Use multiple environments in ASP.NET Core](/aspnet/core/fundamentals/environments).
The following code enforces that requests to any of the serviceΓÇÖs endpoints are authenticated using a bearer token signed with a custom key:
To help drive awareness and demand of our joint integration, we recommend you up
> [Writing expressions for attribute mappings](functions-for-customizing-application-data.md) > [Scoping filters for user provisioning](define-conditional-rules-for-provisioning-user-accounts.md) > [Account provisioning notifications](user-provisioning.md)
-> [List of tutorials on how to integrate SaaS apps](../saas-apps/tutorial-list.md)
+> [List of tutorials on how to integrate SaaS apps](../saas-apps/tutorial-list.md)
active-directory Concept Authentication Authenticator App https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/concept-authentication-authenticator-app.md
Previously updated : 10/09/2020 Last updated : 02/22/2021
The Microsoft Authenticator app provides an additional level of security to your
Users may receive a notification through the mobile app for them to approve or deny, or use the Authenticator app to generate an OATH verification code that can be entered in a sign-in interface. If you enable both a notification and verification code, users who register the Authenticator app can use either method to verify their identity.
-To use the Authenticator app at a sign-in prompt rather than a username and password combination, see [Enable passwordless sign-in with the Microsoft Authenticator app (preview)](howto-authentication-passwordless-phone.md).
+To use the Authenticator app at a sign-in prompt rather than a username and password combination, see [Enable passwordless sign-in with the Microsoft Authenticator app](howto-authentication-passwordless-phone.md).
> [!NOTE] > Users don't have the option to register their mobile app when they enable SSPR. Instead, users can register their mobile app at [https://aka.ms/mfasetup](https://aka.ms/mfasetup) or as part of the combined security info registration at [https://aka.ms/setupsecurityinfo](https://aka.ms/setupsecurityinfo).
Instead of seeing a prompt for a password after entering a username, a user that
![Example of a browser sign-in asking for user to approve the sign-in](./media/howto-authentication-passwordless-phone/phone-sign-in-microsoft-authenticator-app.png)
-This authentication method provides a high level of security, and removes the need for the user to provide a password at sign-in. Passwordless sign-in using the Microsoft Authenticator app is currently in preview.
+This authentication method provides a high level of security, and removes the need for the user to provide a password at sign-in.
To get started with passwordless sign-in, see [Enable passwordless sign-in with the Microsoft Authenticator app](howto-authentication-passwordless-phone.md).
active-directory Concept Authentication Methods https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/concept-authentication-methods.md
Previously updated : 01/22/2021 Last updated : 02/22/2021
The following table outlines the security considerations for the available authe
|--|:--:|::|::| | Windows Hello for Business | High | High | High | | Microsoft Authenticator app | High | High | High |
-| FIDO2 security key (preview) | High | High | High |
-| OATH hardware tokens (preview) | Medium | Medium | High |
+| FIDO2 security key | High | High | High |
+| OATH hardware tokens | Medium | Medium | High |
| OATH software tokens | Medium | Medium | High | | SMS | Medium | High | Medium | | Voice | Medium | Medium | Medium |
The following table outlines when an authentication method can be used during a
| Method | Primary authentication | Secondary authentication | |--|:-:|:-:| | Windows Hello for Business | Yes | MFA |
-| Microsoft Authenticator app | Yes (preview) | MFA and SSPR |
-| FIDO2 security key (preview) | Yes | MFA |
-| OATH hardware tokens (preview) | No | MFA |
+| Microsoft Authenticator app | Yes | MFA and SSPR |
+| FIDO2 security key | Yes | MFA |
+| OATH hardware tokens | No | MFA |
| OATH software tokens | No | MFA | | SMS | Yes | MFA and SSPR | | Voice call | No | MFA and SSPR |
To learn more about how each authentication method works, see the following sepa
* [Windows Hello for Business](/windows/security/identity-protection/hello-for-business/hello-overview) * [Microsoft Authenticator app](concept-authentication-authenticator-app.md)
-* [FIDO2 security key (preview)](concept-authentication-passwordless.md#fido2-security-keys)
-* [OATH hardware tokens (preview)](concept-authentication-oath-tokens.md#oath-hardware-tokens-preview)
+* [FIDO2 security key](concept-authentication-passwordless.md#fido2-security-keys)
+* [OATH hardware tokens](concept-authentication-oath-tokens.md#oath-hardware-tokens)
* [OATH software tokens](concept-authentication-oath-tokens.md#oath-software-tokens) * [SMS sign-in](howto-authentication-sms-signin.md) and [verification](concept-authentication-phone-options.md#mobile-phone-verification) * [Voice call verification](concept-authentication-phone-options.md)
active-directory Concept Authentication Oath Tokens https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/concept-authentication-oath-tokens.md
Previously updated : 02/02/2021 Last updated : 02/22/2021
The Authenticator app automatically generates codes when set up to do push notif
Some OATH TOTP hardware tokens are programmable, meaning they don't come with a secret key or seed pre-programmed. These programmable hardware tokens can be set up using the secret key or seed obtained from the software token setup flow. Customers can purchase these tokens from the vendor of their choice and use the secret key or seed in their vendor's setup process.
-## OATH hardware tokens (preview)
+## OATH hardware tokens
Azure AD supports the use of OATH-TOTP SHA-1 tokens that refresh codes every 30 or 60 seconds. Customers can purchase these tokens from the vendor of their choice.
OATH TOTP hardware tokens typically come with a secret key, or seed, pre-program
Programmable OATH TOTP hardware tokens that can be reseeded can also be set up with Azure AD in the software token setup flow.
-OATH hardware tokens are supported as part of a public preview. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
- ![Uploading OATH tokens to the MFA OATH tokens blade](media/concept-authentication-methods/mfa-server-oath-tokens-azure-ad.png) Once tokens are acquired they must be uploaded in a comma-separated values (CSV) file format including the UPN, serial number, secret key, time interval, manufacturer, and model, as shown in the following example:
active-directory Concept Authentication Passwordless https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/concept-authentication-passwordless.md
Title: Azure Active Directory passwordless sign-in (preview)
+ Title: Azure Active Directory passwordless sign-in
description: Learn about options for passwordless sign-in to Azure Active Directory using FIDO2 security keys or the Microsoft Authenticator app Previously updated : 07/14/2020 Last updated : 02/22/2021
You can also allow your employee's phone to become a passwordless authentication
The Authenticator App turns any iOS or Android phone into a strong, passwordless credential. Users can sign in to any platform or browser by getting a notification to their phone, matching a number displayed on the screen to the one on their phone, and then using their biometric (touch or face) or PIN to confirm. Refer to [Download and install the Microsoft Authenticator app](../user-help/user-help-auth-app-download-install.md) for installation details.
-Passwordless sign-in with the Microsoft Authenticator app to Azure AD is currently in preview. Use of the Microsoft Authenticator app for secondary authentication for Azure AD Multi-Factor Authentication, self-service password reset (SSPR), or OATH software tokens is GA. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
- Passwordless authentication using the Authenticator app follows the same basic pattern as Windows Hello for Business. It's a little more complicated as the user needs to be identified so that Azure AD can find the Microsoft Authenticator App version being used: ![Diagram that outlines the steps involved for user sign-in with the Microsoft Authenticator App](./media/concept-authentication-passwordless/authenticator-app-flow.png)
Users can register and then select a FIDO2 security key at the sign-in interface
FIDO2 security keys can be used to sign in to their Azure AD or hybrid Azure AD joined Windows 10 devices and get single-sign on to their cloud and on-premises resources. Users can also sign in to supported browsers. FIDO2 security keys are a great option for enterprises who are very security sensitive or have scenarios or employees who aren't willing or able to use their phone as a second factor.
-Sign-in with FIDO2 security keys to Azure AD are currently in preview. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
+We have a reference document for which [browsers support FIDO2 authentication with Azure AD](fido2-compatibility.md), as well as best practices for developers wanting to [support FIDO2 auth in the applications they develop](../develop/support-fido2-authentication.md).
![Sign in to Microsoft Edge with a security key](./media/concept-authentication-passwordless/concept-web-sign-in-security-key.png)
To get started with FIDO2 security keys, complete the following how-to:
> [!div class="nextstepaction"] > [Enable passwordless sign using FIDO2 security keys](howto-authentication-passwordless-security-key.md)
-## What scenarios work with the preview?
+## Supported scenarios
-Azure AD passwordless sign-in features are currently in preview. The following considerations apply:
+The following considerations apply:
- Administrators can enable passwordless authentication methods for their tenant - Administrators can target all users or select users/groups within their tenant for each method - End users can register and manage these passwordless authentication methods in their account portal-- End users can sign in with these passwordless authentication methods
- - Microsoft Authenticator App: Works in scenarios where Azure AD authentication is used, including across all browsers, during Windows 10 Out Of Box (OOBE) setup, and with integrated mobile apps on any operating system.
+- End users can sign in with these passwordless authentication methods:
+ - Microsoft Authenticator App: Works in scenarios where Azure AD authentication is used, including across all browsers, during Windows 10 setup, and with integrated mobile apps on any operating system.
- Security keys: Work on lock screen for Windows 10 and the web in supported browsers like Microsoft Edge (both legacy and new Edge). ## Choose a passwordless method
active-directory Fido2 Compatibility https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/fido2-compatibility.md
# Browser support of FIDO2 passwordless authentication
-Azure Active Directory allows [FIDO2 security keys](https://docs.microsoft.com/azure/active-directory/authentication/concept-authentication-passwordless#fido2-security-keys) to be used as a passwordless device. The availability of FIDO2 authentication for Microsoft accounts was [announced in 2018](https://techcommunity.microsoft.com/t5/identity-standards-blog/all-about-fido2-ctap2-and-webauthn/ba-p/288910). As discussed in the announcement, certain optional features and extensions to the FIDO2 CTAP specification must be implemented to support secure authentication with Microsoft and Azure Active Directory accounts. The following diagram shows which browsers and operating system combinations support passwordless authentication using FIDO2 authentication keys with Azure Active Directory.
+Azure Active Directory allows [FIDO2 security keys](./concept-authentication-passwordless.md#fido2-security-keys) to be used as a passwordless device. The availability of FIDO2 authentication for Microsoft accounts was [announced in 2018](https://techcommunity.microsoft.com/t5/identity-standards-blog/all-about-fido2-ctap2-and-webauthn/ba-p/288910). As discussed in the announcement, certain optional features, and extensions to the FIDO2 CTAP specification must be implemented to support secure authentication with Microsoft and Azure Active Directory accounts. The following diagram shows which browsers and operating system combinations support passwordless authentication using FIDO2 authentication keys with Azure Active Directory.
## Supported browsers This table shows support for authenticating Azure Active Directory (Azure AD) and Microsoft Accounts (MSA). Microsoft accounts are created by consumers for services such as Xbox, Skype, or Outlook.com. Supported device types include **USB**, near-field communication (**NFC**), and bluetooth low energy (**BLE**).
-| | Chrome | | | Edge | | | Firefox | | |
+| OS | Chrome | Chrome | Chrome | Edge | Edge | Edge | Firefox | Firefox | Firefox |
|::|::|::|::|::|::|::|::|::|::| | | USB | NFC | BLE | USB | NFC | BLE | USB | NFC | BLE | | **Windows** | ![Chrome supports USB on Windows for AAD accounts.][y] | ![Chrome supports NFC on Windows for AAD accounts.][y] | ![Chrome supports BLE on Windows for AAD accounts.][y] | ![Edge supports USB on Windows for AAD accounts.][y] | ![Edge supports NFC on Windows for AAD accounts.][y] | ![Edge supports BLE on Windows for AAD accounts.][y] | ![Firefox supports USB on Windows for AAD accounts.][y] | ![Firefox supports NFC on Windows for AAD accounts.][y] | ![Firefox supports BLE on Windows for AAD accounts.][y] | | **macOS** | ![Chrome supports USB on macOS for AAD accounts.][y] | ![Chrome does not support NFC on macOS for AAD accounts.][n] | ![Chrome does not support BLE on macOS for AAD accounts.][n] | ![Edge supports USB on macOS for AAD accounts.][y] | ![Edge does not support NFC on macOS for AAD accounts.][n] | ![Edge does not support BLE on macOS for AAD accounts.][n] | ![Firefox does not support USB on macOS for AAD accounts.][n] | ![Firefox does not support NFC on macOS for AAD accounts.][n] | ![Firefox does not support BLE on macOS for AAD accounts.][n] | | **Linux** | ![Chrome supports USB on Linux for AAD accounts.][y] | ![Chrome does not support NFC on Linux for AAD accounts.][n] | ![Chrome does not support BLE on Linux for AAD accounts.][n] | ![Edge does not support USB on Linux for AAD accounts.][n] | ![Edge does not support NFC on Linux for AAD accounts.][n] | ![Edge does not support BLE on Linux for AAD accounts.][n] | ![Firefox does not support USB on Linux for AAD accounts.][n] | ![Firefox does not support NFC on Linux for AAD accounts.][n] | ![Firefox does not support BLE on Linux for AAD accounts.][n] | ++ ## Unsupported browsers
-The following operating system and browser combinations are not supported, but future support and testing is being investigated. If you would like to see additional operating system and browser support, please leave feedback using the product feedback tool at the bottom of the page.
+The following operating system and browser combinations are not supported, but future support and testing is being investigated. If you would like to see other operating system and browser support, please leave feedback using the product feedback tool at the bottom of the page.
| Operating system | Browser | | - | - |
The following operating system and browser combinations are not supported, but f
| Android | Chrome | | ChromeOS | Chrome |
-## Operating system versions tested
+## Minimum browser version
-The information in the table above was tested for the following operating system versions.
+The following are the minimum browser version requirements.
+
+| Browser | Minimum version |
+| - | - |
+| Chrome | 76 |
+| Edge | Windows 10 version 1903<sup>1</sup> |
+| Firefox | Chrome |
+| ChromeOS | 66 |
-| Operating system | Latest tested version |
-| | |
-| Windows | Windows 10 20H2 |
-| macOS | OS X 11 Big Sur |
-| Linux | Fedora 32 Workstation |
+<sup>1</sup>All versions of the new Chromium-based Microsoft Edge support Fido2. Support on Microsoft Edge legacy was added in 1903.
## Next steps
-[Enable passwordless security key sign-in (preview)](https://docs.microsoft.com/azure/active-directory/authentication/howto-authentication-passwordless-security-key)
+[Enable passwordless security key sign-in (preview)](./howto-authentication-passwordless-security-key.md)
<!--Image references--> [y]: ./media/fido2-compatibility/yes.png
active-directory How To Authentication Two Way Sms Unsupported https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/how-to-authentication-two-way-sms-unsupported.md
+
+ Title: Two-way SMS no longer supported - Azure Active Directory
+description: Explains how to enable another method for users who still use two-way SMS.
+++++ Last updated : 03/02/2021++++++++
+# Two-way SMS unsupported
+
+Two-way SMS for Azure AD Multi-Factor Authentication (MFA) Server was originally deprecated in 2018, and is no longer supported after February 24, 2021. Administrators should enable another method for users who still use two-way SMS.
+
+Email notifications and Azure portal Service Health notifications (portal toasts) were sent to affected admins on December 8, 2020 and January 28, 2021. The alerts went to the Owner, Co-Owner, Admin, and Service Admin RBAC roles tied to the subscriptions. If you've already completed the following steps, no action is necessary.
+
+## Required actions
+
+1. Enable the mobile app for your users, if you haven't done so already. For more information, see [Enable mobile app authentication with MFA Server](howto-mfaserver-deploy-mobileapp.md).
+1. Notify your end users to visit your MFA Server [User portal](howto-mfaserver-deploy-userportal.md) to activate the mobile app. The [Microsoft Authenticator app](https://www.microsoft.com/en-us/account/authenticator) is the recommended verification option since it is more secure than two-way SMS. For more information, see please see [It's Time to Hang Up on Phone Transports for Authentication](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/it-s-time-to-hang-up-on-phone-transports-for-authentication/ba-p/1751752).
+1. Change the user settings from two-way text message to mobile app as the default method.
+
+## FAQ
+
+### What if I don't change the default method from two-way SMS to the mobile app?
+Two-way SMS fails after February 24, 2021. Users will see an error when they try to sign in and pass MFA.
+
+### How do I change the user settings from two-way text message to mobile app?
+
+You should change the user settings by following these steps:
+
+1. In MFA Server, filter the user list for two-way text message.
+1. Select all users.
+1. Open the Edit Users dialog.
+1. Change users from Text message to Mobile app.
+
+ ![Screenshot of End Users](media/how-to-authentication-two-way-sms-unsupported/end-users.png)
+
+### Do my users need to take any action? If yes, how?
+Yes. Your end users need to visit your specific MFA Server User portal to activate the mobile app, if they haven't done so already. After you've done Step 3, any users that didn't visit the User Portal to set up the mobile app will start failing sign in until they visit the User portal to re-register.
+
+### What if my users can't install the mobile app? What other options do they have?
+The alternative to two-way SMS or the mobile app is a phone call. However, the Microsoft Authenticator app is the recommended verification method.
+
+### Will one-way SMS be deprecated as well?
+No, just two-way SMS is being deprecated. For MFA Server, one-way SMS works for a subset of scenarios:
+
+- AD FS Adapter
+- IIS Authentication (requires User Portal and configuration)
+- RADIUS (requires that RADIUS clients support access challenge and that PAP protocol is used)
+
+There are limitations to when one-way SMS can be used that make the mobile app a better alternative because it doesnΓÇÖt require the verification code prompt.
+If you still want to use one-way SMS in some scenarios, then you could leave these checked, but change the **Company Settings** section, **General** tab **User Defaults Text Message** to **One-Way** instead of **Two-Way**. Lastly, if you use Directory Synchronization that defaults to SMS, youΓÇÖd need to change it to One-Way instead of Two-Way.
+
+### How can I check which users are still using two-way SMS?
+To list these users, start **MFA Server**, select the **Users** section, click **Filter User List**, and filter for **Text Message Two-Way**.
+
+### How do we hide two-way SMS as an option in the MFA portal to prevent users from selecting it in the future?
+In MFA Server User portal, click **Settings**, you can clear **Text Message** so that it is not available.
+The same is true in the **AD FS** section if you are using AD FS for user enrollment.
+
active-directory Howto Authentication Methods Activity https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-authentication-methods-activity.md
+
+ Title: Authentication Methods Activity - Azure Active Directory
+description: Overview of the authentication methods that users register to sign in and reset passwords.
+++++ Last updated : 03/04/2021++++++++
+# Authentication Methods Activity
+
+The new authentication methods activity dashboard enables admins to monitor authentication method registration and usage across their organization. This reporting capability provides your organization with the means to understand what methods are being registered and how they're being used.
++
+## Permissions and licenses
+
+Built-in and custom roles with the following permissions can access the Authentication Methods Activity blade and APIs:
+
+- Microsoft.directory/auditLogs/allProperties/read
+- Microsoft.directory/signInReports/allProperties/read
+
+The following roles have the required permissions:
+
+- Reports Reader
+- Security Reader
+- Global Reader
+- Security Operator
+- Security Administrator
+- Global Administrator
+
+ An Azure AD Premium P1 or P2 license is required to access usage and insights. Azure AD Multi-Factor Authentication and self-service password reset (SSPR) licensing information can be found on the [Azure Active Directory pricing site](https://azure.microsoft.com/pricing/details/active-directory/).
+
+## How it works
+
+To access authentication method usage and insights:
+
+1. Sign in to the [Azure portal](https://portal.azure.com).
+1. Click **Azure Active Directory** > **Security** > **Authentication Methods** > **Activity**.
+1. There are two tabs in the report: **Registration** and **Usage**.
+
+ ![Authentication Methods Activity overview](media/how-to-authentication-methods-usage-insights/registration-usage-tabs.png)
+
+## Registration details
+
+You can access the [**Registration tab**](https://portal.azure.com/#blade/Microsoft_AAD_IAM/AuthMethodsOverviewBlade) to show the number of users capable of multi-factor authentication, passowordless authentication, and self-service password reset.
+
+Click any of the following options to pre-filter a list of user registration details:
+
+- **Users capable of Azure Multi-Factor Authentication** shows the breakdown of users who are both:
+ - Registered for a strong authentication method
+ - Enabled by policy to use that method for MFA
+
+ This number doesn't reflect users registered for MFA outside of Azure AD.
+- **Users capable of passwordless authentication** shows the breakdown of users who are registered to sign in without a password by using FIDO2, Windows Hello for Business, or passwordless Phone sign-in with the Microsoft Authenticator app.
+- **Users capable of self-service password reset** shows the breakdown of users who can reset their passwords. Users can reset their password if they're both:
+ - Registered for enough methods to satisfy their organization's policy for self-service password reset
+ - Enabled to reset their password
+
+ ![Screenshot of users who can register](media/how-to-authentication-methods-usage-insights/users-capable.png)
+
+**Users registered by authentication method** shows how many users are registered for each authentication method. Click an authentication method to see who is registered for that method.
+
+![Screenshot of Users Registered](media/how-to-authentication-methods-usage-insights/users-registered.png)
+
+**Recent registration by authentication method** shows how many registrations succeeded and failed, sorted by authentication method. Click an authentication method to see recent registration events for that method.
+
+![Screenshot of Recently Registered](media/how-to-authentication-methods-usage-insights/recently-registered.png)
+
+## Usage details
+
+The **Usage** report shows which authentication methods are used to sign-in and reset passwords.
+
+![Screenshot of Usage page](media/how-to-authentication-methods-usage-insights/usage-page.png)
+
+**Sign-ins by authentication requirement** shows the number of successful user interactive sign-ins that were required for single-factor versus multi-factor authentication in Azure AD. Sign-ins where MFA was enforced by a third-party MFA provider are not included.
+
+![Screenshot of sign ins by authentication requirement](media/how-to-authentication-methods-usage-insights/sign-ins-protected.png)
+
+**Sign-ins by authentication method** shows the number of user interactive sign-ins (success and failure) by authentication method used. It doesn't include sign-ins where the authentication requirement was satisfied by a claim in the token.
+
+![Screenshot of sign ins by method](media/how-to-authentication-methods-usage-insights/sign-ins-by-method.png)
+
+**Number of password resets and account unlocks** shows the number of successful password changes and password resets (self-service and by admin) over time.
+
+![Screenshot of resets and unlocks](media/how-to-authentication-methods-usage-insights/password-changes.png)
+
+**Password resets by authentication method** shows the number of successful and failed authentications during the password reset flow by authentication method.
+
+![Screenshot of Resets by method](media/how-to-authentication-methods-usage-insights/resets-by-method.png)
+
+## User registration details
+
+Using the controls at the top of the list, you can search for a user and filter the list of users based on the columns shown.
+
+The registration details report shows the following information for each user:
+
+- User principal name
+- Name
+- MFA Capable (Capable, Not Capable)
+- Passwordless Capable (Capable, Not Capable)
+- SSPR Registered (Registered, Not Registered)
+- SSPR Enabled (Enabled, Not Enabled)
+- SSPR Capable (Capable, Not Capable)
+- Methods registered (Email, Mobile Phone, Alternative Mobile Phone, Office Phone, Microsoft Authenticator Push, Software One Time Passcode, FIDO2, Security Key, Security questions)
+
+ ![Screenshot of user registration details](media/how-to-authentication-methods-usage-insights/registration-details.png)
+
+## Registration and reset events
+
+**Registration and reset events** shows registration and reset events from the last 24 hours, last seven days, or last 30 days including:
+
+- Date
+- User name
+- User
+- Feature (Registration, Reset)
+- Method used (App notification, App code, Phone Call, Office Call, Alternate Mobile Call, SMS, Email, Security questions)
+- Status (Success, Failure)
+- Reason for failure (explanation)
+
+ ![Screenshot of registration and reset events](media/how-to-authentication-methods-usage-insights/registration-and-reset-logs.png)
+
+## Limitations
+
+- The data in the report is not updated in real-time and may reflect a latency of up to a few hours.
+- Temporary Access Pass registrations are not reflected in the registration tab of the report because they are only valid for short period of time.
+
+## Next steps
+
+- [Working with the authentication methods usage report API](/graph/api/resources/authenticationmethods-usage-insights-overview?view=graph-rest-beta)
+- [Choosing authentication methods for your organization](concept-authentication-methods.md)
+- [Combined registration experience](concept-registration-mfa-sspr-combined.md)
active-directory Howto Authentication Methods Usage Insights https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-authentication-methods-usage-insights.md
- Title: Authentication methods usage & insights - Azure Active Directory
-description: Reporting on Azure AD self-service password reset and Multi-Factor Authentication authentication method usage
----- Previously updated : 12/17/2020--------
-# Authentication methods usage & insights (preview)
-
-Usage & insights enables you to understand how authentication methods for features like Azure AD Multi-Factor Authentication and self-service password reset are working in your organization. This reporting capability provides your organization with the means to understand what methods are being registered and how they are being used.
-
-## Permissions and licenses
-
-The following roles can access usage and insights:
--- Global Administrator-- Security Reader-- Security Administrator-- Reports Reader-
- An Azure AD Premium P1 or P2 license is required to access usage and insights. Azure AD Multi-Factor Authentication and self-service password reset (SSPR) licensing information can be found on the [Azure Active Directory pricing site](https://azure.microsoft.com/pricing/details/active-directory/).
-
-## How it works
-
-To access authentication method usage and insights:
-
-1. Browse to the [Azure portal](https://portal.azure.com).
-1. Browse to **Azure Active Directory** > **Password reset** > **Usage & insights**.
-1. From the **Registration** or **Usage** overviews, you can choose to open the pre-filtered reports to filter based on your needs.
-
-![Usage & insights overview](./media/howto-authentication-methods-usage-insights/usage-insights-overview.png)
-
-To access usage & insights directly, go to [https://portal.azure.com/#blade/Microsoft_AAD_IAM/AuthMethodsOverviewBlade](https://portal.azure.com/#blade/Microsoft_AAD_IAM/AuthMethodsOverviewBlade). This link will bring you to the registration overview.
-
-The Users registered, Users enabled, and Users capable tiles show the following registration data for your users:
--- Registered: A user is considered registered if they (or an admin) have registered enough authentication methods to meet your organization's SSPR or Multi-Factor Authentication policy.-- Enabled: A user is considered enabled if they are in scope for the SSPR policy. If SSPR is enabled for a group, then the user is considered enabled if they are in that group. If SSPR is enabled for all users, then all users in the tenant (excluding guests) are considered enabled.-- Capable: A user is considered capable if they are both registered and enabled. This status means that they can perform SSPR at any time if needed.-
-Clicking on any of these tiles or the insights shown in them will bring you to a pre-filtered list of registration details.
-
-The **Registrations** chart on the **Registration** tab shows the number of successful and failed authentication method registrations by authentication method. The **Resets** chart on the **Usage** tab shows the number of successful and failed authentications during the password reset flow by authentication method.
-
-Clicking on either of the charts will bring you to a pre-filtered list of registration or reset events.
-
-Using the control in the upper, right-hand corner, you can change the date range for the audit data shown in the Registrations and Resets charts to 24 hours, 7 days, or 30 days.
-
-### Registration details
-
-Clicking on the **Users registered**, **Users enabled**, or **Users capable** tiles or insights will bring you to the registration details.
-
-The registration details report shows the following information for each user:
--- Name-- User name-- Registration status (All, Registered, Not registered)-- Enabled status (All, Enabled, Not enabled)-- Capable status (All, Capable, Not capable)-- Methods (App notification, App code, Phone call, SMS, Email, Security questions)-
-Using the controls at the top of the list, you can search for a user and filter the list of users based on the columns shown.
-
-### Reset details
-
-Clicking on the Registrations or Resets charts will bring you to the reset details.
-
-The reset details report shows registration and reset events from the last 30 days including:
--- Name-- User name-- Feature (All, Registration, Reset)-- Authentication method (App notification, App code, Phone call, Office call, SMS, Email, Security questions)-- Status (All, Success, Failure)-
-Using the controls at the top of the list, you can search for a user and filter the list of users based on the columns shown.
-
-## Limitations
-
-The data shown in these reports will be delayed by up to 60 minutes. A "Last refreshed" field exists in the Azure portal to identify how recent your data is.
-
-Usage and insights data is not a replacement for the Azure AD Multi-Factor Authentication activity reports or information contained in the Azure AD sign-ins report.
-
-Report can't currently be filtered to exclude external users.
-
-## Next steps
--- [Working with the authentication methods usage report API](/graph/api/resources/authenticationmethods-usage-insights-overview?view=graph-rest-beta)-- [Choosing authentication methods for your organization](concept-authentication-methods.md)-- [Combined registration experience](concept-registration-mfa-sspr-combined.md)
active-directory Howto Authentication Passwordless Deployment https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-authentication-passwordless-deployment.md
Previously updated : 01/30/2020 Last updated : 02/22/2021
There are three types of passwordless sign-in deployments available with securit
- Azure Active Directory web apps on a supported browser - Azure Active Directory Joined Windows 10 devices-- Hybrid Azure Active Directory Joined Windows 10 devices (preview)
+- Hybrid Azure Active Directory Joined Windows 10 devices
- Provides access to both cloud-based and on premises resources. For more information about access to on-premises resources, see [SSO to on-premises resources using FIDO2 keys](./howto-authentication-passwordless-security-key-on-premises.md) You must enable **Compatible FIDO2 security keys**. Microsoft announced [key partnerships with FIDO2 key vendors](https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Microsoft-passwordless-partnership-leads-to-innovation-and-great/ba-p/566493).
Enabling Windows 10 sign-in using FIDO2 security keys requires enabling the cred
#### Enable on-premises integration
-To enable access to on-premises resources, follow the steps to [Enable passwordless security key sign in to on-premises resources (preview)](howto-authentication-passwordless-security-key-on-premises.md).
+To enable access to on-premises resources, follow the steps to [Enable passwordless security key sign in to on-premises resources](howto-authentication-passwordless-security-key-on-premises.md).
> [!IMPORTANT] > These steps must also be completed for any hybrid Azure AD joined devices to utilize FIDO2 security keys for Windows 10 sign in.
active-directory Howto Authentication Passwordless Faqs https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-authentication-passwordless-faqs.md
Title: FAQs for hybrid FIDO2 security key deployment - Azure Active Directory
-description: Learn about some frequently asked questions for passwordless hybrid FIDO2 security key sign-in using Azure Active Directory (preview)
+description: Learn about some frequently asked questions for passwordless hybrid FIDO2 security key sign-in using Azure Active Directory
Previously updated : 08/19/2020 Last updated : 02/22/2021
-# Deployment frequently asked questions (FAQs) for hybrid FIDO2 security keys in Azure AD (preview)
+# Deployment frequently asked questions (FAQs) for hybrid FIDO2 security keys in Azure AD
This article covers deployment frequently asked questions (FAQs) for hybrid Azure AD joined devices and passwordless sign-in to on-prem resources. With this passwordless feature, you can enable Azure AD authentication on Windows 10 devices for hybrid Azure AD joined devices using FIDO2 security keys. Users can sign into Windows on their devices with modern credentials like FIDO2 keys and access traditional Active Directory Domain Services (AD DS) based resources with a seamless single sign-on (SSO) experience to their on-prem resources.
To get started with FIDO2 security keys and hybrid access to on-premises resourc
* [Passwordless Windows 10](howto-authentication-passwordless-security-key-windows.md) * [Passwordless on-premises](howto-authentication-passwordless-security-key-on-premises.md)
-> [!NOTE]
-> FIDO2 security keys are a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
- ## Security keys * [My organization requires two factor authentication to access resources. What can I do to support this requirement?](#my-organization-requires-multi-factor-authentication-to-access-resources-what-can-i-do-to-support-this-requirement)
active-directory Howto Authentication Passwordless Phone https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-authentication-passwordless-phone.md
Title: Passwordless sign-in with the Microsoft Authenticator app - Azure Active Directory
-description: Enable passwordless sign-in to Azure AD using the Microsoft Authenticator app (preview)
+description: Enable passwordless sign-in to Azure AD using the Microsoft Authenticator app
-# Enable passwordless sign-in with the Microsoft Authenticator app (preview)
+# Enable passwordless sign-in with the Microsoft Authenticator app
The Microsoft Authenticator app can be used to sign in to any Azure AD account without using a password. Microsoft Authenticator uses key-based authentication to enable a user credential that is tied to a device, where the device uses a PIN or biometric. [Windows Hello for Business](/windows/security/identity-protection/hello-for-business/hello-identity-verification) uses a similar technology.
To use passwordless phone sign-in with the Microsoft Authenticator app, the foll
- Latest version of Microsoft Authenticator installed on devices running iOS 8.0 or greater, or Android 6.0 or greater. > [!NOTE]
-> If you enabled Microsoft Authenticator passwordless sign-in preview using Azure AD PowerShell, it was enabled for your entire directory. If you enable using this new method, it supercedes the PowerShell policy. We recommend you enable for all users in your tenant via the new *Authentication Methods* menu, otherwise users not in the new policy are no longer be able to sign in without a password.
+> If you enabled Microsoft Authenticator passwordless sign-in using Azure AD PowerShell, it was enabled for your entire directory. If you enable using this new method, it supercedes the PowerShell policy. We recommend you enable for all users in your tenant via the new *Authentication Methods* menu, otherwise users not in the new policy are no longer be able to sign in without a password.
## Enable passwordless authentication methods
To enable the authentication method for passwordless phone sign-in, complete the
1. Sign in to the [Azure portal](https://portal.azure.com) with a *global administrator* account. 1. Search for and select *Azure Active Directory*, then browse to **Security** > **Authentication methods** > **Policies**.
-1. Under **Microsoft Authenticator (preview)**, choose the following options:
+1. Under **Microsoft Authenticator**, choose the following options:
1. **Enable** - Yes or No 1. **Target** - All users or Select users 1. Each added group or user is enabled by default to use Microsoft Authenticator in both passwordless and push notification modes ("Any" mode). To change this, for each row:
After the user has utilized passwordless phone sign-in, the app continues to gui
## Known Issues
-The following known issues exist in the current preview experience.
+The following known issues exist.
### Not seeing option for passwordless phone sign-in
active-directory Howto Authentication Passwordless Security Key On Premises https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises.md
Title: Passwordless security key sign-in to on-premises resources (preview) - Azure Active Directory
-description: Learn how to enable passwordless security key sign-in to on-premises resources using Azure Active Directory (preview)
+ Title: Passwordless security key sign-in to on-premises resources - Azure Active Directory
+description: Learn how to enable passwordless security key sign-in to on-premises resources using Azure Active Directory
Previously updated : 03/09/2020 Last updated : 02/22/2021
-# Enable passwordless security key sign-in to on-premises resources with Azure Active Directory (preview)
+# Enable passwordless security key sign-in to on-premises resources with Azure Active Directory
This document focuses on enabling passwordless authentication to on-premises resources for environments with both **Azure AD joined** and **hybrid Azure AD joined** Windows 10 devices. This functionality provides seamless single sign-on (SSO) to on-premises resources using Microsoft-compatible security keys.
-> [!NOTE]
-> FIDO2 security keys are a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
- ## SSO to on-premises resources using FIDO2 keys Azure Active Directory (AD) can issue Kerberos Ticket Granting Tickets (TGTs) for one or more of your Active Directory domains. This functionality allows users to sign into Windows with modern credentials like FIDO2 security keys and access traditional Active Directory based resources. Kerberos Service Tickets and authorization continue to be controlled by your on-premises Active Directory domain controllers.
An Azure AD Kerberos Server object is created in your on-premises Active Directo
## Requirements
-Organizations must complete the steps to [Enable passwordless security key sign to Windows 10 devices (preview)](howto-authentication-passwordless-security-key.md) before completing the steps in this article.
+Organizations must complete the steps to [Enable passwordless security key sign to Windows 10 devices](howto-authentication-passwordless-security-key.md) before completing the steps in this article.
Organizations must also meet the following software requirements.
Sign in with FIDO is blocked if your password has expired. The expectation is fo
## Troubleshooting and feedback
-If you'd like to share feedback or encounter issues while previewing this feature, share via the Windows Feedback Hub app using the following steps:
+If you'd like to share feedback or encounter issues with this feature, share via the Windows Feedback Hub app using the following steps:
1. Launch **Feedback Hub** and make sure you're signed in. 1. Submit feedback under the following categorization: - Category: Security and Privacy - Subcategory: FIDO
-1. To capture logs, use the option to **Recreate my Problem**
+1. To capture logs, use the option to **Recreate my Problem**.
## Frequently asked questions
active-directory Howto Authentication Passwordless Security Key Windows https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-authentication-passwordless-security-key-windows.md
Title: Passwordless security key sign-in Windows - Azure Active Directory
-description: Learn how to enable passwordless security key sign-in to Azure Active Directory using FIDO2 security keys (preview)
+description: Learn how to enable passwordless security key sign-in to Azure Active Directory using FIDO2 security keys
Previously updated : 11/24/2020 Last updated : 02/22/2021
-# Enable passwordless security key sign-in to Windows 10 devices with Azure Active Directory (preview)
+# Enable passwordless security key sign-in to Windows 10 devices with Azure Active Directory
This document focuses on enabling FIDO2 security key based passwordless authentication with Windows 10 devices. At the end of this article, you will be able to sign in to both your Azure AD and hybrid Azure AD joined Windows 10 devices with your Azure AD account using a FIDO2 security key.
-> [!NOTE]
-> FIDO2 security keys are a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
- ## Requirements | Device Type | Azure AD joined | Hybrid Azure AD joined | | | | | | [Azure AD Multi-Factor Authentication](howto-mfa-getstarted.md) | X | X |
-| [Combined security information registration preview](concept-registration-mfa-sspr-combined.md) | X | X |
+| [Combined security information registration](concept-registration-mfa-sspr-combined.md) | X | X |
| Compatible [FIDO2 security keys](concept-authentication-passwordless.md#fido2-security-keys) | X | X | | WebAuthN requires Windows 10 version 1903 or higher | X | X | | [Azure AD joined devices](../devices/concept-azure-ad-join.md) require Windows 10 version 1909 or higher | X | |
The following scenarios aren't supported:
- Signing in or unlocking a Windows 10 device with a security key containing multiple Azure AD accounts. This scenario utilizes the last account added to the security key. WebAuthN allows users to choose the account they wish to use. - Unlock a device running Windows 10 version 1809. For the best experience, use Windows 10 version 1903 or higher.
-## Prepare devices for preview
+## Prepare devices
-Azure AD joined devices that you are piloting during the feature preview with must run Windows 10 version 1909 or higher.
+Azure AD joined devices must run Windows 10 version 1909 or higher.
Hybrid Azure AD joined devices must run Windows 10 version 2004 or newer.
In the example below, a user named Bala Sandhu has already provisioned their FID
## Troubleshooting and feedback
-If you'd like to share feedback or encounter issues while previewing this feature, share via the Windows Feedback Hub app using the following steps:
+If you'd like to share feedback or encounter issues about this feature, share via the Windows Feedback Hub app using the following steps:
1. Launch **Feedback Hub** and make sure you're signed in. 1. Submit feedback under the following categorization: - Category: Security and Privacy - Subcategory: FIDO
-1. To capture logs, use the option to **Recreate my Problem**
+1. To capture logs, use the option to **Recreate my Problem**.
## Next steps
active-directory Howto Authentication Passwordless Security Key https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-authentication-passwordless-security-key.md
Title: Passwordless security key sign-in (preview) - Azure Active Directory
-description: Enable passwordless security key sign-in to Azure AD using FIDO2 security keys (preview)
+ Title: Passwordless security key sign-in - Azure Active Directory
+description: Enable passwordless security key sign-in to Azure AD using FIDO2 security keys
Previously updated : 09/14/2020 Last updated : 02/22/2021
-# Enable passwordless security key sign-in (preview)
+# Enable passwordless security key sign-in
For enterprises that use passwords today and have a shared PC environment, security keys provide a seamless way for workers to authenticate without entering a username or password. Security keys provide improved productivity for workers, and have better security. This document focuses on enabling security key based passwordless authentication. At the end of this article, you will be able to sign in to web-based applications with your Azure AD account using a FIDO2 security key.
-> [!NOTE]
-> FIDO2 security keys are a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
- ## Requirements - [Azure AD Multi-Factor Authentication](howto-mfa-getstarted.md)-- Enable [Combined security information registration preview](concept-registration-mfa-sspr-combined.md)
+- Enable [Combined security information registration](concept-registration-mfa-sspr-combined.md)
- Compatible [FIDO2 security keys](concept-authentication-passwordless.md#fido2-security-keys) - WebAuthN requires Windows 10 version 1903 or higher** To use security keys for logging in to web apps and services, you must have a browser that supports the WebAuthN protocol. These include Microsoft Edge, Chrome, Firefox, and Safari.
-## Prepare devices for preview
+## Prepare devices
For Azure AD joined devices the best experience is on Windows 10 version 1903 or higher.
Hybrid Azure AD joined devices must run Windows 10 version 2004 or higher.
### Enable the combined registration experience
-Registration features for passwordless authentication methods rely on the combined registration feature. Follow the steps in the article [Enable combined security information registration (preview)](howto-registration-mfa-sspr-combined.md), to enable combined registration.
+Registration features for passwordless authentication methods rely on the combined registration feature. Follow the steps in the article [Enable combined security information registration](howto-registration-mfa-sspr-combined.md), to enable combined registration.
### Enable FIDO2 security key method 1. Sign in to the [Azure portal](https://portal.azure.com).
-1. Browse to **Azure Active Directory** > **Security** > **Authentication methods** > **Authentication method policy (Preview)**.
+1. Browse to **Azure Active Directory** > **Security** > **Authentication methods** > **Authentication method policy**.
1. Under the method **FIDO2 Security Key**, choose the following options: 1. **Enable** - Yes or No 1. **Target** - All users or Select users
In the example below a user has already provisioned their FIDO2 security key. Th
## Troubleshooting and feedback
-If you'd like to share feedback or encounter issues while previewing this feature, share via the Windows Feedback Hub app using the following steps:
+If you'd like to share feedback or encounter issues with this feature, share via the Windows Feedback Hub app using the following steps:
1. Launch **Feedback Hub** and make sure you're signed in. 1. Submit feedback under the following categorization: - Category: Security and Privacy - Subcategory: FIDO
-1. To capture logs, use the option to **Recreate my Problem**
+1. To capture logs, use the option to **Recreate my Problem**.
## Known issues ### Security key provisioning
-Administrator provisioning and de-provisioning of security keys is not available in the public preview.
+Administrator provisioning and de-provisioning of security keys is not available.
### UPN changes
active-directory Howto Authentication Passwordless Troubleshoot https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-authentication-passwordless-troubleshoot.md
Title: Known issues and troubleshooting for hybrid FIDO2 security keys - Azure Active Directory
-description: Learn about some known issues and ways to troubleshoot passwordless hybrid FIDO2 security key sign-in using Azure Active Directory (preview)
+description: Learn about some known issues and ways to troubleshoot passwordless hybrid FIDO2 security key sign-in using Azure Active Directory
Previously updated : 08/19/2020 Last updated : 02/22/2021
-# Troubleshooting for hybrid deployments of FIDO2 security keys in Azure AD (preview)
+# Troubleshooting for hybrid deployments of FIDO2 security keys in Azure AD
This article covers frequently asked questions for hybrid Azure AD joined devices and passwordless sign-in to on-prem resources. With this passwordless feature, you can enable Azure AD authentication on Windows 10 devices for hybrid Azure AD joined devices using FIDO2 security keys. Users can sign into Windows on their devices with modern credentials like FIDO2 keys and access traditional Active Directory Domain Services (AD DS) based resources with a seamless single sign-on (SSO) experience to their on-prem resources.
The following scenarios for users in a hybrid environment are supported:
To get started with FIDO2 security keys and hybrid access to on-premises resources, see the following articles:
-* [Passwordless Security keys](howto-authentication-passwordless-security-key.md)
+* [Passwordless security keys](howto-authentication-passwordless-security-key.md)
* [Passwordless Windows 10](howto-authentication-passwordless-security-key-windows.md)
-* [Passwordless On -premises](howto-authentication-passwordless-security-key-on-premises.md)
-
-> [!NOTE]
-> FIDO2 security keys are a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
+* [Passwordless on-premises](howto-authentication-passwordless-security-key-on-premises.md)
## Known issues
active-directory Howto Authentication Temporary Access Pass https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-authentication-temporary-access-pass.md
Title: Configure a Temporary Access Pass in Azure AD to register Passwordless authentication methods
-description: Learn how to configure and enable users to to register Passwordless authentication methods by using a Temporary Access Pass (TAP)
+description: Learn how to configure and enable users to to register Passwordless authentication methods by using a Temporary Access Pass
Previously updated : 02/12/2021 Last updated : 03/03/2021
Passwordless authentication methods, such as FIDO2 and Passwordless Phone Sign-i
Users can bootstrap Passwordless methods in one of two ways: - Using existing Azure AD multi-factor authentication methods -- Using a Temporary Access Pass (TAP)
+- Using a Temporary Access Pass
-TAP is a time-limited passcode issued by an admin that satisfies strong authentication requirements and can be used to onboard other authentication methods, including Passwordless ones.
-TAP also makes recovery easier when a user has lost or forgotten their strong authentication factor like a FIDO2 security key or Microsoft Authenticator app, but needs to sign in to register new strong authentication methods.
+A Temporary Access Pass is a time-limited passcode issued by an admin that satisfies strong authentication requirements and can be used to onboard other authentication methods, including Passwordless ones.
+A Temporary Access Pass also makes recovery easier when a user has lost or forgotten their strong authentication factor like a FIDO2 security key or Microsoft Authenticator app, but needs to sign in to register new strong authentication methods.
-This article shows you how to enable and use a TAP in Azure AD using the Azure portal.
+This article shows you how to enable and use a Temporary Access Pass in Azure AD using the Azure portal.
You can also perform these actions using the REST APIs. >[!NOTE] >Temporary Access Pass is currently in public preview. Some features might not be supported or have limited capabilities.
-## Enable the TAP policy
+## Enable the Temporary Access Pass policy
-A TAP policy defines settings, such as the lifetime of passes created in the tenant, or the users and groups who can use a TAP to sign-in.
-Before anyone can sign in with a TAP, you need to enable the authentication method policy and choose which users and groups can sign in by using a TAP.
-Although you can create a TAP for any user, only those included in the policy can sign-in with it.
+A Temporary Access Pass policy defines settings, such as the lifetime of passes created in the tenant, or the users and groups who can use a Temporary Access Pass to sign-in.
+Before anyone can sign in with a Temporary Access Pass, you need to enable the authentication method policy and choose which users and groups can sign in by using a Temporary Access Pass.
+Although you can create a Temporary Access Pass for any user, only those included in the policy can sign-in with it.
-Global administrator and Authentication Method Policy administrator role holders can update the TAP authentication method policy.
-To configure the TAP authentication method policy:
+Global administrator and Authentication Method Policy administrator role holders can update the Temporary Access Pass authentication method policy.
+To configure the Temporary Access Pass authentication method policy:
1. Sign in to the Azure portal as a Global admin and click **Azure Active Directory** > **Security** > **Authentication methods** > **Temporary Access Pass**. 1. Click **Yes** to enable the policy, select which users have the policy applied, and any **General** settings.
- ![Screenshot of how to enable the TAP authentication method policy](./media/how-to-authentication-temporary-access-pass/policy.png)
+ ![Screenshot of how to enable the Temporary Access Pass authentication method policy](./media/how-to-authentication-temporary-access-pass/policy.png)
The default value and the range of allowed values are described in the following table. | Setting | Default values | Allowed values | Comments | | ||-||--||
- Minimum lifetime | 1 hour | 10 ΓÇô 43200 Minutes (30 days) | Minimum number of minutes that the TAP is valid. | |
- | Maximum lifetime | 24 hours | 10 ΓÇô 43200 Minutes (30 days) | Maximum number of minutes that the TAP is valid. | |
+ Minimum lifetime | 1 hour | 10 ΓÇô 43200 Minutes (30 days) | Minimum number of minutes that the Temporary Access Pass is valid. | |
+ | Maximum lifetime | 24 hours | 10 ΓÇô 43200 Minutes (30 days) | Maximum number of minutes that the Temporary Access Pass is valid. | |
| Default lifetime | 1 hour | 10 ΓÇô 43200 Minutes (30 days) | Default values can be override by the individual passes, within the minimum and maximum lifetime configured by the policy | |
- | One-time use | False | True / False | When the policy is set to false, passes in the tenant can be used either once or more than once during its validity (maximum lifetime). By enforcing one-time use in the TAP policy, all passes created in the tenant will be created as one-time use. | |
+ | One-time use | False | True / False | When the policy is set to false, passes in the tenant can be used either once or more than once during its validity (maximum lifetime). By enforcing one-time use in the Temporary Access Pass policy, all passes created in the tenant will be created as one-time use. | |
| Length | 8 | 8-48 characters | Defines the length of the passcode. | |
-## Create a TAP in the Azure AD Portal
+## Create a Temporary Access Pass in the Azure AD Portal
-After you enable a TAP policy, you can create a TAP for a user in Azure AD.
-These roles can perform the following actions related to TAP.
+After you enable a policy, you can create a Temporary Access Pass for a user in Azure AD.
+These roles can perform the following actions related to a Temporary Access Pass.
-- Global administrator can create, delete, view TAP on any user (except themselves)-- Privileged Authentication administrators can create, delete, view TAP on admins and members (except themselves)-- Authentication administrators can create, delete, view TAP on members (except themselves)-- Global Administrator can view the TAP details on the user (without reading the code itself).
+- Global administrator can create, delete, view a Temporary Access Pass on any user (except themselves)
+- Privileged Authentication administrators can create, delete, view a Temporary Access Pass on admins and members (except themselves)
+- Authentication administrators can create, delete, view a Temporary Access Pass on members (except themselves)
+- Global Administrator can view the Temporary Access Pass details on the user (without reading the code itself).
-To create a TAP:
+To create a Temporary Access Pass:
1. Sign in to the portal as either a Global administrator, Privileged Authentication administrator, or Authentication administrator. 1. Click **Azure Active Directory**, browse to Users, select a user, such as *Chris Green*, then choose **Authentication methods**.
To create a TAP:
1. Below **Choose method**, click **Temporary Access Pass (Preview)**. 1. Define a custom activation time or duration and click **Add**.
- ![Screenshot of how to create a TAP](./media/how-to-authentication-temporary-access-pass/create.png)
+ ![Screenshot of how to create a Temporary Access Pass](./media/how-to-authentication-temporary-access-pass/create.png)
-1. Once added, the details of the TAP are shown. Make a note of the actual TAP value. You provide this value to the user. You can't view this value after you click **Ok**.
+1. Once added, the details of the Temporary Access Pass are shown. Make a note of the actual Temporary Access Pass value. You provide this value to the user. You can't view this value after you click **Ok**.
- ![Screenshot of TAP details](./media/how-to-authentication-temporary-access-pass/details.png)
+ ![Screenshot of Temporary Access Pass details](./media/how-to-authentication-temporary-access-pass/details.png)
-## Use a TAP
+## Use a Temporary Access Pass
-The most common use for a TAP is for a user to register authentication details during the first sign-in, without the need to complete additional security prompts. Authentication methods are registered at [https://aka.ms/mysecurityinfo](https://aka.ms/mysecurityinfo). Users can also update existing authentication methods here.
+The most common use for a Temporary Access Pass is for a user to register authentication details during the first sign-in, without the need to complete additional security prompts. Authentication methods are registered at [https://aka.ms/mysecurityinfo](https://aka.ms/mysecurityinfo). Users can also update existing authentication methods here.
1. Open a web browser to [https://aka.ms/mysecurityinfo](https://aka.ms/mysecurityinfo).
-1. Enter the UPN of the account you created the TAP for, such as *tapuser@contoso.com*.
-1. If the user is included in the TAP policy, they will see a screen to enter their TAP.
-1. Enter the TAP that was displayed in the Azure portal.
+1. Enter the UPN of the account you created the Temporary Access Pass for, such as *tapuser@contoso.com*.
+1. If the user is included in the Temporary Access Pass policy, they will see a screen to enter their Temporary Access Pass.
+1. Enter the Temporary Access Pass that was displayed in the Azure portal.
- ![Screenshot of how to enter a TAP](./media/how-to-authentication-temporary-access-pass/enter.png)
+ ![Screenshot of how to enter a Temporary Access Pass](./media/how-to-authentication-temporary-access-pass/enter.png)
>[!NOTE]
->For federated domains, a TAP is preferred over federation. A user with a TAP will complete the authentication in Azure AD and will not get redirected to the federated Identity Provider (IdP).
+>For federated domains, a Temporary Access Pass is preferred over federation. A user with a Temporary Access Pass will complete the authentication in Azure AD and will not get redirected to the federated Identity Provider (IdP).
The user is now signed in and can update or register a method such as FIDO2 security key. Users who update their authentication methods due to losing their credentials or device should make sure they remove the old authentication methods.
-Users can also use their TAP to register for Passwordless phone sign-in directly from the Authenticator app. For more information, see [Add your work or school account to the Microsoft Authenticator app](../user-help/user-help-auth-app-add-work-school-account.md).
+Users can also use their Temporary Access Pass to register for Passwordless phone sign-in directly from the Authenticator app. For more information, see [Add your work or school account to the Microsoft Authenticator app](../user-help/user-help-auth-app-add-work-school-account.md).
-![Screenshot of how to enter a TAP using work or school account](./media/how-to-authentication-temporary-access-pass/enter-work-school.png)
+![Screenshot of how to enter a Temporary Access Pass using work or school account](./media/how-to-authentication-temporary-access-pass/enter-work-school.png)
-## Delete a TAP
+## Delete a Temporary Access Pass
-An expired TAP canΓÇÖt be used. Under the **Authentication methods** for a user, the **Detail** column shows when the TAP expired. You can delete these expired TAPs using the following steps:
+An expired Temporary Access Pass canΓÇÖt be used. Under the **Authentication methods** for a user, the **Detail** column shows when the Temporary Access Pass expired. You can delete an expired Temporary Access Pass using the following steps:
1. In the Azure AD portal, browse to **Users**, select a user, such as *Tap User*, then choose **Authentication methods**. 1. On the right-hand side of the **Temporary Access Pass (Preview)** authentication method shown in the list, select **Delete**.
-## Replace a TAP
+## Replace a Temporary Access Pass
-- A user can only have one TAP. The passcode can be used during the start and end time of the TAP.-- If the user requires a new TAP:
- - If the existing TAP is valid, the admin needs to delete the existing TAP and create a new pass for the user. Deleting a valid TAP will revoke the userΓÇÖs sessions.
- - If the existing TAP has expired, a new TAP will override the existing TAP and will not revoke the userΓÇÖs sessions.
+- A user can only have one Temporary Access Pass. The passcode can be used during the start and end time of the Temporary Access Pass.
+- If the user requires a new Temporary Access Pass:
+ - If the existing Temporary Access Pass is valid, the admin needs to delete the existing Temporary Access Pass and create a new pass for the user. Deleting a valid Temporary Access Pass will revoke the userΓÇÖs sessions.
+ - If the existing Temporary Access Pass has expired, a new Temporary Access Pass will override the existing Temporary Access Pass and will not revoke the userΓÇÖs sessions.
For more information about NIST standards for onboarding and recovery, see [NIST Special Publication 800-63A](https://pages.nist.gov/800-63-3/sp800-63a.html#sec4).
For more information about NIST standards for onboarding and recovery, see [NIST
Keep these limitations in mind: -- When using a one-time TAP to register a Passwordless method such as FIDO2 or Phone sign-in, the user must complete the registration within 10 minutes of sign-in with the one-time TAP. This limitation does not apply to a TAP that can be used more than once.-- Guest users can't sign in with a TAP.-- Users in scope for Self Service Password Reset (SSPR) registration policy will be required to register one of the SSPR methods after they have signed in with TAP. If the user is only going to use FIDO2 key, exclude them from the SSPR policy or disable the SSPR registration policy. -- TAP cannot be used with the Network Policy Server (NPS) extension and Active Directory Federation Services (AD FS) adapter.-- When Seamless SSO is enabled on the tenant, the users are prompted to enter a password. The **Use your Temporary Access Pass instead** link will be available for the user to sign-in with TAP.
+- When using a one-time Temporary Access Pass to register a Passwordless method such as FIDO2 or Phone sign-in, the user must complete the registration within 10 minutes of sign-in with the one-time Temporary Access Pass. This limitation does not apply to a Temporary Access Pass that can be used more than once.
+- Guest users can't sign in with a Temporary Access Pass.
+- Users in scope for Self Service Password Reset (SSPR) registration policy will be required to register one of the SSPR methods after they have signed in with a Temporary Access Pass. If the user is only going to use FIDO2 key, exclude them from the SSPR policy or disable the SSPR registration policy.
+- A Temporary Access Pass cannot be used with the Network Policy Server (NPS) extension and Active Directory Federation Services (AD FS) adapter.
+- When Seamless SSO is enabled on the tenant, the users are prompted to enter a password. The **Use your Temporary Access Pass instead** link will be available for the user to sign-in with a Temporary Access Pass.
-![Screenshot of Use a TAP instead](./media/how-to-authentication-temporary-access-pass/alternative.png)
+![Screenshot of Use a Temporary Access Pass instead](./media/how-to-authentication-temporary-access-pass/alternative.png)
## Troubleshooting -- If TAP is not offered to a user during sign-in, check the following:
- - The user is in scope for the TAP authentication method policy.
- - The user has a valid TAP, and if it is one-time use, it wasnΓÇÖt used yet.
-- If **Temporary Access Pass sign in was blocked due to User Credential Policy** appears during sign-in with TAP, check the following:
- - The user has a multi-use TAP while the authentication method policy requires a one-time TAP.
- - A one-time TAP was already used.
+- If a Temporary Access Pass is not offered to a user during sign-in, check the following:
+ - The user is in scope for the Temporary Access Pass authentication method policy.
+ - The user has a valid Temporary Access Pass, and if it is one-time use, it wasnΓÇÖt used yet.
+- If **Temporary Access Pass sign in was blocked due to User Credential Policy** appears during sign-in with a Temporary Access Pass, check the following:
+ - The user has a multi-use Temporary Access Pass while the authentication method policy requires a one-time Temporary Access Pass.
+ - A one-time Temporary Access Pass was already used.
## Next steps
active-directory Howto Mfa Mfasettings https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-mfa-mfasettings.md
Previously updated : 06/05/2020 Last updated : 02/22/2021
OATH TOTP hardware tokens typically come with a secret key, or seed, pre-program
Programmable OATH TOTP hardware tokens that can be reseeded can also be set up with Azure AD in the software token setup flow.
-OATH hardware tokens are supported as part of a public preview. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/)
- ![Uploading OATH tokens to the MFA OATH tokens blade](media/concept-authentication-methods/mfa-server-oath-tokens-azure-ad.png) Once tokens are acquired they must be uploaded in a comma-separated values (CSV) file format including the UPN, serial number, secret key, time interval, manufacturer, and model as shown in the following example:
active-directory Howto Mfa Server Settings https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-mfa-server-settings.md
To create a one-time bypass, complete the following steps:
1. Search for and select **Azure Active Directory**, then browse to **Security** > **MFA** > **One-time bypass**. 1. Select **Add**. 1. If necessary, select the replication group for the bypass.
-1. Enter the username as `username\@domain.com`. Enter the number of seconds that the bypass should last and the reason for the bypass.
+1. Enter the username as `username@domain.com`. Enter the number of seconds that the bypass should last and the reason for the bypass.
1. Select **Add**. The time limit goes into effect immediately. The user needs to sign in before the one-time bypass expires. You can also view the one-time bypass report from this same window.
active-directory Howto Password Ban Bad On Premises Agent Versions https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-password-ban-bad-on-premises-agent-versions.md
# Azure AD Password Protection agent version history
+## 1.2.172.0
+
+Release date: February 22nd 2021
+
+It has been almost two years since the GA versions of the on-premises Azure AD Password Protection agents were released. A new update is now available - see change descriptions below. Thank you to everyone who has given us feedback on the product.
+
+* The DC agent and Proxy agent software both now require .NET 4.7.2 to be installed.
+ * If .NET 4.7.2 is not already installed, download and run the installer found at [The .NET Framework 4.7.2 offline installer for Windows](https://support.microsoft.com/topic/microsoft-net-framework-4-7-2-offline-installer-for-windows-05a72734-2127-a15d-50cf-daf56d5faec2).
+* The AzureADPasswordProtection PowerShell module is now also installed by the DC agent software.
+* Two new health-related PowerShell cmdlets have been added: Test-AzureADPasswordProtectionDCAgent and Test-AzureADPasswordProtectionProxy.
+* The AzureADPasswordProtection DC Agent password filter dll will now load and run on machines where lsass.exe is configured to run in PPL mode.
+* Bug fix to password algorithm that allowed banned passwords fewer than five characters in length to be incorrectly accepted.
+ * This bug is only applicable if your on-premises AD minimum password length policy was configured to allow fewer than five character passwords in the first place.
+* Other minor bug fixes.
+
+The new installers will automatically upgrade older versions of the software. If you have installed both the DC agent and the Proxy software on a single machine (only recommended for test environments), you must upgrade both at the same time.
+
+It is supported to run older and newer versions of the DC agent and proxy software within a domain or forest, although we recommend upgrading all agents to the latest version as a best practice. Any ordering of agent upgrades is supported - new DC agents can communicate through older Proxy agents, and older DC agents can communicate through newer Proxy agents.
+ ## 1.2.125.0
-Release date: 3/22/2019
+Release date: March 22nd 2019
* Fix minor typo errors in event log messages * Update EULA agreement to final General Availability version
Release date: 3/13/2019
* Software version and Azure tenant data are only available for DC agents and proxies running version 1.2.116.0 or later. * Azure tenant data may not be reported until a re-registration (or renewal) of the proxy or forest has occurred. * The Proxy service now requires that .NET 4.7 is installed.
- * .NET 4.7 should already be installed on a fully updated Windows Server. If this is not the case, download and run the installer found at [The .NET Framework 4.7 offline installer for Windows](https://support.microsoft.com/help/3186497/the-net-framework-4-7-offline-installer-for-windows).
- * On Server Core systems it may be necessary to pass the /q flag to the .NET 4.7 installer to get it to succeed.
-* The Proxy service now supports automatic upgrade. Automatic upgrade uses the Microsoft Azure AD Connect Agent Updater service which is installed side-by-side with the Proxy service. Automatic upgrade is on by default.
+ * If .NET 4.7 is not already installed, download and run the installer found at [The .NET Framework 4.7 offline installer for Windows](https://support.microsoft.com/help/3186497/the-net-framework-4-7-offline-installer-for-windows).
+ * On Server Core systems, it may be necessary to pass the /q flag to the .NET 4.7 installer to get it to succeed.
+* The Proxy service now supports automatic upgrade. Automatic upgrade uses the Microsoft Azure AD Connect Agent Updater service, which is installed side by side with the Proxy service. Automatic upgrade is on by default.
* Automatic upgrade can be enabled or disabled using the Set-AzureADPasswordProtectionProxyConfiguration cmdlet. The current setting can be queried using the Get-AzureADPasswordProtectionProxyConfiguration cmdlet. * The service binary for the DC agent service has been renamed to AzureADPasswordProtectionDCAgent.exe. * The service binary for the Proxy service has been renamed to AzureADPasswordProtectionProxy.exe. Firewall rules may need to be modified accordingly if a third-party firewall is in-use.
Release date: 3/13/2019
## 1.2.65.0
-Release date: 2/1/2019
+Release date: February 1st 2019
Changes: * DC agent and proxy service are now supported on Server Core. Mininimum OS requirements are unchanged from before: Windows Server 2012 for DC agents, and Windows Server 2012 R2 for proxies. * The Register-AzureADPasswordProtectionProxy and Register-AzureADPasswordProtectionForest cmdlets now support device-code-based Azure authentication modes.
-* The Get-AzureADPasswordProtectionDCAgent cmdlet will ignore mangled and/or invalid service connection points. This fixes the bug where domain controllers would sometimes show up multiple times in the output.
-* The Get-AzureADPasswordProtectionSummaryReport cmdlet will ignore mangled and/or invalid service connection points. This fixes the bug where domain controllers would sometimes show up multiple times in the output.
-* The Proxy powershell module is now registered from %ProgramFiles%\WindowsPowerShell\Modules. The machine's PSModulePath environment variable is no longer modified.
+* The Get-AzureADPasswordProtectionDCAgent cmdlet will ignore mangled and/or invalid service connection points. This change fixes the bug where domain controllers would sometimes show up multiple times in the output.
+* The Get-AzureADPasswordProtectionSummaryReport cmdlet will ignore mangled and/or invalid service connection points. This change fixes the bug where domain controllers would sometimes show up multiple times in the output.
+* The Proxy PowerShell module is now registered from %ProgramFiles%\WindowsPowerShell\Modules. The machine's PSModulePath environment variable is no longer modified.
* A new Get-AzureADPasswordProtectionProxy cmdlet has been added to aid in discovering registered proxies in a forest or domain. * The DC agent uses a new folder in the sysvol share for replicating password policies and other files.
Changes:
* Each DC agent will periodically delete mangled and stale service connection points in its domain, for both DC agent and proxy service connection points. Both DC agent and proxy service connection points are considered stale if its heartbeat timestamp is older than seven days. * The DC agent will now renew the forest certificate as needed. * The Proxy service will now renew the proxy certificate as needed.
-* Updates to password validation algorithm: the global banned password list and customer-specific banned password list (if configured) are combined prior to password validations. A given password may now be rejected (fail or audit-only) if it contains tokens from both the global and customer-specific list. The event log documentation has been updated to reflect this; please see [Monitor Azure AD Password Protection](howto-password-ban-bad-on-premises-monitor.md).
+* Updates to password validation algorithm: the global banned password list and customer-specific banned password list (if configured) are combined prior to password validations. A given password may now be rejected (fail or audit-only) if it contains tokens from both the global and customer-specific list. The event log documentation has been updated to reflect this; see [Monitor Azure AD Password Protection](howto-password-ban-bad-on-premises-monitor.md).
* Performance and robustness fixes * Improved logging
Changes:
## 1.2.25.0
-Release date: 11/01/2018
+Release date: November 1st 2018
Fixes: * DC agent and proxy service should no longer fail due to certificate trust failures.
-* DC agent and proxy service have additional fixes for FIPS-compliant machines.
+* DC agent and proxy service have fixes for FIPS-compliant machines.
* Proxy service will now work properly in a TLS 1.2-only networking environment. * Minor performance and robustness fixes * Improved logging
Changes:
* The minimum required OS level for the Proxy service is now Windows Server 2012 R2. The minimum required OS level for the DC agent service remains at Windows Server 2012. * The Proxy service now requires .NET version 4.6.2.
-* The password validation algorithm uses an expanded character normalization table. This may result in passwords being rejected that were accepted in prior versions.
+* The password validation algorithm uses an expanded character normalization table. This change may result in passwords being rejected that were accepted in prior versions.
## 1.2.10.0
-Release date: 8/17/2018
+Release date: August 17th 2018
Fixes:
Fixes:
## 1.1.10.3
-Release date: 6/15/2018
+Release date:June 15th 2018
Initial public preview release
active-directory Howto Password Ban Bad On Premises Deploy https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-password-ban-bad-on-premises-deploy.md
It's also possible for stronger password validation to affect your existing Acti
* [Domain controller replica promotion fails because of a weak Directory Services Repair Mode password](howto-password-ban-bad-on-premises-troubleshoot.md#domain-controller-replica-promotion-fails-because-of-a-weak-dsrm-password) * [Domain controller demotion fails due to a weak local Administrator password](howto-password-ban-bad-on-premises-troubleshoot.md#domain-controller-demotion-fails-due-to-a-weak-local-administrator-password)
-After the feature has been running in audit mode for a reasonable period, you can switch the configuration from *Audit* to *Enforce* to require more secure passwords. Additional monitoring during this time is a good idea.
+After the feature has been running in audit mode for a reasonable period, you can switch the configuration from *Audit* to *Enforce* to require more secure passwords. Extra monitoring during this time is a good idea.
It is important to note that Azure AD Password Protection can only validate passwords during password change or set operations. Passwords that were accepted and stored in Active Directory prior to the deployment of Azure AD Password Protection will never be validated and will continue working as-is. Over time, all users and accounts will eventually start using Azure AD Password Protection-validated passwords as their existing passwords expire normally. Accounts configured with "password never expires" are exempt from this.
The following requirements apply to the Azure AD Password Protection DC agent:
* All machines where the Azure AD Password Protection DC agent software will be installed must run Windows Server 2012 or later, including Windows Server Core editions. * The Active Directory domain or forest doesn't need to be at Windows Server 2012 domain functional level (DFL) or forest functional level (FFL). As mentioned in [Design Principles](concept-password-ban-bad-on-premises.md#design-principles), there's no minimum DFL or FFL required for either the DC agent or proxy software to run.
-* All machines that run the Azure AD Password Protection DC agent must have .NET 4.5 installed.
+* All machines where the Azure AD Password Protection proxy service will be installed must have .NET 4.7.2 installed.
+ * If .NET 4.7.2 is not already installed, download and run the installer found at [The .NET Framework 4.7.2 offline installer for Windows](https://support.microsoft.com/topic/microsoft-net-framework-4-7-2-offline-installer-for-windows-05a72734-2127-a15d-50cf-daf56d5faec2).
* Any Active Directory domain that runs the Azure AD Password Protection DC agent service must use Distributed File System Replication (DFSR) for sysvol replication. * If your domain isn't already using DFSR, you must migrate before installing Azure AD Password Protection. For more information, see [SYSVOL Replication Migration Guide: FRS to DFS Replication](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd640019(v=ws.10))
The following requirements apply to the Azure AD Password Protection proxy servi
> [!NOTE] > The Azure AD Password Protection proxy service deployment is a mandatory requirement for deploying Azure AD Password Protection even though the domain controller may have outbound direct internet connectivity.
-* All machines where the Azure AD Password Protection proxy service will be installed must have .NET 4.7 installed.
- * .NET 4.7 should already be installed on a fully updated Windows Server. If necessary, download and run the installer found at [The .NET Framework 4.7 offline installer for Windows](https://support.microsoft.com/help/3186497/the-net-framework-4-7-offline-installer-for-windows).
+* All machines where the Azure AD Password Protection proxy service will be installed must have .NET 4.7.2 installed.
+ * If .NET 4.7.2 is not already installed, download and run the installer found at [The .NET Framework 4.7.2 offline installer for Windows](https://support.microsoft.com/topic/microsoft-net-framework-4-7-2-offline-installer-for-windows-05a72734-2127-a15d-50cf-daf56d5faec2).
* All machines that host the Azure AD Password Protection proxy service must be configured to grant domain controllers the ability to log on to the proxy service. This ability is controlled via the "Access this computer from the network" privilege assignment. * All machines that host the Azure AD Password Protection proxy service must be configured to allow outbound TLS 1.2 HTTP traffic. * A *Global Administrator* or *Security Administrator* account to register the Azure AD Password Protection proxy service and forest with Azure AD.
In the next section, you install the Azure AD Password Protection DC agents on d
Choose one or more servers to host the Azure AD Password Protection proxy service. The following considerations apply for the server(s): * Each such service can only provide password policies for a single forest. The host machine must be joined to any domain in that forest.
-* It does supported to install proxy the service in either root or child domains, or a combination of those.
+* You can install the proxy service in either root or child domains, or a combination of those.
* You need network connectivity between at least one DC in each domain of the forest and one password protection proxy server. * You can run the Azure AD Password Protection proxy service on a domain controller for testing, but that domain controller then requires internet connectivity. This connectivity can be a security concern. We recommend this configuration for testing only. * We recommend at least two Azure AD Password Protection proxy servers per forest for redundancy, as noted in the previous section on [high availability considerations](#high-availability-considerations).
To install the Azure AD Password Protection proxy service, complete the followin
This cmdlet requires either *Global Administrator* or *Security Administrator* credentials for your Azure tenant. This cmdlet must also be run using an account with local administrator privileges.
- After this command succeeds once for a Azure AD Password Protection proxy service, additional invocations of it succeed, but are unnecessary.
+ After this command succeeds once, additional invocations will also succeed but are unnecessary.
The `Register-AzureADPasswordProtectionProxy` cmdlet supports the following three authentication modes. The first two modes support Azure AD Multi-Factor Authentication but the third mode doesn't.
active-directory Howto Password Ban Bad On Premises Troubleshoot https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-password-ban-bad-on-premises-troubleshoot.md
If it is decided to uninstall the Azure AD password protection software and clea
This path is different if the sysvol share has been configured in a non-default location.
+## Health testing with PowerShell cmdlets
+
+The AzureADPasswordProtection PowerShell module includes two health-related cmdlets that perform basic verification that the software is installed and working. It is a good idea to run these cmdlets after setting up a new deployment, periodically thereafter, and when a problem is being investigated.
+
+Each individual health test returns a basic Passed or Failed result, plus an optional message on failure. In cases where the cause of a failure is not clear, look for error event log messages that may explain the failure. Enabling text-log messages may also be useful. For more details please see [Monitor Azure AD Password Protection](howto-password-ban-bad-on-premises-monitor.md).
+
+## Proxy health testing
+
+The Test-AzureADPasswordProtectionProxyHealth cmdlet supports two health tests that can be run individually. A third mode allows for the running of all tests that do not require any parameter input.
+
+### Proxy registration verification
+
+This test verifies that the Proxy agent is properly registered with Azure and is able to authenticate to Azure. A successful run will look like this:
+
+```powershell
+PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration
+
+DiagnosticName Result AdditionalInfo
+-- --
+VerifyProxyRegistration Passed
+```
+
+If an error is detected, the test will return a Failed result and an optional error message. Here is an example of one possible failure:
+
+```powershell
+PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration
+
+DiagnosticName Result AdditionalInfo
+-- --
+VerifyProxyRegistration Failed No proxy certificates were found - please run the Register-AzureADPasswordProtectionProxy cmdlet to register the proxy.
+```
+
+### Proxy verification of end-to-end Azure connectivity
+
+This test is a superset of the -VerifyProxyRegistration test. It requires that the Proxy agent is properly registered with Azure, is able to authenticate to Azure, and finally adds a check that a message can be successfully sent to Azure thus verifying full end-to-end communication is working.
+
+A successful run will look like this:
+
+```powershell
+PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyAzureConnectivity
+
+DiagnosticName Result AdditionalInfo
+-- --
+VerifyAzureConnectivity Passed
+```
+
+### Proxy verification of all tests
+
+This mode allows for the bulk running of all tests supported by the cmdlet that do not require parameter input. A successful run will look like this:
+
+```powershell
+PS C:\> Test-AzureADPasswordProtectionProxyHealth -TestAll
+
+DiagnosticName Result AdditionalInfo
+-- --
+VerifyTLSConfiguration Passed
+VerifyProxyRegistration Passed
+VerifyAzureConnectivity Passed
+```
+
+## DC Agent health testing
+
+The Test-AzureADPasswordProtectionDCAgentHealth cmdlet supports several health tests that can be run individually. A third mode allows for the running of all tests that do not require any parameter input.
+
+### Basic DC agent health tests
+
+The following tests can all be run individually and do not accept. A brief description
+
+|DC agent health test|Description|
+| | :: |
+|-VerifyPasswordFilterDll|Verifies that the password filter dll is currently loaded and is able to call the DC agent service|
+|-VerifyForestRegistration|Verifies that the forest is currently registered|
+|-VerifyEncryptionDecryption|Verifies that basic encryption and decryption is working using the Microsoft KDS service|
+|-VerifyDomainIsUsingDFSR|Verifies that the current domain is using DFSR for sysvol replication|
+|-VerifyAzureConnectivity|Verifies end-to-end communication with Azure is working using any available proxy|
+
+Here is an example of the -VerifyPasswordFilterDll test passing; the other tests will look similar on success:
+
+```powershell
+PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyPasswordFilterDll
+
+DiagnosticName Result AdditionalInfo
+-- --
+VerifyPasswordFilterDll Passed
+```
+
+### DC agent verification of all tests
+
+This mode allows for the bulk running of all tests supported by the cmdlet that do not require parameter input. A successful run will look like this:
+
+```powershell
+PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -TestAll
+
+DiagnosticName Result AdditionalInfo
+-- --
+VerifyPasswordFilterDll Passed
+VerifyForestRegistration Passed
+VerifyEncryptionDecryption Passed
+VerifyDomainIsUsingDFSR Passed
+VerifyAzureConnectivity Passed
+```
+
+### Connectivity testing using specific proxy servers
+
+Many troubleshooting situations involve investigating network connectivity between DC agents and proxies. There are two health tests available to focus on such issues specifically. These tests require that a particular proxy server be specified.
+
+#### Verifying connectivity between a DC agent and a specific proxy
+
+This test validates connectivity over the first communication leg from the DC agent to the proxy. It verifies that the proxy receives the call, however no communication with Azure is involved. A successful run looks like this:
+
+```powershell
+PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyProxyConnectivity bpl2.bpl.com
+
+DiagnosticName Result AdditionalInfo
+-- --
+VerifyProxyConnectivity Passed
+```
+
+Here is an example failure condition where the proxy service running on the target server has been stopped:
+
+```powershell
+PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyProxyConnectivity bpl2.bpl.com
+
+DiagnosticName Result AdditionalInfo
+-- --
+VerifyProxyConnectivity Failed The RPC endpoint mapper on the specified proxy returned no results; please check that the proxy service is running on that server.
+```
+
+#### Verifying connectivity between a DC agent and Azure (using a specific proxy)
+
+This test validates full end-to-end connectivity between a DC agent and Azure using a specific proxy. A successful run looks like this:
+
+```powershell
+PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyAzureConnectivityViaSpecificProxy bpl2.bpl.com
+
+DiagnosticName Result AdditionalInfo
+-- --
+VerifyAzureConnectivityViaSpecificProxy Passed
+```
+ ## Next steps [Frequently asked questions for Azure AD Password Protection](howto-password-ban-bad-on-premises-faq.md)
active-directory Active Directory Acs Migration https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/azuread-dev/active-directory-acs-migration.md
As of November 2017, all Access Control components are fully supported and opera
Here's the schedule for deprecating Access Control components: - **November 2017**: The Azure AD admin experience in the Azure classic portal [is retired](https://blogs.technet.microsoft.com/enterprisemobility/2017/09/18/marching-into-the-future-of-the-azure-ad-admin-experience-retiring-the-azure-classic-portal/). At this point, namespace management for Access Control is available at a new, dedicated URL: `https://manage.windowsazure.com?restoreClassic=true`. Use this URl to view your existing namespaces, enable and disable namespaces, and to delete namespaces, if you choose to.-- **April 2, 2018**: The Azure classic portal is completely retired, meaning Access Control namespace management is no longer available via any URL. At this point, you can't disable or enable, delete, or enumerate your Access Control namespaces. However, the Access Control management portal will be fully functional and located at `https://\<namespace\>.accesscontrol.windows.net`. All other components of Access Control continue to operate normally.
+- **April 2, 2018**: The Azure classic portal is completely retired, meaning Access Control namespace management is no longer available via any URL. At this point, you can't disable or enable, delete, or enumerate your Access Control namespaces. However, the Access Control management portal will be fully functional and located at `https://<namespace>.accesscontrol.windows.net`. All other components of Access Control continue to operate normally.
- **November 7, 2018**: All Access Control components are permanently shut down. This includes the Access Control management portal, the management service, STS, and the token transformation rule engine. At this point, any requests sent to Access Control (located at \<namespace\>.accesscontrol.windows.net) fail. You should have migrated all existing apps and services to other technologies well before this time. > [!NOTE]
active-directory Azure Ad Federation Metadata https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/azuread-dev/azure-ad-federation-metadata.md
In the WS-Federation-specific section, a WS-Federation metadata reader would rea
The following metadata shows a sample `RoleDescriptor` element. ```
-<RoleDescriptor xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:fed="https://docs.oasis-open.org/wsfed/federation/200706" xsi:type="fed:SecurityTokenServiceType"protocolSupportEnumeration="https://docs.oasis-open.org/wsfed/federation/200706">
+<RoleDescriptor xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:fed="https://docs.oasis-open.org/wsfed/federation/200706" xsi:type="fed:SecurityTokenServiceType" protocolSupportEnumeration="https://docs.oasis-open.org/wsfed/federation/200706">
``` In the SAML-specific section, a WS-Federation metadata reader would read the certificates from a `IDPSSODescriptor` element.
active-directory Howto Get Appsource Certified https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/azuread-dev/howto-get-appsource-certified.md
For more information about the AppSource trial experience, see [this video](http
## Get support
-For Azure AD integration, we use [Microsoft Q&A](https://docs.microsoft.com/answers/products/) with the community to provide support.
+For Azure AD integration, we use [Microsoft Q&A](/answers/products/) with the community to provide support.
-We highly recommend you ask your questions on Microsoft Q&A first and browse existing issues to see if someone has asked your question before. Make sure that your questions or comments are tagged with [`[azure-active-directory]`](https://docs.microsoft.com/answers/topics/azure-active-directory.html).
+We highly recommend you ask your questions on Microsoft Q&A first and browse existing issues to see if someone has asked your question before. Make sure that your questions or comments are tagged with [`[azure-active-directory]`](/answers/topics/azure-active-directory.html).
Use the following comments section to provide feedback and help us refine and shape our content.
active-directory How To Gmsa Cmdlets https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/cloud-sync/how-to-gmsa-cmdlets.md
The following prerequisites are required to use these cmdlets.
2. Import Provisioning Agent PS module into a PowerShell session. ```PowerShell
- Import-Module "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\Microsoft.CloudSync.Powershell.dll" 
+ Import-Module "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\Microsoft.CloudSync.Powershell.dll" 
``` 3. Remove existing permissions. To remove all existing permissions on the service account, except SELF use: `Set-AADCloudSyncRestrictedPermission`.
active-directory How To Prerequisites https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/cloud-sync/how-to-prerequisites.md
Previously updated : 12/11/2020 Last updated : 03/02/2021
You need the following to use Azure AD Connect cloud sync:
- Domain Administrator or Enterprise Administrator credentials to create the Azure AD Connect Cloud Sync gMSA (group Managed Service Account) to run the agent service. - A hybrid identity administrator account for your Azure AD tenant that is not a guest user.-- An on-premises server for the provisioning agent with Windows 2012 R2 or later. This server should be a tier 0 server based on the [Active Directory administrative tier model](/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material).
+- An on-premises server for the provisioning agent with Windows 2016 or later. This server should be a tier 0 server based on the [Active Directory administrative tier model](/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material).
- On-premises firewall configurations. ## Group Managed Service Accounts A group Managed Service Account is a managed domain account that provides automatic password management, simplified service principal name (SPN) management,the ability to delegate the management to other administrators, and also extends this functionality over multiple servers. Azure AD Connect Cloud Sync supports and uses a gMSA for running the agent. You will be prompted for administrative credentials during setup, in order to create this account. The account will appear as (domain\provAgentgMSA$). For more information on a gMSA, see [Group Managed Service Accounts](/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) ### Prerequisites for gMSA:
-1. The Active Directory schema in the gMSA domain's forest needs to be updated to Windows Server 2012
+1. The Active Directory schema in the gMSA domain's forest needs to be updated to Windows Server 2012.
2. [PowerShell RSAT modules](/windows-server/remote/remote-server-administration-tools) on a domain controller
-3. At least one domain controller in the domain must be running Windows Server 2012.
+3. At least one domain controller in the domain must be running Windows Server 201.
4. A domain joined server where the agent is being installed needs to be either Windows Server 2012 or later. ### Custom gMSA account
Run the [IdFix tool](/office365/enterprise/prepare-directory-attributes-for-sync
### In your on-premises environment
-1. Identify a domain-joined host server running Windows Server 2012 R2 or greater with a minimum of 4-GB RAM and .NET 4.7.1+ runtime.
+1. Identify a domain-joined host server running Windows Server 2016 or greater with a minimum of 4-GB RAM and .NET 4.7.1+ runtime.
2. The PowerShell execution policy on the local server must be set to Undefined or RemoteSigned.
active-directory Reference Error Codes https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/cloud-sync/reference-error-codes.md
The following is a list of error codes and their description
|HybridIdentityServiceInvalidResource|Error Message: We were unable to process this request at this point. If this issue persists, please contact support and provide the following job identifier: AD2AADProvisioning.3a2a0d8418f34f54a03da5b70b1f7b0c.d583d090-9cd3-4d0a-aee6-8d666658c3e9. Additional details: There seems to be an issue with your cloud sync setup. Please re-register your cloud sync agent on your on-prem AD domain and restart configuration from Azure Portal.|The resource name must be set so HIS knows which agent to contact.|Please re-register your cloud sync agent on your on-prem AD domain and restart configuration from Azure Portal.| |HybridIdentityServiceAgentSignalingError|Error Message: We were unable to process this request at this point. If this issue persists, please contact support and provide the following job identifier: AD2AADProvisioning.92d2e8750f37407fa2301c9e52ad7e9b.efb835ef-62e8-42e3-b495-18d5272eb3f9. Additional details: We were unable to process this request at this point. If this issue persists, please contact support with Job ID (from status pane of your configuration).|Service Bus is not able to send a message to the agent. Could be an outage in service bus, or the agent is not responsive.|If this issue persists, please contact support with Job ID (from status pane of your configuration).| |AzureDirectoryServiceServerBusy|Error Message: An error occurred. Error Code: 81. Error Description: Azure Active Directory is currently busy. This operation will be retried automatically. If this issue persists for more than 24 hours, contact Technical Support. Tracking ID: 8a4ab3b5-3664-4278-ab64-9cff37fd3f4f Server Name:|Azure Active Directory is currently busy.|If this issue persists for more than 24 hours, contact Technical Support.|
-|AzureActiveDirectoryInvalidCredential|Error Message: We found an issue with the service account that is used to run Azure AD Connect Cloud Sync. You can repair the cloud service account by following the instructions at [here](https://go.microsoft.com/fwlink/?linkid=2150988). If the error persists, please contact support with Job ID (from status pane of your configuration). Additional Error Details: CredentialsInvalid AADSTS50034: The user account {EmailHidden} does not exist in the skydrive365.onmicrosoft.com directory. To sign into this application, the account must be added to the directory. Trace ID: 14b63033-3bc9-4bd4-b871-5eb4b3500200 Correlation ID: 57d93ed1-be4d-483c-997c-a3b6f03deb00 Timestamp: 2021-01-12 21:08:29Z |This error is thrown when the sync service account ADToAADSyncServiceAccount doesn't exist in the tenant. It can be due to accidental deletion of the account.|Use [Repair-AADCloudSyncToolsAccount](reference-powershell.md#repair-aadcloudsynctoolsaccount) to fix the service account.|
+|AzureActiveDirectoryInvalidCredential|Error Message: We found an issue with the service account that is used to run Azure AD Connect Cloud Sync. You can repair the cloud service account by following the instructions at [here](./how-to-troubleshoot.md). If the error persists, please contact support with Job ID (from status pane of your configuration). Additional Error Details: CredentialsInvalid AADSTS50034: The user account {EmailHidden} does not exist in the skydrive365.onmicrosoft.com directory. To sign into this application, the account must be added to the directory. Trace ID: 14b63033-3bc9-4bd4-b871-5eb4b3500200 Correlation ID: 57d93ed1-be4d-483c-997c-a3b6f03deb00 Timestamp: 2021-01-12 21:08:29Z |This error is thrown when the sync service account ADToAADSyncServiceAccount doesn't exist in the tenant. It can be due to accidental deletion of the account.|Use [Repair-AADCloudSyncToolsAccount](reference-powershell.md#repair-aadcloudsynctoolsaccount) to fix the service account.|
|AzureActiveDirectoryExpiredCredentials|Error Message: We were unable to process this request at this point. If this issue persists, please contact support with Job ID (from status pane of your configuration). Additional Error Details: CredentialsExpired AADSTS50055: The password is expired. Trace ID: 989b1841-dbe5-49c9-ab6c-9aa25f7b0e00 Correlation ID: 1c69b196-1c3a-4381-9187-c84747807155 Timestamp: 2021-01-12 20:59:31Z | Response status code does not indicate success: 401 (Unauthorized).|AAD Sync service account credentials are expired.|You can repair the cloud service account by following the instructions at https://go.microsoft.com/fwlink/?linkid=2150988. If the error persists, please contact support with Job ID (from status pane of your configuration). Additional Error Details: Your administrative Azure Active Directory tenant credentials were exchanged for an OAuth token that has since expired."| |AzureActiveDirectoryAuthenticationFailed|Error Message: We were unable to process this request at this point. If this issue persists, please contact support and provide the following job identifier: AD2AADProvisioning.60b943e88f234db2b887f8cb91dee87c.707be0d2-c6a9-405d-a3b9-de87761dc3ac. Additional details: We were unable to process this request at this point. If this issue persists, please contact support with Job ID (from status pane of your configuration). Additional Error Details: UnexpectedError.|Unknown error.|If this issue persists, please contact support with Job ID (from status pane of your configuration).| ## Next steps - [What is provisioning?](what-is-provisioning.md)-- [What is Azure AD Connect cloud sync?](what-is-cloud-sync.md)
+- [What is Azure AD Connect cloud sync?](what-is-cloud-sync.md)
active-directory Access Tokens https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/access-tokens.md
Previously updated : 10/27/2020 Last updated : 2/18/2021
Some claims are used to help Azure AD secure tokens in case of reuse. These are
| `name` | String | Provides a human-readable value that identifies the subject of the token. The value is not guaranteed to be unique, it is mutable, and it's designed to be used only for display purposes. The `profile` scope is required in order to receive this claim. | | `scp` | String, a space separated list of scopes | The set of scopes exposed by your application for which the client application has requested (and received) consent. Your app should verify that these scopes are valid ones exposed by your app, and make authorization decisions based on the value of these scopes. Only included for [user tokens](#user-and-application-tokens). | | `roles` | Array of strings, a list of permissions | The set of permissions exposed by your application that the requesting application or user has been given permission to call. For [application tokens](#user-and-application-tokens), this is used during the client credential flow ([v1.0](../azuread-dev/v1-oauth2-client-creds-grant-flow.md), [v2.0](v2-oauth2-client-creds-grant-flow.md)) in place of user scopes. For [user tokens](#user-and-application-tokens) this is populated with the roles the user was assigned to on the target application. |
-| `wids` | Array of [RoleTemplateID](../roles/permissions-reference.md#role-template-ids) GUIDs | Denotes the tenant-wide roles assigned to this user, from the section of roles present in [the admin roles page](../roles/permissions-reference.md#role-template-ids). This claim is configured on a per-application basis, through the `groupMembershipClaims` property of the [application manifest](reference-app-manifest.md). Setting it to "All" or "DirectoryRole" is required. May not be present in tokens obtained through the implicit flow due to token length concerns. |
+| `wids` | Array of [RoleTemplateID](../roles/permissions-reference.md#all-roles) GUIDs | Denotes the tenant-wide roles assigned to this user, from the section of roles present in [Azure AD built-in roles](../roles/permissions-reference.md#all-roles). This claim is configured on a per-application basis, through the `groupMembershipClaims` property of the [application manifest](reference-app-manifest.md). Setting it to "All" or "DirectoryRole" is required. May not be present in tokens obtained through the implicit flow due to token length concerns. |
| `groups` | JSON array of GUIDs | Provides object IDs that represent the subject's group memberships. These values are unique (see Object ID) and can be safely used for managing access, such as enforcing authorization to access a resource. The groups included in the groups claim are configured on a per-application basis, through the `groupMembershipClaims` property of the [application manifest](reference-app-manifest.md). A value of null will exclude all groups, a value of "SecurityGroup" will include only Active Directory Security Group memberships, and a value of "All" will include both Security Groups and Microsoft 365 Distribution Lists. <br><br>See the `hasgroups` claim below for details on using the `groups` claim with the implicit grant. <br>For other flows, if the number of groups the user is in goes over a limit (150 for SAML, 200 for JWT), then an overage claim will be added to the claim sources pointing at the Microsoft Graph endpoint containing the list of groups for the user. | | `hasgroups` | Boolean | If present, always `true`, denoting the user is in at least one group. Used in place of the `groups` claim for JWTs in implicit grant flows if the full groups claim would extend the URI fragment beyond the URL length limits (currently 6 or more groups). Indicates that the client should use the Microsoft Graph API to determine the user's groups (`https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects`). | | `groups:src1` | JSON object | For token requests that are not length limited (see `hasgroups` above) but still too large for the token, a link to the full groups list for the user will be included. For JWTs as a distributed claim, for SAML as a new claim in place of the `groups` claim. <br><br>**Example JWT Value**: <br> `"groups":"src1"` <br> `"_claim_sources`: `"src1" : { "endpoint" : "https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects" }` | | `sub` | String | The principal about which the token asserts information, such as the user of an app. This value is immutable and cannot be reassigned or reused. It can be used to perform authorization checks safely, such as when the token is used to access a resource, and can be used as a key in database tables. Because the subject is always present in the tokens that Azure AD issues, we recommend using this value in a general-purpose authorization system. The subject is, however, a pairwise identifier - it is unique to a particular application ID. Therefore, if a single user signs into two different apps using two different client IDs, those apps will receive two different values for the subject claim. This may or may not be desired depending on your architecture and privacy requirements. See also the `oid` claim (which does remain the same across apps within a tenant). |
-| `oid` | String, a GUID | The immutable identifier for an object in the Microsoft identity platform, in this case, a user account. It can also be used to perform authorization checks safely and as a key in database tables. This ID uniquely identifies the user across applications - two different applications signing in the same user will receive the same value in the `oid` claim. Thus, `oid` can be used when making queries to Microsoft online services, such as the Microsoft Graph. The Microsoft Graph will return this ID as the `id` property for a given [user account](/graph/api/resources/user). Because the `oid` allows multiple apps to correlate users, the `profile` scope is required in order to receive this claim. Note that if a single user exists in multiple tenants, the user will contain a different object ID in each tenant - they are considered different accounts, even though the user logs into each account with the same credentials. |
+| `oid` | String, a GUID | The immutable identifier for the "principal" of the request - the user or service principal whose identity has been verified. In ID tokens and app+user tokens, this is the object ID of the user. In app-only tokens, this is the object id of the calling service principal. It can also be used to perform authorization checks safely and as a key in database tables. This ID uniquely identifies the principal across applications - two different applications signing in the same user will receive the same value in the `oid` claim. Thus, `oid` can be used when making queries to Microsoft online services, such as the Microsoft Graph. The Microsoft Graph will return this ID as the `id` property for a given [user account](/graph/api/resources/user). Because the `oid` allows multiple apps to correlate principals, the `profile` scope is required in order to receive this claim for users. Note that if a single user exists in multiple tenants, the user will contain a different object ID in each tenant - they are considered different accounts, even though the user logs into each account with the same credentials. |
| `tid` | String, a GUID | Represents the Azure AD tenant that the user is from. For work and school accounts, the GUID is the immutable tenant ID of the organization that the user belongs to. For personal accounts, the value is `9188040d-6c67-4c5b-b112-36a304b66dad`. The `profile` scope is required in order to receive this claim. | | `unique_name` | String | Only present in v1.0 tokens. Provides a human readable value that identifies the subject of the token. This value is not guaranteed to be unique within a tenant and should be used only for display purposes. | | `uti` | Opaque String | An internal claim used by Azure to revalidate tokens. Resources shouldn't use this claim. |
active-directory Active Directory Enterprise App Role Management https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/active-directory-enterprise-app-role-management.md
By using Azure Active Directory (Azure AD), you can customize the claim type for
- A subscription that has single sign-on (SSO) enabled. You must configure SSO with your application. > [!NOTE]
-> This article explains on how to create/update/delete application roles on the service principal using APIs in Azure AD. If you would like to use the new user interface for App Roles then please see the details [here](https://docs.microsoft.com/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps).
+> This article explains on how to create/update/delete application roles on the service principal using APIs in Azure AD. If you would like to use the new user interface for App Roles then please see the details [here](./howto-add-app-roles-in-azure-ad-apps.md).
## When to use this feature
For additional steps, see the [app documentation](../saas-apps/tutorial-list.md)
[1]: ./media/active-directory-enterprise-app-role-management/tutorial_general_01.png [2]: ./media/active-directory-enterprise-app-role-management/tutorial_general_02.png [3]: ./media/active-directory-enterprise-app-role-management/tutorial_general_03.png
-[4]: ./media/active-directory-enterprise-app-role-management/tutorial_general_04.png
+[4]: ./media/active-directory-enterprise-app-role-management/tutorial_general_04.png
active-directory Active Directory Signing Key Rollover https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/active-directory-signing-key-rollover.md
If you built an application on WIF v1.0, there is no provided mechanism to autom
Instructions to use the FedUtil to update your configuration:
-1. Verify that you have the WIF v1.0 SDK installed on your development machine for Visual Studio 2008 or 2010. You can [download it from here](https://www.softpedia.com/get/Programming/Other-Programming-Files/Windows-Identity-Foundation-SDK.shtml) if you have not yet installed it.
+1. Verify that you have the WIF v1.0 SDK installed on your development machine for Visual Studio 2008 or 2010. You can [download it from here](https://www.microsoft.com/download/details.aspx?id=17331) if you have not yet installed it.
2. In Visual Studio, open the solution, and then right-click the applicable project and select **Update federation metadata**. If this option is not available, FedUtil and/or the WIF v1.0 SDK has not been installed. 3. From the prompt, select **Update** to begin updating your federation metadata. If you have access to the server environment where the application is hosted, you can optionally use FedUtilΓÇÖs [automatic metadata update scheduler](/previous-versions/windows-identity-foundation/ee517272(v=msdn.10)). 4. Click **Finish** to complete the update process.
If they key is being stored somewhere or hardcoded in your application, you can
You can validate whether your application supports automatic key rollover by downloading the scripts and following the instructions in [this GitHub repository.](https://github.com/AzureAD/azure-activedirectory-powershell-tokenkey) ## How to perform a manual rollover if your application does not support automatic rollover
-If your application does **not** support automatic rollover, you will need to establish a process that periodically monitors Microsoft identity platform's signing keys and performs a manual rollover accordingly. [This GitHub repository](https://github.com/AzureAD/azure-activedirectory-powershell-tokenkey) contains scripts and instructions on how to do this.
+If your application does **not** support automatic rollover, you will need to establish a process that periodically monitors Microsoft identity platform's signing keys and performs a manual rollover accordingly. [This GitHub repository](https://github.com/AzureAD/azure-activedirectory-powershell-tokenkey) contains scripts and instructions on how to do this.
active-directory App Objects And Service Principals https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/app-objects-and-service-principals.md
The application object serves as the template from which common and default prop
A service principal must be created in each tenant where the application is used, enabling it to establish an identity for sign-in and/or access to resources being secured by the tenant. A single-tenant application has only one service principal (in its home tenant), created and consented for use during application registration. A multi-tenant Web application/API also has a service principal created in each tenant where a user from that tenant has consented to its use.
-> [!NOTE]
-> Any changes you make to your application object are also reflected in its service principal object in the application's home tenant only (the tenant where it was registered). For multi-tenant applications, changes to the application object are not reflected in any consumer tenants' service principal objects, until the access is removed through the [Application Access Panel](https://myapps.microsoft.com) and granted again.
->
-> Also note that native applications are registered as multi-tenant by default.
+Any changes you make to your application object, including deletion, are reflected in its service principal object in the application's home tenant only (the tenant where it was registered). For multi-tenant applications, changes to the application object are not reflected in any consumer tenants' service principal objects, until the access is removed through the [Application Access Panel](https://myapps.microsoft.com) and granted again.
+
+Native applications are registered as multi-tenant by default.
## Example
active-directory Consent Framework Links https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/consent-framework-links.md
This article is to help you learn more about how the Azure AD consent framework
- For more depth, learn [how consent is supported at the OAuth 2.0 protocol layer during the authorization code grant flow.](../azuread-dev/v1-protocols-oauth-code.md#request-an-authorization-code) ## Next steps
-[AzureAD Microsoft Q&A](https://docs.microsoft.com/answers/topics/azure-active-directory.html)
+[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)
active-directory Delegated And App Perms https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/delegated-and-app-perms.md
- For more depth, learn how resource applications expose [scopes](developer-glossary.md#scopes) and [application roles](developer-glossary.md#roles) to client applications, which manifest as delegated and application permissions respectively in the Azure portal. ## Next steps
-[AzureAD Microsoft Q&A](https://docs.microsoft.com/answers/topics/azure-active-directory.html)
+[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)
active-directory Developer Support Help Options https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/developer-support-help-options.md
If you're just starting to integrate with Azure Active Directory (Azure AD), Mic
## Search
-If you have a development-related question, you may be able to find the answer in the documentation, [GitHub samples](https://github.com/azure-samples), or answers to [Microsoft Q&A](https://docs.microsoft.com/answers/products/) questions.
+If you have a development-related question, you may be able to find the answer in the documentation, [GitHub samples](https://github.com/azure-samples), or answers to [Microsoft Q&A](/answers/products/) questions.
### Scoped search
-For faster results, scope your search to [Microsoft Q&A](https://docs.microsoft.com/answers/products/)the documentation, and the code samples by using the following query in your favorite search engine:
+For faster results, scope your search to [Microsoft Q&A](/answers/products/)the documentation, and the code samples by using the following query in your favorite search engine:
``` {Your Search Terms} (site:http://www.docs.microsoft.com/answers/products/ OR site:docs.microsoft.com OR site:github.com/azure-samples OR site:cloudidentity.com OR site:developer.microsoft.com/graph)
Where *{Your Search Terms}* correspond to your search keywords.
## Post a question to Microsoft Q&A
-[Microsoft Q&A](https://docs.microsoft.com/answers/products/) is the preferred channel for development-related questions. Here, members of the developer community and Microsoft team members are directly involved in helping you to solve your problems.
+[Microsoft Q&A](/answers/products/) is the preferred channel for development-related questions. Here, members of the developer community and Microsoft team members are directly involved in helping you to solve your problems.
-If you can't find an answer to your question through search, submit a new question to [Microsoft Q&A](https://docs.microsoft.com/answers/products/) . Use one of the following tags when asking questions to help the community identify and answer your question more quickly:
+If you can't find an answer to your question through search, submit a new question to [Microsoft Q&A](/answers/products/) . Use one of the following tags when asking questions to help the community identify and answer your question more quickly:
|Component/area | Tags | |||
-| ADAL library | [[adal]](https://docs.microsoft.com/answers/topics/azure-ad-adal-deprecation.html) |
-| MSAL library | [[msal]](https://docs.microsoft.com/answers/topics/azure-ad-msal.html) |
-| OWIN middleware | [[azure-active-directory]](https://docs.microsoft.com/answers/topics/azure-active-directory.html) |
-| [Azure B2B](../external-identities/what-is-b2b.md) | [[azure-ad-b2b]](https://docs.microsoft.com/answers/topics/azure-ad-b2b.html) |
-| [Azure B2C](https://azure.microsoft.com/services/active-directory-b2c/) | [[azure-ad-b2c]](https://docs.microsoft.com/answers/topics/azure-ad-b2c.html) |
-| [Microsoft Graph API](https://developer.microsoft.com/graph/) | [[azure-ad-graph]](https://docs.microsoft.com/answers/topics/azure-ad-graph.html) |
-| Any other area related to authentication or authorization topics | [[azure-active-directory]](https://docs.microsoft.com/answers/topics/azure-active-directory.html) |
-
-The following posts from [Microsoft Q&A](https://docs.microsoft.com/answers/products/) contain tips on how to ask questions and how to add source code. Follow these guidelines to increase the chances for community members to assess and respond to your question quickly:
-
-* [How do I ask a good question](https://docs.microsoft.com/answers/articles/24951/how-to-write-a-quality-question.html)
-* [How to create a minimal, complete, and verifiable example](https://docs.microsoft.com/answers/articles/24907/how-to-write-a-quality-answer.html)
+| ADAL library | [[adal]](/answers/topics/azure-ad-adal-deprecation.html) |
+| MSAL library | [[msal]](/answers/topics/azure-ad-msal.html) |
+| OWIN middleware | [[azure-active-directory]](/answers/topics/azure-active-directory.html) |
+| [Azure B2B](../external-identities/what-is-b2b.md) | [[azure-ad-b2b]](/answers/topics/azure-ad-b2b.html) |
+| [Azure B2C](https://azure.microsoft.com/services/active-directory-b2c/) | [[azure-ad-b2c]](/answers/topics/azure-ad-b2c.html) |
+| [Microsoft Graph API](https://developer.microsoft.com/graph/) | [[azure-ad-graph]](/answers/topics/azure-ad-graph.html) |
+| Any other area related to authentication or authorization topics | [[azure-active-directory]](/answers/topics/azure-active-directory.html) |
+
+The following posts from [Microsoft Q&A](/answers/products/) contain tips on how to ask questions and how to add source code. Follow these guidelines to increase the chances for community members to assess and respond to your question quickly:
+
+* [How do I ask a good question](/answers/articles/24951/how-to-write-a-quality-question.html)
+* [How to create a minimal, complete, and verifiable example](/answers/articles/24907/how-to-write-a-quality-answer.html)
## Create a GitHub issue
active-directory Howto Authenticate Service Principal Powershell https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/howto-authenticate-service-principal-powershell.md
multiple Previously updated : 06/26/2020 Last updated : 02/22/2021
The example sleeps for 20 seconds to allow some time for the new service princip
You can scope the role assignment to a specific resource group by using the **ResourceGroupName** parameter. You can scope to a specific resource by also using the **ResourceType** and **ResourceName** parameters.
-If you **do not have Windows 10 or Windows Server 2016**, download the [Self-signed certificate generator](https://gallery.technet.microsoft.com/scriptcenter/Self-signed-certificate-5920a7c6/) from Microsoft Script Center. Extract its contents and import the cmdlet you need.
+If you **do not have Windows 10 or Windows Server 2016**, download the [New-SelfSignedCertificateEx cmdlet](https://www.pkisolutions.com/tools/pspki/New-SelfSignedCertificateEx/) from PKI Solutions. Extract its contents and import the cmdlet you need.
```powershell # Only run if you could not use New-SelfSignedCertificate
active-directory Howto Create Service Principal Portal https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/howto-create-service-principal-portal.md
You must have sufficient permissions to register an application with your Azure
1. In the left pane, select **User settings**. 1. Check the **App registrations** setting. This value can only be set by an administrator. If set to **Yes**, any user in the Azure AD tenant can register an app.
-If the app registrations setting is set to **No**, only users with an administrator role may register these types of applications. See [available roles](../roles/permissions-reference.md#available-roles) and [role permissions](../roles/permissions-reference.md#role-permissions) to learn about available administrator roles and the specific permissions in Azure AD that are given to each role. If your account is assigned the User role, but the app registration setting is limited to admin users, ask your administrator to either assign you one of the administrator roles that can create and manage all aspects of app registrations, or to enable users to register apps.
+If the app registrations setting is set to **No**, only users with an administrator role may register these types of applications. See [Azure AD built-in roles](../roles/permissions-reference.md#all-roles) to learn about available administrator roles and the specific permissions in Azure AD that are given to each role. If your account is assigned the User role, but the app registration setting is limited to admin users, ask your administrator to either assign you one of the administrator roles that can create and manage all aspects of app registrations, or to enable users to register apps.
### Check Azure subscription permissions
active-directory Msal Android B2c https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/msal-android-b2c.md
Title: Azure AD B2C (MSAL Android) | Azure
description: Learn about specific considerations when using Azure AD B2C with the Microsoft Authentication Library for Android (MSAL.Android) -+
The Microsoft Authentication Library (MSAL) enables application developers to authenticate users with social and local identities by using [Azure Active Directory B2C (Azure AD B2C)](../../active-directory-b2c/index.yml). Azure AD B2C is an identity management service. Use it to customize and control how customers sign up, sign in, and manage their profiles when they use your applications.
+## Choosing a compatible authorization_user_agent
+The B2C identity management system supports authentication with a number of social account providers such as Google, Facebook, Twitter, and Amazon. If you plan to support such account types in your app, it is recommended that you configure your MSAL public client application to use either the `DEFAULT` or `BROWSER` value when specifying your manifest's [`authorization_user_agent`](msal-configuration.md#authorization_user_agent) due to restrictions prohibiting use of WebView-based authentication with some external identity providers.
+ ## Configure known authorities and redirect URI In MSAL for Android, B2C policies (user journeys) are configured as individual authorities.
The configuration file for the app would declare two `authorities`. One for each
>Note: The `account_mode` must be set to **MULTIPLE** for B2C applications. Refer to the documentation for more information about [multiple account public client apps](./single-multi-account.md#multiple-account-public-client-application). ### `app/src/main/res/raw/msal_config.json`+ ```json {
- "client_id": "<your_client_id_here>",
- "redirect_uri": "<your_redirect_uri_here>",
- "account_mode" : "MULTIPLE",
- "authorities": [{
- "type": "B2C",
- "authority_url": "https://contoso.b2clogin.com/tfp/contoso.onmicrosoft.com/B2C_1_SISOPolicy/",
- "default": true
- },
- {
- "type": "B2C",
- "authority_url": "https://contoso.b2clogin.com/tfp/contoso.onmicrosoft.com/B2C_1_EditProfile/"
- }
- ]
+ "client_id": "<your_client_id_here>",
+ "redirect_uri": "<your_redirect_uri_here>",
+ "account_mode" : "MULTIPLE",
+ "authorization_user_agent" : "DEFAULT",
+ "authorities": [
+ {
+ "type": "B2C",
+ "authority_url": "https://contoso.b2clogin.com/tfp/contoso.onmicrosoft.com/B2C_1_SISOPolicy/",
+ "default": true
+ },
+ {
+ "type": "B2C",
+ "authority_url": "https://contoso.b2clogin.com/tfp/contoso.onmicrosoft.com/B2C_1_EditProfile/"
+ }
+ ]
} ```
pca.acquireToken(parameters);
To acquire a token silently with MSAL, build an `AcquireTokenSilentParameters` instance and supply it to the `acquireTokenSilentAsync` method. Unlike the `acquireToken` method, the `authority` must be specified to acquire a token silently. ```java
-IMultilpeAccountPublicClientApplication pca = ...; // Initialization not shown
+IMultipleAccountPublicClientApplication pca = ...; // Initialization not shown
AcquireTokenSilentParameters parameters = new AcquireTokenSilentParameters.Builder() .withScopes(Arrays.asList("https://contoso.onmicrosoft.com/contosob2c/read")) // Provide your registered scope here .forAccount(account)
When you renew tokens for a policy with `acquireTokenSilent`, provide the same `
## Next steps
-Learn more about Azure Active Directory B2C (Azure AD B2C) at [What is Azure Active Directory B2C?](../../active-directory-b2c/overview.md)
+Learn more about Azure Active Directory B2C (Azure AD B2C) at [What is Azure Active Directory B2C?](../../active-directory-b2c/overview.md)
active-directory Msal Android Shared Devices https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/msal-android-shared-devices.md
Shared device mode also provides Microsoft identity backed management of the dev
To create a shared device mode app, developers and cloud device admins work together: - Developers write a single-account app (multiple-account apps are not supported in shared device mode), add `"shared_device_mode_supported": true` to the app's configuration, and write code to handle things like shared device sign-out.-- Device admins prepare the device to be shared by installing the authenticator app, and setting the device to shared mode using the authenticator app. Only users who are in the [Cloud Device Administrator](../roles/permissions-reference.md#cloud-device-administrator-permissions) role can put a device into shared mode by using the [Authenticator app](../user-help/user-help-auth-app-overview.md). You can configure the membership of your organizational roles in the Azure portal via:
+- Device admins prepare the device to be shared by installing the authenticator app, and setting the device to shared mode using the authenticator app. Only users who are in the [Cloud Device Administrator](../roles/permissions-reference.md#cloud-device-administrator) role can put a device into shared mode by using the [Authenticator app](../user-help/user-help-auth-app-overview.md). You can configure the membership of your organizational roles in the Azure portal via:
**Azure Active Directory** > **Roles and Administrators** > **Cloud Device Administrator**. This article focuses primarily what developers should think about.
active-directory Msal Migration https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/msal-migration.md
__Q: How does MSAL work with AD FS?__
A: MSAL.NET supports certain scenarios to authenticate against AD FS 2019. If your app needs to acquire tokens directly from earlier version of AD FS, you should remain on ADAL. [Learn more](msal-net-adfs-support.md). __Q: How do I get help migrating my application?__
-A: See the [Migration guidance](#migration-guidance) section of this article. If, after reading the guide for your app's platform, you have additional questions, you can post on [Microsoft Q&A](https://docs.microsoft.com/answers/topics/azure-ad-adal-deprecation.html) with the tag `[azure-ad-adal-deprecation]` or open an issue in library's GitHub repository. See the [Languages and frameworks](msal-overview.md#languages-and-frameworks) section of the MSAL overview article for links to each library's repo.
+A: See the [Migration guidance](#migration-guidance) section of this article. If, after reading the guide for your app's platform, you have additional questions, you can post on [Microsoft Q&A](/answers/topics/azure-ad-adal-deprecation.html) with the tag `[azure-ad-adal-deprecation]` or open an issue in library's GitHub repository. See the [Languages and frameworks](msal-overview.md#languages-and-frameworks) section of the MSAL overview article for links to each library's repo.
## Next steps - [Update your applications to use Microsoft Authentication Library and Microsoft Graph API](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/update-your-applications-to-use-microsoft-authentication-library/ba-p/1257363) - [Overview of the Microsoft identity platform](v2-overview.md)-- [Review our MSAL code samples](sample-v2-code.md)
+- [Review our MSAL code samples](sample-v2-code.md)
active-directory Msal Net Uwp Considerations https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/msal-net-uwp-considerations.md
Previously updated : 07/16/2019 Last updated : 03/03/2021
Developers of applications that use Universal Windows Platform (UWP) with MSAL.NET should consider the concepts this article presents. ## The UseCorporateNetwork property
-On the Windows Runtime (WinRT) platform, `PublicClientApplication` has the Boolean property `UseCorporateNetwork`. This property enables Windows 8.1 applications and UWP applications to benefit from Integrated Windows authentication (IWA) if the user is signed in to an account that has a federated Azure Active Directory (Azure AD) tenant. Users who are signed in to the operating system can also use single sign-on (SSO). When you set the `UseCorporateNetwork` property, MSAL.NET uses a web authentication broker (WAB).
+On the Windows Runtime (WinRT) platform, `PublicClientApplication` has the Boolean property `UseCorporateNetwork`. This property enables Windows 10 applications and UWP applications to benefit from Integrated Windows authentication (IWA) if the user is signed in to an account that has a federated Azure Active Directory (Azure AD) tenant. Users who are signed in to the operating system can also use single sign-on (SSO). When you set the `UseCorporateNetwork` property, MSAL.NET uses a web authentication broker (WAB).
> [!IMPORTANT] > Setting the `UseCorporateNetwork` property to true assumes that the application developer has enabled IWA in the application. To enable IWA:
active-directory Perms For Given Api https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/perms-for-given-api.md
## Next steps
-[AzureAD Microsoft Q&A](https://docs.microsoft.com/answers/topics/azure-active-directory.html)
+[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)
active-directory Quickstart Register App https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/quickstart-register-app.md
Registering your application establishes a trust relationship between your app a
Follow these steps to create the app registration:
-1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal<span class="docon docon-navigate-external x-hidden-focus"></span></a>.
+1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.
1. If you have access to multiple tenants, in the top menu, use the **Directory + subscription** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: to select the tenant in which you want to register an application. 1. Search for and select **Azure Active Directory**. 1. Under **Manage**, select **App registrations** > **New registration**.
-1. Enter a **Name** for your application. Users of your app might see this name. You can change it later.
+1. Enter a display **Name** for your application. Users of your application might see the display name when they use the app, for example during sign-in.
+ You can change the display name at any time and multiple app registrations can share the same name. The app registration's automatically generated Application (client) ID, not its display name, uniquely identifies your app within the identity platform.
1. Specify who can use the application, sometimes called its *sign-in audience*. | Supported account types | Description |
active-directory Quickstart Remove App https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/quickstart-remove-app.md
In the following sections, you learn how to:
Applications that you or your organization have registered are represented by both an application object and service principal object in your tenant. For more information, see [Application Objects and Service Principal Objects](./app-objects-and-service-principals.md).
+> [!NOTE]
+> Deleting an application will also delete its service principal object in the application's home directory. For multi-tenant applications, service principal objects in other directories will not be deleted.
+ To delete an application, be listed as an owner of the application or have admin privileges. 1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.
active-directory Quickstart V2 Aspnet Webapp https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/quickstart-v2-aspnet-webapp.md
public void Configuration(IAppBuilder app)
// PostLogoutRedirectUri is the page that users will be redirected to after sign-out. In this case, it is using the home page PostLogoutRedirectUri = redirectUri, Scope = OpenIdConnectScope.OpenIdProfile,
- // ResponseType is set to request the id_token - which contains basic information about the signed-in user
- ResponseType = OpenIdConnectResponseType.IdToken,
+ // ResponseType is set to request the code id_token - which contains basic information about the signed-in user
+ ResponseType = OpenIdConnectResponseType.CodeIdToken,
// ValidateIssuer set to false to allow personal and work accounts from any organization to sign in to your application // To only allow users from a single organizations, set ValidateIssuer to true and 'tenant' setting in web.config to the tenant name // To allow users from only a list of specific organizations, set ValidateIssuer to true and use ValidIssuers parameter
public void Configuration(IAppBuilder app)
> | `RedirectUri` | URL where users are sent after authentication against the Microsoft identity platform | > | `PostLogoutRedirectUri` | URL where users are sent after signing-off | > | `Scope` | The list of scopes being requested, separated by spaces |
-> | `ResponseType` | Request that the response from authentication contains an ID token |
+> | `ResponseType` | Request that the response from authentication contains an Authorization Code and an ID token |
> | `TokenValidationParameters` | A list of parameters for token validation. In this case, `ValidateIssuer` is set to `false` to indicate that it can accept sign-ins from any personal, or work or school account types | > | `Notifications` | A list of delegates that can be executed on different *OpenIdConnect* messages |
active-directory Quickstart V2 Javascript Auth Code Angular https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/quickstart-v2-javascript-auth-code-angular.md
See [How the sample works](#how-the-sample-works) for an illustration.
This quickstart uses MSAL Angular v2 with the authorization code flow. For a similar quickstart that uses MSAL Angular 1.x with the implicit flow, see [Quickstart: Sign in users in JavaScript single-page apps](./quickstart-v2-angular.md).
+> [!IMPORTANT]
+> MSAL Angular v2 [!INCLUDE [PREVIEW BOILERPLATE](../../../includes/active-directory-develop-preview.md)]
+ ## Prerequisites * Azure subscription - [Create an Azure subscription for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F)
This quickstart uses MSAL Angular v2 with the authorization code flow. For a sim
> > Scroll down in the same file and update the `graphMeEndpoint`. > - Replace the string `Enter_the_Graph_Endpoint_Herev1.0/me` with `https://graph.microsoft.com/v1.0/me`
-> - `Enter_the_Graph_Endpoint_Herev1.0/me` is the endpoint that API calls will be made against. For the main (global) Microsoft Graph API service, enter `https://graph.microsoft.com/` (include the trailing forward-slash). For more information, see the [documentation](https://docs.microsoft.com/graph/deployments).
+> - `Enter_the_Graph_Endpoint_Herev1.0/me` is the endpoint that API calls will be made against. For the main (global) Microsoft Graph API service, enter `https://graph.microsoft.com/` (include the trailing forward-slash). For more information, see the [documentation](/graph/deployments).
> > > ```javascript
npm install @azure/msal-browser @azure/msal-angular@2
For a detailed step-by-step guide on building the auth code flow application using vanilla JavaScript, see the following tutorial: > [!div class="nextstepaction"]
-> [Tutorial to sign in and call MS Graph](./tutorial-v2-javascript-auth-code.md)
+> [Tutorial to sign in and call MS Graph](./tutorial-v2-javascript-auth-code.md)
active-directory Quickstart V2 Javascript Auth Code React https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/quickstart-v2-javascript-auth-code-react.md
See [How the sample works](#how-the-sample-works) for an illustration.
This quickstart uses MSAL React with the authorization code flow. For a similar quickstart that uses MSAL.js with the implicit flow, see [Quickstart: Sign in users in JavaScript single-page apps](./quickstart-v2-javascript.md).
+> [!IMPORTANT]
+> MSAL React [!INCLUDE [PREVIEW BOILERPLATE](../../../includes/active-directory-develop-preview.md)]
+ ## Prerequisites * Azure subscription - [Create an Azure subscription for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F)
This quickstart uses MSAL React with the authorization code flow. For a similar
> > Scroll down in the same file and update the `graphMeEndpoint`. > - Replace the string `Enter_the_Graph_Endpoint_Herev1.0/me` with `https://graph.microsoft.com/v1.0/me`
-> - `Enter_the_Graph_Endpoint_Herev1.0/me` is the endpoint that API calls will be made against. For the main (global) Microsoft Graph API service, enter `https://graph.microsoft.com/` (include the trailing forward-slash). For more information, see the [documentation](https://docs.microsoft.com/graph/deployments).
+> - `Enter_the_Graph_Endpoint_Herev1.0/me` is the endpoint that API calls will be made against. For the main (global) Microsoft Graph API service, enter `https://graph.microsoft.com/` (include the trailing forward-slash). For more information, see the [documentation](/graph/deployments).
> > >
npm install @azure/msal-browser @azure/msal-react
For a detailed step-by-step guide on building the auth code flow application using vanilla JavaScript, see the following tutorial: > [!div class="nextstepaction"]
-> [Tutorial to sign in and call MS Graph](./tutorial-v2-javascript-auth-code.md)
+> [Tutorial to sign in and call MS Graph](./tutorial-v2-javascript-auth-code.md)
active-directory Quickstart V2 Nodejs Console https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/quickstart-v2-nodejs-console.md
Title: "Quickstart: Call Microsoft Graph from a Node.js console app | Azure"
-description: In this quickstart, you learn how a Node.js console application can get an access token and call an API protected by a Microsoft identity platform endpoint, using the app's own identity
+description: In this quickstart, you download and run a code sample that shows how a Node.js console application can get an access token and call an API protected by a Microsoft identity platform endpoint, using the app's own identity
Previously updated : 02/11/2021 Last updated : 02/17/2021 #Customer intent: As an application developer, I want to learn how my Node.js app can get an access token and call an API that is protected by an Microsoft identity platform endpoint using client credentials flow.
This quickstart uses the [Microsoft Authentication Library for Node.js (MSAL Nod
* [Visual Studio Code](https://code.visualstudio.com/download) or another code editor > [!div renderon="docs"]
-> ## Register and download your quickstart application
+> ## Register and download the sample application
> > Follow the steps below to get started. > > [!div renderon="docs"]
-> #### Step 1: Register your application
+> #### Step 1: Register the application
> To register your application and add the app's registration information to your solution manually, follow these steps: > > 1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.
This quickstart uses the [Microsoft Authentication Library for Node.js (MSAL Nod
> 1. Under **User** node, select **User.Read.All**, then select **Add permissions**. > [!div class="sxs-lookup" renderon="portal"]
-> ### Download and configure your quickstart app
+> ### Download and configure the sample app
>
-> #### Step 1: Configure your application in Azure portal
+> #### Step 1: Configure the application in Azure portal
> For the code sample for this quickstart to work, you need to create a client secret, and add Graph API's **User.Read.All** application permission. > > [!div renderon="portal" id="makechanges" class="nextstepaction"] > > [Make these changes for me]()
This quickstart uses the [Microsoft Authentication Library for Node.js (MSAL Nod
> > [!div id="appconfigured" class="alert alert-info"] > > ![Already configured](media/quickstart-v2-netcore-daemon/green-check.png) Your application is configured with these attributes.
-#### Step 2: Download your Node.js project
+#### Step 2: Download the Node.js sample project
> [!div renderon="docs"] > [Download the code sample](https://github.com/azure-samples/ms-identity-javascript-nodejs-console/archive/main.zip)
This quickstart uses the [Microsoft Authentication Library for Node.js (MSAL Nod
> > `Enter_the_Supported_Account_Info_Here` > [!div renderon="docs"]
-> #### Step 3: Configure your Node.js project
+> #### Step 3: Configure the Node.js sample project
> > 1. Extract the zip file to a local folder close to the root of the disk, for example, *C:/Azure-Samples*. > 1. Edit *.env* and replace the values of the fields `TENANT_ID`, `CLIENT_ID`, and `CLIENT_SECRET` with the following snippet:
const msalConfig = {
clientId: "Enter_the_Application_Id_Here", authority: "https://login.microsoftonline.com/Enter_the_Tenant_Id_Here", clientSecret: "Enter_the_Client_Secret_Here",
- }
+ }
}; const cca = new msal.ConfidentialClientApplication(msalConfig); ```
active-directory Quickstart V2 Nodejs Desktop https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/quickstart-v2-nodejs-desktop.md
Previously updated : 02/11/2021 Last updated : 02/17/2021 #Customer intent: As an application developer, I want to learn how my Node.js Electron desktop application can get an access token and call an API that's protected by a Microsoft identity platform endpoint.
This quickstart uses the [Microsoft Authentication Library for Node.js (MSAL Nod
* [Visual Studio Code](https://code.visualstudio.com/download) or another code editor > [!div renderon="docs"]
-> ## Register and download your quickstart application
->
+> ## Register and download the sample application
+>
> Follow the steps below to get started.
->
-> #### Step 1: Register your application
+>
+> #### Step 1: Register the application
> To register your application and add the app's registration information to your solution manually, follow these steps: > > 1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.
This quickstart uses the [Microsoft Authentication Library for Node.js (MSAL Nod
> 1. Select **Configure**. > [!div class="sxs-lookup" renderon="portal"]
-> #### Step 1: Configure your application in Azure portal
+> #### Step 1: Configure the application in Azure portal
> For the code sample for this quickstart to work, you need to add a reply URL as **msal://redirect**. > > [!div renderon="portal" id="makechanges" class="nextstepaction"] > > [Make this change for me]()
This quickstart uses the [Microsoft Authentication Library for Node.js (MSAL Nod
> > [!div id="appconfigured" class="alert alert-info"] > > ![Already configured](media/quickstart-v2-windows-desktop/green-check.png) Your application is configured with these attributes.
-#### Step 2: Download your Electron project
+#### Step 2: Download the Electron sample project
> [!div renderon="docs"] > [Download the code sample](https://github.com/azure-samples/ms-identity-javascript-nodejs-desktop/archive/main.zip)
This quickstart uses the [Microsoft Authentication Library for Node.js (MSAL Nod
> > `Enter_the_Supported_Account_Info_Here` > [!div renderon="docs"]
-> #### Step 3: Configure your Electron project
+> #### Step 3: Configure the Electron sample project
> > 1. Extract the zip file to a local folder close to the root of the disk, for example, *C:/Azure-Samples*. > 1. Edit *.env* and replace the values of the fields `TENANT_ID` and `CLIENT_ID` with the following snippet:
async function getTokenInteractive(authWindow, tokenRequest) {
/** * Proof Key for Code Exchange (PKCE) Setup
- *
+ *
* MSAL enables PKCE in the Authorization Code Grant Flow by including the codeChallenge and codeChallengeMethod * parameters in the request passed into getAuthCodeUrl() API, as well as the codeVerifier parameter in the * second leg (acquireTokenByCode() API).
async function getTokenInteractive(authWindow, tokenRequest) {
pkceCodes.verifier = verifier; pkceCodes.challenge = challenge;
- const authCodeUrlParams = {
- redirectUri: redirectUri
+ const authCodeUrlParams = {
+ redirectUri: redirectUri
scopes: tokenRequest.scopes, codeChallenge: pkceCodes.challenge, // PKCE Code Challenge
- codeChallengeMethod: pkceCodes.challengeMethod // PKCE Code Challenge Method
+ codeChallengeMethod: pkceCodes.challengeMethod // PKCE Code Challenge Method
}; const authCodeUrl = await pca.getAuthCodeUrl(authCodeUrlParams);
async function getTokenInteractive(authWindow, tokenRequest) {
}); const authCode = await listenForAuthCode(authCodeUrl, authWindow); // see below
-
- const authResponse = await pca.acquireTokenByCode({
- redirectUri: redirectUri,
- scopes: tokenRequest.scopes,
+
+ const authResponse = await pca.acquireTokenByCode({
+ redirectUri: redirectUri,
+ scopes: tokenRequest.scopes,
code: authCode,
- codeVerifier: pkceCodes.verifier // PKCE Code Verifier
+ codeVerifier: pkceCodes.verifier // PKCE Code Verifier
});
-
+ return authResponse; }
async function getTokenInteractive(authWindow, tokenRequest) {
* @param {object} authWindow: Electron window object */ async function listenForAuthCode(navigateUrl, authWindow) {
-
+ authWindow.loadURL(navigateUrl); return new Promise((resolve, reject) => {
active-directory Reference Aadsts Error Codes https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/reference-aadsts-error-codes.md
For example, if you received the error code "AADSTS50058" then do a search in [h
| AADSTS50000 | TokenIssuanceError - There's an issue with the sign-in service. [Open a support ticket](../fundamentals/active-directory-troubleshooting-support-howto.md) to resolve this issue. | | AADSTS50001 | InvalidResource - The resource is disabled or does not exist. Check your app's code to ensure that you have specified the exact resource URL for the resource you are trying to access. | | AADSTS50002 | NotAllowedTenant - Sign-in failed because of a restricted proxy access on the tenant. If it's your own tenant policy, you can change your restricted tenant settings to fix this issue. |
-| AADSTS500021 | Access to '{tenant}' tenant is denied. AADSTS500021 indicates that the tenant restriction feature is configured and that the user is trying to access a tenant that is not in the list of allowed tenants specified in the header `Restrict-Access-To-Tenant`. For more information, see [Use tenant restrictions to manage access to SaaS cloud applications](/azure/active-directory/manage-apps/tenant-restrictions).|
+| AADSTS500021 | Access to '{tenant}' tenant is denied. AADSTS500021 indicates that the tenant restriction feature is configured and that the user is trying to access a tenant that is not in the list of allowed tenants specified in the header `Restrict-Access-To-Tenant`. For more information, see [Use tenant restrictions to manage access to SaaS cloud applications](../manage-apps/tenant-restrictions.md).|
| AADSTS50003 | MissingSigningKey - Sign-in failed because of a missing signing key or certificate. This might be because there was no signing key configured in the app. Check out the resolutions outlined at [../manage-apps/application-sign-in-problem-federated-sso-gallery.md#certificate-or-key-not-configured](../manage-apps/application-sign-in-problem-federated-sso-gallery.md#certificate-or-key-not-configured). If you still see issues, contact the app owner or an app admin. | | AADSTS50005 | DevicePolicyError - User tried to log in to a device from a platform that's currently not supported through Conditional Access policy. | | AADSTS50006 | InvalidSignature - Signature verification failed because of an invalid signature. |
active-directory Reference Breaking Changes https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/reference-breaking-changes.md
Previously updated : 5/4/2020 Last updated : 2/22/2021
> Get notified of updates to this page by pasting this URL into your RSS feed reader:<br/>`https://docs.microsoft.com/api/search/rss?search=%22whats%20new%20for%20authentication%22&locale=en-us`
-The authentication system alters and adds features on an ongoing basis to improve security and standards compliance. To stay up-to-date with the most recent developments, this article provides you with information about the following details:
+The authentication system alters and adds features on an ongoing basis to improve security and standards compliance. To stay up to date with the most recent developments, this article provides you with information about the following details:
- Latest features - Known issues
The authentication system alters and adds features on an ongoing basis to improv
## Upcoming changes
-None scheduled at this time. Please see below for the changes that are in or are coming to production.
+### Conditional Access will only trigger for explicitly requested scopes
+
+**Effective date**: March 2021
+
+**Endpoints impacted**: v2.0
+
+**Protocol impacted**: All flows using [dynamic consent](v2-permissions-and-consent.md#requesting-individual-user-consent)
+
+Applications using dynamic consent today are given all of the permissions they have consent for, even if they were not requested in the `scope` parameter by name. This can cause an app requesting e.g. only `user.read`, but with consent to `files.read`, to be forced to pass the Conditional Access assigned for the `files.read` permission.
+
+In order to reduce the number of unnecessary Conditional Access prompts, Azure AD is changing the way that unrequested scopes are provided to applications so that only explicitly requested scopes trigger Conditional Access. This change may cause apps reliant on Azure AD's previous behavior (namely, providing all permissions even when they were not requested) to break, as the tokens they request will be missing permissions.
+
+Apps will now receive access tokens with a mix of permissions in this - those requested, as well as those they have consent for that do not require Conditional Access prompts. The scopes of the access token is reflected in the token response's `scope` parameter.
+
+**Examples**
+
+An app has consent for `user.read`, `files.readwrite`, and `tasks.read`. `files.readwrite` has Conditional Access policies applied to it, while the other two do not. If an app makes a token request for `scope=user.read`, and the currently signed in user has not passed any Conditional Access policies, then the resulting token will be for the `user.read` and `tasks.read` permissions. `tasks.read` is included because the app has consent for it, and it does not require a Conditional Access policy to be enforced.
+
+If the app then requests `scope=files.readwrite`, the Conditional Access required by the tenant will trigger, forcing the app to show an interactive auth prompt where the Conditional Access policy can be satisfied. The token returned will have all three scopes in it.
+
+If the app then makes one last request for any of the three scopes (say, `scope=tasks.read`), Azure AD will see that the user has already completed the Conditional access policies needed for `files.readwrite`, and again issue a token with all three permissions in it.
+ ## May 2020
active-directory Registration Config Sso How To https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/registration-config-sso-how-to.md
For iOS, see [Enabling Cross App SSO in iOS](../azuread-dev/howto-v1-enable-sso-
[Permissions and consent in the Microsoft identity platform](./v2-permissions-and-consent.md)<br>
-[AzureAD Microsoft Q&A](https://docs.microsoft.com/answers/topics/azure-active-directory.html)
+[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)
active-directory Scenario Protected Web Api App Registration https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/scenario-protected-web-api-app-registration.md
The following sample shows the contents of `appRoles`, where the value of `id` c
```json "appRoles": [
- {
- "allowedMemberTypes": [ "Application" ],
- "description": "Accesses the TodoListService-Cert as an application.",
- "displayName": "access_as_application",
- "id": "ccf784a6-fd0c-45f2-9c08-2f9d162a0628",
- "isEnabled": true,
- "lang": null,
- "origin": "Application",
- "value": "access_as_application"
- }
+ {
+ "allowedMemberTypes": [ "Application" ],
+ "description": "Accesses the TodoListService-Cert as an application.",
+ "displayName": "access_as_application",
+ "id": "ccf784a6-fd0c-45f2-9c08-2f9d162a0628",
+ "isEnabled": true,
+ "lang": null,
+ "origin": "Application",
+ "value": "access_as_application"
+ }
], ```
active-directory Scenario Web Api Call Api App Configuration https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/scenario-web-api-call-api-app-configuration.md
The On-behalf-of (OBO) flow is used to obtain a token to call the downstream web
A Python web API will need to use some middleware to validate the bearer token received from the client. The web API can then obtain the access token for downstream API using MSAL Python library by calling the [`acquire_token_on_behalf_of`](https://msal-python.readthedocs.io/en/latest/?badge=latest#msal.ConfidentialClientApplication.acquire_token_on_behalf_of) method. For an example of using this API, see the [test code for the microsoft-authentication-library-for-python on GitHub](https://github.com/AzureAD/microsoft-authentication-library-for-python/blob/1.2.0/tests/test_e2e.py#L429-L472). Also see the discussion of [issue 53](https://github.com/AzureAD/microsoft-authentication-library-for-python/issues/53) in that same repository for an approach that bypasses the need for a middle-tier application.
+You can also see an example of the OBO flow implementation in the [ms-identity-python-on-behalf-of](https://github.com/Azure-Samples/ms-identity-python-on-behalf-of) sample.
+ You can also see an example of OBO flow implementation in [Node.js and Azure Functions](https://github.com/Azure-Samples/ms-identity-nodejs-webapi-onbehalfof-azurefunctions/blob/master/Function/MyHttpTrigger/index.js#L61).
active-directory Scenario Web Api Call Api Call Api https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/scenario-web-api-call-api-call-api.md
After you have a token, you can call a protected web API. You usually call the d
When you use *Microsoft.Identity.Web*, you have three usage scenarios: -- [Option 1: Call Microsoft Graph with the Microsoft Graph SDK](#option-1-call-microsoft-graph-with-the-sdk)
+- [Option 1: Call Microsoft Graph with the SDK](#option-1-call-microsoft-graph-with-the-sdk)
- [Option 2: Call a downstream web API with the helper class](#option-2-call-a-downstream-web-api-with-the-helper-class) - [Option 3: Call a downstream web API without the helper class](#option-3-call-a-downstream-web-api-without-the-helper-class)
private String callMicrosoftGraphMeEndpoint(String accessToken){
``` # [Python](#tab/python)
-A sample demonstrating this flow with MSAL Python isn't yet available.
+A sample demonstrating this flow with MSAL Python is available at [ms-identity-python-on-behalf-of](https://github.com/Azure-Samples/ms-identity-python-on-behalf-of).
active-directory Scenario Web Api Call Api Overview https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/scenario-web-api-call-api-overview.md
Previously updated : 05/07/2019 Last updated : 03/03/2021 #Customer intent: As an application developer, I want to know how to write a web API that calls web APIs by using the Microsoft identity platform.
This scenario, in which a protected web API calls other web APIs, builds on [Sce
## Overview - A web, desktop, mobile, or single-page application client (not represented in the accompanying diagram) calls a protected web API and provides a JSON Web Token (JWT) bearer token in its "Authorization" HTTP header.-- The protected web API validates the token and uses the Microsoft Authentication Library (MSAL) `AcquireTokenOnBehalfOf` method to request another token from Azure Active Directory (Azure AD) so that the protected web API can call a second web API, or downstream web API, on behalf of the user.-- The protected web API can also call `AcquireTokenSilent`later to request tokens for other downstream APIs on behalf of the same user. `AcquireTokenSilent` refreshes the token when needed.-
+- The protected web API validates the token and uses the Microsoft Authentication Library (MSAL) `AcquireTokenOnBehalfOf` method to request another token from Azure Active Directory (Azure AD) so that the protected web API can call a second web API, or downstream web API, on behalf of the user. `AcquireTokenOnBehalfOf` refreshes the token when needed.
![Diagram of a web API calling a web API](media/scenarios/web-api.svg) ## Specifics
active-directory Setup Multi Tenant App https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/setup-multi-tenant-app.md
Here is a list of recommended topics to learn more about multi-tenant applicatio
- For more depth, learn [how a multi-tenant application is configured and coded end-to-end](./howto-convert-app-to-be-multi-tenant.md), including how to register, use the "common" endpoint, implement "user" and "admin" consent, how to implement more advanced multi-tier scenarios ## Next steps
-[AzureAD Microsoft Q&A](https://docs.microsoft.com/answers/topics/azure-active-directory.html)
+[AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)
active-directory Support Fido2 Authentication https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/support-fido2-authentication.md
The sign-in method that was most recently used by a user will be presented to th
The recommended options for implementing authentication are, in order: - .NET desktop applications that are using the Microsoft Authentication Library (MSAL) should use the Windows Authentication Manager (WAM). This integration and its benefits are [documented on GitHub](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/wam).-- Use [WebView2](https://docs.microsoft.com/microsoft-edge/webview2/) to support FIDO2 in an embedded browser.
+- Use [WebView2](/microsoft-edge/webview2/) to support FIDO2 in an embedded browser.
- Use the system browser. The MSAL libraries for desktop platforms use this method by default. You can consult our page on FIDO2 browser compatibility to ensure the browser you use supports FIDO2 authentication. ### Mobile
-As of February 2020, FIDO2 is not currently supported for native iOS or Android apps, but it is in development.
+As of February 2021, FIDO2 is not currently supported for native iOS or Android apps, but it is in development.
To prepare applications for its availability, and as a general best practice, iOS and Android applications should use MSAL with its default configuration of using the system web browser.
The availability of FIDO2 passwordless authentication for applications that run
## Next steps
-[Passwordless authentication options for Azure Active Directory](../../active-directory/authentication/concept-authentication-passwordless.md)
+[Passwordless authentication options for Azure Active Directory](../../active-directory/authentication/concept-authentication-passwordless.md)
active-directory Tutorial V2 Asp Webapp https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/tutorial-v2-asp-webapp.md
The following steps are used to create an OWIN middleware Startup class to confi
// PostLogoutRedirectUri is the page that users will be redirected to after sign-out. In this case, it is using the home page PostLogoutRedirectUri = redirectUri, Scope = OpenIdConnectScope.OpenIdProfile,
- // ResponseType is set to request the id_token - which contains basic information about the signed-in user
- ResponseType = OpenIdConnectResponseType.IdToken,
+ // ResponseType is set to request the code id_token - which contains basic information about the signed-in user
+ ResponseType = OpenIdConnectResponseType.CodeIdToken,
// ValidateIssuer set to false to allow personal and work accounts from any organization to sign in to your application // To only allow users from a single organizations, set ValidateIssuer to true and 'tenant' setting in web.config to the tenant name // To allow users from only a list of specific organizations, set ValidateIssuer to true and use ValidIssuers parameter
active-directory Tutorial V2 Aspnet Daemon Web App https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/tutorial-v2-aspnet-daemon-web-app.md
When no longer needed, delete the app object that you created in the [Register y
## Get help
-Use [Microsoft Q&A](https://docs.microsoft.com/answers/products/) to get support from the community.
-Ask your questions on [Microsoft Q&A](https://docs.microsoft.com/answers/products/) first, and browse existing issues to see if someone has asked your question before.
+Use [Microsoft Q&A](/answers/products/) to get support from the community.
+Ask your questions on [Microsoft Q&A](/answers/products/) first, and browse existing issues to see if someone has asked your question before.
Make sure that your questions or comments are tagged with "azure-ad-adal-deprecation," "azure-ad-msal," and "dotnet-standard." If you find a bug in the sample, please raise the issue on [GitHub Issues](https://github.com/Azure-Samples/ms-identity-aspnet-daemon-webapp/issues).
To provide a recommendation, go to the [User Voice page](https://feedback.azure.
Learn more about building daemon apps that use the Microsoft identity platform to access protected web APIs: > [!div class="nextstepaction"]
-> [Scenario: Daemon application that calls web APIs](scenario-daemon-overview.md)
+> [Scenario: Daemon application that calls web APIs](scenario-daemon-overview.md)
active-directory Tutorial V2 Nodejs Console https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/tutorial-v2-nodejs-console.md
Previously updated : 01/12/2021 Last updated : 02/17/2021
Inside the *bin* folder, create another file named *auth.js* and add the followi
const msal = require('@azure/msal-node'); /**
- * Configuration object to be passed to MSAL instance on creation.
+ * Configuration object to be passed to MSAL instance on creation.
* For a full list of MSAL Node configuration parameters, visit:
- * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-node/docs/configuration.md
+ * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-node/docs/configuration.md
*/ const msalConfig = { auth: {
const msalConfig = {
/** * With client credentials flows permissions need to be granted in the portal by a tenant administrator.
- * The scope is always in the format '<resource>/.default'. For more, visit:
- * https://docs.microsoft.com/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow
+ * The scope is always in the format '<resource>/.default'. For more, visit:
+ * https://docs.microsoft.com/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow
*/ const tokenRequest = { scopes: [process.env.GRAPH_ENDPOINT + '.default'],
const cca = new msal.ConfidentialClientApplication(msalConfig);
/** * Acquires token with client credentials.
- * @param {object} tokenRequest
+ * @param {object} tokenRequest
*/ async function getToken(tokenRequest) { return await cca.acquireTokenByClientCredential(tokenRequest);
const axios = require('axios');
/** * Calls the endpoint with authorization bearer token.
- * @param {string} endpoint
- * @param {string} accessToken
+ * @param {string} endpoint
+ * @param {string} accessToken
*/ async function callApi(endpoint, accessToken) {
module.exports = {
}; ```
-Here, the `callApi` method is used to make an HTTP `GET` request against a protected resource that requires an access token. The request then returns the content to the caller. This method adds the acquired token in the *HTTP Authorization header*. The protected resource here is the Microsoft Graph API [users endpoint](https://docs.microsoft.com/graph/api/user-list) which displays the users in the tenant where this app is registered.
+Here, the `callApi` method is used to make an HTTP `GET` request against a protected resource that requires an access token. The request then returns the content to the caller. This method adds the acquired token in the *HTTP Authorization header*. The protected resource here is the Microsoft Graph API [users endpoint](/graph/api/user-list) which displays the users in the tenant where this app is registered.
## Test the app
request made to web API at: Fri Jan 22 2021 09:31:52 GMT-0800 (Pacific Standard
## How the application works
-This application uses [OAuth 2.0 client credentials grant](https://docs.microsoft.com/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow). This type of grant is commonly used for server-to-server interactions that must run in the background, without immediate interaction with a user. The credentials grant flow permits a web service (confidential client) to use its own credentials, instead of impersonating a user, to authenticate when calling another web service. The type of applications supported with this authentication model are usually **daemons** or **service accounts**.
+This application uses [OAuth 2.0 client credentials grant](./v2-oauth2-client-creds-grant-flow.md). This type of grant is commonly used for server-to-server interactions that must run in the background, without immediate interaction with a user. The credentials grant flow permits a web service (confidential client) to use its own credentials, instead of impersonating a user, to authenticate when calling another web service. The type of applications supported with this authentication model are usually **daemons** or **service accounts**.
The scope to request for a client credential flow is the name of the resource followed by `/.default`. This notation tells Azure Active Directory (Azure AD) to use the application-level permissions declared statically during application registration. Also, these API permissions must be granted by a **tenant administrator**.
The scope to request for a client credential flow is the name of the resource fo
If you'd like to dive deeper into Node.js console application development on the Microsoft identity platform, see our multi-part scenario series: > [!div class="nextstepaction"]
-> [Scenario: Daemon application](scenario-daemon-overview.md)
+> [Scenario: Daemon application](scenario-daemon-overview.md)
active-directory Tutorial V2 Nodejs Desktop https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/tutorial-v2-nodejs-desktop.md
Previously updated : 01/12/2021 Last updated : 02/17/2021
const path = require('path');
const url = require('url'); /**
- * To demonstrate best security practices, this Electron sample application makes use of
- * a custom file protocol instead of a regular web (https://) redirect URI in order to
+ * To demonstrate best security practices, this Electron sample application makes use of
+ * a custom file protocol instead of a regular web (https://) redirect URI in order to
* handle the redirection step of the authorization flow, as suggested in the OAuth2.0 specification for Native Apps. */ const CUSTOM_FILE_PROTOCOL_NAME = process.env.REDIRECT_URI.split(':')[0]; // e.g. msal://redirect /**
- * Configuration object to be passed to MSAL instance on creation.
+ * Configuration object to be passed to MSAL instance on creation.
* For a full list of MSAL Node configuration parameters, visit:
- * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-node/docs/configuration.md
+ * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-node/docs/configuration.md
*/ const MSAL_CONFIG = { auth: {
class AuthProvider {
constructor() { /** * Initialize a public client application. For more information, visit:
- * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-node/docs/initialize-public-client-application.md
+ * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-node/docs/initialize-public-client-application.md
*/ this.clientApplication = new PublicClientApplication(MSAL_CONFIG); this.account = null;
class AuthProvider {
async getToken(authWindow, tokenRequest) { let authResponse;
-
+ authResponse = await this.getTokenInteractive(authWindow, tokenRequest);
-
+ return authResponse.accessToken || null; }
class AuthProvider {
/** * Proof Key for Code Exchange (PKCE) Setup
- *
+ *
* MSAL enables PKCE in the Authorization Code Grant Flow by including the codeChallenge and codeChallengeMethod parameters * in the request passed into getAuthCodeUrl() API, as well as the codeVerifier parameter in the * second leg (acquireTokenByCode() API).
- *
+ *
* MSAL Node provides PKCE Generation tools through the CryptoProvider class, which exposes * the generatePkceCodes() asynchronous API. As illustrated in the example below, the verifier * and challenge values should be generated previous to the authorization flow initiation.
- *
- * For details on PKCE code generation logic, consult the
+ *
+ * For details on PKCE code generation logic, consult the
* PKCE specification https://tools.ietf.org/html/rfc7636#section-4 */
class AuthProvider {
this.pkceCodes.verifier = verifier; this.pkceCodes.challenge = challenge;
- const authCodeUrlParams = {
- ...this.authCodeUrlParams,
+ const authCodeUrlParams = {
+ ...this.authCodeUrlParams,
scopes: tokenRequest.scopes, codeChallenge: this.pkceCodes.challenge, // PKCE Code Challenge
- codeChallengeMethod: this.pkceCodes.challengeMethod // PKCE Code Challenge Method
+ codeChallengeMethod: this.pkceCodes.challengeMethod // PKCE Code Challenge Method
}; const authCodeUrl = await this.clientApplication.getAuthCodeUrl(authCodeUrlParams);
class AuthProvider {
}); const authCode = await this.listenForAuthCode(authCodeUrl, authWindow);
-
- const authResponse = await this.clientApplication.acquireTokenByCode({
- ...this.authCodeRequest,
- scopes: tokenRequest.scopes,
+
+ const authResponse = await this.clientApplication.acquireTokenByCode({
+ ...this.authCodeRequest,
+ scopes: tokenRequest.scopes,
code: authCode,
- codeVerifier: this.pkceCodes.verifier // PKCE Code Verifier
+ codeVerifier: this.pkceCodes.verifier // PKCE Code Verifier
});
-
+ return authResponse; } // Listen for authorization code response from Azure AD async listenForAuthCode(navigateUrl, authWindow) {
-
+ authWindow.loadURL(navigateUrl); return new Promise((resolve, reject) => {
class AuthProvider {
/** * Handles the response from a popup or redirect. If response is null, will check if we have any accounts and attempt to sign in.
- * @param response
+ * @param response
*/ async handleResponse(response) { if (response !== null) {
const axios = require('axios');
/** * Makes an Authorization 'Bearer' request with the given accessToken to the given endpoint.
- * @param endpoint
- * @param accessToken
+ * @param endpoint
+ * @param accessToken
*/ async function callEndpointWithToken(endpoint, accessToken) { const options = {
active-directory Tutorial V2 Nodejs Webapp Msal https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/tutorial-v2-nodejs-webapp-msal.md
- Previously updated : 01/12/2021 Last updated : 02/17/2021
Create a folder to host your application, for example *ExpressWebApp*.
```JavaScript const express = require("express"); const msal = require('@azure/msal-node');
-
+ const SERVER_PORT = process.env.PORT || 3000;
-
+ // Create Express App and Routes const app = express();
Locate the root of your project directory in a terminal and install the MSAL Nod
In the *index.js* file you've created earlier, add the following code: ```JavaScript
- // Before running the sample, you will need to replace the values in the config,
+ // Before running the sample, you will need to replace the values in the config,
// including the clientSecret const config = { auth: {
In the *index.js* file you've created earlier, add the following code:
```JavaScript // Create msal application object const cca = new msal.ConfidentialClientApplication(config);
-
+ app.get('/', (req, res) => { const authCodeUrlParameters = { scopes: ["user.read"], redirectUri: "http://localhost:3000/redirect", };
-
+ // get url to sign user in and consent to scopes needed for application cca.getAuthCodeUrl(authCodeUrlParameters).then((response) => { res.redirect(response); }).catch((error) => console.log(JSON.stringify(error))); });
-
+ app.get('/redirect', (req, res) => { const tokenRequest = { code: req.query.code, scopes: ["user.read"], redirectUri: "http://localhost:3000/redirect", };
-
+ cca.acquireTokenByCode(tokenRequest).then((response) => { console.log("\nResponse: \n:", response); res.sendStatus(200);
You've completed creation of the application and are now ready to test the app's
## How the application works
-In this tutorial, you initialized an MSAL Node [ConfidentialClientApplication](https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-node/docs/initialize-confidential-client-application.md) object by passing it a configuration object (*msalConfig*) that contains parameters obtained from your Azure AD app registration on Azure portal. The web app you created uses the [OAuth 2.0 Authorization code grant flow](https://docs.microsoft.com/azure/active-directory/develop/v2-oauth2-auth-code-flow) to sign-in users and obtain ID and access tokens.
+In this tutorial, you initialized an MSAL Node [ConfidentialClientApplication](https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-node/docs/initialize-confidential-client-application.md) object by passing it a configuration object (*msalConfig*) that contains parameters obtained from your Azure AD app registration on Azure portal. The web app you created uses the [OAuth 2.0 Authorization code grant flow](./v2-oauth2-auth-code-flow.md) to sign-in users and obtain ID and access tokens.
## Next steps If you'd like to dive deeper into Node.js & Express web application development on the Microsoft identity platform, see our multi-part scenario series: > [!div class="nextstepaction"]
-> [Scenario: Web app that signs in users](scenario-web-app-sign-user-overview.md)
+> [Scenario: Web app that signs in users](scenario-web-app-sign-user-overview.md)
active-directory Tutorial V2 Shared Device Mode https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/tutorial-v2-shared-device-mode.md
Use `isSharedDevice()` to determine if an app is running on a device that is in
Here's a code snippet that shows how you could use `isSharedDevice()`. It's from the `SingleAccountModeFragment` class in the sample app: ```Java
-deviceModeTextView.setText(mSingleAccountApp.isSharedDevice() ?"Shared" :"Non-Shared");
+deviceModeTextView.setText(mSingleAccountApp.isSharedDevice() ? "Shared" : "Non-Shared");
``` ### Initialize the PublicClientApplication object
active-directory Tutorial V2 Windows Desktop https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/tutorial-v2-windows-desktop.md
In this step, you create a class to handle interaction with MSAL, such as handli
{ _clientApp = PublicClientApplicationBuilder.Create(ClientId) .WithAuthority(AzureCloudInstance.AzurePublic, Tenant)
+ .WithDefaultRedirectUri()
.Build(); }
active-directory V2 Admin Consent https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/v2-admin-consent.md
When you sign the user into your app, you can identify the organization to which
When you're ready to request permissions from your organization's admin, you can redirect the user to the Microsoft identity platform *admin consent endpoint*.
-```HTTP
-// Line breaks are for legibility only.
-GET https://login.microsoftonline.com/{tenant}/v2.0/adminconsent?
-client_id=6731de76-14a6-49ae-97bc-6eba6914391e
-&state=12345
-&redirect_uri=http://localhost/myapp/permissions
-&scope=
-https://graph.microsoft.com/calendars.read
-https://graph.microsoft.com/mail.send
+```none
+https://login.microsoftonline.com/{tenant}/v2.0/adminconsent
+ ?client_id=6731de76-14a6-49ae-97bc-6eba6914391e
+ &scope=https://graph.microsoft.com/Calendars.Read https://graph.microsoft.com/Mail.Send
+ &redirect_uri=http://localhost/myapp/permissions
+ &state=12345
``` | Parameter | Condition | Description |
-| : | : | :: |
+| : | : | : |
| `tenant` | Required | The directory tenant that you want to request permission from. Can be provided in GUID or friendly name format OR generically referenced with `organizations` as seen in the example. Do not use 'common', as personal accounts cannot provide admin consent except in the context of a tenant. To ensure best compatibility with personal accounts that manage tenants, use the tenant ID when possible. | | `client_id` | Required | The **Application (client) ID** that the [Azure portal ΓÇô App registrations](https://go.microsoft.com/fwlink/?linkid=2083908) experience assigned to your app. | | `redirect_uri` | Required |The redirect URI where you want the response to be sent for your app to handle. It must exactly match one of the redirect URIs that you registered in the app registration portal. |
At this point, Azure AD requires a tenant administrator to sign in to complete t
If the admin approves the permissions for your app, the successful response looks like this:
-```
-http://localhost/myapp/permissions?admin_consent=True&tenant=fa00d692-e9c7-4460-a743-29f2956fd429&state=12345&scope=https%3a%2f%2fgraph.microsoft.com%2fCalendars.Read+https%3a%2f%2fgraph.microsoft.com%2fMail.Send
+```none
+http://localhost/myapp/permissions
+ ?admin_consent=True
+ &tenant=fa00d692-e9c7-4460-a743-29f2956fd429
+ &scope=https://graph.microsoft.com/Calendars.Read https://graph.microsoft.com/Mail.Send
+ &state=12345
``` | Parameter | Description |
-| : | :: |
+| : | : |
| `tenant`| The directory tenant that granted your application the permissions it requested, in GUID format.| | `state` | A value included in the request that also will be returned in the token response. It can be a string of any content you want. The state is used to encode information about the user's state in the app before the authentication request occurred, such as the page or view they were on.| | `scope` | The set of permissions that were granted access to, for the application.|
http://localhost/myapp/permissions?admin_consent=True&tenant=fa00d692-e9c7-4460-
### Error response
-`http://localhost/myapp/permissions?error=consent_required&error_description=AADSTS65004%3a+The+resource+owner+or+authorization+server+denied+the+request.%0d%0aTrace+ID%3a+d320620c-3d56-42bc-bc45-4cdd85c41f00%0d%0aCorrelation+ID%3a+8478d534-5b2c-4325-8c2c-51395c342c89%0d%0aTimestamp%3a+2019-09-24+18%3a34%3a26Z&admin_consent=True&tenant=fa15d692-e9c7-4460-a743-29f2956fd429&state=12345`
+```none
+http://localhost/myapp/permissions
+ ?admin_consent=True
+ &tenant=fa15d692-e9c7-4460-a743-29f2956fd429
+ &error=consent_required
+ &error_description=AADSTS65004%3a+The+resource+owner+or+authorization+server+denied+the+request.%0d%0aTrace+ID%3a+d320620c-3d56-42bc-bc45-4cdd85c41f00%0d%0aCorrelation+ID%3a+8478d534-5b2c-4325-8c2c-51395c342c89%0d%0aTimestamp%3a+2019-09-24+18%3a34%3a26Z
+ &state=12345
+```
Adding to the parameters seen in a successful response, error parameters are seen as below. | Parameter | Description |
-|-:|:-:|
+|:-|:-|
| `error` | An error code string that can be used to classify types of errors that occur, and can be used to react to errors.| | `error_description` | A specific error message that can help a developer identify the root cause of an error.| | `tenant`| The directory tenant that granted your application the permissions it requested, in GUID format.|
Adding to the parameters seen in a successful response, error parameters are see
- See [how to convert an app to be multi-tenant](howto-convert-app-to-be-multi-tenant.md) - Learn how [consent is supported at the OAuth 2.0 protocol layer during the authorization code grant flow](v2-oauth2-auth-code-flow.md#request-an-authorization-code). - Learn [how a multi-tenant application can use the consent framework](./howto-convert-app-to-be-multi-tenant.md) to implement "user" and "admin" consent, supporting more advanced multi-tier application patterns.-- Understanding [Azure AD application consent experiences](application-consent-experience.md)
+- Understanding [Azure AD application consent experiences](application-consent-experience.md)
active-directory V2 Howto Get Appsource Certified https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/v2-howto-get-appsource-certified.md
For more information about the AppSource trial experience, see [this video](http
## Get support
-For Azure AD integration, we use [Microsoft Q&A](https://docs.microsoft.com/answers/topics/azure-active-directory.html) with the community to provide support.
+For Azure AD integration, we use [Microsoft Q&A](/answers/topics/azure-active-directory.html) with the community to provide support.
-We highly recommend you ask your questions on [Microsoft Q&A](https://docs.microsoft.com/answers/topics/azure-active-directory.html) first and browse existing issues to see if someone has asked your question before. Make sure that your questions or comments are tagged with [`[azure-active-directory]`](https://docs.microsoft.com/answers/topics/azure-active-directory.html).
+We highly recommend you ask your questions on [Microsoft Q&A](/answers/topics/azure-active-directory.html) first and browse existing issues to see if someone has asked your question before. Make sure that your questions or comments are tagged with [`[azure-active-directory]`](/answers/topics/azure-active-directory.html).
Use the following comments section to provide feedback and help us refine and shape our content.
active-directory V2 Oauth Ropc https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/v2-oauth-ropc.md
The Microsoft identity platform supports the [OAuth 2.0 Resource Owner Password
> * Accounts that don't have passwords can't sign in through ROPC. For this scenario, we recommend that you use a different flow for your app instead. > * If users need to use [multi-factor authentication (MFA)](../authentication/concept-mfa-howitworks.md) to log in to the application, they will be blocked instead. > * ROPC is not supported in [hybrid identity federation](../hybrid/whatis-fed.md) scenarios (for example, Azure AD and ADFS used to authenticate on-premises accounts). If users are full-page redirected to an on-premises identity providers, Azure AD is not able to test the username and password against that identity provider. [Pass-through authentication](../hybrid/how-to-connect-pta.md) is supported with ROPC, however.
+> * An exception to a hybrid identity federation scenario would be the following: Home Realm Discovery policy with AllowCloudPasswordValidation set to TRUE will enable ROPC flow to work for federated users when on-premises password is synced to cloud. For more information, see [Enable direct ROPC authentication of federated users for legacy applications](../manage-apps/configure-authentication-for-federated-users-portal.md#enable-direct-ropc-authentication-of-federated-users-for-legacy-applications).
## Protocol diagram
active-directory V2 Oauth2 Auth Code Flow https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/v2-oauth2-auth-code-flow.md
Previously updated : 02/19/2021 Last updated : 02/23/2021
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
| `tenant` | required | The `{tenant}` value in the path of the request can be used to control who can sign into the application. The allowed values are `common`, `organizations`, `consumers`, and tenant identifiers. For more detail, see [protocol basics](active-directory-v2-protocols.md#endpoints). | | `client_id` | required | The **Application (client) ID** that the [Azure portal ΓÇô App registrations](https://go.microsoft.com/fwlink/?linkid=2083908) experience assigned to your app. | | `response_type` | required | Must include `code` for the authorization code flow. Can also include `id_token` or `token` if using the [hybrid flow](#request-an-id-token-as-well-hybrid-flow). |
-| `redirect_uri` | required | The redirect_uri of your app, where authentication responses can be sent and received by your app. It must exactly match one of the redirect_uris you registered in the portal, except it must be url encoded. For native & mobile apps, you should use the default value of `https://login.microsoftonline.com/common/oauth2/nativeclient`. |
+| `redirect_uri` | required | The redirect_uri of your app, where authentication responses can be sent and received by your app. It must exactly match one of the redirect_uris you registered in the portal, except it must be url encoded. For native & mobile apps, you should use one of the recommended values - `https://login.microsoftonline.com/common/oauth2/nativeclient` (for apps using embedded browsers) or `http://localhost` (for apps that use system browsers). |
| `scope` | required | A space-separated list of [scopes](v2-permissions-and-consent.md) that you want the user to consent to. For the `/authorize` leg of the request, this can cover multiple resources, allowing your app to get consent for multiple web APIs you want to call. | | `response_mode` | recommended | Specifies the method that should be used to send the resulting token back to your app. Can be one of the following:<br/><br/>- `query`<br/>- `fragment`<br/>- `form_post`<br/><br/>`query` provides the code as a query string parameter on your redirect URI. If you're requesting an ID token using the implicit flow, you can't use `query` as specified in the [OpenID spec](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#Combinations). If you're requesting just the code, you can use `query`, `fragment`, or `form_post`. `form_post` executes a POST containing the code to your redirect URI. | | `state` | recommended | A value included in the request that will also be returned in the token response. It can be a string of any content that you wish. A randomly generated unique value is typically used for [preventing cross-site request forgery attacks](https://tools.ietf.org/html/rfc6749#section-10.12). The value can also encode information about the user's state in the app before the authentication request occurred, such as the page or view they were on. |
-| `prompt` | optional | Indicates the type of user interaction that is required. The only valid values at this time are `login`, `none`, `consent`, and `select_account`.<br/><br/>- `prompt=login` will force the user to enter their credentials on that request, negating single-sign on.<br/>- `prompt=none` is the opposite - it will ensure that the user isn't presented with any interactive prompt whatsoever. If the request can't be completed silently via single-sign on, the Microsoft identity platform will return an `interaction_required` error.<br/>- `prompt=consent` will trigger the OAuth consent dialog after the user signs in, asking the user to grant permissions to the app.<br/>- `prompt=select_account` will interrupt single sign-on providing account selection experience listing all the accounts either in session or any remembered account or an option to choose to use a different account altogether.<br/> |
+| `prompt` | optional | Indicates the type of user interaction that is required. The only valid values at this time are `login`, `none`, and `consent`.<br/><br/>- `prompt=login` will force the user to enter their credentials on that request, negating single-sign on.<br/>- `prompt=none` is the opposite - it will ensure that the user isn't presented with any interactive prompt whatsoever. If the request can't be completed silently via single-sign on, the Microsoft identity platform will return an `interaction_required` error.<br/>- `prompt=consent` will trigger the OAuth consent dialog after the user signs in, asking the user to grant permissions to the app.<br/>- `prompt=select_account` will interrupt single sign-on providing account selection experience listing all the accounts either in session or any remembered account or an option to choose to use a different account altogether.<br/> |
| `login_hint` | optional | Can be used to pre-fill the username/email address field of the sign-in page for the user, if you know their username ahead of time. Often apps will use this parameter during re-authentication, having already extracted the username from a previous sign-in using the `preferred_username` claim. | | `domain_hint` | optional | If included, it will skip the email-based discovery process that user goes through on the sign-in page, leading to a slightly more streamlined user experience - for example, sending them to their federated identity provider. Often apps will use this parameter during re-authentication, by extracting the `tid` from a previous sign-in. If the `tid` claim value is `9188040d-6c67-4c5b-b112-36a304b66dad`, you should use `domain_hint=consumers`. Otherwise, use `domain_hint=organizations`. |
-| `code_challenge` | recommended / required | Used to secure authorization code grants via Proof Key for Code Exchange (PKCE). Required if `code_challenge_method` is included. For more information, see the [PKCE RFC](https://tools.ietf.org/html/rfc7636). This is now recommended for all application types - native apps, SPAs, and confidential clients like web apps. |
+| `code_challenge` | recommended / required | Used to secure authorization code grants via Proof Key for Code Exchange (PKCE). Required if `code_challenge_method` is included. For more information, see the [PKCE RFC](https://tools.ietf.org/html/rfc7636). This is now recommended for all application types - both public and confidential clients - and required by the Microsoft identity platform for [single page apps using the authorization code flow](reference-third-party-cookies-spas.md). |
| `code_challenge_method` | recommended / required | The method used to encode the `code_verifier` for the `code_challenge` parameter. This *SHOULD* be `S256`, but the spec allows the use of `plain` if for some reason the client cannot support SHA256. <br/><br/>If excluded, `code_challenge` is assumed to be plaintext if `code_challenge` is included. The Microsoft identity platform supports both `plain` and `S256`. For more information, see the [PKCE RFC](https://tools.ietf.org/html/rfc7636). This is required for [single page apps using the authorization code flow](reference-third-party-cookies-spas.md).|
Once the user authenticates and grants consent, the Microsoft identity platform
A successful response using `response_mode=query` looks like: ```HTTP
-GET https://login.microsoftonline.com/common/oauth2/nativeclient?
+GET http://localhost?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq... &state=12345 ```
You can also receive an ID token if you request one and have the implicit grant
Error responses may also be sent to the `redirect_uri` so the app can handle them appropriately: ```HTTP
-GET https://login.microsoftonline.com/common/oauth2/nativeclient?
+GET http://localhost?
error=access_denied &error_description=the+user+canceled+the+authentication ```
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
|`response_type`| Required | The addition of `id_token` indicates to the server that the application would like an ID token in the response from the `/authorize` endpoint. | |`scope`| Required | For ID tokens, must be updated to include the ID token scopes - `openid`, and optionally `profile` and `email`. | |`nonce`| Required| A value included in the request, generated by the app, that will be included in the resulting id_token as a claim. The app can then verify this value to mitigate token replay attacks. The value is typically a randomized, unique string that can be used to identify the origin of the request. |
-|`response_mode`| Recommended | Specifies the method that should be used to send the resulting token back to your app. Defaults to `query` for just an authorization code, but `fragment` if the request includes an id_token `response_type`.|
+|`response_mode`| Recommended | Specifies the method that should be used to send the resulting token back to your app. Defaults to `query` for just an authorization code, but `fragment` if the request includes an id_token `response_type`. However, apps are recommended to use `form_post`, especially when using `http:/localhost` as a redirect URI. |
-The use of `fragment` as a response mode can cause issues for web apps that read the code from the redirect, as browsers do not pass the fragment to the web server. In these situations, apps are recommended to use the `form_post` response mode to ensure that all data is sent to the server.
+The use of `fragment` as a response mode causes issues for web apps that read the code from the redirect, as browsers do not pass the fragment to the web server. In these situations, apps should use the `form_post` response mode to ensure that all data is sent to the server.
#### Successful response
active-directory Whats New Docs https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/whats-new-docs.md
Welcome to what's new in the Microsoft identity platform documentation. This article lists new docs that have been added and those that have had significant updates in the last three months.
+## February 2021
+
+### New articles
+
+- [Quickstart: Acquire an access token and call the Microsoft Graph API from an Electron desktop app](quickstart-v2-nodejs-desktop.md)
+- [Tutorial: Sign in users and call the Microsoft Graph API in an Electron desktop app](tutorial-v2-nodejs-desktop.md)
+- [Quickstart: Acquire a token and call Microsoft Graph API from a Node.js console app using app's identity](quickstart-v2-nodejs-console.md)
+- [Tutorial: Call the Microsoft Graph API in a Node.js console app](tutorial-v2-nodejs-console.md)
+- [Tutorial: Sign-in users in a Node.js & Express web app](tutorial-v2-nodejs-webapp-msal.md)
+- [Support passwordless authentication with FIDO2 keys in apps you develop](support-fido2-authentication.md)
+
+### Updated articles
+
+- [What's new for authentication?](reference-breaking-changes.md)
+- [Use MSAL.NET to sign in users with social identities](msal-net-aad-b2c-considerations.md)
+- [Microsoft identity platform code samples (v2.0 endpoint)](sample-v2-code.md)
+- [Microsoft identity platform videos](identity-videos.md)
+- [Quickstart: Set up a tenant](quickstart-create-new-tenant.md)
+- [Quickstart: Register an application with the Microsoft identity platform](quickstart-register-app.md)
+- [Quickstart: Acquire a token and call Microsoft Graph API from a Java console app using app's identity](quickstart-v2-java-daemon.md)
+ ## January 2021 ### New articles
Welcome to what's new in the Microsoft identity platform documentation. This art
- [Microsoft identity platform access tokens](access-tokens.md) - [A web API that calls web APIs: Acquire a token for the app](scenario-web-api-call-api-acquire-token.md) -
-## November 2020
-
-### New articles
--- [How to use Continuous Access Evaluation-enabled APIs in your applications](app-resilience-continuous-access-evaluation.md)-
-### Updated articles
--- [Microsoft identity platform access tokens](access-tokens.md)-- [Application configuration options (MSAL)](msal-client-application-configuration.md)-- [How to: Provide optional claims to your app](active-directory-optional-claims.md)-- [Publish your app to the Azure AD app gallery](v2-howto-app-gallery-listing.md)-- [How to: Add app roles to your application and receive them in the token](howto-add-app-roles-in-azure-ad-apps.md)
active-directory Concept Primary Refresh Token https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/devices/concept-primary-refresh-token.md
A PRT is protected by binding it to the device the user has signed in to. Azure
* **During first sign in**: During first sign in, a PRT is issued by signing requests using the device key cryptographically generated during device registration. On a device with a valid and functioning TPM, the device key is secured by the TPM preventing any malicious access. A PRT is not issued if the corresponding device key signature cannot be validated. * **During token requests and renewal**: When a PRT is issued, Azure AD also issues an encrypted session key to the device. It is encrypted with the public transport key (tkpub) generated and sent to Azure AD as part of device registration. This session key can only be decrypted by the private transport key (tkpriv) secured by the TPM. The session key is the Proof-of-Possession (POP) key for any requests sent to Azure AD. The session key is also protected by the TPM and no other OS component can access it. Token requests or PRT renewal requests are securely signed by this session key through the TPM and hence, cannot be tampered with. Azure AD will invalidate any requests from the device that are not signed by the corresponding session key.
-By securing these keys with the TPM, malicious actors cannot steal the keys nor replay the PRT elsewhere as the TPM is inaccessible even if an attacker has physical possession of the device. Thus, using a TPM greatly enhances the security of Azure AD Joined, Hybrid Azure AD joined, and Azure AD registered devices against credential theft. For performance and reliability, TPM 2.0 is the recommended version for all Azure AD device registration scenarios on Windows 10.
+By securing these keys with the TPM, we enhance the security for PRT from malicious actors trying to steal the keys or replay the PRT. So, using a TPM greatly enhances the security of Azure AD Joined, Hybrid Azure AD joined, and Azure AD registered devices against credential theft. For performance and reliability, TPM 2.0 is the recommended version for all Azure AD device registration scenarios on Windows 10. Starting Windows 10, 1903 update, Azure AD does not use TPM 1.2 for any of the above keys due to reliability issues.
### How are app tokens and browser cookies protected?
By securing these keys with the TPM, malicious actors cannot steal the keys nor
**Browser cookies**: In Windows 10, Azure AD supports browser SSO in Internet Explorer and Microsoft Edge natively or in Google Chrome via the Windows 10 accounts extension. The security is built not only to protect the cookies but also the endpoints to which the cookies are sent. Browser cookies are protected the same way a PRT is, by utilizing the session key to sign and protect the cookies.
-When a user initiates a browser interaction, the browser (or extension) invokes a COM native client host. The native client host ensures that the page is from one of the allowed domains. The browser could send other parameters to the native client host, including a nonce, however the native client host guarantees validation of the hostname. The native client host requests a PRT-cookie from CloudAP plugin, which creates and signs it with the TPM-protected session key. As the PRT-cookie is signed by the session key, it cannot be tampered with. This PRT-cookie is included in the request header for Azure AD to validate the device it is originating from. If using the Chrome browser, only the extension explicitly defined in the native client hostΓÇÖs manifest can invoke it preventing arbitrary extensions from making these requests. Once Azure AD validates the PRT cookie, it issues a session cookie to the browser. This session cookie also contains the same session key issued with a PRT. During subsequent requests, the session key is validated effectively binding the cookie to the device and preventing replays from elsewhere.
+When a user initiates a browser interaction, the browser (or extension) invokes a COM native client host. The native client host ensures that the page is from one of the allowed domains. The browser could send other parameters to the native client host, including a nonce, however the native client host guarantees validation of the hostname. The native client host requests a PRT-cookie from CloudAP plugin, which creates and signs it with the TPM-protected session key. As the PRT-cookie is signed by the session key, it is very difficult to tamper with. This PRT-cookie is included in the request header for Azure AD to validate the device it is originating from. If using the Chrome browser, only the extension explicitly defined in the native client hostΓÇÖs manifest can invoke it preventing arbitrary extensions from making these requests. Once Azure AD validates the PRT cookie, it issues a session cookie to the browser. This session cookie also contains the same session key issued with a PRT. During subsequent requests, the session key is validated effectively binding the cookie to the device and preventing replays from elsewhere.
## When does a PRT get an MFA claim?
The following diagrams illustrate the underlying details in issuing, renewing, a
| A | User logs in to Windows with their credentials to get a PRT. Once user opens the browser, browser (or extension) loads the URLs from the registry. | | B | When a user opens an Azure AD login URL, the browser or extension validates the URL with the ones obtained from the registry. If they match, the browser invokes the native client host for getting a token. | | C | The native client host validates that the URLs belong to the Microsoft identity providers (Microsoft account or Azure AD), extracts a nonce sent from the URL and makes a call to CloudAP plugin to get a PRT cookie. |
-| D | The CloudAP plugin will create the PRT cookie, sign in with the TPM-bound session key and send it back to the native client host. As the cookie is signed by the session key, it cannot be tampered with. |
+| D | The CloudAP plugin will create the PRT cookie, sign in with the TPM-bound session key and send it back to the native client host. |
| E | The native client host will return this PRT cookie to the browser, which will include it as part of the request header called x-ms-RefreshTokenCredential and request tokens from Azure AD. | | F | Azure AD validates the Session key signature on the PRT cookie, validates the nonce, verifies that the device is valid in the tenant, and issues an ID token for the web page and an encrypted session cookie for the browser. |
active-directory Device Management Azure Portal https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/devices/device-management-azure-portal.md
You must be assigned one of the following roles to view or manage device setting
- **Users may join devices to Azure AD** - This setting enables you to select the users who can register their devices as Azure AD joined devices. The default is **All**. > [!NOTE]
-> **Users may join devices to Azure AD** setting is only applicable to Azure AD join on Windows 10.
+> **Users may join devices to Azure AD** setting is only applicable to Azure AD join on Windows 10. This setting does not apply to hybrid Azure AD joined devices, [Azure AD joined VMs in Azure](./howto-vm-sign-in-azure-ad-windows.md#enabling-azure-ad-login-in-for-windows-vm-in-azure) and Azure AD joined devices using [Windows Autopilot self-deployment mode](/mem/autopilot/self-deploying) as these methods work in a userless context.
- **Additional local administrators on Azure AD joined devices** - You can select the users that are granted local administrator rights on a device. These users are added to the *Device Administrators* role in Azure AD. Global administrators in Azure AD and device owners are granted local administrator rights by default. This option is a premium edition capability available through products such as Azure AD Premium or the Enterprise Mobility Suite (EMS).
In addition to the filters, you can search for specific entries.
[How to manage stale devices in Azure AD](manage-stale-devices.md)
-[Enterprise State Roaming](enterprise-state-roaming-overview.md)
+[Enterprise State Roaming](enterprise-state-roaming-overview.md)
active-directory Howto Vm Sign In Azure Ad Windows https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/devices/howto-vm-sign-in-azure-ad-windows.md
The following Azure regions are currently supported during the preview of this f
To enable Azure AD authentication for your Windows VMs in Azure, you need to ensure your VMs network configuration permits outbound access to the following endpoints over TCP port 443: -- https:\//enterpriseregistration.windows.net-- https:\//login.microsoftonline.com-- https:\//device.login.microsoftonline.com-- https:\//pas.windows.net
+- `https://enterpriseregistration.windows.net`
+- `https://login.microsoftonline.com`
+- `https://device.login.microsoftonline.com`
+- `https://pas.windows.net`
## Enabling Azure AD login in for Windows VM in Azure
To create a Windows Server 2019 Datacenter VM in Azure with Azure AD logon:
Azure Cloud Shell is a free, interactive shell that you can use to run the steps in this article. Common Azure tools are preinstalled and configured in Cloud Shell for you to use with your account. Just select the Copy button to copy the code, paste it in Cloud Shell, and then press Enter to run it. There are a few ways to open Cloud Shell:
-Select Try It in the upper-right corner of a code block.
-Open Cloud Shell in your browser.
-Select the Cloud Shell button on the menu in the upper-right corner of the [Azure portal](https://portal.azure.com).
+- Select **Try It** in the upper-right corner of a code block.
+- Open Cloud Shell in your browser.
+- Select the Cloud Shell button on the menu in the upper-right corner of the [Azure portal](https://portal.azure.com).
If you choose to install and use the CLI locally, this article requires that you are running the Azure CLI version 2.0.31 or later. Run az --version to find the version. If you need to install or upgrade, see the article [Install Azure CLI](/cli/azure/install-azure-cli).
az vm create \
It takes a few minutes to create the VM and supporting resources.
-Finally, install the Azure AD login VM extension to enable Azure AD login for Windows VM. VM extensions are small applications that provide post-deployment configuration and automation tasks on Azure virtual machines. Use [az vm extension](/cli/azure/vm/extension#az-vm-extension-set) set to install the AADLoginForWindows extension on the VM named myVM in the myResourceGroup resource group:
+Finally, install the Azure AD login VM extension to enable Azure AD login for Windows VM. VM extensions are small applications that provide post-deployment configuration and automation tasks on Azure virtual machines. Use [az vm extension](/cli/azure/vm/extension#az-vm-extension-set) set to install the AADLoginForWindows extension on the VM named `myVM` in the `myResourceGroup` resource group:
> [!NOTE] > You can install AADLoginForWindows extension on an existing Windows Server 2019 or Windows 10 1809 and later VM to enable it for Azure AD authentication. An example of AZ CLI is shown below.
For more information on how to use Azure RBAC to manage access to your Azure sub
## Using Conditional Access
-You can enforce Conditional Access policies such as multi-factor authentication or user sign-in risk check before authorizing access to Windows VMs in Azure that are enabled with Azure AD sign in. To apply Conditional Access policy, you must select "Azure Windows VM Sign-In" app from the cloud apps or actions assignment option and then use Sign-in risk as a condition and/or
+You can enforce Conditional Access policies such as multi-factor authentication or user sign-in risk check before authorizing access to Windows VMs in Azure that are enabled with Azure AD sign in. To apply Conditional Access policy, you must select the "Azure Windows VM Sign-In" app from the cloud apps or actions assignment option and then use Sign-in risk as a condition and/or
require multi-factor authentication as a grant access control. > [!NOTE]
require multi-factor authentication as a grant access control.
## Log in using Azure AD credentials to a Windows VM > [!IMPORTANT]
-> Remote connection to VMs joined to Azure AD is only allowed from Windows 10 PCs that are either Azure AD registered (minimum required build is 20H1) or Azure AD joined or hybrid Azure AD joined to the **same** directory as the VM. Additionally, to RDP using Azure AD credentials, the user must belong to one of the two Azure roles, Virtual Machine Administrator Login or Virtual Machine User Login. If using an Azure AD registered Windows 10 PC, you must enter credentials in the AzureAD\UPN format (e.g. AzureAD\john@contoso.com). At this time, Azure Bastion can't be used to log in by using Azure Active Directory authentication with the AADLoginForWindows extension; only direct RDP is supported.
+> Remote connection to VMs joined to Azure AD is only allowed from Windows 10 PCs that are either Azure AD registered (minimum required build is 20H1) or Azure AD joined or hybrid Azure AD joined to the **same** directory as the VM. Additionally, to RDP using Azure AD credentials, the user must belong to one of the two Azure roles, Virtual Machine Administrator Login or Virtual Machine User Login. If using an Azure AD registered Windows 10 PC, you must enter credentials in the `AzureAD\UPN` format (for example, `AzureAD\john@contoso.com`). At this time, Azure Bastion can't be used to log in by using Azure Active Directory authentication with the AADLoginForWindows extension; only direct RDP is supported.
To log in to your Windows Server 2019 virtual machine using Azure AD:
You are now signed in to the Windows Server 2019 Azure virtual machine with the
The AADLoginForWindows extension must install successfully in order for the VM to complete the Azure AD join process. Perform the following steps if the VM extension fails to install correctly.
-1. RDP to the VM using the local administrator account and examine the CommandExecuti'n.log under
+1. RDP to the VM using the local administrator account and examine the `CommandExecution.log` file under:
- C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.ActiveDirectory.AADLoginForWindows\0.3.1.0.
+ `C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.ActiveDirectory.AADLoginForWindows\0.3.1.0.`
> [!NOTE]
- > If the extension restarts after the initial failure, the log with the deployment error will be saved as CommandExecution_YYYYMMDDHHMMSSSSS.log.
+ > If the extension restarts after the initial failure, the log with the deployment error will be saved as `CommandExecution_YYYYMMDDHHMMSSSSS.log`.
" 1. Open a PowerShell command prompt on the VM and verify these queries against the Instance Metadata Service (IMDS) Endpoint running on the Azure host returns:
The AADLoginForWindows extension must install successfully in order for the VM t
| `curl -H @{"Metadata"="true"} "http://169.254.169.254/metadata/identity/oauth2/token?resource=urn:ms-drs:enterpriseregistration.windows.net&api-version=2018-02-01"` | Valid access token issued by Azure Active Directory for the managed identity that is assigned to this VM | > [!NOTE]
- > The access token can be decoded using a tool like [http://calebb.net/](http://calebb.net/). Verify the "appid" in the access token matches the managed identity assigned to the VM.
+ > The access token can be decoded using a tool like [calebb.net](http://calebb.net/). Verify the `appid` in the access token matches the managed identity assigned to the VM.
1. Ensure the required endpoints are accessible from the VM using the command line:
- - curl https:\//login.microsoftonline.com/ -D ΓÇô
- - curl https:\//login.microsoftonline.com/`<TenantID>`/ -D ΓÇô
+ - `curl https://login.microsoftonline.com/ -D -`
+ - `curl https://login.microsoftonline.com/<TenantID>/ -D -`
> [!NOTE] > Replace `<TenantID>` with the Azure AD Tenant ID that is associated with the Azure subscription.
- - curl https:\//enterpriseregistration.windows.net/ -D -
- - curl https:\//device.login.microsoftonline.com/ -D -
- - curl https:\//pas.windows.net/ -D -
+ - `curl https://enterpriseregistration.windows.net/ -D -`
+ - `curl https://device.login.microsoftonline.com/ -D -`
+ - `curl https://pas.windows.net/ -D -`
1. The Device State can be viewed by running `dsregcmd /status`. The goal is for Device State to show as `AzureAdJoined : YES`. > [!NOTE]
- > Azure AD join activity is captured in Event viewer under the User Device Registration\Admin log.
+ > Azure AD join activity is captured in Event viewer under the `User Device Registration\Admin` log.
If AADLoginForWindows extension fails with certain error code, you can perform the following steps:
-#### Issue 1: AADLoginForWindows extension fails to install with terminal error code '1007' and Exit code: -2145648574.
+#### Issue 1: AADLoginForWindows extension fails to install with terminal error code '1007' and exit code: -2145648574.
-This exit code translates to DSREG_E_MSI_TENANTID_UNAVAILABLE because the extension is unable to query the Azure AD Tenant information.
+This exit code translates to `DSREG_E_MSI_TENANTID_UNAVAILABLE` because the extension is unable to query the Azure AD Tenant information.
1. Verify the Azure VM can retrieve the TenantID from the Instance Metadata Service. - RDP to the VM as a local administrator and verify the endpoint returns valid Tenant ID by running this command from an elevated command line on the VM:
- - curl -H Metadata:true http://169.254.169.254/metadata/identity/info?api-version=2018-02-01
+ - `curl -H Metadata:true http://169.254.169.254/metadata/identity/info?api-version=2018-02-01`
1. The VM admin attempts to install the AADLoginForWindows extension, but a system assigned managed identity has not enabled the VM first. Navigate to the Identity blade of the VM. From the System assigned tab, verify Status is toggled to On. #### Issue 2: AADLoginForWindows extension fails to install with Exit code: -2145648607
-This Exit code translates to DSREG_AUTOJOIN_DISC_FAILED because the extension is not able to reach the `https://enterpriseregistration.windows.net` endpoint.
+This Exit code translates to `DSREG_AUTOJOIN_DISC_FAILED` because the extension is not able to reach the `https://enterpriseregistration.windows.net` endpoint.
1. Verify the required endpoints are accessible from the VM using the command line:
- - curl https:\//login.microsoftonline.com/ -D ΓÇô
- - curl https:\//login.microsoftonline.com/`<TenantID>`/ -D ΓÇô
+ - `curl https://login.microsoftonline.com/ -D -`
+ - `curl https://login.microsoftonline.com/<TenantID>/ -D -`
> [!NOTE]
- > Replace `<TenantID>` with the Azure AD Tenant ID that is associated with the Azure subscription. If you need to find the tenant ID, you can hover over your account name to get the directory / tenant ID, or select Azure Active Directory > Properties > Directory ID in the Azure portal.
+ > Replace `<TenantID>` with the Azure AD Tenant ID that is associated with the Azure subscription. If you need to find the tenant ID, you can hover over your account name to get the directory / tenant ID, or select **Azure Active Directory > Properties > Directory ID** in the Azure portal.
- - curl https:\//enterpriseregistration.windows.net/ -D -
- - curl https:\//device.login.microsoftonline.com/ -D -
- - curl https:\//pas.windows.net/ -D -
+ - `curl https://enterpriseregistration.windows.net/ -D -`
+ - `curl https://device.login.microsoftonline.com/ -D -`
+ - `curl https://pas.windows.net/ -D -`
1. If any of the commands fails with "Could not resolve host `<URL>`", try running this command to determine the DNS server that is being used by the VM. `nslookup <URL>` > [!NOTE]
- > Replace `<URL>` with the fully qualified domain names used by the endpoints, such as "login.microsoftonline.com".
+ > Replace `<URL>` with the fully qualified domain names used by the endpoints, such as `login.microsoftonline.com`.
1. Next, see if specifying a public DNS server allows the command to succeed:
Some common errors when you try to RDP with Azure AD credentials include no Azur
The Device and SSO State can be viewed by running `dsregcmd /status`. The goal is for Device State to show as `AzureAdJoined : YES` and `SSO State` to show `AzureAdPrt : YES`.
-Also, RDP Sign-in using Azure AD accounts is captured in Event viewer under the AAD\Operational event logs.
+Also, RDP Sign-in using Azure AD accounts is captured in Event viewer under the `AAD\Operational` event logs.
#### Azure role not assigned If you see the following error message when you initiate a remote desktop connection to your VM: -- Your account is configured to prevent you from using this device. For more info, contact your system administrator
+- Your account is configured to prevent you from using this device. For more info, contact your system administrator.
![Your account is configured to prevent you from using this device.](./media/howto-vm-sign-in-azure-ad-windows/rbac-role-not-assigned.png)
Verify that you have [configured Azure RBAC policies](../../virtual-machines/lin
If you see the following error message when you initiate a remote desktop connection to your VM: -- Your credentials did not work
+- Your credentials did not work.
![Your credentials did not work](./media/howto-vm-sign-in-azure-ad-windows/your-credentials-did-not-work.png) Verify that the Windows 10 PC you are using to initiate the remote desktop connection is one that is either Azure AD joined, or hybrid Azure AD joined to the same Azure AD directory where your VM is joined to. For more information about device identity, see the article [What is a device identity](./overview.md). > [!NOTE]
-> Windows 10 Build 20H1 added support for an Azure AD registered PC to initiate RDP connection to your VM. When using an Azure AD registered (not Azure AD joined or hybrid Azure AD joined) PC as the RDP client to initiate connections to your VM, you must enter credentials in the format AzureAD\UPn (e.g. AzureAD\john@contoso.com).
+> Windows 10 Build 20H1 added support for an Azure AD registered PC to initiate RDP connection to your VM. When using an Azure AD registered (not Azure AD joined or hybrid Azure AD joined) PC as the RDP client to initiate connections to your VM, you must enter credentials in the format `AzureAD\UPN` (for example, `AzureAD\john@contoso.com`).
Verify that the AADLoginForWindows extension was not uninstalled after the Azure AD join finished.
-Also, make sure that the security policy ΓÇ£Network security: Allow PKU2U authentication requests to this computer to use online identitiesΓÇ¥ is enabled on both the server *and* the client.
+Also, make sure that the security policy "Network security: Allow PKU2U authentication requests to this computer to use online identities" is enabled on both the server **and** the client.
#### MFA sign-in method required
If you have configured a Conditional Access policy that requires multi-factor au
If you have not deployed Windows Hello for Business and if that is not an option for now, you can exclude MFA requirement by configuring Conditional Access policy that excludes "Azure Windows VM Sign-In" app from the list of cloud apps that require MFA. To learn more about Windows Hello for Business, see [Windows Hello for Business Overview](/windows/security/identity-protection/hello-for-business/hello-identity-verification). > [!NOTE]
-> Windows Hello for Business PIN authentication with RDP has been supported by Windows 10 for several versions, however support for Biometric authentication with RDP was added in Windows 10 version 1809. Using Windows Hello for Business auth during RDP is only available for deployments that use cert trust model and currently not available for key trust model.
+> Windows Hello for Business PIN authentication with RDP has been supported by Windows 10 for several versions, however support for Biometric authentication with RDP was added in Windows 10 version 1809. Using Windows Hello for Business authentication during RDP is only available for deployments that use cert trust model and currently not available for key trust model.
## Preview feedback
Share your feedback about this preview feature or report issues using it on the
## Next steps
-For more information on Azure Active Directory, see [What is Azure Active Directory](../fundamentals/active-directory-whatis.md)
+For more information on Azure Active Directory, see [What is Azure Active Directory](../fundamentals/active-directory-whatis.md).
active-directory Hybrid Azuread Join Federated Domains https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/devices/hybrid-azuread-join-federated-domains.md
If you don't use WPAD and want to configure proxy settings on your computer, you
If your organization requires access to the internet via an authenticated outbound proxy, you must make sure that your Windows 10 computers can successfully authenticate to the outbound proxy. Because Windows 10 computers run device registration by using machine context, you must configure outbound proxy authentication by using machine context. Follow up with your outbound proxy provider on the configuration requirements.
-To verify if the device is able to access the above Microsoft resources under the system account, you can use [Test Device Registration Connectivity](https://docs.microsoft.com/samples/azure-samples/testdeviceregconnectivity/testdeviceregconnectivity/) script.
+To verify if the device is able to access the above Microsoft resources under the system account, you can use [Test Device Registration Connectivity](/samples/azure-samples/testdeviceregconnectivity/testdeviceregconnectivity/) script.
## Configure hybrid Azure AD join
If you experience issues with completing hybrid Azure AD join for domain-joined
Learn how to [manage device identities by using the Azure portal](device-management-azure-portal.md). <!--Image references-->
-[1]: ./media/active-directory-conditional-access-automatic-device-registration-setup/12.png
+[1]: ./media/active-directory-conditional-access-automatic-device-registration-setup/12.png
active-directory Hybrid Azuread Join Managed Domains https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/devices/hybrid-azuread-join-managed-domains.md
If you don't use WPAD, you can configure WinHTTP proxy settings on your computer
If your organization requires access to the internet via an authenticated outbound proxy, make sure that your Windows 10 computers can successfully authenticate to the outbound proxy. Because Windows 10 computers run device registration by using machine context, configure outbound proxy authentication by using machine context. Follow up with your outbound proxy provider on the configuration requirements.
-Verify the device can access the above Microsoft resources under the system account by using the [Test Device Registration Connectivity](https://docs.microsoft.com/samples/azure-samples/testdeviceregconnectivity/testdeviceregconnectivity/) script.
+Verify the device can access the above Microsoft resources under the system account by using the [Test Device Registration Connectivity](/samples/azure-samples/testdeviceregconnectivity/testdeviceregconnectivity/) script.
## Configure hybrid Azure AD join
If you experience issues completing hybrid Azure AD join for domain-joined Windo
Advance to the next article to learn how to manage device identities by using the Azure portal. > [!div class="nextstepaction"]
-> [Manage device identities](device-management-azure-portal.md)
+> [Manage device identities](device-management-azure-portal.md)
active-directory Hybrid Azuread Join Manual https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/devices/hybrid-azuread-join-manual.md
For Windows 10 devices on version 1703 or earlier, if your organization requires
Beginning with Windows 10 1803, even if a hybrid Azure AD join attempt by a device in a federated domain through AD FS fails, and if Azure AD Connect is configured to sync the computer/device objects to Azure AD, the device will try to complete the hybrid Azure AD join by using the synced computer/device.
-To verify if the device is able to access the above Microsoft resources under the system account, you can use [Test Device Registration Connectivity](https://docs.microsoft.com/samples/azure-samples/testdeviceregconnectivity/testdeviceregconnectivity/) script.
+To verify if the device is able to access the above Microsoft resources under the system account, you can use [Test Device Registration Connectivity](/samples/azure-samples/testdeviceregconnectivity/testdeviceregconnectivity/) script.
## Verify configuration steps
If you experience issues completing hybrid Azure AD join for domain-joined Windo
* [Introduction to device management in Azure Active Directory](overview.md) <!--Image references-->
-[1]: ./media/hybrid-azuread-join-manual/12.png
+[1]: ./media/hybrid-azuread-join-manual/12.png
active-directory Hybrid Azuread Join Plan https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/devices/hybrid-azuread-join-plan.md
As a first planning step, you should review your environment and determine wheth
If your Windows 10 domain joined devices are [Azure AD registered](overview.md#getting-devices-in-azure-ad) to your tenant, it could lead to a dual state of Hybrid Azure AD joined and Azure AD registered device. We recommend upgrading to Windows 10 1803 (with KB4489894 applied) or above to automatically address this scenario. In pre-1803 releases, you will need to remove the Azure AD registered state manually before enabling Hybrid Azure AD join. In 1803 and above releases, the following changes have been made to avoid this dual state: - Any existing Azure AD registered state for a user would be automatically removed <i>after the device is Hybrid Azure AD joined and the same user logs in</i>. For example, if User A had an Azure AD registered state on the device, the dual state for User A is cleaned up only when User A logs in to the device. If there are multiple users on the same device, the dual state is cleaned up individually when those users log in. In addition to removing the Azure AD registered state, Windows 10 will also unenroll the device from Intune or other MDM, if the enrollment happened as part of the Azure AD registration via auto-enrollment.
+- Azure AD registered state on any local accounts on the device is not impacted by this change. It is only applicable to domain accounts. So Azure AD registered state on local accounts is not removed automatically even after user logon, since the user is not a domain user.
- You can prevent your domain joined device from being Azure AD registered by adding the following registry value to HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin: "BlockAADWorkplaceJoin"=dword:00000001. - In Windows 10 1803, if you have Windows Hello for Business configured, the user needs to re-setup Windows Hello for Business after the dual state clean up.This issue has been addressed with KB4512509
active-directory Groups Dynamic Membership https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/enterprise-users/groups-dynamic-membership.md
The following expression selects all users who have any service plan that is ass
user.assignedPlans -any (assignedPlan.service -eq "SCO" -and assignedPlan.capabilityStatus -eq "Enabled") ```
+#### Example 3
+
+The following expression selects all users who have no asigned service plan:
+
+```
+user.assignedPlans -all (assignedPlan.servicePlanId -eq "")
+```
+ ### Using the underscore (\_) syntax The underscore (\_) syntax matches occurrences of a specific value in one of the multivalued string collection properties to add users or devices to a dynamic group. It is used with the -any or -all operators.
active-directory Groups Lifecycle https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/enterprise-users/groups-lifecycle.md
For information on how to download and install the Azure AD PowerShell cmdlets,
## Activity-based automatic renewal
-With Azure AD intelligence, groups are now automatically renewed based on whether they have been recently used. This feature eliminates the need for manual action by group owners, because it's based on user activity in groups across Microsoft 365 services like Outlook, SharePoint, or Teams. For example, if an owner or a group member does something like upload a document in SharePoint, visit a Teams channel, or send an email to the group in Outlook, the group is automatically renewed and the owner does not get any renewal notifications.
+With Azure AD intelligence, groups are now automatically renewed based on whether they have been recently used. This feature eliminates the need for manual action by group owners, because it's based on user activity in groups across Microsoft 365 services like Outlook, SharePoint, or Teams. For example, if an owner or a group member does something like upload a document in SharePoint, visit a Teams channel, or send an email to the group in Outlook, the group is automatically renewed around 35 days before the group expires and the owner does not get any renewal notifications.
### Activities that automatically renew group expiration
These articles provide additional information on Azure AD groups.
- [Manage settings of a group](../fundamentals/active-directory-groups-settings-azure-portal.md) - [Manage members of a group](../fundamentals/active-directory-groups-members-azure-portal.md) - [Manage memberships of a group](../fundamentals/active-directory-groups-membership-azure-portal.md)-- [Manage dynamic rules for users in a group](groups-dynamic-membership.md)
+- [Manage dynamic rules for users in a group](groups-dynamic-membership.md)
active-directory Licensing Service Plan Reference https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/enterprise-users/licensing-service-plan-reference.md
When managing licenses in [the Azure portal](https://portal.azure.com/#blade/Mic
| DYNAMICS 365 FOR SALES AND CUSTOMER SERVICE ENTERPRISE EDITION | DYN365_ENTERPRISE_SALES_CUSTOMERSERVICE | 8edc2cf8-6438-4fa9-b6e3-aa1660c640cc | DYN365_ENTERPRISE_P1 (d56f3deb-50d8-465a-bedb-f079817ccac1)<br/>FLOW_DYN_APPS (7e6d7d78-73de-46ba-83b1-6d25117334ba)<br/>NBENTERPRISE (03acaee3-9492-4f40-aed4-bcb6b32981b6)<br/>POWERAPPS_DYN_APPS (874fc546-6efe-4d22-90b8-5c4e7aa59f4b)<br/>PROJECT_ESSENTIALS (1259157c-8581-4875-bca7-2ffb18c51bda)<br/>SHAREPOINTENTERPRISE (5dbe027f-2339-4123-9542-606e4d348a72)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014) |DYNAMICS 365 CUSTOMER ENGAGEMENT PLAN (d56f3deb-50d8-465a-bedb-f079817ccac1)<br/>FLOW FOR DYNAMICS 365 (7e6d7d78-73de-46ba-83b1-6d25117334ba)<br/>MICROSOFT SOCIAL ENGAGEMENT - SERVICE DISCONTINUATION (03acaee3-9492-4f40-aed4-bcb6b32981b6)<br/>POWERAPPS FOR DYNAMICS 365 (874fc546-6efe-4d22-90b8-5c4e7aa59f4b)<br/>PROJECT ONLINE ESSENTIALS (1259157c-8581-4875-bca7-2ffb18c51bda)<br/>SHAREPOINT ONLINE (PLAN 2) (5dbe027f-2339-4123-9542-606e4d348a72)<br/>OFFICE ONLINE (e95bec33-7c88-4a70-8e19-b10bd9d0c014) | | DYNAMICS 365 FOR SALES ENTERPRISE EDITION | DYN365_ENTERPRISE_SALES | 1e1a282c-9c54-43a2-9310-98ef728faace | DYN365_ENTERPRISE_SALES (2da8e897-7791-486b-b08f-cc63c8129df7)<br/>FLOW_DYN_APPS (7e6d7d78-73de-46ba-83b1-6d25117334ba)<br/>NBENTERPRISE (03acaee3-9492-4f40-aed4-bcb6b32981b6)<br/>POWERAPPS_DYN_APPS (874fc546-6efe-4d22-90b8-5c4e7aa59f4b)<br/>PROJECT_ESSENTIALS (1259157c-8581-4875-bca7-2ffb18c51bda)<br/>SHAREPOINTENTERPRISE (5dbe027f-2339-4123-9542-606e4d348a72)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014) | DYNAMICS 365 FOR SALES (2da8e897-7791-486b-b08f-cc63c8129df7)<br/>FLOW FOR DYNAMICS 365 (7e6d7d78-73de-46ba-83b1-6d25117334ba)<br/>MICROSOFT SOCIAL ENGAGEMENT - SERVICE DISCONTINUATION (03acaee3-9492-4f40-aed4-bcb6b32981b6)<br/>POWERAPPS FOR DYNAMICS 365 (874fc546-6efe-4d22-90b8-5c4e7aa59f4b)<br/>PROJECT ONLINE ESSENTIALS (1259157c-8581-4875-bca7-2ffb18c51bda)<br/>SHAREPOINT ONLINE (PLAN 2) (5dbe027f-2339-4123-9542-606e4d348a72)<br/>OFFICE ONLINE (e95bec33-7c88-4a70-8e19-b10bd9d0c014) | | DYNAMICS 365 FOR TEAM MEMBERS ENTERPRISE EDITION | DYN365_ENTERPRISE_TEAM_MEMBERS | 8e7a3d30-d97d-43ab-837c-d7701cef83dc | DYN365_Enterprise_Talent_Attract_TeamMember (643d201a-9884-45be-962a-06ba97062e5e)<br/>DYN365_Enterprise_Talent_Onboard_TeamMember (f2f49eef-4b3f-4853-809a-a055c6103fe0)<br/>DYN365_ENTERPRISE_TEAM_MEMBERS (6a54b05e-4fab-40e7-9828-428db3b336fa)<br/>Dynamics_365_for_Operations_Team_members (f5aa7b45-8a36-4cd1-bc37-5d06dea98645)<br/>Dynamics_365_for_Retail_Team_members (c0454a3d-32b5-4740-b090-78c32f48f0ad)<br/>Dynamics_365_for_Talent_Team_members (d5156635-0704-4f66-8803-93258f8b2678)<br/>FLOW_DYN_TEAM (1ec58c70-f69c-486a-8109-4b87ce86e449)<br/>POWERAPPS_DYN_TEAM (52e619e2-2730-439a-b0d3-d09ab7e8b705)<br/>PROJECT_ESSENTIALS (1259157c-8581-4875-bca7-2ffb18c51bda)<br/>SHAREPOINTENTERPRISE (5dbe027f-2339-4123-9542-606e4d348a72)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014) | DYNAMICS 365 FOR TALENT - ATTRACT EXPERIENCE TEAM MEMBER (643d201a-9884-45be-962a-06ba97062e5e)<br/>DYNAMICS 365 FOR TALENT - ONBOARD EXPERIENCE (f2f49eef-4b3f-4853-809a-a055c6103fe0)<br/>DYNAMICS 365 FOR TEAM MEMBERS (6a54b05e-4fab-40e7-9828-428db3b336fa)<br/>DYNAMICS_365_FOR_OPERATIONS_TEAM_MEMBERS (f5aa7b45-8a36-4cd1-bc37-5d06dea98645)<br/>DYNAMICS 365 FOR RETAIL TEAM MEMBERS (c0454a3d-32b5-4740-b090-78c32f48f0ad)<br/>DYNAMICS 365 FOR TALENT TEAM MEMBERS (d5156635-0704-4f66-8803-93258f8b2678)<br/>FLOW FOR DYNAMICS 365 (1ec58c70-f69c-486a-8109-4b87ce86e449)<br/>POWERAPPS FOR DYNAMICS 365 (52e619e2-2730-439a-b0d3-d09ab7e8b705)<br/>PROJECT ONLINE ESSENTIALS (1259157c-8581-4875-bca7-2ffb18c51bda)<br/>SHAREPOINT ONLINE (PLAN 2) (5dbe027f-2339-4123-9542-606e4d348a72)<br/>OFFICE ONLINE (e95bec33-7c88-4a70-8e19-b10bd9d0c014) |
+| DYNAMICS 365 TEAM MEMBERS | DYN365_TEAM_MEMBERS | 7ac9fe77-66b7-4e5e-9e46-10eed1cff547 | DYNAMICS_365_FOR_RETAIL_TEAM_MEMBERS (c0454a3d-32b5-4740-b090-78c32f48f0ad)<br/>DYN365_ENTERPRISE_TALENT_ATTRACT_TEAMMEMBER (643d201a-9884-45be-962a-06ba97062e5e)<br/>DYN365_ENTERPRISE_TALENT_ONBOARD_TEAMMEMBER (f2f49eef-4b3f-4853-809a-a055c6103fe0)<br/>DYNAMICS_365_FOR_TALENT_TEAM_MEMBERS (d5156635-0704-4f66-8803-93258f8b2678)<br/>DYN365_TEAM_MEMBERS (4092fdb5-8d81-41d3-be76-aaba4074530b)<br/>DYNAMICS_365_FOR_OPERATIONS_TEAM_MEMBERS (f5aa7b45-8a36-4cd1-bc37-5d06dea98645)<br/>EXCHANGE_S_FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318)<br/>FLOW_DYN_TEAM (1ec58c70-f69c-486a-8109-4b87ce86e449)<br/>FLOW_DYN_APPS (7e6d7d78-73de-46ba-83b1-6d25117334ba)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>POWERAPPS_DYN_TEAM (52e619e2-2730-439a-b0d3-d09ab7e8b705)<br/>PROJECT_ESSENTIALS (1259157c-8581-4875-bca7-2ffb18c51bda)<br/>SHAREPOINTENTERPRISE (5dbe027f-2339-4123-9542-606e4d348a72) | DYNAMICS 365 FOR RETAIL TEAM MEMBERS (c0454a3d-32b5-4740-b090-78c32f48f0ad)<br/>Dynamics 365 for Talent - ATTRACT EXPERIENCE TEAM MEMBER (643d201a-9884-45be-962a-06ba97062e5e)<br/>DYNAMICS 365 FOR TALENT - ONBOARD EXPERIENCE (f2f49eef-4b3f-4853-809a-a055c6103fe0)<br/>DYNAMICS 365 FOR TALENT TEAM MEMBERS (d5156635-0704-4f66-8803-93258f8b2678)<br/>DYNAMICS 365 TEAM MEMBERS (4092fdb5-8d81-41d3-be76-aaba4074530b)<br/>DYNAMICS_365_FOR_OPERATIONS_TEAM_MEMBERS (f5aa7b45-8a36-4cd1-bc37-5d06dea98645)<br/>EXCHANGE FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318)<br/>FLOW FOR DYNAMICS 365 (1ec58c70-f69c-486a-8109-4b87ce86e449)<br/>FLOW FOR DYNAMICS 365 (7e6d7d78-73de-46ba-83b1-6d25117334ba)<br/>OFFICE FOR THE WEB (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>POWERAPPS FOR DYNAMICS 365 (52e619e2-2730-439a-b0d3-d09ab7e8b705)<br/>PROJECT ONLINE ESSENTIALS (1259157c-8581-4875-bca7-2ffb18c51bda)<br/>SHAREPOINT (PLAN 2) (5dbe027f-2339-4123-9542-606e4d348a72) |
| DYNAMICS 365 UNF OPS PLAN ENT EDITION | Dynamics_365_for_Operations | ccba3cfe-71ef-423a-bd87-b6df3dce59a9 | DDYN365_CDS_DYN_P2 (d1142cfd-872e-4e77-b6ff-d98ec5a51f66)<br/>DYN365_TALENT_ENTERPRISE (65a1ebf4-6732-4f00-9dcb-3d115ffdeecd)<br/>Dynamics_365_for_Operations (95d2cd7b-1007-484b-8595-5e97e63fe189)<br/>Dynamics_365_for_Retail (a9e39199-8369-444b-89c1-5fe65ec45665)<br/>Dynamics_365_Hiring_Free_PLAN (f815ac79-c5dd-4bcc-9b78-d97f7b817d0d)<br/>Dynamics_365_Onboarding_Free_PLAN (300b8114-8555-4313-b861-0c115d820f50)<br/>FLOW_DYN_P2 (b650d915-9886-424b-a08d-633cede56f57)<br/>POWERAPPS_DYN_P2 (0b03f40b-c404-40c3-8651-2aceb74365fa) | COMMON DATA SERVICE (d1142cfd-872e-4e77-b6ff-d98ec5a51f66)<br/>DYNAMICS 365 FOR TALENT (65a1ebf4-6732-4f00-9dcb-3d115ffdeecd)<br/>DYNAMICS_365_FOR_OPERATIONS (95d2cd7b-1007-484b-8595-5e97e63fe189)<br/>DYNAMICS 365 FOR RETAIL (a9e39199-8369-444b-89c1-5fe65ec45665)<br/>Dynamics_365_Hiring_Free_PLAN (f815ac79-c5dd-4bcc-9b78-d97f7b817d0d)<br/>DYNAMICS 365 FOR TALENT: ONBOARD (300b8114-8555-4313-b861-0c115d820f50)<br/>FLOW FOR DYNAMICS 365(b650d915-9886-424b-a08d-633cede56f57)<br/>POWERAPPS FOR DYNAMICS 365 (0b03f40b-c404-40c3-8651-2aceb74365fa) | | ENTERPRISE MOBILITY + SECURITY E3 | EMS | efccb6f7-5641-4e0e-bd10-b4976e1bf68e | AAD_PREMIUM (41781fb2-bc02-4b7c-bd55-b576c07bb09d)<br/>ADALLOM_S_DISCOVERY (932ad362-64a8-4783-9106-97849a1a30b9)<br/>INTUNE_A (c1ec4a95-1f05-45b3-a911-aa3fa01094f5)<br/>MFA_PREMIUM (8a256a2b-b617-496d-b51b-e76466e88db0)<br/>RMS_S_ENTERPRISE (bea4c11e-220a-4e6d-8eb8-8ea15d019f90)<br/>RMS_S_PREMIUM (6c57d4b6-3b23-47a5-9bc9-69f17b4947b3) | AZURE ACTIVE DIRECTORY PREMIUM P1 (41781fb2-bc02-4b7c-bd55-b576c07bb09d)<br/>CLOUD APP SECURITY DISCOVERY (932ad362-64a8-4783-9106-97849a1a30b9)<br/>MICROSOFT INTUNE (c1ec4a95-1f05-45b3-a911-aa3fa01094f5)<br/>MICROSOFT AZURE MULTI-FACTOR AUTHENTICATION (8a256a2b-b617-496d-b51b-e76466e88db0)<br/>MICROSOFT AZURE ACTIVE DIRECTORY RIGHTS (bea4c11e-220a-4e6d-8eb8-8ea15d019f90)<br/>AZURE INFORMATION PROTECTION PREMIUM P1 (6c57d4b6-3b23-47a5-9bc9-69f17b4947b3) | | ENTERPRISE MOBILITY + SECURITY E5 | EMSPREMIUM | b05e124f-c7cc-45a0-a6aa-8cf78c946968 | AAD_PREMIUM (41781fb2-bc02-4b7c-bd55-b576c07bb09d)<br/>AAD_PREMIUM_P2 (eec0eb4f-6444-4f95-aba0-50c24d67f998)<br/>ADALLOM_S_STANDALONE (2e2ddb96-6af9-4b1d-a3f0-d6ecfd22edb2)<br/>ATA (14ab5db5-e6c4-4b20-b4bc-13e36fd2227f)<br/>INTUNE_A (c1ec4a95-1f05-45b3-a911-aa3fa01094f5)<br/>MFA_PREMIUM (8a256a2b-b617-496d-b51b-e76466e88db0)<br/>RMS_S_ENTERPRISE (bea4c11e-220a-4e6d-8eb8-8ea15d019f90)<br/>RMS_S_PREMIUM (6c57d4b6-3b23-47a5-9bc9-69f17b4947b3)<br/>RMS_S_PREMIUM2 (5689bec4-755d-4753-8b61-40975025187c) | AZURE ACTIVE DIRECTORY PREMIUM P1 (41781fb2-bc02-4b7c-bd55-b576c07bb09d)<br/>AZURE ACTIVE DIRECTORY PREMIUM P2 (eec0eb4f-6444-4f95-aba0-50c24d67f998)<br/>MICROSOFT CLOUD APP SECURITY (2e2ddb96-6af9-4b1d-a3f0-d6ecfd22edb2)<br/>AZURE ADVANCED THREAT PROTECTION (14ab5db5-e6c4-4b20-b4bc-13e36fd2227f)<br/>MICROSOFT INTUNE (c1ec4a95-1f05-45b3-a911-aa3fa01094f5)<br/>MICROSOFT AZURE MULTI-FACTOR AUTHENTICATION (8a256a2b-b617-496d-b51b-e76466e88db0)<br/>MICROSOFT AZURE ACTIVE DIRECTORY RIGHTS (bea4c11e-220a-4e6d-8eb8-8ea15d019f90)<br/>AZURE INFORMATION PROTECTION PREMIUM P1 (6c57d4b6-3b23-47a5-9bc9-69f17b4947b3)<br/>AZURE INFORMATION PROTECTION PREMIUM P2 (5689bec4-755d-4753-8b61-40975025187c) |
When managing licenses in [the Azure portal](https://portal.azure.com/#blade/Mic
| MICROSOFT 365 APPS FOR BUSINESS | O365_BUSINESS | cdd28e44-67e3-425e-be4c-737fab2899d3 | FORMS_PLAN_E1 (159f4cd6-e380-449f-a816-af1a9ef76344)<br/>OFFICE_BUSINESS (094e7854-93fc-4d55-b2c0-3ab5369ebdc1)<br/>ONEDRIVESTANDARD (13696edf-5a08-49f6-8134-03083ed8ba30)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97) | MICROSOFT FORMS (PLAN E1) (159f4cd6-e380-449f-a816-af1a9ef76344)<br/>OFFICE 365 BUSINESS (094e7854-93fc-4d55-b2c0-3ab5369ebdc1)<br/>ONEDRIVESTANDARD (13696edf-5a08-49f6-8134-03083ed8ba30)<br/>OFFICE ONLINE (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97) | | MICROSOFT 365 APPS FOR BUSINESS | SMB_BUSINESS | b214fe43-f5a3-4703-beeb-fa97188220fc | FORMS_PLAN_E1 (159f4cd6-e380-449f-a816-af1a9ef76344)<br/>OFFICE_BUSINESS (094e7854-93fc-4d55-b2c0-3ab5369ebdc1)<br/>ONEDRIVESTANDARD (13696edf-5a08-49f6-8134-03083ed8ba30)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97) | MICROSOFT FORMS (PLAN E1) (159f4cd6-e380-449f-a816-af1a9ef76344)<br/>OFFICE 365 BUSINESS (094e7854-93fc-4d55-b2c0-3ab5369ebdc1)<br/>ONEDRIVESTANDARD (13696edf-5a08-49f6-8134-03083ed8ba30)<br/>OFFICE ONLINE (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97) | | MICROSOFT 365 APPS FOR ENTERPRISE | OFFICESUBSCRIPTION | c2273bd0-dff7-4215-9ef5-2c7bcfb06425 | FORMS_PLAN_E1 (159f4cd6-e380-449f-a816-af1a9ef76344)<br/>OFFICESUBSCRIPTION (43de0ff5-c92c-492b-9116-175376d08c38)<br/>ONEDRIVESTANDARD (13696edf-5a08-49f6-8134-03083ed8ba30)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97) | MICROSOFT FORMS (PLAN E1) (159f4cd6-e380-449f-a816-af1a9ef76344)<br/>OFFICESUBSCRIPTION (43de0ff5-c92c-492b-9116-175376d08c38)<br/>ONEDRIVESTANDARD (13696edf-5a08-49f6-8134-03083ed8ba30)<br/>OFFICE ONLINE (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97) |
+| MICROSOFT 365 AUDIO CONFERENCING FOR GCC | MCOMEETADV_GOC | 2d3091c7-0712-488b-b3d8-6b97bde6a1f5 | ECHANGE_FOUNDATION_GOV (922ba911-5694-4e99-a794-73aed9bfeec8<br/>MCOMEETADV_GOV (f544b08d-1645-4287-82de-8d91f37c02a1) | EXCHANGE FOUNDATION FOR GOVERNMENT (922ba911-5694-4e99-a794-73aed9bfeec8)<br/>MICROSOFT 365 AUDIO CONFERENCING FOR GOVERNMENT (f544b08d-1645-4287-82de-8d91f37c02a1) |
| MICROSOFT 365 BUSINESS BASIC | O365_BUSINESS_ESSENTIALS | 3b555118-da6a-4418-894f-7df1e2096870 | BPOS_S_TODO_1 (5e62787c-c316-451f-b873-1d05acd4d12c)<br/>EXCHANGE_S_STANDARD (9aaf7827-d63c-4b61-89c3-182f06f82e5c)<br/>FLOW_O365_P1 (0f9b09cb-62d1-4ff4-9129-43f4996f83f4)<br/>FORMS_PLAN_E1 (159f4cd6-e380-449f-a816-af1a9ef76344)<br/>MCOSTANDARD (0feaeb32-d00e-4d66-bd5a-43b5b83db82c)<br/>OFFICEMOBILE_SUBSCRIPTION (c63d4d19-e8cb-460e-b37c-4d6c34603745)<br/>POWERAPPS_O365_P1 (92f7a6f3-b89b-4bbd-8c30-809e6da5ad1c)<br/>PROJECTWORKMANAGEMENT (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>SHAREPOINTSTANDARD (c7699d2e-19aa-44de-8edf-1736da088ca1)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>YAMMER_ENTERPRISE (7547a3fe-08ee-4ccb-b430-5077c5041653) | BPOS_S_TODO_1 (5e62787c-c316-451f-b873-1d05acd4d12c)<br/>EXCHANGE ONLINE (PLAN 1) (9aaf7827-d63c-4b61-89c3-182f06f82e5c)<br/>FLOW FOR OFFICE 365 (0f9b09cb-62d1-4ff4-9129-43f4996f83f4)<br/>MICROSOFT FORMS (PLAN E1) (159f4cd6-e380-449f-a816-af1a9ef76344)<br/>SKYPE FOR BUSINESS ONLINE (PLAN 2) (0feaeb32-d00e-4d66-bd5a-43b5b83db82c)<br/>OFFICEMOBILE_SUBSCRIPTION (c63d4d19-e8cb-460e-b37c-4d6c34603745)<br/>POWERAPPS FOR OFFICE 365 (92f7a6f3-b89b-4bbd-8c30-809e6da5ad1c)<br/>MICROSOFT PLANNER(b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>SHAREPOINTSTANDARD (c7699d2e-19aa-44de-8edf-1736da088ca1)<br/>OFFICE ONLINE (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>YAMMER_ENTERPRISE (7547a3fe-08ee-4ccb-b430-5077c5041653) | | MICROSOFT 365 BUSINESS BASIC | SMB_BUSINESS_ESSENTIALS | dab7782a-93b1-4074-8bb1-0e61318bea0b | BPOS_S_TODO_1 (5e62787c-c316-451f-b873-1d05acd4d12c)<br/>EXCHANGE_S_STANDARD (9aaf7827-d63c-4b61-89c3-182f06f82e5c)<br/>FLOW_O365_P1 (0f9b09cb-62d1-4ff4-9129-43f4996f83f4)<br/>FORMS_PLAN_E1 (159f4cd6-e380-449f-a816-af1a9ef76344)<br/>MCOSTANDARD (0feaeb32-d00e-4d66-bd5a-43b5b83db82c)<br/>OFFICEMOBILE_SUBSCRIPTION (c63d4d19-e8cb-460e-b37c-4d6c34603745)<br/>POWERAPPS_O365_P1 (92f7a6f3-b89b-4bbd-8c30-809e6da5ad1c)<br/>PROJECTWORKMANAGEMENT (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>SHAREPOINTSTANDARD (c7699d2e-19aa-44de-8edf-1736da088ca1)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>YAMMER_MIDSIZE (41bf139a-4e60-409f-9346-a1361efc6dfb) | BPOS_S_TODO_1 (5e62787c-c316-451f-b873-1d05acd4d12c)<br/>EXCHANGE ONLINE (PLAN 1) (9aaf7827-d63c-4b61-89c3-182f06f82e5c)<br/>FLOW FOR OFFICE 365 (0f9b09cb-62d1-4ff4-9129-43f4996f83f4)<br/>MICROSOFT FORMS (PLAN E1) (159f4cd6-e380-449f-a816-af1a9ef76344)<br/>SKYPE FOR BUSINESS ONLINE (PLAN 2) (0feaeb32-d00e-4d66-bd5a-43b5b83db82c)<br/>OFFICEMOBILE_SUBSCRIPTION (c63d4d19-e8cb-460e-b37c-4d6c34603745)<br/>POWERAPPS FOR OFFICE 365 (92f7a6f3-b89b-4bbd-8c30-809e6da5ad1c)<br/>MICROSOFT PLANNER(b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>SHAREPOINTSTANDARD (c7699d2e-19aa-44de-8edf-1736da088ca1)<br/>OFFICE ONLINE (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>YAMMER_MIDSIZE (41bf139a-4e60-409f-9346-a1361efc6dfb) | | MICROSOFT 365 BUSINESS STANDARD | O365_BUSINESS_PREMIUM | f245ecc8-75af-4f8e-b61f-27d8114de5f3 | BPOS_S_TODO_1 (5e62787c-c316-451f-b873-1d05acd4d12c)<br/>Deskless (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>EXCHANGE_S_STANDARD (9aaf7827-d63c-4b61-89c3-182f06f82e5c)<br/>FLOW_O365_P1 (0f9b09cb-62d1-4ff4-9129-43f4996f83f4)<br/>FORMS_PLAN_E1 (159f4cd6-e380-449f-a816-af1a9ef76344)<br/>MCOSTANDARD (0feaeb32-d00e-4d66-bd5a-43b5b83db82c)<br/>MICROSOFTBOOKINGS (199a5c09-e0ca-4e37-8f7c-b05d533e1ea2)<br/>O365_SB_Relationship_Management (5bfe124c-bbdc-4494-8835-f1297d457d79)<br/>OFFICE_BUSINESS (094e7854-93fc-4d55-b2c0-3ab5369ebdc1)<br/>POWERAPPS_O365_P1 (92f7a6f3-b89b-4bbd-8c30-809e6da5ad1c)<br/>PROJECTWORKMANAGEMENT (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>SHAREPOINTSTANDARD (c7699d2e-19aa-44de-8edf-1736da088ca1)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>YAMMER_ENTERPRISE (7547a3fe-08ee-4ccb-b430-5077c5041653)| BPOS_S_TODO_1 (5e62787c-c316-451f-b873-1d05acd4d12c)<br/>MICROSOFT STAFFHUB (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>EXCHANGE ONLINE (PLAN 1) (9aaf7827-d63c-4b61-89c3-182f06f82e5c)<br/>FLOW FOR OFFICE 365 (0f9b09cb-62d1-4ff4-9129-43f4996f83f4)<br/>MICROSOFT FORMS (PLAN E1) (159f4cd6-e380-449f-a816-af1a9ef76344)<br/>SKYPE FOR BUSINESS ONLINE (PLAN 2) (0feaeb32-d00e-4d66-bd5a-43b5b83db82c)<br/>MICROSOFTBOOKINGS (199a5c09-e0ca-4e37-8f7c-b05d533e1ea2)<br/>OUTLOOK CUSTOMER MANAGER (5bfe124c-bbdc-4494-8835-f1297d457d79)<br/>OFFICE 365 BUSINESS (094e7854-93fc-4d55-b2c0-3ab5369ebdc1)<br/>POWERAPPS FOR OFFICE 365 (92f7a6f3-b89b-4bbd-8c30-809e6da5ad1c)<br/>MICROSOFT PLANNER(b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>SHAREPOINTSTANDARD (c7699d2e-19aa-44de-8edf-1736da088ca1)<br/>OFFICE ONLINE (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>YAMMER_ENTERPRISE (7547a3fe-08ee-4ccb-b430-5077c5041653) |
When managing licenses in [the Azure portal](https://portal.azure.com/#blade/Mic
| Microsoft 365 F1 | M365_F1 | 44575883-256e-4a79-9da4-ebe9acabe2b2 | AAD_PREMIUM (41781fb2-bc02-4b7c-bd55-b576c07bb09d)<br/>RMS_S_PREMIUM (6c57d4b6-3b23-47a5-9bc9-69f17b4947b3)<br/>RMS_S_ENTERPRISE_GOV (6a76346d-5d6e-4051-9fe3-ed3f312b5597)<br/>ADALLOM_S_DISCOVERY (932ad362-64a8-4783-9106-97849a1a30b9)<br/>EXCHANGE_S_FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318)<br/>MFA_PREMIUM (8a256a2b-b617-496d-b51b-e76466e88db0)<br/>INTUNE_A (c1ec4a95-1f05-45b3-a911-aa3fa01094f5)<br/>PROJECTWORKMANAGEMENT (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>STREAM_O365_K (3ffba0d2-38e5-4d5e-8ec0-98f2b05c09d9)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>INTUNE_O365 (882e1d05-acd1-4ccb-8708-6ee03664b117)<br/>SHAREPOINTDESKLESS (902b47e5-dcb2-4fdc-858b-c63a90a2bdb9)<br/>MCOIMP (afc06cb0-b4f4-4473-8286-d644f70d8faf)<br/>YAMMER_ENTERPRISE (7547a3fe-08ee-4ccb-b430-5077c5041653) | Azure Active Directory Premium P1 (41781fb2-bc02-4b7c-bd55-b576c07bb09d)<br/>Azure Information Protection Premium P1 (6c57d4b6-3b23-47a5-9bc9-69f17b4947b3)<br/>Azure Rights Management (6a76346d-5d6e-4051-9fe3-ed3f312b5597)<br/>Cloud App Security Discovery (932ad362-64a8-4783-9106-97849a1a30b9)<br/>Exchange Foundation (113feb6c-3fe4-4440-bddc-54d774bf0318)<br/>Microsoft Azure Multi-Factor Authentication (8a256a2b-b617-496d-b51b-e76466e88db0)<br/>Microsoft Intune (c1ec4a95-1f05-45b3-a911-aa3fa01094f5)<br/>Microsoft Planner (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>Microsoft Stream for O365 K SKU (3ffba0d2-38e5-4d5e-8ec0-98f2b05c09d9)<br/>Microsoft Teams (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>Mobile Device Management for Office 365 (882e1d05-acd1-4ccb-8708-6ee03664b117)<br/>SharePoint Online Kiosk (902b47e5-dcb2-4fdc-858b-c63a90a2bdb9)<br/>Skype for Business Online (Plan 1) (afc06cb0-b4f4-4473-8286-d644f70d8faf)<br/>Yammer Enterprise (7547a3fe-08ee-4ccb-b430-5077c5041653) | | Microsoft 365 F3 | SPE_F1 | 66b55226-6b4f-492c-910c-a3b7a3c9d993 | AAD_PREMIUM (41781fb2-bc02-4b7c-bd55-b576c07bb09d)<br/>RMS_S_PREMIUM (6c57d4b6-3b23-47a5-9bc9-69f17b4947b3)<br/>RMS_S_ENTERPRISE (bea4c11e-220a-4e6d-8eb8-8ea15d019f90)<br/>ADALLOM_S_DISCOVERY (932ad362-64a8-4783-9106-97849a1a30b9)<br/>EXCHANGE_S_DESKLESS (4a82b400-a79f-41a4-b4e2-e94f5787b113)<br/>FLOW_O365_S1 (bd91b1a4-9f94-4ecf-b45b-3a65e5c8128a)<br/>MFA_PREMIUM (8a256a2b-b617-496d-b51b-e76466e88db0)<br/>FORMS_PLAN_K (f07046bd-2a3c-4b96-b0be-dea79d7cbfb8)<br/>INTUNE_A (c1ec4a95-1f05-45b3-a911-aa3fa01094f5)<br/>KAIZALA_O365_P1 (73b2a583-6a59-42e3-8e83-54db46bc3278)<br/>PROJECTWORKMANAGEMENT (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>MICROSOFT_SEARCH (94065c59-bc8e-4e8b-89e5-5138d471eaff)<br/>Deskless (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>STREAM_O365_K (3ffba0d2-38e5-4d5e-8ec0-98f2b05c09d9)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>INTUNE_O365 (882e1d05-acd1-4ccb-8708-6ee03664b117)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>OFFICEMOBILE_SUBSCRIPTION (c63d4d19-e8cb-460e-b37c-4d6c34603745)<br/>POWERAPPS_O365_S1 (e0287f9f-e222-4f98-9a83-f379e249159a)<br/>SHAREPOINTDESKLESS (902b47e5-dcb2-4fdc-858b-c63a90a2bdb9)<br/>MCOIMP (afc06cb0-b4f4-4473-8286-d644f70d8faf)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>BPOS_S_TODO_FIRSTLINE (80873e7a-cd2a-4e67-b061-1b5381a676a5)<br/>WHITEBOARD_FIRSTLINE1 (36b29273-c6d0-477a-aca6-6fbe24f538e3)<br/>WIN10_ENT_LOC_F1 (e041597c-9c7f-4ed9-99b0-2663301576f7)<br/>YAMMER_ENTERPRISE (7547a3fe-08ee-4ccb-b430-5077c5041653) | Azure Active Directory Premium P1 (41781fb2-bc02-4b7c-bd55-b576c07bb09d)<br/>Azure Information Protection Premium P1 (6c57d4b6-3b23-47a5-9bc9-69f17b4947b3)<br/>Azure Rights Management (bea4c11e-220a-4e6d-8eb8-8ea15d019f90)<br/>Cloud App Security Discovery (932ad362-64a8-4783-9106-97849a1a30b9)<br/>Exchange Online Kiosk (4a82b400-a79f-41a4-b4e2-e94f5787b113)<br/>Flow for Office 365 K1 (bd91b1a4-9f94-4ecf-b45b-3a65e5c8128a)<br/>Microsoft Azure Multi-Factor Authentication (8a256a2b-b617-496d-b51b-e76466e88db0)<br/>Microsoft Forms (Plan F1) (f07046bd-2a3c-4b96-b0be-dea79d7cbfb8)<br/>Microsoft Intune (c1ec4a95-1f05-45b3-a911-aa3fa01094f5)<br/>Microsoft Kaizala Pro Plan 1 (73b2a583-6a59-42e3-8e83-54db46bc3278)<br/>Microsoft Planner (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>Microsoft Search (94065c59-bc8e-4e8b-89e5-5138d471eaff)<br/>Microsoft StaffHub (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>Microsoft Stream for O365 K SKU (3ffba0d2-38e5-4d5e-8ec0-98f2b05c09d9)<br/>Microsoft Teams (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>Mobile Device Management for Office 365 (882e1d05-acd1-4ccb-8708-6ee03664b117)<br/>Office for the web (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>Office Mobile Apps for Office 365 (c63d4d19-e8cb-460e-b37c-4d6c34603745)<br/>PowerApps for Office 365 K1 (e0287f9f-e222-4f98-9a83-f379e249159a)<br/>SharePoint Online Kiosk (902b47e5-dcb2-4fdc-858b-c63a90a2bdb9)<br/>Skype for Business Online (Plan 1) (afc06cb0-b4f4-4473-8286-d644f70d8faf)<br/>Sway (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>To-Do (Firstline) (80873e7a-cd2a-4e67-b061-1b5381a676a5)<br/>Whiteboard (Firstline) (36b29273-c6d0-477a-aca6-6fbe24f538e3)<br/>Windows 10 Enterprise E3 (local only) (e041597c-9c7f-4ed9-99b0-2663301576f7)<br/>Yammer Enterprise (7547a3fe-08ee-4ccb-b430-5077c5041653) | | MICROSOFT FLOW FREE | FLOW_FREE | f30db892-07e9-47e9-837c-80727f46fd3d | DYN365_CDS_VIRAL (17ab22cd-a0b3-4536-910a-cb6eb12696c0) | EXCHANGE_S_FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318) | FLOW_P2_VIRAL (50e68c76-46c6-4674-81f9-75456511b170) | COMMON DATA SERVICE - VIRAL (17ab22cd-a0b3-4536-910a-cb6eb12696c0) | EXCHANGE FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318) | FLOW FREE (50e68c76-46c6-4674-81f9-75456511b170) |
+| MICROSOFT 365 GCC G3 | M365_G3_GOV | e823ca47-49c4-46b3-b38d-ca11d5abe3d2 | AAD_PREMIUM (41781fb2-bc02-4b7c-bd55-b576c07bb09d)<br/>RMS_S_ENTERPRISE_GOV (6a76346d-5d6e-4051-9fe3-ed3f312b5597)<br/>RMS_S_PREMIUM_GOV (1b66aedf-8ca1-4f73-af76-ec76c6180f98)<br/>CONTENT_EXPLORER (d9fa6af4-e046-4c89-9226-729a0786685d)<br/>EXCHANGE_S_ENTERPRISE_GOV (8c3069c0-ccdb-44be-ab77-986203a67df2)<br/>FORMS_GOV_E3 (24af5f65-d0f3-467b-9f78-ea798c4aeffc)<br/>MIP_S_CLP1 (5136a095-5cf0-4aff-bec3-e84448b38ea5)<br/>MYANALYTICS_P2_GOV (6e5b7995-bd4f-4cbd-9d19-0e32010c72f0)<br/>OFFICESUBSCRIPTION_GOV (de9234ff-6483-44d9-b15e-dca72fdd27af)<br/>MFA_PREMIUM (8a256a2b-b617-496d-b51b-e76466e88db0)<br/>MICROSOFTBOOKINGS (199a5c09-e0ca-4e37-8f7c-b05d533e1ea2)<br/>INTUNE_A (c1ec4a95-1f05-45b3-a911-aa3fa01094f5)<br/>STREAM_O365_E3_GOV (2c1ada27-dbaa-46f9-bda6-ecb94445f758)<br/>TEAMS_GOV (304767db-7d23-49e8-a945-4a7eb65f9f28)<br/>PROJECTWORKMANAGEMENT_GOV (5b4ef465-7ea1-459a-9f91-033317755a51)<br/>SHAREPOINTWAC_GOV (8f9f0f3b-ca90-406c-a842-95579171f8ec)<br/>POWERAPPS_O365_P2_GOV (0a20c815-5e81-4727-9bdc-2b5a117850c3)<br/>FLOW_O365_P2_GOV (c537f360-6a00-4ace-a7f5-9128d0ac1e4b)<br/>SHAREPOINTENTERPRISE_GOV (153f85dd-d912-4762-af6c-d6e0fb4f6692)<br/>MCOSTANDARD_GOV (a31ef4a2-f787-435e-8335-e47eb0cafc94) | AZURE ACTIVE DIRECTORY PREMIUM P1 (41781fb2-bc02-4b7c-bd55-b576c07bb09d)<br/>AZURE RIGHTS MANAGEMENT (6a76346d-5d6e-4051-9fe3-ed3f312b5597)<br/>AZURE RIGHTS MANAGEMENT PREMIUM FOR GOVERNMENT (1b66aedf-8ca1-4f73-af76-ec76c6180f98)<br/>CONTENT EXPLORER (d9fa6af4-e046-4c89-9226-729a0786685d)<br/>EXCHANGE PLAN 2G (8c3069c0-ccdb-44be-ab77-986203a67df2)<br/>FORMS FOR GOVERNMENT (PLAN E3) (24af5f65-d0f3-467b-9f78-ea798c4aeffc)<br/>INFORMATION PROTECTION FOR OFFICE 365 ΓÇô STANDARD (5136a095-5cf0-4aff-bec3-e84448b38ea5)<br/>INSIGHTS BY MYANALYTICS FOR GOVERNMENT (6e5b7995-bd4f-4cbd-9d19-0e32010c72f0)<br/>MICROSOFT 365 APPS FOR ENTERPRISE G (de9234ff-6483-44d9-b15e-dca72fdd27af)<br/>MICROSOFT AZURE MULTI-FACTOR AUTHENTICATION (8a256a2b-b617-496d-b51b-e76466e88db0)<br/>MICROSOFT BOOKINGS (199a5c09-e0ca-4e37-8f7c-b05d533e1ea2)<br/>MICROSOFT INTUNE (c1ec4a95-1f05-45b3-a911-aa3fa01094f5)<br/>MICROSOFT STREAM FOR O365 FOR GOVERNMENT (E3) (2c1ada27-dbaa-46f9-bda6-ecb94445f758)<br/>MICROSOFT TEAMS FOR GOVERNMENT (304767db-7d23-49e8-a945-4a7eb65f9f28)<br/>OFFICE 365 PLANNER FOR GOVERNMENT (5b4ef465-7ea1-459a-9f91-033317755a51)<br/>OFFICE FOR THE WEB (GOVERNMENT) (8f9f0f3b-ca90-406c-a842-95579171f8ec)<br/>POWER APPS FOR OFFICE 365 FOR GOVERNMENT (0a20c815-5e81-4727-9bdc-2b5a117850c3)<br/>POWER AUTOMATE FOR OFFICE 365 FOR GOVERNMENT (c537f360-6a00-4ace-a7f5-9128d0ac1e4b)<br/>SHAREPOINT PLAN 2G (153f85dd-d912-4762-af6c-d6e0fb4f6692)<br/>SKYPE FOR BUSINESS ONLINE (PLAN 2) FOR GOVERNMENT (a31ef4a2-f787-435e-8335-e47eb0cafc94) |
| MICROSOFT 365 PHONE SYSTEM | MCOEV | e43b5b99-8dfb-405f-9987-dc307f34bcbd | MCOEV (4828c8ec-dc2e-4779-b502-87ac9ce28ab7) | MICROSOFT 365 PHONE SYSTEM (4828c8ec-dc2e-4779-b502-87ac9ce28ab7) | | MICROSOFT 365 PHONE SYSTEM FOR DOD | MCOEV_DOD | d01d9287-694b-44f3-bcc5-ada78c8d953e | MCOEV (4828c8ec-dc2e-4779-b502-87ac9ce28ab7) | MICROSOFT 365 PHONE SYSTEM (4828c8ec-dc2e-4779-b502-87ac9ce28ab7) | | MICROSOFT 365 PHONE SYSTEM FOR FACULTY | MCOEV_FACULTY | d979703c-028d-4de5-acbf-7955566b69b9 | MCOEV (4828c8ec-dc2e-4779-b502-87ac9ce28ab7) | MICROSOFT 365 PHONE SYSTEM(4828c8ec-dc2e-4779-b502-87ac9ce28ab7) |
When managing licenses in [the Azure portal](https://portal.azure.com/#blade/Mic
| MICROSOFT DYNAMICS CRM ONLINE BASIC | CRMPLAN2 | 906af65a-2970-46d5-9b58-4e9aa50f0657 | CRMPLAN2 (bf36ca64-95c6-4918-9275-eb9f4ce2c04f)<br/>FLOW_DYN_APPS (7e6d7d78-73de-46ba-83b1-6d25117334ba)<br/>POWERAPPS_DYN_APPS (874fc546-6efe-4d22-90b8-5c4e7aa59f4b) | MICROSOFT DYNAMICS CRM ONLINE BASIC(bf36ca64-95c6-4918-9275-eb9f4ce2c04f)<br/>FLOW FOR DYNAMICS 365 (7e6d7d78-73de-46ba-83b1-6d25117334ba)<br/>POWERAPPS FOR DYNAMICS 365 (874fc546-6efe-4d22-90b8-5c4e7aa59f4b) | | MICROSOFT DYNAMICS CRM ONLINE | CRMSTANDARD | d17b27af-3f49-4822-99f9-56a661538792 | CRMSTANDARD (f9646fb2-e3b2-4309-95de-dc4833737456)<br/>FLOW_DYN_APPS (7e6d7d78-73de-46ba-83b1-6d25117334ba)<br/>MDM_SALES_COLLABORATION (3413916e-ee66-4071-be30-6f94d4adfeda)<br/>NBPROFESSIONALFORCRM (3e58e97c-9abe-ebab-cd5f-d543d1529634)<br/>POWERAPPS_DYN_APPS (874fc546-6efe-4d22-90b8-5c4e7aa59f4b) | MICROSOFT DYNAMICS CRM ONLINE PROFESSIONAL(f9646fb2-e3b2-4309-95de-dc4833737456)<br/>FLOW FOR DYNAMICS 365 (7e6d7d78-73de-46ba-83b1-6d25117334ba)<br/>MICROSOFT DYNAMICS MARKETING SALES COLLABORATION - ELIGIBILITY CRITERIA APPLY (3413916e-ee66-4071-be30-6f94d4adfeda)<br/>MICROSOFT SOCIAL ENGAGEMENT PROFESSIONAL - ELIGIBILITY CRITERIA APPLY (3e58e97c-9abe-ebab-cd5f-d543d1529634)<br/>POWERAPPS FOR DYNAMICS 365 (874fc546-6efe-4d22-90b8-5c4e7aa59f4b) | | MS IMAGINE ACADEMY | IT_ACADEMY_AD | ba9a34de-4489-469d-879c-0f0f145321cd | IT_ACADEMY_AD (d736def0-1fde-43f0-a5be-e3f8b2de6e41) | MS IMAGINE ACADEMY (d736def0-1fde-43f0-a5be-e3f8b2de6e41) |
+| MICROSOFT INTUNE DEVICE for GOVERNMENT | INTUNE_A_D_GOV | 2c21e77a-e0d6-4570-b38a-7ff2dc17d2ca | EXCHANGE_S_FOUNDATION_GOV (922ba911-5694-4e99-a794-73aed9bfeec8)<br/>INTUNE_A (c1ec4a95-1f05-45b3-a911-aa3fa01094f5) | EXCHANGE FOUNDATION FOR GOVERNMENT (922ba911-5694-4e99-a794-73aed9bfeec8)<br/>MICROSOFT INTUNE (c1ec4a95-1f05-45b3-a911-aa3fa01094f5) |
+| MICROSOFT POWER APPS PLAN 2 TRIAL | POWERAPPS_VIRAL | dcb1a3ae-b33f-4487-846a-a640262fadf4 | DYN365_CDS_VIRAL (17ab22cd-a0b3-4536-910a-cb6eb12696c0)<br/>EXCHANGE_S_FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318)<br/>FLOW_P2_VIRAL (50e68c76-46c6-4674-81f9-75456511b170)<br/>FLOW_P2_VIRAL_REAL (d20bfa21-e9ae-43fc-93c2-20783f0840c3)<br/>POWERAPPS_P2_VIRAL (d5368ca3-357e-4acb-9c21-8495fb025d1f) | COMMON DATA SERVICE ΓÇô VIRAL (17ab22cd-a0b3-4536-910a-cb6eb12696c0)<br/>EXCHANGE FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318)<br/>FLOW FREE (50e68c76-46c6-4674-81f9-75456511b170)<br/>FLOW P2 VIRAL (d20bfa21-e9ae-43fc-93c2-20783f0840c3)<br/>POWERAPPS TRIAL (d5368ca3-357e-4acb-9c21-8495fb025d1f) |
| MICROSOFT TEAM (FREE) | TEAMS_FREE | 16ddbbfc-09ea-4de2-b1d7-312db6112d70 | EXCHANGE_S_FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318) | MCOFREE (617d9209-3b90-4879-96e6-838c42b2701d) | TEAMS_FREE (4fa4026d-ce74-4962-a151-8e96d57ea8e4) | SHAREPOINTDESKLESS (902b47e5-dcb2-4fdc-858b-c63a90a2bdb9) | TEAMS_FREE_SERVICE (bd6f2ac2-991a-49f9-b23c-18c96a02c228) | WHITEBOARD_FIRSTLINE1 (36b29273-c6d0-477a-aca6-6fbe24f538e3) | EXCHANGE FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318) | MCO FREE FOR MICROSOFT TEAMS (FREE) (617d9209-3b90-4879-96e6-838c42b2701d) | MICROSOFT TEAMS (FREE) (4fa4026d-ce74-4962-a151-8e96d57ea8e4) | SHAREPOINT KIOSK (902b47e5-dcb2-4fdc-858b-c63a90a2bdb9) | TEAMS FREE SERVICE (bd6f2ac2-991a-49f9-b23c-18c96a02c228) | WHITEBOARD (FIRSTLINE) (36b29273-c6d0-477a-aca6-6fbe24f538e3) |
+| MICROSOFT TEAMS EXPLORATORY | TEAMS_EXPLORATORY | 710779e8-3d4a-4c88-adb9-386c958d1fdf | CDS_O365_P1 (bed136c6-b799-4462-824d-fc045d3a9d25)<br/>EXCHANGE_S_STANDARD (9aaf7827-d63c-4b61-89c3-182f06f82e5c)<br/>MYANALYTICS_P2 (33c4f319-9bdd-48d6-9c4d-410b750a4a5a)<br/>FORMS_PLAN_E1 (159f4cd6-e380-449f-a816-af1a9ef76344)<br/>PROJECTWORKMANAGEMENT (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>MICROSOFT_SEARCH (94065c59-bc8e-4e8b-89e5-5138d471eaff)<br/>DESKLESS (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>STREAM_O365_E1 (743dd19e-1ce3-4c62-a3ad-49ba8f63a2f6)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>MCO_TEAMS_IW (42a3ec34-28ba-46b6-992f-db53a675ac5b)<br/>INTUNE_O365 (882e1d05-acd1-4ccb-8708-6ee03664b117)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>OFFICEMOBILE_SUBSCRIPTION (c63d4d19-e8cb-460e-b37c-4d6c34603745)<br/>POWERAPPS_O365_P1 (92f7a6f3-b89b-4bbd-8c30-809e6da5ad1c)<br/>FLOW_O365_P1 (0f9b09cb-62d1-4ff4-9129-43f4996f83f4)<br/>POWER_VIRTUAL_AGENTS_O365_P1 (0683001c-0492-4d59-9515-d9a6426b5813)<br/>SHAREPOINTSTANDARD (c7699d2e-19aa-44de-8edf-1736da088ca1)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>BPOS_S_TODO_1 (5e62787c-c316-451f-b873-1d05acd4d12c)<br/>WHITEBOARD_PLAN1 (b8afc642-032e-4de5-8c0a-507a7bba7e5d)<br/>YAMMER_ENTERPRISE (7547a3fe-08ee-4ccb-b430-5077c5041653) | COMMON DATA SERVICE FOR TEAMS_P1 (bed136c6-b799-4462-824d-fc045d3a9d25)<br/>EXCHANGE ONLINE (PLAN 1) (9aaf7827-d63c-4b61-89c3-182f06f82e5c)<br/>INSIGHTS BY MYANALYTICS (33c4f319-9bdd-48d6-9c4d-410b750a4a5a)<br/>MICROSOFT FORMS (PLAN E1) (159f4cd6-e380-449f-a816-af1a9ef76344)<br/>MICROSOFT PLANNER (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>MICROSOFT SEARCH (94065c59-bc8e-4e8b-89e5-5138d471eaff)<br/>MICROSOFT STAFFHUB (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>MICROSOFT STREAM FOR O365 E1 SKU (743dd19e-1ce3-4c62-a3ad-49ba8f63a2f6)<br/>MICROSOFT TEAMS (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>MICROSOFT TEAMS (42a3ec34-28ba-46b6-992f-db53a675ac5b)<br/>MOBILE DEVICE MANAGEMENT FOR OFFICE 365 (882e1d05-acd1-4ccb-8708-6ee03664b117)<br/>OFFICE FOR THE WEB (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>OFFICE MOBILE APPS FOR OFFICE 365 (c63d4d19-e8cb-460e-b37c-4d6c34603745)<br/>POWER APPS FOR OFFICE 365 (92f7a6f3-b89b-4bbd-8c30-809e6da5ad1c)<br/>POWER AUTOMATE FOR OFFICE 365 (0f9b09cb-62d1-4ff4-9129-43f4996f83f4)<br/>POWER VIRTUAL AGENTS FOR OFFICE 365 P1(0683001c-0492-4d59-9515-d9a6426b5813)<br/>SHAREPOINT ONLINE (PLAN 1) (c7699d2e-19aa-44de-8edf-1736da088ca1)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>TO-DO (PLAN 1) (5e62787c-c316-451f-b873-1d05acd4d12c)<br/>WHITEBOARD (PLAN 1) (b8afc642-032e-4de5-8c0a-507a7bba7e5d)<br/>YAMMER ENTERPRISE (7547a3fe-08ee-4ccb-b430-5077c5041653) |
| Office 365 A5 for faculty| ENTERPRISEPREMIUM_FACULTY | a4585165-0533-458a-97e3-c400570268c4 | AAD_BASIC_EDU (1d0f309f-fdf9-4b2a-9ae7-9c48b91f1426)<br/>RMS_S_ENTERPRISE (bea4c11e-220a-4e6d-8eb8-8ea15d019f90)<br/>LOCKBOX_ENTERPRISE (9f431833-0334-42de-a7dc-70aa40db46db)<br/>EducationAnalyticsP1 (a9b86446-fa4e-498f-a92a-41b447e03337)<br/>EXCHANGE_S_ENTERPRISE (efb87545-963c-4e0d-99df-69c6916d9eb0)<br/>FLOW_O365_P3 (07699545-9485-468e-95b6-2fca3738be01)<br/>INFORMATION_BARRIERS (c4801e8a-cb58-4c35-aca6-f2dcc106f287)<br/>MIP_S_CLP2 (efb0351d-3b08-4503-993d-383af8de41e3)<br/>MIP_S_CLP1 (5136a095-5cf0-4aff-bec3-e84448b38ea5)<br/>M365_ADVANCED_AUDITING (2f442157-a11c-46b9-ae5b-6e39ff4e5849)<br/>MCOMEETADV (3e26ee1f-8a5f-4d52-aee2-b81ce45c8f40)<br/>MCOEV (4828c8ec-dc2e-4779-b502-87ac9ce28ab7)<br/>MICROSOFTBOOKINGS (199a5c09-e0ca-4e37-8f7c-b05d533e1ea2)<br/>COMMUNICATIONS_COMPLIANCE (41fcdd7d-4733-4863-9cf4-c65b83ce2df4)<br/>COMMUNICATIONS_DLP (6dc145d6-95dd-4191-b9c3-185575ee6f6b)<br/>CUSTOMER_KEY (6db1f1db-2b46-403f-be40-e39395f08dbb)<br/>DATA_INVESTIGATIONS (46129a58-a698-46f0-aa5b-17f6586297d9)<br/>OFFICE_FORMS_PLAN_3 (96c1e14a-ef43-418d-b115-9636cdaa8eed)<br/>INFO_GOVERNANCE (e26c2fcc-ab91-4a61-b35c-03cdc8dddf66)<br/>KAIZALA_STANDALONE (0898bdbb-73b0-471a-81e5-20f1fe4dd66e)<br/>EXCHANGE_ANALYTICS (34c0d7a0-a70f-4668-9238-47f9fc208882)<br/>PROJECTWORKMANAGEMENT (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>RECORDS_MANAGEMENT (65cc641f-cccd-4643-97e0-a17e3045e541)<br/>MICROSOFT_SEARCH (94065c59-bc8e-4e8b-89e5-5138d471eaff)<br/>Deskless (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>STREAM_O365_E5 (6c6042f5-6f01-4d67-b8c1-eb99d36eed3e)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>INTUNE_O365 (882e1d05-acd1-4ccb-8708-6ee03664b117)<br/>EQUIVIO_ANALYTICS (4de31727-a228-4ec3-a5bf-8e45b5ca48cc)<br/>ADALLOM_S_O365 (8c098270-9dd4-4350-9b30-ba4703f3b36b)<br/>ATP_ENTERPRISE (f20fedf3-f3c3-43c3-8267-2bfdd51c0939)<br/>THREAT_INTELLIGENCE (8e0c0a52-6a6c-4d40-8370-dd62790dcd70)<br/>PAM_ENTERPRISE (b1188c4c-1b36-4018-b48b-ee07604f6feb)<br/>OFFICESUBSCRIPTION (43de0ff5-c92c-492b-9116-175376d08c38)<br/>SHAREPOINTWAC_EDU (e03c7e47-402c-463c-ab25-949079bedb21)<br/>BI_AZURE_P2 (70d33638-9c74-4d01-bfd3-562de28bd4ba)<br/>POWERAPPS_O365_P3 (9c0dab89-a30c-4117-86e7-97bda240acd2)<br/>PREMIUM_ENCRYPTION (617b097b-4b93-4ede-83de-5f075bb5fb2f)<br/>SCHOOL_DATA_SYNC_P2 (500b6a2a-7a50-4f40-b5f9-160e5b8c2f48)<br/>SHAREPOINTENTERPRISE_EDU (63038b2c-28d0-45f6-bc36-33062963b498)<br/>MCOSTANDARD (0feaeb32-d00e-4d66-bd5a-43b5b83db82c)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>BPOS_S_TODO_3 (3fb82609-8c27-4f7b-bd51-30634711ee67)<br/>WHITEBOARD_PLAN3 (4a51bca5-1eff-43f5-878c-177680f191af)<br/>YAMMER_EDU (2078e8df-cff6-4290-98cb-5408261a760a) | Azure Active Directory Basic for EDU (1d0f309f-fdf9-4b2a-9ae7-9c48b91f1426)<br/>Azure Rights Management (bea4c11e-220a-4e6d-8eb8-8ea15d019f90)<br/>Customer Lockbox (9f431833-0334-42de-a7dc-70aa40db46db)<br/>Education Analytics (a9b86446-fa4e-498f-a92a-41b447e03337)<br/>Exchange Online (Plan 2) (efb87545-963c-4e0d-99df-69c6916d9eb0)<br/>Flow for Office 365 (07699545-9485-468e-95b6-2fca3738be01)<br/>Information Barriers (c4801e8a-cb58-4c35-aca6-f2dcc106f287)<br/>Information Protection for Office 365 - Premium (efb0351d-3b08-4503-993d-383af8de41e3)<br/>Information Protection for Office 365 - Standard (5136a095-5cf0-4aff-bec3-e84448b38ea5)<br/>Microsoft 365 Advanced Auditing (2f442157-a11c-46b9-ae5b-6e39ff4e5849)<br/>Microsoft 365 Audio Conferencing (3e26ee1f-8a5f-4d52-aee2-b81ce45c8f40)<br/>Microsoft 365 Phone System (4828c8ec-dc2e-4779-b502-87ac9ce28ab7)<br/>Microsoft Bookings (199a5c09-e0ca-4e37-8f7c-b05d533e1ea2)<br/>Microsoft Communications Compliance (41fcdd7d-4733-4863-9cf4-c65b83ce2df4)<br/>Microsoft Communications DLP (6dc145d6-95dd-4191-b9c3-185575ee6f6b)<br/>Microsoft Customer Key (6db1f1db-2b46-403f-be40-e39395f08dbb)<br/>Microsoft Data Investigations (46129a58-a698-46f0-aa5b-17f6586297d9)<br/>Microsoft Forms (Plan 3) (96c1e14a-ef43-418d-b115-9636cdaa8eed)<br/>Microsoft Information Governance (e26c2fcc-ab91-4a61-b35c-03cdc8dddf66)<br/>Microsoft Kaizala (0898bdbb-73b0-471a-81e5-20f1fe4dd66e)<br/>Microsoft MyAnalytics (Full) (34c0d7a0-a70f-4668-9238-47f9fc208882)<br/>Microsoft Planner (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>Microsoft Records Management (65cc641f-cccd-4643-97e0-a17e3045e541)<br/>Microsoft Search (94065c59-bc8e-4e8b-89e5-5138d471eaff)<br/>Microsoft StaffHub (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>Microsoft Stream for O365 E5 SKU (6c6042f5-6f01-4d67-b8c1-eb99d36eed3e)<br/>Microsoft Teams (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>Mobile Device Management for Office 365 (882e1d05-acd1-4ccb-8708-6ee03664b117)<br/>Office 365 Advanced eDiscovery (4de31727-a228-4ec3-a5bf-8e45b5ca48cc)<br/>Office 365 Advanced Security Management (8c098270-9dd4-4350-9b30-ba4703f3b36b)<br/>Office 365 Advanced Threat Protection (Plan 1) (f20fedf3-f3c3-43c3-8267-2bfdd51c0939)<br/>Office 365 Advanced Threat Protection (Plan 2) (8e0c0a52-6a6c-4d40-8370-dd62790dcd70)<br/>Office 365 Privileged Access Management (b1188c4c-1b36-4018-b48b-ee07604f6feb)<br/>Office 365 ProPlus (43de0ff5-c92c-492b-9116-175376d08c38)<br/>Office for the web (Education) (e03c7e47-402c-463c-ab25-949079bedb21)<br/>Power BI Pro (70d33638-9c74-4d01-bfd3-562de28bd4ba)<br/>PowerApps for Office 365 Plan 3 (9c0dab89-a30c-4117-86e7-97bda240acd2)<br/>Premium Encryption in Office 365 (617b097b-4b93-4ede-83de-5f075bb5fb2f)<br/>School Data Sync (Plan 2) (500b6a2a-7a50-4f40-b5f9-160e5b8c2f48)<br/>SharePoint Plan 2 for EDU (63038b2c-28d0-45f6-bc36-33062963b498)<br/>Skype for Business Online (Plan 2) (0feaeb32-d00e-4d66-bd5a-43b5b83db82c)<br/>Sway (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>To-Do (Plan 3) (3fb82609-8c27-4f7b-bd51-30634711ee67)<br/>Whiteboard (Plan 3)(4a51bca5-1eff-43f5-878c-177680f191af)<br/>Yammer for Academic (2078e8df-cff6-4290-98cb-5408261a760a) | | Office 365 A5 for students | ENTERPRISEPREMIUM_STUDENT | ee656612-49fa-43e5-b67e-cb1fdf7699df | AAD_BASIC_EDU (1d0f309f-fdf9-4b2a-9ae7-9c48b91f1426)<br/>RMS_S_ENTERPRISE (bea4c11e-220a-4e6d-8eb8-8ea15d019f90)<br/>LOCKBOX_ENTERPRISE (9f431833-0334-42de-a7dc-70aa40db46db)<br/>EducationAnalyticsP1 (a9b86446-fa4e-498f-a92a-41b447e03337)<br/>EXCHANGE_S_ENTERPRISE (efb87545-963c-4e0d-99df-69c6916d9eb0)<br/>FLOW_O365_P3 (07699545-9485-468e-95b6-2fca3738be01)<br/>INFORMATION_BARRIERS (c4801e8a-cb58-4c35-aca6-f2dcc106f287)<br/>MIP_S_CLP2 (efb0351d-3b08-4503-993d-383af8de41e3)<br/>MIP_S_CLP1 (5136a095-5cf0-4aff-bec3-e84448b38ea5)<br/>M365_ADVANCED_AUDITING (2f442157-a11c-46b9-ae5b-6e39ff4e5849)<br/>MCOMEETADV (3e26ee1f-8a5f-4d52-aee2-b81ce45c8f40)<br/>MCOEV (4828c8ec-dc2e-4779-b502-87ac9ce28ab7)<br/>MICROSOFTBOOKINGS (199a5c09-e0ca-4e37-8f7c-b05d533e1ea2)<br/>COMMUNICATIONS_COMPLIANCE (41fcdd7d-4733-4863-9cf4-c65b83ce2df4)<br/>COMMUNICATIONS_DLP (6dc145d6-95dd-4191-b9c3-185575ee6f6b)<br/>CUSTOMER_KEY (6db1f1db-2b46-403f-be40-e39395f08dbb)<br/>DATA_INVESTIGATIONS (46129a58-a698-46f0-aa5b-17f6586297d9)<br/>OFFICE_FORMS_PLAN_3 (96c1e14a-ef43-418d-b115-9636cdaa8eed)<br/>INFO_GOVERNANCE (e26c2fcc-ab91-4a61-b35c-03cdc8dddf66)<br/>KAIZALA_STANDALONE (0898bdbb-73b0-471a-81e5-20f1fe4dd66e)<br/>EXCHANGE_ANALYTICS (34c0d7a0-a70f-4668-9238-47f9fc208882)<br/>PROJECTWORKMANAGEMENT (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>RECORDS_MANAGEMENT (65cc641f-cccd-4643-97e0-a17e3045e541)<br/>MICROSOFT_SEARCH (94065c59-bc8e-4e8b-89e5-5138d471eaff)<br/>Deskless (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>STREAM_O365_E5 (6c6042f5-6f01-4d67-b8c1-eb99d36eed3e)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>INTUNE_O365 (882e1d05-acd1-4ccb-8708-6ee03664b117)<br/>EQUIVIO_ANALYTICS (4de31727-a228-4ec3-a5bf-8e45b5ca48cc)<br/>ADALLOM_S_O365 (8c098270-9dd4-4350-9b30-ba4703f3b36b)<br/>ATP_ENTERPRISE (f20fedf3-f3c3-43c3-8267-2bfdd51c0939)<br/>THREAT_INTELLIGENCE (8e0c0a52-6a6c-4d40-8370-dd62790dcd70)<br/>PAM_ENTERPRISE (b1188c4c-1b36-4018-b48b-ee07604f6feb)<br/>OFFICESUBSCRIPTION (43de0ff5-c92c-492b-9116-175376d08c38)<br/>SHAREPOINTWAC_EDU (e03c7e47-402c-463c-ab25-949079bedb21)<br/>BI_AZURE_P2 (70d33638-9c74-4d01-bfd3-562de28bd4ba)<br/>POWERAPPS_O365_P3 (9c0dab89-a30c-4117-86e7-97bda240acd2)<br/>PREMIUM_ENCRYPTION (617b097b-4b93-4ede-83de-5f075bb5fb2f)<br/>SCHOOL_DATA_SYNC_P2 (500b6a2a-7a50-4f40-b5f9-160e5b8c2f48)<br/>SHAREPOINTENTERPRISE_EDU (63038b2c-28d0-45f6-bc36-33062963b498)<br/>MCOSTANDARD (0feaeb32-d00e-4d66-bd5a-43b5b83db82c)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>BPOS_S_TODO_3 (3fb82609-8c27-4f7b-bd51-30634711ee67)<br/>WHITEBOARD_PLAN3 (4a51bca5-1eff-43f5-878c-177680f191af)<br/>YAMMER_EDU (2078e8df-cff6-4290-98cb-5408261a760a) | Azure Active Directory Basic for EDU (1d0f309f-fdf9-4b2a-9ae7-9c48b91f1426)<br/>Azure Rights Management (bea4c11e-220a-4e6d-8eb8-8ea15d019f90)<br/>Customer Lockbox (9f431833-0334-42de-a7dc-70aa40db46db)<br/>Education Analytics (a9b86446-fa4e-498f-a92a-41b447e03337)<br/>Exchange Online (Plan 2) (efb87545-963c-4e0d-99df-69c6916d9eb0)<br/>Flow for Office 365 (07699545-9485-468e-95b6-2fca3738be01)<br/>Information Barriers (c4801e8a-cb58-4c35-aca6-f2dcc106f287)<br/>Information Protection for Office 365 - Premium (efb0351d-3b08-4503-993d-383af8de41e3)<br/>Information Protection for Office 365 - Standard (5136a095-5cf0-4aff-bec3-e84448b38ea5)<br/>Microsoft 365 Advanced Auditing (2f442157-a11c-46b9-ae5b-6e39ff4e5849)<br/>Microsoft 365 Audio Conferencing (3e26ee1f-8a5f-4d52-aee2-b81ce45c8f40)<br/>Microsoft 365 Phone System (4828c8ec-dc2e-4779-b502-87ac9ce28ab7)<br/>Microsoft Bookings (199a5c09-e0ca-4e37-8f7c-b05d533e1ea2)<br/>Microsoft Communications Compliance (41fcdd7d-4733-4863-9cf4-c65b83ce2df4)<br/>Microsoft Communications DLP (6dc145d6-95dd-4191-b9c3-185575ee6f6b)<br/>Microsoft Customer Key (6db1f1db-2b46-403f-be40-e39395f08dbb)<br/>Microsoft Data Investigations (46129a58-a698-46f0-aa5b-17f6586297d9)<br/>Microsoft Forms (Plan 3) (96c1e14a-ef43-418d-b115-9636cdaa8eed)<br/>Microsoft Information Governance (e26c2fcc-ab91-4a61-b35c-03cdc8dddf66)<br/>Microsoft Kaizala (0898bdbb-73b0-471a-81e5-20f1fe4dd66e)<br/>Microsoft MyAnalytics (Full) (34c0d7a0-a70f-4668-9238-47f9fc208882)<br/>Microsoft Planner (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>Microsoft Records Management (65cc641f-cccd-4643-97e0-a17e3045e541)<br/>Microsoft Search (94065c59-bc8e-4e8b-89e5-5138d471eaff)<br/>Microsoft StaffHub (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>Microsoft Stream for O365 E5 SKU (6c6042f5-6f01-4d67-b8c1-eb99d36eed3e)<br/>Microsoft Teams (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>Mobile Device Management for Office 365 (882e1d05-acd1-4ccb-8708-6ee03664b117)<br/>Office 365 Advanced eDiscovery (4de31727-a228-4ec3-a5bf-8e45b5ca48cc)<br/>Office 365 Advanced Security Management (8c098270-9dd4-4350-9b30-ba4703f3b36b)<br/>Office 365 Advanced Threat Protection (Plan 1) (f20fedf3-f3c3-43c3-8267-2bfdd51c0939)<br/>Office 365 Advanced Threat Protection (Plan 2) (8e0c0a52-6a6c-4d40-8370-dd62790dcd70)<br/>Office 365 Privileged Access Management (b1188c4c-1b36-4018-b48b-ee07604f6feb)<br/>Office 365 ProPlus (43de0ff5-c92c-492b-9116-175376d08c38)<br/>Office for the web (Education) (e03c7e47-402c-463c-ab25-949079bedb21)<br/>Power BI Pro (70d33638-9c74-4d01-bfd3-562de28bd4ba)<br/>PowerApps for Office 365 Plan 3 (9c0dab89-a30c-4117-86e7-97bda240acd2)<br/>Premium Encryption in Office 365 (617b097b-4b93-4ede-83de-5f075bb5fb2f)<br/>School Data Sync (Plan 2) (500b6a2a-7a50-4f40-b5f9-160e5b8c2f48)<br/>SharePoint Plan 2 for EDU (63038b2c-28d0-45f6-bc36-33062963b498)<br/>Skype for Business Online (Plan 2) (0feaeb32-d00e-4d66-bd5a-43b5b83db82c)<br/>Sway (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>To-Do (Plan 3) (3fb82609-8c27-4f7b-bd51-30634711ee67)<br/>Whiteboard (Plan 3)(4a51bca5-1eff-43f5-878c-177680f191af)<br/>Yammer for Academic (2078e8df-cff6-4290-98cb-5408261a760a) | | Office 365 Advanced Compliance | EQUIVIO_ANALYTICS | 1b1b1f7a-8355-43b6-829f-336cfccb744c | LOCKBOX_ENTERPRISE (9f431833-0334-42de-a7dc-70aa40db46db)<br/>INFORMATION_BARRIERS (c4801e8a-cb58-4c35-aca6-f2dcc106f287)<br/>MIP_S_CLP2 (efb0351d-3b08-4503-993d-383af8de41e3)<br/>EQUIVIO_ANALYTICS (4de31727-a228-4ec3-a5bf-8e45b5ca48cc)<br/>PAM_ENTERPRISE (b1188c4c-1b36-4018-b48b-ee07604f6feb)<br/>PREMIUM_ENCRYPTION (617b097b-4b93-4ede-83de-5f075bb5fb2f) | Customer Lockbox (9f431833-0334-42de-a7dc-70aa40db46db)<br/>Information Barriers (c4801e8a-cb58-4c35-aca6-f2dcc106f287)<br/>Information Protection for Office 365 - Premium (efb0351d-3b08-4503-993d-383af8de41e3)<br/>Office 365 Advanced eDiscovery (4de31727-a228-4ec3-a5bf-8e45b5ca48cc)<br/>Office 365 Privileged Access Management (b1188c4c-1b36-4018-b48b-ee07604f6feb)<br/>Premium Encryption in Office 365 (617b097b-4b93-4ede-83de-5f075bb5fb2f) |
When managing licenses in [the Azure portal](https://portal.azure.com/#blade/Mic
| OFFICE 365 E5 | ENTERPRISEPREMIUM | c7df2760-2c81-4ef7-b578-5b5392b571df | ADALLOM_S_O365 (8c098270-9dd4-4350-9b30-ba4703f3b36b)<br/>BI_AZURE_P2 (70d33638-9c74-4d01-bfd3-562de28bd4ba)<br/>BPOS_S_TODO_3 (3fb82609-8c27-4f7b-bd51-30634711ee67)<br/>Deskless (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>EQUIVIO_ANALYTICS (4de31727-a228-4ec3-a5bf-8e45b5ca48cc)<br/>EXCHANGE_ANALYTICS (34c0d7a0-a70f-4668-9238-47f9fc208882)<br/>EXCHANGE_S_ENTERPRISE (efb87545-963c-4e0d-99df-69c6916d9eb0)<br/>FLOW_O365_P3 (07699545-9485-468e-95b6-2fca3738be01)<br/>FORMS_PLAN_E5 (e212cbc7-0961-4c40-9825-01117710dcb1)<br/>LOCKBOX_ENTERPRISE (9f431833-0334-42de-a7dc-70aa40db46db)<br/>MCOEV (4828c8ec-dc2e-4779-b502-87ac9ce28ab7)<br/>MCOMEETADV (3e26ee1f-8a5f-4d52-aee2-b81ce45c8f40)<br/>MCOSTANDARD (0feaeb32-d00e-4d66-bd5a-43b5b83db82c)<br/>MICROSOFTBOOKINGS (199a5c09-e0ca-4e37-8f7c-b05d533e1ea2)<br/>OFFICESUBSCRIPTION (43de0ff5-c92c-492b-9116-175376d08c38)<br/>POWERAPPS_O365_P3 (9c0dab89-a30c-4117-86e7-97bda240acd2)<br/>PROJECTWORKMANAGEMENT (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>RMS_S_ENTERPRISE (bea4c11e-220a-4e6d-8eb8-8ea15d019f90)<br/>SHAREPOINTENTERPRISE (5dbe027f-2339-4123-9542-606e4d348a72)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>STREAM_O365_E5 (6c6042f5-6f01-4d67-b8c1-eb99d36eed3e)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>THREAT_INTELLIGENCE (8e0c0a52-6a6c-4d40-8370-dd62790dcd70)<br/>YAMMER_ENTERPRISE (7547a3fe-08ee-4ccb-b430-5077c5041653) | OFFICE 365 CLOUD APP SECURITY (8c098270-9dd4-4350-9b30-ba4703f3b36b)<br/>POWER BI PRO (70d33638-9c74-4d01-bfd3-562de28bd4ba)<br/>BPOS_S_TODO_3 (3fb82609-8c27-4f7b-bd51-30634711ee67)<br/>MICROSOFT STAFFHUB (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>OFFICE 365 ADVANCED EDISCOVERY (4de31727-a228-4ec3-a5bf-8e45b5ca48cc)<br/>EXCHANGE_ANALYTICS (34c0d7a0-a70f-4668-9238-47f9fc208882)<br/>EXCHANGE ONLINE (PLAN 2)(efb87545-963c-4e0d-99df-69c6916d9eb0)<br/>FLOW FOR OFFICE 365 (07699545-9485-468e-95b6-2fca3738be01)<br/>MICROSOFT FORMS (PLAN E5)(e212cbc7-0961-4c40-9825-01117710dcb1)<br/>LOCKBOX_ENTERPRISE (9f431833-0334-42de-a7dc-70aa40db46db)<br/>PHONE SYSTEM (4828c8ec-dc2e-4779-b502-87ac9ce28ab7)<br/>AUDIO CONFERENCING (3e26ee1f-8a5f-4d52-aee2-b81ce45c8f40)<br/>SKYPE FOR BUSINESS ONLINE (PLAN 2) (0feaeb32-d00e-4d66-bd5a-43b5b83db82c)<br/>MICROSOFTBOOKINGS (199a5c09-e0ca-4e37-8f7c-b05d533e1ea2)<br/>OFFICESUBSCRIPTION (43de0ff5-c92c-492b-9116-175376d08c38)<br/>POWERAPPS FOR OFFICE 365 (9c0dab89-a30c-4117-86e7-97bda240acd2)<br/>MICROSOFT PLANNER(b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>MICROSOFT AZURE ACTIVE DIRECTORY RIGHTS (bea4c11e-220a-4e6d-8eb8-8ea15d019f90)<br/>SHAREPOINT ONLINE (PLAN 2) (5dbe027f-2339-4123-9542-606e4d348a72)<br/>OFFICE ONLINE (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>MICROSOFT STREAM FOR O365 E5 SKU (6c6042f5-6f01-4d67-b8c1-eb99d36eed3e)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>OFFICE 365 ADVANCED THREAT PROTECTION (PLAN 2) (8e0c0a52-6a6c-4d40-8370-dd62790dcd70)<br/>YAMMER_ENTERPRISE (7547a3fe-08ee-4ccb-b430-5077c5041653) | | OFFICE 365 E5 WITHOUT AUDIO CONFERENCING | ENTERPRISEPREMIUM_NOPSTNCONF | 26d45bd9-adf1-46cd-a9e1-51e9a5524128 | ADALLOM_S_O365 (8c098270-9dd4-4350-9b30-ba4703f3b36b)<br/>BI_AZURE_P2 (70d33638-9c74-4d01-bfd3-562de28bd4ba)<br/>BPOS_S_TODO_3 (3fb82609-8c27-4f7b-bd51-30634711ee67)<br/>Deskless (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>EQUIVIO_ANALYTICS (4de31727-a228-4ec3-a5bf-8e45b5ca48cc)<br/>EXCHANGE_ANALYTICS (34c0d7a0-a70f-4668-9238-47f9fc208882)<br/>EXCHANGE_S_ENTERPRISE (efb87545-963c-4e0d-99df-69c6916d9eb0)<br/>FLOW_O365_P3 (07699545-9485-468e-95b6-2fca3738be01)<br/>FORMS_PLAN_E5 (e212cbc7-0961-4c40-9825-01117710dcb1)<br/>LOCKBOX_ENTERPRISE (9f431833-0334-42de-a7dc-70aa40db46db)<br/>MCOEV (4828c8ec-dc2e-4779-b502-87ac9ce28ab7)<br/>MCOSTANDARD (0feaeb32-d00e-4d66-bd5a-43b5b83db82c)<br/>OFFICESUBSCRIPTION (43de0ff5-c92c-492b-9116-175376d08c38)<br/>POWERAPPS_O365_P3 (9c0dab89-a30c-4117-86e7-97bda240acd2)<br/>PROJECTWORKMANAGEMENT (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>RMS_S_ENTERPRISE (bea4c11e-220a-4e6d-8eb8-8ea15d019f90)<br/>SHAREPOINTENTERPRISE (5dbe027f-2339-4123-9542-606e4d348a72)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>STREAM_O365_E5 (6c6042f5-6f01-4d67-b8c1-eb99d36eed3e)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>THREAT_INTELLIGENCE (8e0c0a52-6a6c-4d40-8370-dd62790dcd70)<br/>YAMMER_ENTERPRISE (7547a3fe-08ee-4ccb-b430-5077c5041653) | OFFICE 365 CLOUD APP SECURITY (8c098270-9dd4-4350-9b30-ba4703f3b36b)<br/>POWER BI PRO (70d33638-9c74-4d01-bfd3-562de28bd4ba)<br/>BPOS_S_TODO_3 (3fb82609-8c27-4f7b-bd51-30634711ee67)<br/>MICROSOFT STAFFHUB (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>OFFICE 365 ADVANCED EDISCOVERY (4de31727-a228-4ec3-a5bf-8e45b5ca48cc)<br/>EXCHANGE_ANALYTICS (34c0d7a0-a70f-4668-9238-47f9fc208882)<br/>EXCHANGE ONLINE (PLAN 2)(efb87545-963c-4e0d-99df-69c6916d9eb0)<br/>FLOW FOR OFFICE 365 (07699545-9485-468e-95b6-2fca3738be01)<br/>MICROSOFT FORMS (PLAN E5)(e212cbc7-0961-4c40-9825-01117710dcb1)<br/>LOCKBOX_ENTERPRISE (9f431833-0334-42de-a7dc-70aa40db46db)<br/>PHONE SYSTEM (4828c8ec-dc2e-4779-b502-87ac9ce28ab7)<br/>SKYPE FOR BUSINESS ONLINE (PLAN 2) (0feaeb32-d00e-4d66-bd5a-43b5b83db82c)<br/>OFFICESUBSCRIPTION (43de0ff5-c92c-492b-9116-175376d08c38)<br/>POWERAPPS FOR OFFICE 365 (9c0dab89-a30c-4117-86e7-97bda240acd2)<br/>MICROSOFT PLANNER(b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>MICROSOFT AZURE ACTIVE DIRECTORY RIGHTS (bea4c11e-220a-4e6d-8eb8-8ea15d019f90)<br/>SHAREPOINT ONLINE (PLAN 2) (5dbe027f-2339-4123-9542-606e4d348a72)<br/>OFFICE ONLINE (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>MICROSOFT STREAM FOR O365 E5 SKU (6c6042f5-6f01-4d67-b8c1-eb99d36eed3e)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>OFFICE 365 ADVANCED THREAT PROTECTION (PLAN 2) (8e0c0a52-6a6c-4d40-8370-dd62790dcd70)<br/>YAMMER_ENTERPRISE (7547a3fe-08ee-4ccb-b430-5077c5041653) | | OFFICE 365 F3 | DESKLESSPACK | 4b585984-651b-448a-9e53-3b10f069cf7f | BPOS_S_TODO_FIRSTLINE (80873e7a-cd2a-4e67-b061-1b5381a676a5)<br/>CDS_O365_F1 (90db65a7-bf11-4904-a79f-ef657605145b)<br/>DESKLESS (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>DYN365_CDS_O365_F1 (ca6e61ec-d4f4-41eb-8b88-d96e0e14323f)<br/>EXCHANGE_S_DESKLESS (4a82b400-a79f-41a4-b4e2-e94f5787b113)<br/>FLOW_O365_S1 (bd91b1a4-9f94-4ecf-b45b-3a65e5c8128a)<br/>FORMS_PLAN_K (f07046bd-2a3c-4b96-b0be-dea79d7cbfb8)<br/>INTUNE_365 (882e1d05-acd1-4ccb-8708-6ee03664b117)<br/>KAIZALA_O365_P1 (73b2a583-6a59-42e3-8e83-54db46bc3278)<br/>MCOIMP (afc06cb0-b4f4-4473-8286-d644f70d8faf)<br/>MICROSOFT_SEARCH (94065c59-bc8e-4e8b-89e5-5138d471eaff)<br/>OFFICEMOBILE_SUBSCRIPTION (c63d4d19-e8cb-460e-b37c-4d6c34603745)<br/>POWERAPPS_O365_S1 (e0287f9f-e222-4f98-9a83-f379e249159a)<br/>POWER_VIRTUAL_AGENTS_O365_F1 (ba2fdb48-290b-4632-b46a-e4ecc58ac11a)<br/>PROJECT_O365_F3 (7f6f28c2-34bb-4d4b-be36-48ca2e77e1ec)<br/>PROJECTWORKMANAGEMENT (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>RMS_S_BASIC (31cf2cfc-6b0d-4adc-a336-88b724ed8122)<br/>SHAREPOINTDESKLESS (902b47e5-dcb2-4fdc-858b-c63a90a2bdb9)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>STREAM_O365_K (3ffba0d2-38e5-4d5e-8ec0-98f2b05c09d9)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>TEAMS1 (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>WHITEBOARD_FIRSTLINE_1 (36b29273-c6d0-477a-aca6-6fbe24f538e3)<br/>YAMMER_ENTERPRISE (7547a3fe-08ee-4ccb-b430-5077c5041653) | BPOS_S_TODO_FIRSTLINE (80873e7a-cd2a-4e67-b061-1b5381a676a5)<br/>COMMON DATA SERVICE - O365 F1 (ca6e61ec-d4f4-41eb-8b88-d96e0e14323f)<br/>COMMON DATA SERVICE FOR TEAMS_F1 (90db65a7-bf11-4904-a79f-ef657605145b)<br/>EXCHANGE ONLINE KIOSK (4a82b400-a79f-41a4-b4e2-e94f5787b113)<br/>FLOW FOR OFFICE 365 K1 (bd91b1a4-9f94-4ecf-b45b-3a65e5c8128a)<br/>MICROSOFT AZURE RIGHTS MANAGEMENT SERVICE (31cf2cfc-6b0d-4adc-a336-88b724ed8122)<br/>MICROSOFT FORMS (PLAN F1) (f07046bd-2a3c-4b96-b0be-dea79d7cbfb8)<br/>MICROSOFT KAIZALA PRO PLAN 1 (73b2a583-6a59-42e3-8e83-54db46bc3278)<br/>MICROSOFT PLANNER (b737dad2-2f6c-4c65-90e3-ca563267e8b9)<br/>MICROSOFT SEARCH (94065c59-bc8e-4e8b-89e5-5138d471eaff)<br/>MICROSOFT STAFFHUB (8c7d2df8-86f0-4902-b2ed-a0458298f3b3)<br/>MICROSOFT STREAM FOR O365 K SKU (3ffba0d2-38e5-4d5e-8ec0-98f2b05c09d9)<br/>MICROSOFT TEAMS (57ff2da0-773e-42df-b2af-ffb7a2317929)<br/>MOBILE DEVICE MANAGEMENT FOR OFFICE 365 (882e1d05-acd1-4ccb-8708-6ee03664b117)<br/>OFFICE FOR THE WEB (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>OFFICE MOBILE APPS FOR OFFICE 365 (c63d4d19-e8cb-460e-b37c-4d6c34603745)<br/>POWER VIRTUAL AGENTS FOR OFFICE 365 F1 (ba2fdb48-290b-4632-b46a-e4ecc58ac11a)<br/>POWERAPPS FOR OFFICE 365 K1 (e0287f9f-e222-4f98-9a83-f379e249159a)<br/>PROJECT FOR OFFICE (PLAN F) (7f6f28c2-34bb-4d4b-be36-48ca2e77e1ec)<br/>SHAREPOINT KIOSK (902b47e5-dcb2-4fdc-858b-c63a90a2bdb9)<br/>SKYPE FOR BUSINESS ONLINE (PLAN 1) (afc06cb0-b4f4-4473-8286-d644f70d8faf)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>TO-DO (FIRSTLINE) (80873e7a-cd2a-4e67-b061-1b5381a676a5)<br/>YAMMER ENTERPRISE (7547a3fe-08ee-4ccb-b430-5077c5041653) |
+| OFFICE 365 GCC G3 | ENTERPRISEPACK_GOV | 535a3a29-c5f0-42fe-8215-d3b9e1f38c4a | RMS_S_ENTERPRISE_GOV (6a76346d-5d6e-4051-9fe3-ed3f312b5597)<br/>CONTENT_EXPLORER (d9fa6af4-e046-4c89-9226-729a0786685d)<br/>EXCHANGE_S_ENTERPRISE_GOV (8c3069c0-ccdb-44be-ab77-986203a67df2)<br/>FORMS_GOV_E3 (24af5f65-d0f3-467b-9f78-ea798c4aeffc)<br/>MIP_S_CLP1 (5136a095-5cf0-4aff-bec3-e84448b38ea5)<br/>MYANALYTICS_P2_GOV (6e5b7995-bd4f-4cbd-9d19-0e32010c72f0)<br/>OFFICESUBSCRIPTION_GOV (de9234ff-6483-44d9-b15e-dca72fdd27af)<br/>MICROSOFTBOOKINGS (199a5c09-e0ca-4e37-8f7c-b05d533e1ea2)<br/>STREAM_O365_E3_GOV (2c1ada27-dbaa-46f9-bda6-ecb94445f758)<br/>TEAMS_GOV (304767db-7d23-49e8-a945-4a7eb65f9f28)<br/>INTUNE_O365 (882e1d05-acd1-4ccb-8708-6ee03664b117)<br/>PROJECTWORKMANAGEMENT_GOV (5b4ef465-7ea1-459a-9f91-033317755a51)<br/>SHAREPOINTWAC_GOV (8f9f0f3b-ca90-406c-a842-95579171f8ec)<br/> POWERAPPS_O365_P2_GOV (0a20c815-5e81-4727-9bdc-2b5a117850c3)<br/>FLOW_O365_P2_GOV (c537f360-6a00-4ace-a7f5-9128d0ac1e4b)<br/>SHAREPOINTENTERPRISE_GOV (153f85dd-d912-4762-af6c-d6e0fb4f6692)<br/>MCOSTANDARD_GOV (a31ef4a2-f787-435e-8335-e47eb0cafc94) | AZURE RIGHTS MANAGEMENT (6a76346d-5d6e-4051-9fe3-ed3f312b5597)<br/>CONTENT EXPLORER (d9fa6af4-e046-4c89-9226-729a0786685d)<br/>EXCHANGE PLAN 2G (8c3069c0-ccdb-44be-ab77-986203a67df2)<br/>FORMS FOR GOVERNMENT (PLAN E3) (24af5f65-d0f3-467b-9f78-ea798c4aeffc)<br/>INFORMATION PROTECTION FOR OFFICE 365 ΓÇô STANDARD (5136a095-5cf0-4aff-bec3-e84448b38ea5)<br/>INSIGHTS BY MYANALYTICS FOR GOVERNMENT (6e5b7995-bd4f-4cbd-9d19-0e32010c72f0)<br/>MICROSOFT 365 APPS FOR ENTERPRISE G (de9234ff-6483-44d9-b15e-dca72fdd27af)<br/>MICROSOFT BOOKINGS (199a5c09-e0ca-4e37-8f7c-b05d533e1ea2)<br/>MICROSOFT STREAM FOR O365 FOR GOVERNMENT (E3) (2c1ada27-dbaa-46f9-bda6-ecb94445f758)<br/>MICROSOFT TEAMS FOR GOVERNMENT (304767db-7d23-49e8-a945-4a7eb65f9f28)<br/>MOBILE DEVICE MANAGEMENT FOR OFFICE 365 (882e1d05-acd1-4ccb-8708-6ee03664b117)<br/>OFFICE 365 PLANNER FOR GOVERNMENT (5b4ef465-7ea1-459a-9f91-033317755a51)<br/>OFFICE FOR THE WEB (GOVERNMENT) (8f9f0f3b-ca90-406c-a842-95579171f8ec)<br/>POWER APPS FOR OFFICE 365 FOR GOVERNMENT (0a20c815-5e81-4727-9bdc-2b5a117850c3)<br/>POWER AUTOMATE FOR OFFICE 365 FOR GOVERNMENT (c537f360-6a00-4ace-a7f5-9128d0ac1e4b)<br/>SHAREPOINT PLAN 2G (153f85dd-d912-4762-af6c-d6e0fb4f6692)<br/>SKYPE FOR BUSINESS ONLINE (PLAN 2) FOR GOVERNMENT (a31ef4a2-f787-435e-8335-e47eb0cafc94) |
| OFFICE 365 MIDSIZE BUSINESS | MIDSIZEPACK | 04a7fb0d-32e0-4241-b4f5-3f7618cd1162 | EXCHANGE_S_STANDARD_MIDMARKET (fc52cc4b-ed7d-472d-bbe7-b081c23ecc56)<br/>MCOSTANDARD_MIDMARKET (b2669e95-76ef-4e7e-a367-002f60a39f3e)<br/>OFFICESUBSCRIPTION (43de0ff5-c92c-492b-9116-175376d08c38)<br/>SHAREPOINTENTERPRISE_MIDMARKET (6b5b6a67-fc72-4a1f-a2b5-beecf05de761)<br/>SHAREPOINTWAC (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>YAMMER_MIDSIZE (41bf139a-4e60-409f-9346-a1361efc6dfb) | EXCHANGE ONLINE PLAN 1(fc52cc4b-ed7d-472d-bbe7-b081c23ecc56)<br/>SKYPE FOR BUSINESS ONLINE (PLAN 2) FOR MIDSIZE(b2669e95-76ef-4e7e-a367-002f60a39f3e)<br/>OFFICESUBSCRIPTION (43de0ff5-c92c-492b-9116-175376d08c38)<br/>SHAREPOINTENTERPRISE_MIDMARKET (6b5b6a67-fc72-4a1f-a2b5-beecf05de761)<br/>OFFICE ONLINE (e95bec33-7c88-4a70-8e19-b10bd9d0c014)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97)<br/>YAMMER_MIDSIZE (41bf139a-4e60-409f-9346-a1361efc6dfb) | | OFFICE 365 SMALL BUSINESS | LITEPACK | bd09678e-b83c-4d3f-aaba-3dad4abd128b | EXCHANGE_L_STANDARD (d42bdbd6-c335-4231-ab3d-c8f348d5aff5)<br/>MCOLITE (70710b6b-3ab4-4a38-9f6d-9f169461650a)<br/>SHAREPOINTLITE (a1f3d0a8-84c0-4ae0-bae4-685917b8ab48)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97) | EXCHANGE ONLINE (P1)(d42bdbd6-c335-4231-ab3d-c8f348d5aff5)<br/>SKYPE FOR BUSINESS ONLINE (PLAN P1) (70710b6b-3ab4-4a38-9f6d-9f169461650a)<br/>SHAREPOINTLITE (a1f3d0a8-84c0-4ae0-bae4-685917b8ab48)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97) | | OFFICE 365 SMALL BUSINESS PREMIUM | LITEPACK_P2 | fc14ec4a-4169-49a4-a51e-2c852931814b | EXCHANGE_L_STANDARD (d42bdbd6-c335-4231-ab3d-c8f348d5aff5)<br/>MCOLITE (70710b6b-3ab4-4a38-9f6d-9f169461650a)<br/>OFFICE_PRO_PLUS_SUBSCRIPTION_SMBIZ (8ca59559-e2ca-470b-b7dd-afd8c0dee963)<br/>SHAREPOINTLITE (a1f3d0a8-84c0-4ae0-bae4-685917b8ab48)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97) | EXCHANGE ONLINE (P1)(d42bdbd6-c335-4231-ab3d-c8f348d5aff5)<br/>SKYPE FOR BUSINESS ONLINE (PLAN P1) (70710b6b-3ab4-4a38-9f6d-9f169461650a)<br/>OFFICE_PRO_PLUS_SUBSCRIPTION_SMBIZ (8ca59559-e2ca-470b-b7dd-afd8c0dee963)<br/>SHAREPOINTLITE (a1f3d0a8-84c0-4ae0-bae4-685917b8ab48)<br/>SWAY (a23b959c-7ce8-4e57-9140-b90eb88a9e97) |
When managing licenses in [the Azure portal](https://portal.azure.com/#blade/Mic
| SKYPE FOR BUSINESS PSTN DOMESTIC AND INTERNATIONAL CALLING | MCOPSTN2 | d3b4fe1f-9992-4930-8acb-ca6ec609365e | MCOPSTN2 (5a10155d-f5c1-411a-a8ec-e99aae125390) | DOMESTIC AND INTERNATIONAL CALLING PLAN (5a10155d-f5c1-411a-a8ec-e99aae125390) | | SKYPE FOR BUSINESS PSTN DOMESTIC CALLING | MCOPSTN1 | 0dab259f-bf13-4952-b7f8-7db8f131b28d | MCOPSTN1 (4ed3ff63-69d7-4fb7-b984-5aec7f605ca8) | DOMESTIC CALLING PLAN (4ed3ff63-69d7-4fb7-b984-5aec7f605ca8) | | SKYPE FOR BUSINESS PSTN DOMESTIC CALLING (120 Minutes)| MCOPSTN5 | 54a152dc-90de-4996-93d2-bc47e670fc06 | MCOPSTN5 (54a152dc-90de-4996-93d2-bc47e670fc06) | DOMESTIC CALLING PLAN (54a152dc-90de-4996-93d2-bc47e670fc06) |
+| TOPIC EXPERIENCES | TOPIC_EXPERIENCES | 4016f256-b063-4864-816e-d818aad600c9 | GRAPH_CONNECTORS_SEARCH_INDEX_TOPICEXP (b74d57b2-58e9-484a-9731-aeccbba954f0)<br/>CORTEX (c815c93d-0759-4bb8-b857-bc921a71be83) | GRAPH CONNECTORS SEARCH WITH INDEX (b74d57b2-58e9-484a-9731-aeccbba954f0)<br/>TOPIC EXPERIENCES (c815c93d-0759-4bb8-b857-bc921a71be83)|
| TELSTRA CALLING FOR O365 | MCOPSTNEAU2 | de3312e1-c7b0-46e6-a7c3-a515ff90bc86 | MCOPSTNEAU (7861360b-dc3b-4eba-a3fc-0d323a035746) | AUSTRALIA CALLING PLAN (7861360b-dc3b-4eba-a3fc-0d323a035746) | | VISIO ONLINE PLAN 1 | VISIOONLINE_PLAN1 | 4b244418-9658-4451-a2b8-b5e2b364e9bd | ONEDRIVE_BASIC (da792a53-cbc0-4184-a10d-e544dd34b3c1)<br/>VISIOONLINE (2bdbaf8f-738f-4ac7-9234-3c3ee2ce7d0f) | ONEDRIVE_BASIC (da792a53-cbc0-4184-a10d-e544dd34b3c1)<br/>VISIOONLINE (2bdbaf8f-738f-4ac7-9234-3c3ee2ce7d0f) | | VISIO Online Plan 2 | VISIOCLIENT | c5928f49-12ba-48f7-ada3-0d743a3601d5 | ONEDRIVE_BASIC (da792a53-cbc0-4184-a10d-e544dd34b3c1)<br/>VISIO_CLIENT_SUBSCRIPTION (663a804f-1c30-4ff0-9915-9db84f0d1cea)<br/>VISIOONLINE (2bdbaf8f-738f-4ac7-9234-3c3ee2ce7d0f) | ONEDRIVE_BASIC (da792a53-cbc0-4184-a10d-e544dd34b3c1)<br/>VISIO_CLIENT_SUBSCRIPTION (663a804f-1c30-4ff0-9915-9db84f0d1cea)<br/>VISIOONLINE (2bdbaf8f-738f-4ac7-9234-3c3ee2ce7d0f) |
+| VISIO PLAN 2 FOR GOV | VISIOCLIENT_GOV | 4ae99959-6b0f-43b0-b1ce-68146001bdba | EXCHANGE_S_FOUNDATION_GOV (922ba911-5694-4e99-a794-73aed9bfeec8)<br/>ONEDRIVE_BASIC_GOV (98709c2e-96b5-4244-95f5-a0ebe139fb8a)<br/>VISIO_CLIENT_SUBSCRIPTION_GOV (f85945f4-7a55-4009-bc39-6a5f14a8eac1)<br/>VISIOONLINE_GOV (8a9ecb07-cfc0-48ab-866c-f83c4d911576) | EXCHANGE FOUNDATION FOR GOVERNMENT (922ba911-5694-4e99-a794-73aed9bfeec8)<br/>ONEDRIVE FOR BUSINESS BASIC FOR GOVERNMENT (98709c2e-96b5-4244-95f5-a0ebe139fb8a)<br/>VISIO DESKTOP APP FOR GOVERNMENT (4ae99959-6b0f-43b0-b1ce-68146001bdba)<br/>VISIO WEB APP FOR GOVERNMENT (8a9ecb07-cfc0-48ab-866c-f83c4d911576) |
| WINDOWS 10 ENTERPRISE E3 | WIN10_PRO_ENT_SUB | cb10e6cd-9da4-4992-867b-67546b1db821 | WIN10_PRO_ENT_SUB (21b439ba-a0ca-424f-a6cc-52f954a5b111) | WINDOWS 10 ENTERPRISE (21b439ba-a0ca-424f-a6cc-52f954a5b111) |
+| WINDOWS 10 ENTERPRISE E3 | WIN10_VDA_E3 | 6a0f6da5-0b87-4190-a6ae-9bb5a2b9546a | EXCHANGE_S_FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318)<br/>VIRTUALIZATION RIGHTS FOR WINDOWS 10 (E3/E5+VDA) (e7c91390-7625-45be-94e0-e16907e03118) | EXCHANGE FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318)<br/>WINDOWS 10 ENTERPRISE (NEW) (e7c91390-7625-45be-94e0-e16907e03118) |
| Windows 10 Enterprise E5 | WIN10_VDA_E5 | 488ba24a-39a9-4473-8ee5-19291e71b002 | EXCHANGE_S_FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318)<br/>WINDEFATP (871d91ec-ec1a-452b-a83f-bd76c7d770ef)<br/>Virtualization Rights for Windows 10 (E3/E5+VDA) (e7c91390-7625-45be-94e0-e16907e03118) | Exchange Foundation (113feb6c-3fe4-4440-bddc-54d774bf0318)<br/>Microsoft Defender Advanced Threat Protection (871d91ec-ec1a-452b-a83f-bd76c7d770ef)<br/>Windows 10 Enterprise (New) (e7c91390-7625-45be-94e0-e16907e03118) | WINDOWS STORE FOR BUSINESS | WINDOWS_STORE | 6470687e-a428-4b7a-bef2-8a291ad947c9 | EXCHANGE_S_FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318) | WINDOWS_STORE (a420f25f-a7b3-4ff5-a9d0-5d58f73b537d) | EXCHANGE FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318) | WINDOWS STORE SERVICE (a420f25f-a7b3-4ff5-a9d0-5d58f73b537d) |
active-directory Compare With B2c https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/compare-with-b2c.md
Previously updated : 10/23/2020 Last updated : 03/02/2021
With External Identities in Azure AD, you can allow people outside your organiza
Azure AD External Identities focuses less on a user's relationship to your organization and more on how the user wants to sign in to your apps and resources. Within this framework, Azure AD supports a variety of scenarios from business-to-business (B2B) collaboration to access management for consumer/customer- or citizen-facing applications (business-to-customer, or B2C). -- **Share your apps and resources with external users (B2B collaboration)**. Invite external users into your own tenant as "guest" users that you can assign permissions to (for authorization) while letting them use their existing credentials (for authentication). Users sign in to the shared resources using a simple invitation and redemption process with their work, school, or other email account. You can also use [Azure AD entitlement management](../governance/entitlement-management-overview.md) to configure policies that [manage access for external users](../governance/entitlement-management-external-users.md#how-access-works-for-external-users). And now with the availability of [self-service sign-up user flows (preview)](self-service-sign-up-overview.md), you can allow external users to sign up for applications themselves. The experience can be customized to allow sign-up with a work, school, or social identity (like Google or Facebook). You can also collect information about the user during the sign-up process. For more information, see the [Azure AD B2B documentation](index.yml).
+- **Share your apps and resources with external users (B2B collaboration)**. Invite external users into your own tenant as "guest" users that you can assign permissions to (for authorization) while letting them use their existing credentials (for authentication). Users sign in to the shared resources using a simple invitation and redemption process with their work, school, or other email account. You can also use [Azure AD entitlement management](../governance/entitlement-management-overview.md) to configure policies that [manage access for external users](../governance/entitlement-management-external-users.md#how-access-works-for-external-users). And now with the availability of [self-service sign-up user flows](self-service-sign-up-overview.md), you can allow external users to sign up for applications themselves. The experience can be customized to allow sign-up with a work, school, or social identity (like Google or Facebook). You can also collect information about the user during the sign-up process. For more information, see the [Azure AD B2B documentation](index.yml).
- **Build user journeys with a white-label identity management solution for consumer- and customer-facing apps (Azure AD B2C)**. If you're a business or developer creating customer-facing apps, you can scale to millions of consumers, customers, or citizens by using Azure AD B2C. Developers can use Azure AD as the full-featured Customer Identity and Access Management (CIAM) system for their applications. Customers can sign in with an identity they already have established (like Facebook or Gmail). With Azure AD B2C, you can completely customize and control how customers sign up, sign in, and manage their profiles when using your applications. For more information, see the [Azure AD B2C documentation](../../active-directory-b2c/index.yml).
active-directory Conditional Access https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/conditional-access.md
The following diagram illustrates the flow:
| Step | Description | |--|--| | 1. |The user requests access to a resource in another tenant. The resource redirects the user to its resource tenant, a trusted IdP.|
-| 2. | The resource tenant identifies the user as an [external email one-time passcode (OTP) user](https://docs.microsoft.com/azure/active-directory/external-identities/one-time-passcode) and sends an email with the OTP to the user.|
+| 2. | The resource tenant identifies the user as an [external email one-time passcode (OTP) user](./one-time-passcode.md) and sends an email with the OTP to the user.|
| 3. | The user retrieves the OTP and submits the code. The resource tenant evaluates the user against its CA policies. | 4. | Once all CA policies are satisfied, the resource tenant issues a token and redirects the user to its resource. |
The resource tenant is always responsible for Azure AD Multi-Factor Authenticati
5. This scenario works for any identity ΓÇô Azure AD or Personal Microsoft Account (MSA). For example, if user in Contoso authenticates using social ID.
-6. Fabrikam must have sufficient premium Azure AD licenses that support Azure AD Multi-Factor Authentication. The user from Contoso then consumes this license from Fabrikam. See [billing model for Azure AD external identities](https://docs.microsoft.com/azure/active-directory/external-identities/external-identities-pricing) for information on the B2B licensing.
+6. Fabrikam must have sufficient premium Azure AD licenses that support Azure AD Multi-Factor Authentication. The user from Contoso then consumes this license from Fabrikam. See [billing model for Azure AD external identities](./external-identities-pricing.md) for information on the B2B licensing.
>[!NOTE] >Azure AD Multi-Factor Authentication is done at resource tenancy to ensure predictability.
There are various factors that influence CA policies for B2B guest users.
### Device-based Conditional Access
-In CA, there's an option to require a userΓÇÖs [device to be Compliant or Hybrid Azure AD joined](https://docs.microsoft.com/azure/active-directory/conditional-access/concept-conditional-access-conditions#device-state-preview). B2B guest users can only satisfy compliance if the resource tenant can manage their device. Devices cannot be managed by more than one organization at a time. B2B guest users can't satisfy the Hybrid Azure AD join because they don't have an on-premises AD account. Only if the guest userΓÇÖs device is unmanaged, they can register or enroll their device in the resource tenant and then make the device compliant. The user can then satisfy the grant control.
+In CA, there's an option to require a userΓÇÖs [device to be Compliant or Hybrid Azure AD joined](../conditional-access/concept-conditional-access-conditions.md#device-state-preview). B2B guest users can only satisfy compliance if the resource tenant can manage their device. Devices cannot be managed by more than one organization at a time. B2B guest users can't satisfy the Hybrid Azure AD join because they don't have an on-premises AD account. Only if the guest userΓÇÖs device is unmanaged, they can register or enroll their device in the resource tenant and then make the device compliant. The user can then satisfy the grant control.
>[!Note] >It is not recommended to require a managed device for external users. ### Mobile application management policies
-The CA grant controls such as **Require approved client apps** and **Require app protection policies** need the device to be registered in the tenant. These controls can only be applied to [iOS and Android devices](https://docs.microsoft.com/azure/active-directory/conditional-access/concept-conditional-access-conditions#device-platforms). However, neither of these controls can be applied to B2B guest users if the userΓÇÖs device is already being managed by another organization. A mobile device cannot be registered in more than one tenant at a time. If the mobile device is managed by another organization, the user will be blocked. Only if the guest userΓÇÖs device is unmanaged, they can register their device in the resource tenant. The user can then satisfy the grant control.
+The CA grant controls such as **Require approved client apps** and **Require app protection policies** need the device to be registered in the tenant. These controls can only be applied to [iOS and Android devices](../conditional-access/concept-conditional-access-conditions.md#device-platforms). However, neither of these controls can be applied to B2B guest users if the userΓÇÖs device is already being managed by another organization. A mobile device cannot be registered in more than one tenant at a time. If the mobile device is managed by another organization, the user will be blocked. Only if the guest userΓÇÖs device is unmanaged, they can register their device in the resource tenant. The user can then satisfy the grant control.
>[!NOTE] >It is not recommended to require an app protection policy for external users. ### Location-based Conditional Access
-The [location-based policy](https://docs.microsoft.com/azure/active-directory/conditional-access/concept-conditional-access-conditions#locations) based on IP ranges can be enforced if the inviting organization can create a trusted IP address range that defines their partner organizations.
+The [location-based policy](../conditional-access/concept-conditional-access-conditions.md#locations) based on IP ranges can be enforced if the inviting organization can create a trusted IP address range that defines their partner organizations.
Policies can also be enforced based on **geographical locations**. ### Risk-based Conditional Access
-The [Sign-in risk policy](https://docs.microsoft.com/azure/active-directory/conditional-access/concept-conditional-access-conditions#sign-in-risk) is enforced if the B2B guest user satisfies the grant control. For example, an organization could require Azure AD Multi-Factor Authentication for medium or high sign-in risk. However, if a user hasn't previously registered for Azure AD Multi-Factor Authentication in the resource tenant, the user will be blocked. This is done to prevent malicious users from registering their own Azure AD Multi-Factor Authentication credentials in the event they compromise a legitimate userΓÇÖs password.
+The [Sign-in risk policy](../conditional-access/concept-conditional-access-conditions.md#sign-in-risk) is enforced if the B2B guest user satisfies the grant control. For example, an organization could require Azure AD Multi-Factor Authentication for medium or high sign-in risk. However, if a user hasn't previously registered for Azure AD Multi-Factor Authentication in the resource tenant, the user will be blocked. This is done to prevent malicious users from registering their own Azure AD Multi-Factor Authentication credentials in the event they compromise a legitimate userΓÇÖs password.
-The [User-risk policy](https://docs.microsoft.com/azure/active-directory/conditional-access/concept-conditional-access-conditions#user-risk) however cannot be resolved in the resource tenant. For example, if you require a password change for high-risk guest users, they'll be blocked because of the inability to reset passwords in the resource directory.
+The [User-risk policy](../conditional-access/concept-conditional-access-conditions.md#user-risk) however cannot be resolved in the resource tenant. For example, if you require a password change for high-risk guest users, they'll be blocked because of the inability to reset passwords in the resource directory.
### Conditional Access client apps condition
-[Client apps conditions](https://docs.microsoft.com/azure/active-directory/conditional-access/concept-conditional-access-conditions#client-apps) behave the same for B2B guest users as they do for any other type of user. For example, you could prevent guest users from using legacy authentication protocols.
+[Client apps conditions](../conditional-access/concept-conditional-access-conditions.md#client-apps) behave the same for B2B guest users as they do for any other type of user. For example, you could prevent guest users from using legacy authentication protocols.
### Conditional Access session controls
-[Session controls](https://docs.microsoft.com/azure/active-directory/conditional-access/concept-conditional-access-session) behave the same for B2B guest users as they do for any other type of user.
+[Session controls](../conditional-access/concept-conditional-access-session.md) behave the same for B2B guest users as they do for any other type of user.
## Next steps For more information, see the following articles on Azure AD B2B collaboration: -- [What is Azure AD B2B collaboration?](https://docs.microsoft.com/azure/active-directory/external-identities/what-is-b2b)-- [Identity Protection and B2B users](https://docs.microsoft.com/azure/active-directory/identity-protection/concept-identity-protection-b2b)
+- [What is Azure AD B2B collaboration?](./what-is-b2b.md)
+- [Identity Protection and B2B users](../identity-protection/concept-identity-protection-b2b.md)
- [External Identities pricing](https://azure.microsoft.com/pricing/details/active-directory/)-- [Frequently Asked Questions (FAQs)](https://docs.microsoft.com/azure/active-directory/external-identities/faq)-
+- [Frequently Asked Questions (FAQs)](./faq.md)
active-directory Delegate Invitations https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/delegate-invitations.md
Previously updated : 02/12/2021 Last updated : 03/02/2021
By default, all users, including guests, can invite guest users.
> >![Enable Email one-time passcode opted in](media/delegate-invitations/enable-email-otp-opted-in.png)
-7. Under **Enable guest self-service sign up via user flows (Preview)**, select **Yes** if you want to be able to create user flows that let users sign up for apps. For more information about this setting, see [Add a self-service sign-up user flow to an app (Preview)](self-service-sign-up-user-flow.md).
+7. Under **Enable guest self-service sign up via user flows**, select **Yes** if you want to be able to create user flows that let users sign up for apps. For more information about this setting, see [Add a self-service sign-up user flow to an app](self-service-sign-up-user-flow.md).
![Self-service sign up via user flows setting](./media/delegate-invitations/self-service-sign-up-setting.png)
-7. Under **Collaboration restrictions**, choose whether to allow or deny invitations to the domains you specify. For more information, see [Allow or block invitations to B2B users from specific organizations](allow-deny-list.md).
+7. Under **Collaboration restrictions**, you can choose whether to allow or deny invitations to the domains you specify and enter specific domain names in the text boxes. For multiple domains, enter each domain on a new line. For more information, see [Allow or block invitations to B2B users from specific organizations](allow-deny-list.md).
![Collaboration restrictions settings](./media/delegate-invitations/collaboration-restrictions.png) ## Assign the Guest Inviter role to a user
active-directory Direct Federation https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/direct-federation.md
Previously updated : 06/24/2020 Last updated : 03/02/2021
This article describes how to set up direct federation with another organization for B2B collaboration. You can set up direct federation with any organization whose identity provider (IdP) supports the SAML 2.0 or WS-Fed protocol. When you set up direct federation with a partner's IdP, new guest users from that domain can use their own IdP-managed organizational account to sign in to your Azure AD tenant and start collaborating with you. There's no need for the guest user to create a separate Azure AD account.
-> [!NOTE]
-> Direct federation guest users must sign in using a link that includes the tenant context (for example, `https://myapps.microsoft.com/?tenantid=<tenant id>` or `https://portal.azure.com/<tenant id>`, or in the case of a verified domain, `https://myapps.microsoft.com/\<verified domain>.onmicrosoft.com`). Direct links to applications and resources also work as long as they include the tenant context. Direct federation users are currently unable to sign in using common endpoints that have no tenant context. For example, using `https://myapps.microsoft.com`, `https://portal.azure.com`, or `https://teams.microsoft.com` will result in an error.
-
+ ## When is a guest user authenticated with direct federation? After you set up direct federation with an organization, any new guest users you invite will be authenticated using direct federation. ItΓÇÖs important to note that setting up direct federation doesnΓÇÖt change the authentication method for guest users who have already redeemed an invitation from you. Here are some examples: - If guest users have already redeemed invitations from you, and you subsequently set up direct federation with their organization, those guest users will continue to use the same authentication method they used before you set up direct federation.
Direct federation is tied to domain namespaces, such as contoso.com and fabrikam
## End-user experience With direct federation, guest users sign into your Azure AD tenant using their own organizational account. When they are accessing shared resources and are prompted for sign-in, direct federation users are redirected to their IdP. After successful sign-in, they are returned to Azure AD to access resources. Direct federation usersΓÇÖ refresh tokens are valid for 12 hours, the [default length for passthrough refresh token](../develop/active-directory-configurable-token-lifetimes.md#exceptions) in Azure AD. If the federated IdP has SSO enabled, the user will experience SSO and will not see any sign-in prompt after initial authentication.
+## Sign-in endpoints
+
+Direct federation guest users can now sign in to your multi-tenant or Microsoft first-party apps by using a [common endpoint](redemption-experience.md#redemption-and-sign-in-through-a-common-endpoint) (in other words, a general app URL that doesn't include your tenant context). During the sign-in process, the guest user chooses **Sign-in options**, and then selects **Sign in to an organization**. The user then types the name of your organization and continues signing in using their own credentials.
+
+Direct federation guest users can also use application endpoints that include your tenant information, for example:
+
+ * `https://myapps.microsoft.com/?tenantid=<your tenant ID>`
+ * `https://myapps.microsoft.com/<your verified domain>.onmicrosoft.com`
+ * `https://portal.azure.com/<your tenant ID>`
+
+You can also give Direct federation guest users a direct link to an application or resource by including your tenant information, for example `https://myapps.microsoft.com/signin/Twitter/<application ID?tenantId=<your tenant ID>`.
+ ## Limitations ### DNS-verified domains in Azure AD
Next, you'll configure federation with the identity provider configured in step
1. Go to the [Azure portal](https://portal.azure.com/). In the left pane, select **Azure Active Directory**. 2. Select **External Identities** > **All identity providers**.
-3. Select, and then select **New SAML/WS-Fed IdP**.
+3. Select **New SAML/WS-Fed IdP**.
![Screenshot showing button for adding a new SAML or WS-Fed IdP](media/direct-federation/new-saml-wsfed-idp.png)
active-directory Facebook Federation https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/facebook-federation.md
Previously updated : 05/19/2020 Last updated : 03/02/2021
# Add Facebook as an identity provider for External Identities
-You can add Facebook to your self-service sign-up user flows (Preview) so that users can sign in to your applications using their own Facebook accounts. To allow users to sign in using Facebook, you'll first need to [enable self-service sign-up](self-service-sign-up-user-flow.md) for your tenant. After you add Facebook as an identity provider, set up a user flow for the application and select Facebook as one of the sign-in options.
+You can add Facebook to your self-service sign-up user flows so that users can sign in to your applications using their own Facebook accounts. To allow users to sign in using Facebook, you'll first need to [enable self-service sign-up](self-service-sign-up-user-flow.md) for your tenant. After you add Facebook as an identity provider, set up a user flow for the application and select Facebook as one of the sign-in options.
+
+After you've added Facebook as one of your application's sign-in options, on the **Sign in** page, a user can simply enter the email they use to sign in to Facebook, or they can select **Sign-in options** and choose **Sign in with Facebook**. In either case, they'll be redirected to the Facebook login page for authentication.
+
+![Sign in options for facebook users](media/facebook-federation/sign-in-with-facebook-overview.png)
> [!NOTE] > Users can only use their Facebook accounts to sign up through apps using self-service sign-up and user flows. Users cannot be invited and redeem their invitation using a Facebook account.
active-directory Google Federation https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/google-federation.md
Previously updated : 05/11/2020 Last updated : 03/02/2021
# Add Google as an identity provider for B2B guest users
-By setting up federation with Google, you can allow invited users to sign in to your shared apps and resources with their own Gmail accounts, without having to create Microsoft accounts.
+By setting up federation with Google, you can allow invited users to sign in to your shared apps and resources with their own Gmail accounts, without having to create Microsoft accounts.
+
+After you've added Google as one of your application's sign-in options, on the **Sign in** page, a user can simply enter the email they use to sign in to Google, or they can select **Sign-in options** and choose **Sign in with Google**. In either case, they'll be redirected to the Google sign-in page for authentication.
+
+![Sign in options for Google users](media/google-federation/sign-in-with-google-overview.png)
> [!NOTE] > Google federation is designed specifically for Gmail users. To federate with G Suite domains, use [direct federation](direct-federation.md).
By setting up federation with Google, you can allow invited users to sign in to
> **Starting January 4, 2021**, Google is [deprecating WebView sign-in support](https://developers.googleblog.com/2020/08/guidance-for-our-effort-to-block-less-secure-browser-and-apps.html). If youΓÇÖre using Google federation or self-service sign-up with Gmail, you should [test your line-of-business native applications for compatibility](google-federation.md#deprecation-of-webview-sign-in-support). ## What is the experience for the Google user?
-When you send an invitation to Google Gmail users, the guest users should access your shared apps or resources by using a link that includes the tenant context. Their experience varies depending on whether they're already signed in to Google:
- - Guest users who aren't signed in to Google will be prompted to do so.
- - Guest users who are already signed in to Google will be prompted to choose the account they want to use. They must choose the account you used to invite them.
+
+When a Google user redeems your invitation, their experience varies depending on whether they're already signed in to Google:
+
+- Guest users who aren't signed in to Google will be prompted to do so.
+- Guest users who are already signed in to Google will be prompted to choose the account they want to use. They must choose the account you used to invite them.
Guest users who see a "header too long" error can clear their cookies or open a private or incognito window and try to sign in again. ![Screenshot that shows the Google sign-in page.](media/google-federation/google-sign-in.png)
+## Sign-in endpoints
+
+Google guest users can now sign in to your multi-tenant or Microsoft first-party apps by using a [common endpoint](redemption-experience.md#redemption-and-sign-in-through-a-common-endpoint) (in other words, a general app URL that doesn't include your tenant context). During the sign-in process, the guest user chooses **Sign-in options**, and then selects **Sign in to an organization**. The user then types the name of your organization and continues signing in using their Google credentials.
+
+Google guest users can also use application endpoints that include your tenant information, for example:
+
+ * `https://myapps.microsoft.com/?tenantid=<your tenant ID>`
+ * `https://myapps.microsoft.com/<your verified domain>.onmicrosoft.com`
+ * `https://portal.azure.com/<your tenant ID>`
+
+You can also give Google guest users a direct link to an application or resource by including your tenant information, for example `https://myapps.microsoft.com/signin/Twitter/<application ID?tenantId=<your tenant ID>`.
+ ## Deprecation of WebView sign-in support Starting January 4, 2021, Google is [deprecating embedded WebView sign-in support](https://developers.googleblog.com/2020/08/guidance-for-our-effort-to-block-less-secure-browser-and-apps.html). If youΓÇÖre using Google federation or [self-service sign-up with Gmail](identity-providers.md), you should test your line-of-business native applications for compatibility. If your apps include WebView content that requires authentication, Google Gmail users won't be able to authenticate. The following are known scenarios that will impact Gmail users:
WeΓÇÖre continuing to test various platforms and scenarios, and will update this
- If your Windows app uses embedded WebView or the WebAccountManager (WAM) on an older version of Windows, update to the latest version of Windows. - Modify your apps to use the system browser for sign-in. For details, see [Embedded vs System Web UI](../develop/msal-net-web-browsers.md#embedded-vs-system-web-ui) in the MSAL.NET documentation.
-## Sign-in endpoints
-
-Teams fully supports Google guest users on all devices. Google users can sign in to Teams from a common endpoint like `https://teams.microsoft.com`.
-
-Other applications' common endpoints might not support Google users. Google guest users must sign in by using a link that includes your tenant information. Following are examples:
- * `https://myapps.microsoft.com/?tenantid=<your tenant ID>`
- * `https://portal.azure.com/<your tenant ID>`
- * `https://myapps.microsoft.com/<your verified domain>.onmicrosoft.com`
-
- If Google guest users try to use a link like `https://myapps.microsoft.com` or `https://portal.azure.com`, they'll get an error.
-You can also give Google guest users a direct link to an application or resource, as long as the link includes your tenant information. For example, `https://myapps.microsoft.com/signin/Twitter/<application ID?tenantId=<your tenant ID>`.
## Step 1: Configure a Google developer project First, create a new project in the Google Developers Console to obtain a client ID and a client secret that you can later add to Azure Active Directory (Azure AD). 1. Go to the Google APIs at https://console.developers.google.com, and sign in with your Google account. We recommend that you use a shared team Google account. 2. Accept the terms of service if you're prompted to do so.
-3. Create a new project: On the dashboard, select **Create Project**, give the project a name (for example, **Azure AD B2B**), and then select **Create**:
+3. Create a new project: In the upper-left corner of the page, select the project list, and then on the **Select a project** page, select **New Project**.
+4. On the **New Project** page, give the project a name (for example, **Azure AD B2B**), and then select **Create**:
![Screenshot that shows a New Project page.](media/google-federation/google-new-project.png)
active-directory Identity Providers https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/identity-providers.md
Previously updated : 05/19/2020 Last updated : 03/02/2021 - # Identity Providers for External Identities
+> [!NOTE]
+> Some of the features mentioned in this article are public preview features of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
+ An *identity provider* creates, maintains, and manages identity information while providing authentication services to applications. When sharing your apps and resources with external users, Azure AD is the default identity provider for sharing. This means when you invite external users who already have an Azure AD or Microsoft account, they can automatically sign in without further configuration on your part.
-However, you can enable users to sign in with various identity providers.
+In addition to Azure AD accounts, External Identities offers a variety of identity providers.
+
+- **Microsoft accounts** (Preview): Guest users can use their own personal Microsoft account (MSA) to redeem your B2B collaboration invitations. When setting up a self-service sign-up user flow, you can add [Microsoft Account (Preview)](microsoft-account.md) as one of the allowed identity providers. No additional configuration is needed to make this identity provider available for user flows.
-- **Google**: Google federation allows external users to redeem invitations from you by signing in to your apps with their own Gmail accounts. Google federation can also be used in your self-service sign-up user flows.
+- **Email one-time passcode** (Preview): When redeeming an invitation or accessing a shared resource, a guest user can request a temporary code, which is sent to their email address. Then they enter this code to continue signing in. The email one-time passcode feature authenticates B2B guest users when they can't be authenticated through other means. When setting up a self-service sign-up user flow, you can add **Email One-Time Passcode (Preview)** as one of the allowed identity providers. Some setup is required; see [Email one-time passcode authentication](one-time-passcode.md).
+
+- **Google**: Google federation allows external users to redeem invitations from you by signing in to your apps with their own Gmail accounts. Google federation can also be used in your self-service sign-up user flows. See how to [add Google as an identity provider](google-federation.md).
> [!IMPORTANT] > **Starting January 4, 2021**, Google is [deprecating WebView sign-in support](https://developers.googleblog.com/2020/08/guidance-for-our-effort-to-block-less-secure-browser-and-apps.html). If youΓÇÖre using Google federation or self-service sign-up with Gmail, you should [test your line-of-business native applications for compatibility](google-federation.md#deprecation-of-webview-sign-in-support).
- > [!NOTE]
- > In the current self-service sign-up preview, if a user flow is associated with an app and you send a user an invitation to that app, the user won't be able to use a Gmail account to redeem the invitation. As a workaround, the user can go through the self-service sign-up process. Or, they can redeem the invitation by accessing a different app or by using their My Apps portal at https://myapps.microsoft.com.
--- **Facebook**: When building an app, you can configure self-service sign-up and enable Facebook federation so that users can sign up for your app using their own Facebook accounts. Facebook can only be used for self-service sign-up user flows and isn't available as a sign-in option when users are redeeming invitations from you.
+- **Facebook**: When building an app, you can configure self-service sign-up and enable Facebook federation so that users can sign up for your app using their own Facebook accounts. Facebook can only be used for self-service sign-up user flows and isn't available as a sign-in option when users are redeeming invitations from you. See how to [add Facebook as an identity provider](facebook-federation.md).
-- **Direct federation**: You can also set up direct federation with any external identity provider that supports the SAML or WS-Fed protocols. Direct federation allows external users to redeem invitations from you by signing in to your apps with their existing social or enterprise accounts.
+- **Direct federation**: You can also set up direct federation with any external identity provider that supports the SAML or WS-Fed protocols. Direct federation allows external users to redeem invitations from you by signing in to your apps with their existing social or enterprise accounts. See how to [set up direct federation](direct-federation.md).
> [!NOTE] > Direct federation identity providers can't be used in your self-service sign-up user flows.
+## Adding social identity providers
-## How it works
-
-The Azure AD External Identities self-service sign up feature allows users to sign up with their Azure AD, Google, or Facebook account. To set up social identity providers in your Azure AD tenant, you'll create an application at each identity provider and configure credentials. You'll obtain a client or app ID and a client or app secret, which you can then add to your Azure AD tenant.
+Azure AD is enabled by default for self-service sign-up, so users always have the option of signing up using an Azure AD account. However, you can enable other identity providers, including social identity providers like Google or Facebook. To set up social identity providers in your Azure AD tenant, you'll create an application at the identity provider and configure credentials. You'll obtain a client or app ID and a client or app secret, which you can then add to your Azure AD tenant.
Once you've added an identity provider to your Azure AD tenant: - When you invite an external user to apps or resources in your organization, the external user can sign in using their own account with that identity provider.-- When you enable [self-service sign-up](self-service-sign-up-overview.md) for your apps, external users can sign up for your apps using their own accounts with the identity providers you've added.-
-> [!NOTE]
-> Azure AD is enabled by default for self-service sign-up, so users always have the option of signing up using an Azure AD account.
-
-When redeeming your invitation or signing up for your app, the external user has the option to sign in and authenticate with the social identity provider:
+- When you enable [self-service sign-up](self-service-sign-up-overview.md) for your apps, external users can sign up for your apps using their own accounts with the identity providers you've added. They'll be able to select from the social identity providers options you've made available on the sign-up page:
-![Screenshot showing the sign-in screen with Google and Facebook options](media/identity-providers/sign-in-with-social-identity.png)
+ ![Screenshot showing the sign-in screen with Google and Facebook options](media/identity-providers/sign-in-with-social-identity.png)
For an optimal sign-in experience, federate with identity providers whenever possible so you can give your invited guests a seamless sign-in experience when they access your apps.
For an optimal sign-in experience, federate with identity providers whenever pos
To learn how to add identity providers for sign-in to your applications, refer to the following articles: -- [Add Google](google-federation.md) to your list of social identity providers-- [Add Facebook](facebook-federation.md) to your list of social identity providers
+- [Add email one-time passcode authentication](one-time-passcode.md)
+- [Add Google](google-federation.md) as an allowed social identity provider
+- [Add Facebook](facebook-federation.md) as an allowed social identity provider
- [Set up direct federation](direct-federation.md) with any organization whose identity provider supports the SAML 2.0 or WS-Fed protocol. Note that direct federation is not an option for self-service sign-up user flows.
active-directory Microsoft Account https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/microsoft-account.md
++
+ Title: Microsoft Account (MSA) identity provider in Azure AD
+description: Use Azure AD to enable an external user (guest) to sign in to your Azure AD apps with their Microsoft account (MSA).
+++++ Last updated : 03/02/2021+++++++
+# Microsoft Account (MSA) identity provider for External Identities (Preview)
+
+> [!NOTE]
+> The Microsoft Account identity provider is a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
+
+Your B2B guest users can use their own personal Microsoft accounts for B2B collaboration without further configuration. Guest users can redeem your B2B collaboration invitations or complete your sign-up user flows using their personal Microsoft account.
+
+Microsoft accounts are set up by a user to get access to consumer-oriented Microsoft products and cloud services, such as Outlook, OneDrive, Xbox LIVE, or Microsoft 365. The account is created and stored in the Microsoft consumer identity account system that's run by Microsoft.
+
+## Guest sign-in using Microsoft accounts
+
+Microsoft Account is available in the list of External Identities identity providers by default. No further configuration is needed to allow guest users to sign in with their Microsoft account using either the invitation flow or a self-service sign-up user flow.
+
+![Microsoft Account in the identity providers list](media/microsoft-account/microsoft-account-identity-provider.png)
+
+### Microsoft Account in the invitation flow
+
+When you [invite a guest user](add-users-administrator.md) to B2B collaboration, you can specify their Microsoft account as the email address they'll use to sign in.
+
+![Invite using a Microsoft account](media/microsoft-account/microsoft-account-invite.png)
+
+### Microsoft Account in self-service sign-up user flows
+
+Microsoft Account is an identity provider option for your self-service sign-up user flows. Users can sign up for your applications using their own Microsoft accounts. First, you'll need to [enable self-service sign-up](self-service-sign-up-user-flow.md) for your tenant. Then you can set up a user flow for the application and select Microsoft Account as one of the sign-in options.
+
+![Microsoft account in a self-service sign-up user flow](media/microsoft-account/microsoft-account-user-flow.png)
+
+## Next steps
+
+- [Add Azure Active Directory B2B collaboration users](add-users-administrator.md)
+- [Add self-service sign-up to an app](self-service-sign-up-user-flow.md)
active-directory One Time Passcode https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/one-time-passcode.md
Previously updated : 02/12/2021 Last updated : 03/02/2021
This article describes how to enable email one-time passcode authentication for
![Email one-time passcode overview diagram](media/one-time-passcode/email-otp.png) > [!IMPORTANT]
-> **Starting October 2021**, the email one-time passcode feature will be turned on for all existing tenants and enabled by default for new tenants. If you don't want to allow this feature to turn on automatically, you can disable it. See [Disable email one-time passcode](#disable-email-one-time-passcode) below.
+> - **Starting October 2021**, the email one-time passcode feature will be turned on for all existing tenants and enabled by default for new tenants. If you don't want to allow this feature to turn on automatically, you can disable it. See [Disable email one-time passcode](#disable-email-one-time-passcode) below.
+> - Email one-time passcode settings have moved in the Azure portal from **External collaboration settings** to **All identity providers**.
> [!NOTE] > One-time passcode users must sign in using a link that includes the tenant context (for example, `https://myapps.microsoft.com/?tenantid=<tenant id>` or `https://portal.azure.com/<tenant id>`, or in the case of a verified domain, `https://myapps.microsoft.com/<verified domain>.onmicrosoft.com`). Direct links to applications and resources also work as long as they include the tenant context. Guest users are currently unable to sign in using endpoints that have no tenant context. For example, using `https://myapps.microsoft.com`, `https://portal.azure.com` will result in an error.
Starting October 2021, the email one-time passcode feature will be turned on for
2. In the navigation pane, select **Azure Active Directory**.
-3. Select **External Identities** > **External collaboration settings**.
+3. Select **External Identities** > **All identity providers**.
-4. Under **Email one-time passcode for guests**, select **Disable email one-time passcode for guests**.
+4. Select **Email one-time passcode**, and then select **Disable email one-time passcode for guests**.
> [!NOTE]
- > If you see the following toggle instead of the email one-time passcode options, this means you've previously enabled, disabled, or opted into the preview of the feature. Select **No** to disable the feature.
+ > Email one-time passcode settings have moved in the Azure portal from **External collaboration settings** to **All identity providers**.
+ > If you see a toggle instead of the email one-time passcode options, this means you've previously enabled, disabled, or opted into the preview of the feature. Select **No** to disable the feature.
>
- >![Enable Email one-time passcode opted in](media/delegate-invitations/enable-email-otp-opted-in.png)
+ >![Email one-time passcode toggle disabled](media/one-time-passcode/enable-email-otp-disabled.png)
5. Select **Save**. ## Note for public preview customers
-If you've previously opted in to the email one-time passcode public preview, the October 2021 date for automatic feature enablement doesn't apply to you, so your related business processes won't be affected. Additionally, in the Azure portal, under the **Email one-time passcode for guests** properties, you won't see the option to **Automatically enable email one-time passcode for guests in October 2021**. Instead, you'll see the following **Yes** or **No** toggle:
+If you've previously opted in to the email one-time passcode public preview, the October 2021 date for automatic feature enablement doesn't apply to you, so your related business processes won't be affected. Additionally, in the Azure portal, under the **Email one-time passcode for guests** properties, you won't see the option to **Automatically enable email one-time passcode for guests starting October 2021**. Instead, you'll see the following **Yes** or **No** toggle:
-![Enable Email one-time passcode opted in](media/delegate-invitations/enable-email-otp-opted-in.png)
+![Email one-time passcode opted in](media/one-time-passcode/enable-email-otp-opted-in.png)
However, if you'd prefer to opt out of the feature and allow it to be automatically enabled in October 2021, you can revert to the default settings by using the Microsoft Graph API [email authentication method configuration resource type](/graph/api/resources/emailauthenticationmethodconfiguration). After you revert to the default settings, the following options will be available under **Email one-time passcode for guests**: -- **Automatically enable email one-time passcode for guests in October 2021**. (Default) If the email one-time passcode feature is not already enabled for your tenant, it will be automatically turned on in October 2021. No further action is necessary if you want the feature enabled at that time. If you've already enabled or disabled the feature, this option will be unavailable.
+![Enable Email one-time passcode opted in](media/one-time-passcode/email-otp-options.png)
+
+- **Automatically enable email one-time passcode for guests starting October 2021**. (Default) If the email one-time passcode feature is not already enabled for your tenant, it will be automatically turned on starting October 2021. No further action is necessary if you want the feature enabled at that time. If you've already enabled or disabled the feature, this option will be unavailable.
- **Enable email one-time passcode for guests effective now**. Turns on the email one-time passcode feature for your tenant. -- **Disable email one-time passcode for guests**. Turns off the email one-time passcode feature for your tenant, and prevents the feature from turning on in October 2021.
+- **Disable email one-time passcode for guests**. Turns off the email one-time passcode feature for your tenant, and prevents the feature from turning on in October 2021.
+
+## Note for Azure US Government customers
+
+The email one-time passcode feature is disabled by default in the Azure US Government cloud.
+
+ ![Email one-time passcode disabled](media/one-time-passcode/enable-email-otp-disabled.png)
+
+To enable the email one-time passcode feature in Azure US Government cloud:
+
+1. Sign in to the [Azure portal](https://portal.azure.com) as an Azure AD global administrator.
+2. In the navigation pane, select **Azure Active Directory**.
+3. Select **Organizational relationships**ΓÇ»>ΓÇ»**Settings**.
+
+ > [!NOTE]
+ > - If you don't see **Organizational relationships**, search for "External IdentitiesΓÇ¥ in the search bar at the top.
+
+4. Select **Email one-time passcode**, and then select **Yes**.
+5. Select **Save**.
+
+For more information about current limitations, see [Azure US Government clouds](current-limitations.md#azure-us-government-clouds).
active-directory Redemption Experience https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/redemption-experience.md
Previously updated : 02/12/2021 Last updated : 03/02/2021
When you add a guest user to your directory, the guest user account has a consen
> - **Starting January 4, 2021**, Google is [deprecating WebView sign-in support](https://developers.googleblog.com/2020/08/guidance-for-our-effort-to-block-less-secure-browser-and-apps.html). If youΓÇÖre using Google federation or self-service sign-up with Gmail, you should [test your line-of-business native applications for compatibility](google-federation.md#deprecation-of-webview-sign-in-support). > - **Starting October 2021**, Microsoft will no longer support the redemption of invitations by creating unmanaged Azure AD accounts and tenants for B2B collaboration scenarios. In preparation, we encourage customers to opt into [email one-time passcode authentication](one-time-passcode.md). We welcome your feedback on this public preview feature and are excited to create even more ways to collaborate.
-## Redemption through the invitation email
+## Redemption and sign-in through a common endpoint
-When you add a guest user to your directory by [using the Azure portal](./b2b-quickstart-add-guest-users-portal.md), an invitation email is sent to the guest in the process. You can also choose to send invitation emails when youΓÇÖre [using PowerShell](./b2b-quickstart-invite-powershell.md) to add guest users to your directory. HereΓÇÖs a description of the guestΓÇÖs experience when they redeem the link in the email.
+Guest users can now sign in to your multi-tenant or Microsoft first-party apps through a common endpoint (URL), for example `https://myapps.microsoft.com`. Previously, a common URL would redirect a guest user to their home tenant instead of your resource tenant for authentication, so a tenant-specific link was required (for example `https://myapps.microsoft.com/?tenantid=<tenant id>`). Now the guest user can go to the application's common URL, choose **Sign-in options**, and then select **Sign in to an organization**. The user then types the name of your organization.
-1. The guest receives an [invitation email](./invitation-email-elements.md) that's sent from **Microsoft Invitations**.
-2. The guest selects **Accept invitation** in the email.
-3. The guest will use their own credentials to sign in to your directory. If the guest does not have an account that can be federated to your directory and the [email one-time passcode (OTP)](./one-time-passcode.md) feature is not enabled; the guest is prompted to create a personal [MSA](https://support.microsoft.com/help/4026324/microsoft-account-how-to-create) or an [Azure AD self-service account](../enterprise-users/directory-self-service-signup.md). Refer to the [invitation redemption flow](#invitation-redemption-flow) for details.
-4. The guest is guided through the [consent experience](#consent-experience-for-the-guest) described below.
+![Common endpoint sign-in](media/redemption-experience/common-endpoint-flow-small.png)
+The user is then redirected to your tenanted endpoint, where they can either sign in with their email address or select an identity provider you've configured.
## Redemption through a direct link
-As an alternative to the invitation email, you can give a guest a direct link to your app or portal. You first need to add the guest user to your directory via the [Azure portal](./b2b-quickstart-add-guest-users-portal.md) or [PowerShell](./b2b-quickstart-invite-powershell.md). Then you can use any of the [customizable ways to deploy applications to users](../manage-apps/end-user-experiences.md), including direct sign-on links. When a guest uses a direct link instead of the invitation email, theyΓÇÖll still be guided through the first-time consent experience.
+As an alternative to the invitation email or an application's common URL, you can give a guest a direct link to your app or portal. You first need to add the guest user to your directory via the [Azure portal](./b2b-quickstart-add-guest-users-portal.md) or [PowerShell](./b2b-quickstart-invite-powershell.md). Then you can use any of the [customizable ways to deploy applications to users](../manage-apps/end-user-experiences.md), including direct sign-on links. When a guest uses a direct link instead of the invitation email, theyΓÇÖll still be guided through the first-time consent experience.
-> [!IMPORTANT]
-> The direct link must be tenant-specific. In other words, it must include a tenant ID or verified domain so the guest can be authenticated in your tenant, where the shared app is located. A common URL like https://myapps.microsoft.com wonΓÇÖt work for a guest because it will redirect to their home tenant for authentication. Here are some examples of direct links with tenant context:
+> [!NOTE]
+> A direct link is tenant-specific. In other words, it includes a tenant ID or verified domain so the guest can be authenticated in your tenant, where the shared app is located. Here are some examples of direct links with tenant context:
> - Apps access panel: `https://myapps.microsoft.com/?tenantid=<tenant id>` > - Apps access panel for a verified domain: `https://myapps.microsoft.com/<;verified domain>` > - Azure portal: `https://portal.azure.com/<tenant id>`
There are some cases where the invitation email is recommended over a direct lin
- Sometimes the invited user object may not have an email address because of a conflict with a contact object (for example, an Outlook contact object). In this case, the user must click the redemption URL in the invitation email. - The user may sign in with an alias of the email address that was invited. (An alias is an additional email address associated with an email account.) In this case, the user must click the redemption URL in the invitation email.
+## Redemption through the invitation email
+
+When you add a guest user to your directory by [using the Azure portal](./b2b-quickstart-add-guest-users-portal.md), an invitation email is sent to the guest in the process. You can also choose to send invitation emails when youΓÇÖre [using PowerShell](./b2b-quickstart-invite-powershell.md) to add guest users to your directory. HereΓÇÖs a description of the guestΓÇÖs experience when they redeem the link in the email.
+
+1. The guest receives an [invitation email](./invitation-email-elements.md) that's sent from **Microsoft Invitations**.
+2. The guest selects **Accept invitation** in the email.
+3. The guest will use their own credentials to sign in to your directory. If the guest does not have an account that can be federated to your directory and the [email one-time passcode (OTP)](./one-time-passcode.md) feature is not enabled; the guest is prompted to create a personal [MSA](https://support.microsoft.com/help/4026324/microsoft-account-how-to-create) or an [Azure AD self-service account](../enterprise-users/directory-self-service-signup.md). Refer to the [invitation redemption flow](#invitation-redemption-flow) for details.
+4. The guest is guided through the [consent experience](#consent-experience-for-the-guest) described below.
## Invitation redemption flow When a user clicks the **Accept invitation** link in an [invitation email](invitation-email-elements.md), Azure AD automatically redeems the invitation based on the redemption flow as shown below:
active-directory Self Service Sign Up Add Api Connector https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/self-service-sign-up-add-api-connector.md
Previously updated : 06/16/2020 Last updated : 03/02/2021
To use an [API connector](api-connectors-overview.md), you first create the API
1. Sign in to the [Azure portal](https://portal.azure.com/) as an Azure AD administrator. 2. Under **Azure services**, select **Azure Active Directory**. 3. In the left menu, select **External Identities**.
-4. Select **All API connectors (Preview)**, and then select **New API connector**.
+4. Select **All API connectors**, and then select **New API connector**.
![Add a new API connector](./media/self-service-sign-up-add-api-connector/api-connector-new.png)
Follow these steps to add an API connector to a self-service sign-up user flow.
1. Sign in to the [Azure portal](https://portal.azure.com/) as an Azure AD administrator. 2. Under **Azure services**, select **Azure Active Directory**. 3. In the left menu, select **External Identities**.
-4. Select **User flows (Preview)**, and then select the user flow you want to add the API connector to.
+4. Select **User flows**, and then select the user flow you want to add the API connector to.
5. Select **API connectors**, and then select the API endpoints you want to invoke at the following steps in the user flow: - **After signing in with an identity provider**
active-directory Self Service Sign Up Add Approvals https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/self-service-sign-up-add-approvals.md
Previously updated : 06/16/2020 Last updated : 03/02/2021
Now you'll add the API connectors to a self-service sign-up user flow with these
1. Sign in to the [Azure portal](https://portal.azure.com/) as an Azure AD administrator. 2. Under **Azure services**, select **Azure Active Directory**. 3. In the left menu, select **External Identities**.
-4. Select **User flows (Preview)**, and then select the user flow you want to enable the API connector for.
+4. Select **User flows**, and then select the user flow you want to enable the API connector for.
5. Select **API connectors**, and then select the API endpoints you want to invoke at the following steps in the user flow: - **After signing in with an identity provider**: Select your approval status API connector, for example _Check approval status_.
POST https://graph.microsoft.com/v1.0/invitations
Content-type: application/json {
-    "invitedUserEmailAddress":"johnsmith@fabrikam.onmicrosoft.com",
-    "inviteRedirectUrl" : "https://myapp.com"
+ "invitedUserEmailAddress": "johnsmith@fabrikam.onmicrosoft.com",
+ "inviteRedirectUrl"ΓÇ»: "https://myapp.com"
} ```
Content-type: application/json
{ ...
-    "invitedUser": {
-        "id": "<generated-user-guid>"
-    }
+ "invitedUser":ΓÇ»{
+ "id":ΓÇ»"<generated-user-guid>"
+ }
} ```
active-directory Self Service Sign Up Overview https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/self-service-sign-up-overview.md
Previously updated : 05/19/2020 Last updated : 03/02/2021
-# Self-service sign-up (Preview)
-
-> [!NOTE]
-> Self-service sign-up is a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
+# Self-service sign-up
When sharing an application with external users, you might not always know in advance who will need access to the application. As an alternative to sending invitations directly to individuals, you can allow external users to sign up for specific applications themselves by enabling self-service sign-up. You can create a personalized sign-up experience by customizing the self-service sign-up user flow. For example, you can provide options to sign up with Azure AD or social identity providers and collect information about the user during the sign-up process.
active-directory Self Service Sign Up User Flow https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/self-service-sign-up-user-flow.md
Previously updated : 06/16/2020 Last updated : 03/02/2021
-# Add a self-service sign-up user flow to an app (Preview)
+# Add a self-service sign-up user flow to an app
+ > [!NOTE]
-> Self-service sign-up is a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
+> Some of the features mentioned in this article are public preview features of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
-You can create user flows for apps that are built by your organization. Associating your user flow with an application allows you to enable sign-up on that app. You can choose more than one application to be associated with the user flow. Once you associate the user flow with one or more applications, users who visit that app will be able to sign up and gain a guest account using the options configured in the user flow.
+For applications you build, you can create user flows that allow a user to sign up for an app and create a new guest account. A self-service sign-up user flow defines the series of steps the user will follow during sign-up, the identity providers you'll allow them to use, and the user attributes you want to collect. You can associate one or more applications with a single user flow.
> [!NOTE] > You can associate user flows with apps built by your organization. User flows can't be used for Microsoft apps, like SharePoint or Teams. ## Before you begin
-### Add social identity providers (optional)
+### Add identity providers (optional)
-Azure AD is the default identity provider for self-service sign-up. This means that users are able to sign up by default with an Azure AD account. Social identity providers can also be included in these sign-up flows to support Google and Facebook accounts.
+Azure AD is the default identity provider for self-service sign-up. This means that users are able to sign up by default with an Azure AD account. In your self-service sign-up user flows, you can also include social identity providers like Google and Facebook, Microsoft Account (Preview), and Email One-time Passcode (Preview).
+- [Microsoft Account (Preview) identity provider](microsoft-account.md)
+- [Email one-time passcode authentication](one-time-passcode.md)
- [Add Facebook to your list of social identity providers](facebook-federation.md) - [Add Google to your list of social identity providers](google-federation.md)
-> [!NOTE]
-> In the current preview, if a self-service sign-up user flow is associated with an app and you send a user an invitation to that app, the user won't be able to use a Gmail account to redeem the invitation. As a workaround, the user can go through the self-service sign-up process. Or, they can redeem the invitation by accessing a different app or by using their My Apps portal at https://myapps.microsoft.com.
- ### Define custom attributes (optional) User attributes are values collected from the user during self-service sign-up. Azure AD comes with a built-in set of attributes, but you can create custom attributes for use in your user flow. You can also read and write these attributes by using the Microsoft Graph API. See [Define custom attributes for user flows](user-flow-add-custom-attributes.md).
Before you can add a self-service sign-up user flow to your applications, you ne
1. Sign in to the [Azure portal](https://portal.azure.com) as an Azure AD administrator. 2. Under **Azure services**, select **Azure Active Directory**. 3. Select **User settings**, and then under **External users**, select **Manage external collaboration settings**.
-4. Set the **Enable guest self-service sign up via user flows (Preview)** toggle to **Yes**.
+4. Set the **Enable guest self-service sign up via user flows** toggle to **Yes**.
![Enable guest self-service sign-up](media/self-service-sign-up-user-flow/enable-self-service-sign-up.png) 5. Select **Save**.
Next, you'll create the user flow for self-service sign-up and add it to an appl
1. Sign in to the [Azure portal](https://portal.azure.com) as an Azure AD administrator. 2. Under **Azure services**, select **Azure Active Directory**. 3. In the left menu, select **External Identities**.
-4. Select **User flows (Preview)**, and then select **New user flow**.
+4. Select **User flows**, and then select **New user flow**.
![Add a new user flow button](media/self-service-sign-up-user-flow/new-user-flow.png)
Next, you'll create the user flow for self-service sign-up and add it to an appl
> You can only collect attributes when a user signs up for the first time. After a user signs up, they will no longer be prompted to collect attribute information, even if you change the user flow. 8. Select **Create**.
-9. The new user flow appears in the **User flows (Preview)** list. If necessary, refresh the page.
+9. The new user flow appears in the **User flows** list. If necessary, refresh the page.
## Select the layout of the attribute collection form You can choose order in which the attributes are displayed on the sign-up page. 1. In the [Azure portal](https://portal.azure.com), select **Azure Active Directory**.
-2. Select **External Identities**, select **User flows (Preview)**.
+2. Select **External Identities**, select **User flows**.
3. Select the self-service sign-up user flow from the list. 4. Under **Customize**, select **Page layouts**. 5. The attributes you chose to collect are listed. To change the order of display, select an attribute, and then select **Move up**, **Move down**, **Move to the top**, or **Move to the bottom**.
Now you can associate applications with the user flow.
1. Sign in to the [Azure portal](https://portal.azure.com) as an Azure AD administrator. 2. Under **Azure services**, select **Azure Active Directory**. 3. In the left menu, select **External Identities**.
-4. Under **Self-service sign up**, select **User flows (Preview)**.
+4. Under **Self-service sign up**, select **User flows**.
5. Select the self-service sign-up user flow from the list. 6. In the left menu, under **Use**, select **Applications**. 7. Select **Add application**.
active-directory User Flow Add Custom Attributes https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/user-flow-add-custom-attributes.md
Previously updated : 06/16/2020 Last updated : 03/02/2021
-# Define custom attributes for user flows (Preview)
-
-> [!NOTE]
-> The custom user attributes feature is a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
+# Define custom attributes for user flows
For each application, you might have different requirements for the information you want to collect during sign-up. Azure AD comes with a built-in set of information stored in attributes, such as Given Name, Surname, City, and Postal Code. With Azure AD, you can extend the set of attributes stored on a guest account when the external user signs up through a user flow.
-You can create custom attributes in the Azure portal and use them in your self-service sign-up user flows. You can also read and write these attributes by using the [Microsoft Graph API](../../active-directory-b2c/manage-user-accounts-graph-api.md). Microsoft Graph API supports creating and updating a user with extension attributes. Extension attributes in the Graph API are named by using the convention `extension_<extensions-app-id>_attributename`. For example:
+You can create custom attributes in the Azure portal and use them in your self-service sign-up user flows. You can also read and write these attributes by using the [Microsoft Graph API](../../active-directory-b2c/microsoft-graph-operations.md). Microsoft Graph API supports creating and updating a user with extension attributes. Extension attributes in the Graph API are named by using the convention `extension_<extensions-app-id>_attributename`. For example:
```JSON "extension_831374b3bd5041bfaa54263ec9e050fc_loyaltyNumber": "212342"
The `<extensions-app-id>` is specific to your tenant. To find this identifier, n
1. Sign in to the [Azure portal](https://portal.azure.com) as an Azure AD administrator. 2. Under **Azure services**, select **Azure Active Directory**. 3. In the left menu, select **External Identities**.
-4. Select **Custom user attributes (Preview)**. The available user attributes are listed.
+4. Select **Custom user attributes**. The available user attributes are listed.
![Select user attributes for sign-up](media/user-flow-add-custom-attributes/user-attributes.png)
active-directory User Flow Customize Language https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/user-flow-customize-language.md
Previously updated : 05/06/2020 Last updated : 03/02/2021
-# Language customization in Azure Active Directory (Preview)
-
-> [!NOTE]
-> Self-service sign-up is a public preview feature of Azure Active Directory. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
+# Language customization in Azure Active Directory
Language customization in Azure Active Directory (Azure AD) allows your user flow to accommodate different languages to suit your user's needs. Microsoft provides the translations for [36 languages](#supported-languages). Even if your experience is provided for only a single language, you can customize the attribute names on the attribute collection page.
Language customization enables you to customize any string in your user flow.
1. Sign in to the [Azure portal](https://portal.azure.com) as an Azure AD administrator. 2. Under **Azure services**, select **Azure Active Directory**. 3. In the left menu, select **External Identities**.
-4. Select **User flows (Preview)**.
+4. Select **User flows**.
3. Select the user flow that you want to enable for translations. 4. Select **Languages**. 5. On the **Languages** page for the user flow, select the language that you want to customize.
active-directory What Is B2b https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/what-is-b2b.md
Previously updated : 02/12/2021 Last updated : 03/02/2021
Azure AD supports external identity providers like Facebook, Microsoft accounts,
![Screenshot showing the Identity providers page](media/what-is-b2b/identity-providers.png)
-## Create a self-service sign-up user flow (Preview)
+## Create a self-service sign-up user flow
With a self-service sign-up user flow, you can create a sign-up experience for external users who want to access your apps. As part of the sign-up flow, you can provide options for different social or enterprise identity providers, and collect information about the user. Learn about [self-service sign-up and how to set it up](self-service-sign-up-overview.md).
active-directory 5 Secure Access B2b https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/5-secure-access-b2b.md
Determine who can invite guest users to access resources.
If you use Azure AD entitlement management, you can configure questions for external users to answer. The questions will then be shown to approvers to help them make a decision. You can configure different sets of questions for each [access package policy](../governance/entitlement-management-access-package-approval-policy.md) so that approvers can have relevant information for the access they're approving. For example, if one access package is intended for vendor access, then the requestor may be asked for their vendor contract number. A different access package intended for suppliers, may ask for their country of origin.
-If you use a self-service portal, you can use [API connectors](../external-identities/api-connectors-overview.md) to collect additional attributes about users as they sign up. You can then potentially use those attributes to assign access. For example, if during the sign-up process you collect their supplier ID, you could use that attribute to dynamically assign them to a group or access package for that supplier. You can create custom attributes in the Azure portal and use them in your self-service sign-up user flows. You can also read and write these attributes by using the [Microsoft Graph API](../../active-directory-b2c/manage-user-accounts-graph-api.md).
+If you use a self-service portal, you can use [API connectors](../external-identities/api-connectors-overview.md) to collect additional attributes about users as they sign up. You can then potentially use those attributes to assign access. For example, if during the sign-up process you collect their supplier ID, you could use that attribute to dynamically assign them to a group or access package for that supplier. You can create custom attributes in the Azure portal and use them in your self-service sign-up user flows. You can also read and write these attributes by using the [Microsoft Graph API](../../active-directory-b2c/microsoft-graph-operations.md).
### Troubleshoot invitation redemption to Azure AD users
active-directory Active Directory Users Reset Password Azure Portal https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/active-directory-users-reset-password-azure-portal.md
As an administrator, you can reset a user's password if the password is forgotte
## To reset a password
-1. Sign in to the [Azure portal](https://portal.azure.com/) as a user administrator, or password administrator. For more information about the available roles, see [Assigning administrator roles in Azure Active Directory](../roles/permissions-reference.md#available-roles)
+1. Sign in to the [Azure portal](https://portal.azure.com/) as a user administrator, or password administrator. For more information about the available roles, see [Azure AD built-in roles](../roles/permissions-reference.md)
2. Select **Azure Active Directory**, select **Users**, search for and select the user that needs the reset, and then select **Reset Password**.
As an administrator, you can reset a user's password if the password is forgotte
>[!Note] >The temporary password never expires. The next time the user signs in, the password will still work, regardless how much time has passed since the temporary password was generated.
+> [!IMPORTANT]
+> If an administrator is unable to reset the user's password, and in the Application Event Logs on the Azure AD Connect server the following error code hr=80231367 is seen, review the user's attributes in Active Directory. If the attribute **AdminCount** is set to 1, this will prevent an administrator from resetting the user's password. The attribute **AdminCount** must be set to 0, in order for an administrators to reset the user's password.
++ ## Next steps After you've reset your user's password, you can perform the following basic processes:
active-directory Monitor Sign In Health For Resilience https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/monitor-sign-in-health-for-resilience.md
This article walks through setting up the sign-in health workbook to monitor for
* A Log Analytics workspace in your Azure subscription to send logs to Azure Monitor logs.
- * Learn how to [create a Log Analytics workspace](https://docs.microsoft.com/azure/azure-monitor/learn/quick-create-workspace)
+ * Learn how to [create a Log Analytics workspace](../../azure-monitor/logs/quick-create-workspace.md)
* Azure AD logs integrated with Azure Monitor logs
Use the following instructions to create email alerts based on the queries refle
To configure the underlying query and set alerts, complete the following steps. You'll use the Sample Query as the basis for your configuration. An explanation of the query structure appears at the end of this section.
-For more information on how to create, view, and manage log alerts using Azure Monitor see [Manage log alerts](https://docs.microsoft.com/azure/azure-monitor/platform/alerts-log).
+For more information on how to create, view, and manage log alerts using Azure Monitor see [Manage log alerts](../../azure-monitor/alerts/alerts-log.md).
1. In the workbook, select **Edit**, then select the **query icon** just above the right-hand side of the graph.
Once you have set up the query and alerts, create business processes to manage t
## Next steps
-[Learn more about workbooks](https://docs.microsoft.com/azure/active-directory/reports-monitoring/howto-use-azure-monitor-workbooks)
+[Learn more about workbooks](../reports-monitoring/howto-use-azure-monitor-workbooks.md)
-
active-directory Protect M365 From On Premises Attacks https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/protect-m365-from-on-premises-attacks.md
We recommend the following provisioning methods:
access](../../role-based-access-control/conditional-access-azure-management.md). * **Disconnected forests**: Use [Azure AD cloud
- provisioning](../cloud-provisioning/what-is-cloud-provisioning.md). This method enables you to connect to disconnected forests, eliminating the need to establish cross-forest connectivity or trusts, which can
+ provisioning](../cloud-sync/what-is-cloud-sync.md). This method enables you to connect to disconnected forests, eliminating the need to establish cross-forest connectivity or trusts, which can
broaden the effect of an on-premises breach. ### Limitations and tradeoffs
active-directory Resilience With Monitoring Alerting https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/resilience-with-monitoring-alerting.md
For example, track the following metrics, since a sudden drop in either will lea
- **Previous period**: Create temporal charts to show changes in the Total requests and Success rate (%) over some previous period for reference purposes, for example, last week. -- **Alerting**: Using log analytics define [alerts](../../azure-monitor/platform/alerts-log.md) that get triggered when there are sudden changes in the key indicators. These changes may negatively impact the SLOs. Alerts use various forms of notification methods including email, SMS, and webhooks. Start by defining a criterion that acts as a threshold against which alert will be triggered. For example:
+- **Alerting**: Using log analytics define [alerts](../../azure-monitor/alerts/alerts-log.md) that get triggered when there are sudden changes in the key indicators. These changes may negatively impact the SLOs. Alerts use various forms of notification methods including email, SMS, and webhooks. Start by defining a criterion that acts as a threshold against which alert will be triggered. For example:
- Alert against abrupt drop in Total requests: Trigger an alert when number of total requests drop abruptly. For example, when there is a 25% drop in the total number of requests compared to previous period, raise an alert. - Alert against significant drop in Success rate (%): Trigger an alert when success rate of the selected policy significantly drops. - Upon receiving an alert, troubleshoot the issue using [Log Analytics](../reports-monitoring/howto-install-use-log-analytics-views.md), [Application Insights](../../active-directory-b2c/troubleshoot-with-application-insights.md), and [VS Code extension](https://marketplace.visualstudio.com/items?itemName=AzureADB2CTools.aadb2c) for Azure AD B2C. After resolving the issue and deploying an updated application or policy, it continues to monitor the key indicators until they return back to normal range.
For example, track the following metrics, since a sudden drop in either will lea
- **Service alerts**: Use the [Azure AD B2C service level alerts](../../service-health/service-health-overview.md) to get notified of service issues, planned maintenance, health advisory, and security advisory. - **Reporting**: [By using log analytics](../reports-monitoring/howto-integrate-activity-logs-with-log-analytics.md), build reports that help you gain understanding about user insights, technical challenges, and growth opportunities.
- - **Health Dashboard**: Create [custom dashboards using Azure Dashboard](../../azure-monitor/learn/tutorial-app-dashboards.md) feature, which supports adding charts using Log Analytics queries. For example, identify pattern of successful and failed sign-ins, failure reasons and telemetry about devices used to make the requests.
+ - **Health Dashboard**: Create [custom dashboards using Azure Dashboard](../../azure-monitor/app/tutorial-app-dashboards.md) feature, which supports adding charts using Log Analytics queries. For example, identify pattern of successful and failed sign-ins, failure reasons and telemetry about devices used to make the requests.
- **Abandon Azure AD B2C journeys**: Use the [workbook](https://github.com/azure-ad-b2c/siem#list-of-abandon-journeys) to track the list of abandoned Azure AD B2C journeys where user started the sign-in or sign-up journey but never finished it. It provides you details about policy ID and breakdown of steps that are taken by the user before abandoning the journey. - **Azure AD B2C monitoring workbooks**: Use the [monitoring workbooks](https://github.com/azure-ad-b2c/siem), which includes Azure AD B2C dashboard, Multi-factor authentication (MFA) operations, Conditional Access report, and Search logs by correlationId, to get better insights into the health of your Azure AD B2C environment.
For example, track the following metrics, since a sudden drop in either will lea
- [Resilient interfaces with external processes](resilient-external-processes.md) - [Resilience through developer best practices](resilience-b2c-developer-best-practices.md) - [Build resilience in your authentication infrastructure](resilience-in-infrastructure.md)-- [Increase resilience of authentication and authorization in your applications](resilience-app-development-overview.md)
+- [Increase resilience of authentication and authorization in your applications](resilience-app-development-overview.md)
active-directory Service Accounts Govern On Premises https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/service-accounts-govern-on-premises.md
Use the following criteria when creating a new service account.
Use the following settings with user accounts used as service accounts:
-* [**Account Expiry**](https://docs.microsoft.com/powershell/module/activedirectory/set-adaccountexpiration?view=winserver2012-ps): set the service account to automatically expire a set time after its review period unless it's determined that it should continue
+* [**Account Expiry**](/powershell/module/activedirectory/set-adaccountexpiration?view=winserver2012-ps): set the service account to automatically expire a set time after its review period unless it's determined that it should continue
* **LogonWorkstations**: restrict permissions for where the service account can sign in. If it runs locally on a machine and accesses only resources on that machine, restrict it from logging on anywhere else.
-* [**Cannot change password**](https://docs.microsoft.com/powershell/module/addsadministration/set-aduser?view=win10-ps): prevent the service account from changing its own password by setting the parameter to false.
+* [**Cannot change password**](/powershell/module/addsadministration/set-aduser?view=win10-ps): prevent the service account from changing its own password by setting the parameter to false.
## Build a lifecycle management process
The risk assessment, once conducted and documented, may have impact on:
Create service account only after relevant information is documented in your CMDB and you perform a risk assessment. Account restrictions should be aligned to risk assessment. Consider the following restrictions when relevant to you assessment.:
-* [Account Expiry](https://docs.microsoft.com/powershell/module/activedirectory/set-adaccountexpiration?view=winserver2012-ps)
+* [Account Expiry](/powershell/module/activedirectory/set-adaccountexpiration?view=winserver2012-ps)
- * For all user accounts used as service accounts, define a realistic and definite end-date for use. Set this using the ΓÇ£Account ExpiresΓÇ¥ flag. For more details, refer to[ Set-ADAccountExpiration](https://docs.microsoft.com/powershell/module/addsadministration/set-adaccountexpiration?view=win10-ps).
+ * For all user accounts used as service accounts, define a realistic and definite end-date for use. Set this using the ΓÇ£Account ExpiresΓÇ¥ flag. For more details, refer to[ Set-ADAccountExpiration](/powershell/module/addsadministration/set-adaccountexpiration?view=win10-ps).