+ Title: Build a global identity solution with funnel-based approach

+ Title: Build a global identity solution with region-based approach

+1. [Download the .zip file](https://github.com/Azure-Samples/active-directory-b2c-ios-swift-native-msal/archive/refs/heads/master.zip), or clone the sample web app from the [GitHub repo](https://github.com/Azure-Samples/active-directory-b2c-ios-swift-native-msal).

+ git clone https://github.com/Azure-Samples/active-directory-b2c-ios-swift-native-msal

+ | ps-sso-first | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name` |

+ | ps-sso-last | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname` |

+ Title: Tutorial to configure Azure Active Directory B2C with the Arkose Labs platform

+description: Learn to configure Azure Active Directory B2C with the Arkose Labs platform to identify risky and fraudulent users

+# Tutorial: Configure Azure Active Directory B2C with the Arkose Labs platform

+In this tutorial, learn how to integrate Azure Active Directory B2C (Azure AD B2C) authentication with the [Arkose Labs](https://www.arkoselabs.com/) Arkose Protect Platform. Arkose Labs products help organizations against bot attacks, account takeover, and fraudulent account openings.

+- An Azure subscription

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

+- [An Azure AD B2C tenant](tutorial-create-tenant.md) linked to your Azure subscription

+- An Arkose Labs account

+ - Go to arkoselabs.com to [request a demo](https://www.arkoselabs.com/book-a-demo/)

+Arkose Labs products integration includes the following components:

+- **Arkose Protect Platform** - A service to protect against bots and other automated abuse

+- **Azure AD B2C sign-up user flow** - The sign-up experience that uses the Arkose Labs platform

+ - Custom HTML, JavaScript, and API connectors integrate with the Arkose platform

+- **Azure Functions** - Your hosted API endpoint that works with the API connectors feature

+ - This API validates the server-side of the Arkose Labs session token

+ - Learn more in the [Azure Functions Overview](/azure/azure-functions/functions-overview)

+The following diagram illustrates how the Arkose Labs platform integrates with Azure AD B2C.

+ 

+1. A user signs up and creates an account. The user selects **Submit**, and an Arkose Labs enforcement challenge appears.

+2. The user completes the challenge. Azure AD B2C sends the status to Arkose Labs to generate a token.

+3. Arkose Labs sends the token to Azure AD B2C.

+4. Azure AD B2C calls an intermediate web API to pass the sign-up form.

+5. The sign-up form goes to Arkose Labs for token verification.

+6. Arkose Labs sends verification results to the intermediate web API.

+7. The API sends a success or failure result to Azure AD B2C.

+8. If the challenge is successful, a sign-up form goes to Azure AD B2C, which completes authentication.

+## Request a demo from Arkose Labs

+1. Go to arkoselabs.com to [book a demo](https://www.arkoselabs.com/book-a-demo/).

+2. Create an account.

+3. Navigate to the [Arkose Portal](https://dashboard.arkoselabs.com/login) sign-in page.

+4. In the dashboard, navigate to site settings.

+5. Locate your public key and private key. You'll use this information later.

+> [!NOTE]

+> The public and private key values are `ARKOSE_PUBLIC_KEY` and `ARKOSE_PRIVATE_KEY`.

+> See, [Azure-Samples/active-directory-b2c-node-sign-up-user-flow-arkose](https://github.com/Azure-Samples/active-directory-b2c-node-sign-up-user-flow-arkose).

+### Create an ArkoseSessionToken custom attribute

+To create a custom attribute:

+1. Go to the [Azure portal](https://ms.portal.azure.com/#home), then to **Azure AD B2C**.

+2. Select **User attributes**.

+3. Select **Add**.

+4. Enter **ArkoseSessionToken** as the attribute Name.

+5. Select **Create**.

+Learn more: [Define custom attributes in Azure Active Directory B2C](./user-flow-custom-attributes.md?pivots=b2c-user-flow)

+### Create a user flow

+The user flow is for sign-up and sign-in, or sign-up. The Arkose Labs user flow appears during sign-up.

+1. [Create user flows and custom policies in Azure Active Directory B2C](./tutorial-create-user-flows.md). If using a user flow, use **Recommended**.

+2. In the user flow settings, go to **User attributes**.

+3. Select the **ArkoseSessionToken** claim.

+ 

+### Configure custom HTML, JavaScript, and page layout

+1. Go to [Azure-Samples/active-directory-b2c-node-sign-up-user-flow-arkose](https://github.com/Azure-Samples/active-directory-b2c-node-sign-up-user-flow-arkose/blob/main/Assets/selfAsserted.html).

+2. Find the HTML template with JavaScript `<script>` tags. These do three things:

+* Load the Arkose Labs script, which renders their widget and does client-side Arkose Labs validation.

+* Hide the `extension_ArkoseSessionToken` input element and label, corresponding to the `ArkoseSessionToken` custom attribute.

+* When a user completes the Arkose Labs challenge, the user response is verified and a token generated. The callback `arkoseCallback` in the custom JavaScript sets the value of `extension_ArkoseSessionToken` to the generated token value. This value is submitted to the API endpoint.

+ > [!NOTE]

+ > Go to developer.arkoselabs.com for [Client-Side Instructions](https://developer.arkoselabs.com/docs/standard-setup). Follow the steps to use the custom HTML and JavaScript for your user flow.

+3. In Azure-Samples, modify [selfAsserted.html](https://github.com/Azure-Samples/active-directory-b2c-node-sign-up-user-flow-arkose/blob/main/Assets/selfAsserted.html) file so `<ARKOSE_PUBLIC_KEY>` matches the value you generated for the client-side validation.

+4. Host the HTML page on a Cross-Origin Resource Sharing (CORS) enabled web endpoint.

+5. [Create a storage account](../storage/common/storage-account-create.md?tabs=azure-portal&toc=%2fazure%2fstorage%2fblobs%2ftoc.json).

+6. [CORS support for Azure Storage](/rest/api/storageservices/cross-origin-resource-sharing--cors--support-for-the-azure-storage-services).

+ >[!NOTE]

+ >If you have custom HTML, copy and paste the `<script>` elements onto your HTML page.

+7. In the Azure portal, go to **Azure AD B2C**.

+8. Navigate to **User flows**.

+9. Select your user flow.

+10. Select **Page layouts**.

+11. Select **Local account sign up page layout**.

+12. For **Use custom page content**, select **YES**.

+13. In **Use custom page content**, paste your custom HTML URI.

+14. (Optional) If you use social identity providers, repeat steps for **Social account sign-up page**.

+ 

+15. From your user flow, go to **Properties**.

+16. Select **Enable JavaScript**.

+Learn more: [Enable JavaScript and page layout versions in Azure Active Directory B2C](./javascript-and-page-layout.md?pivots=b2c-user-flow)

+### Create and deploy your API

+This section assumes you use Visual Studio Code to deploy Azure Functions. You can use the Azure portal, terminal, or command prompt to deploy.

+Go to Visual Studio Marketplace to install [Azure Functions](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azurefunctions) for Visual Studio Code.

+1. In Visual Studio code, in the left navigation, go to the Azure extension.

+2. Select the **Local Project** folder for your local Azure Function.

+3. Press **F5** or select **Debug** > **Start Debugging**. This command uses the debug configuration Azure Function created.

+4. Azure Function generates files for local development, installs dependencies, and the Function Core tools, if needed.

+5. In the Visual Studio Code **Terminal** panel, output from the Function Core tool appears.

+6. When the host starts, select **Alt+click** on the local URL in the output.

+7. The browser opens and runs the function.

+8. In the Azure Functions explorer, right-click the function to see the locally hosted function URL.

+The sample in this section protects the web API endpoint when using HTTP Basic authentication. Learn more on the Internet Engineering Task Force page [RFC 7617: The Basic Authentication](https://tools.ietf.org/html/rfc7617).

+Username and password are stored as environment variables, not part of the repository. Learn more on [Code and test Azure Functions locally, Local settings file](../azure-functions/functions-develop-local.md#local-settings-file).

+1. In your root folder, create a local.settings.json file.

+2. Copy and paste the following code onto the file:

+3. The **BASIC_AUTH_USERNAME** and **BASIC_AUTH_PASSWORD** are the credentials to authenticate the API call to your Azure Function. Select values.

+* <ARKOSE_PRIVATE_KEY> is the server-side secret you generated in the Arkose Labs platform.

+ * It calls the Arkose Labs server-side validation API to validate the value of the `ArkoseSessionToken` generated by the front end.

+ * See, [Server-Side Instructions](https://developer.arkoselabs.com/docs/server-side-instructions-v4).

+* <B2C_EXTENSIONS_APP_ID> is the application ID used by Azure AD B2C to store custom attributes in the directory.

+4. Navigate to App registrations.

+5. Search for b2c-extensions-app.

+6. From the **Overview** pane, copy the Application (client) ID.

+7. Remove the `-` characters.

+ 

+1. Deploy your Azure Function to the cloud. Learn more with [Azure Functions documentation](/azure/azure-functions/).

+2. Copy the endpoint web URL of your Azure Function.

+3. After deployment, select the **Upload settings** option.

+4. Your environment variables are uploaded to the Application settings of the app service. Learn more on [Application settings in Azure](../azure-functions/functions-develop-vs-code.md?tabs=csharp#application-settings-in-azure).

+ >[!NOTE]

+ >You can [manage your function app](../azure-functions/functions-how-to-use-azure-function-app-settings.md). See also, [Deploy project files](../azure-functions/functions-develop-vs-code.md?tabs=csharp#republish-project-files) to learn about Visual Studio Code development for Azure Functions.

+1. Create an API connector. See, [Add an API connector to a sign-up user flow](./add-api-connector.md).

+2. Enable it for your user flow.

+ 

+- **Endpoint URL** - The Function URL you copied while you deployed Azure Function

+- **Username** - The username you defined

+- **Password** - The password you defined

+3. In the **API connector** settings for your user flow, select the API connector to be invoked at **Before creating the user**.

+4. The API validates the `ArkoseSessionToken` value.

+ 

+1. Open the Azure AD B2C tenant.

+2. Under **Policies**, select **User flows**.

+3. Select your created user flow.

+4. Select **Run user flow**.

+5. For **Application** select the registered app (the example is JWT).

+6. For **Reply URL**, select the redirect URL.

+7. Select **Run user flow**.

+8. Perform the sign-up flow.

+9. Create an account.

+10. Sign out.

+11. Perform the sign-in flow.

+12. Select **Continue**.

+13. An Arkose Labs puzzle appears.

+## Resources

+- [Azure-Samples/active-directory-b2c-node-sign-up-user-flow-arkose](https://github.com/Azure-Samples/active-directory-b2c-node-sign-up-user-flow-arkose)

+ - Find the Azure AD B2C sign-up user flow

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

+- [Tutorial: Create user flows and custom policies in Azure Active Directory B2C](./tutorial-create-user-flows.md?pivots=b2c-custom-policy)

+# Tutorial to configure Azure Active Directory B2C with Strata

+In this tutorial, learn how to integrate Azure Active Directory B2C (Azure AD B2C) with Strata [Maverics Identity Orchestrator](https://www.strata.io/maverics-identity-orchestrator/), which helps protect on-premises applications. It connects to identity systems, migrates users and credentials, synchronizes policies and configurations, and abstracts authentication and session management. Use Strata to transition from legacy, to Azure AD B2C, without rewriting applications.

+The solution has the following benefits:

+- **Customer single sign-on (SSO) to on-premises hybrid apps** - Azure AD B2C supports customer SSO with Maverics Identity Orchestrator

+ - Users sign in with accounts hosted in Azure AD B2C or identity provider (IdP)

+ - Maverics proves SSO to apps historically secured by legacy identity systems like Symantec SiteMinder

+- **Extend standards SSO to apps** - Use Azure AD B2C to manage user access and enable SSO with Maverics Identity Orchestrator Security Assertion Markup Language (SAML) or OpenID Connect (OIDC) connectors

+- **Easy configuration** - Connect Maverics Identity Orchestrator SAML or OIDC connectors to Azure AD B2C

+- An Azure AD subscription

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

+- An [Azure AD B2C tenant](./tutorial-create-tenant.md) linked to your Azure subscription

+- An instance of [Azure Key Vault](https://azure.microsoft.com/services/key-vault/) to store secrets used by Maverics Identity Orchestrator. Connect to Azure AD B2C or other attribute providers such as a Lightweight Directory Access Protocol (LDAP) directory or database.

+- An instance of [Maverics Identity Orchestrator](https://www.strata.io/maverics-identity-orchestrator/) running in an Azure virtual machine (VM), or an on-premises server. To get software and documentation, go to strata.io [Contact Strata Identity](https://www.strata.io/contact/).

+- An on-premises application to transition to Azure AD B2C

+Maverics Identity Orchestrator integration includes the following components:

+- **Azure AD B2C** - The authorization server that verifies user credentials

+ - Authenticated users access on-premises apps using a local account in the Azure AD B2C directory

+- **External social or enterprise identity provider (IdP)**: An OIDC provider, Facebook, Google, or GitHub

+ - See, [Add an identity provider to your Azure Active Directory B2C tenant](./add-identity-provider.md)

+- **Strata Maverics Identity Orchestrator**: The user sign-on service that passes identity to apps through HTTP headers

+ 

+1. The user requests access the on-premises hosted application. Maverics Identity Orchestrator proxies the request to the application.

+2. Orchestrator checks the user authentication state. If there's no session token, or the token is invalid, the user goes to Azure AD B2C for authentication

+3. Azure AD B2C sends the authentication request to the configured social IdP.

+4. The IdP challenges the user for credential. Multi-factor authentication (MFA) might be required.

+5. The IdP sends the authentication response to Azure AD B2C. The user can create a local account in the Azure AD B2C directory.

+6. Azure AD B2C sends the user request to the endpoint specified during the Orchestrator app registration in the Azure AD B2C tenant.

+7. The Orchestrator evaluates access policies and attribute values for HTTP headers forwarded to the app. Orchestrator might call to other attribute providers to retrieve information to set the header values. The Orchestrator sends the request to the app.

+8. The user is authenticated and has access to the app.

+## Maverics Identity Orchestrator

+To get software and documentation, go to strata.io [Contact Strata Identity](https://www.strata.io/contact/). Determine Orchestrator prerequisites. Install and configure.

+## Configure your Azure AD B2C tenant

+During the following instructions, document:

+* Tenant name and identifier

+* Client ID

+* Client secret

+* Configured claims

+* Redirect URI

+1. [Register a web application in Azure Active Directory B2C](./tutorial-register-applications.md?tabs=app-reg-ga) in Azure AD B2C tenant.

+2. Grant Microsoft MS Graph API permissions to your applications. Use permissions: `offline_access`, `openid`.

+3. Add a redirect URI that matches the `oauthRedirectURL` parameter of the Orchestrator Azure AD B2C connector configuration, for example, `https://example.com/oidc-endpoint`.

+4. [Create user flows and custom policies in Azure Active Directory B2C](./tutorial-create-user-flows.md).

+5. [Add an identity provider to your Azure Active Directory B2C tenant](./add-identity-provider.md). Sign in your user with a local account, a social, or enterprise.

+6. Define the attributes to be collected during sign-up.

+7. Specify attributes to be returned to the application with your Orchestrator instance.

+> [!NOTE]

+> The Orchestrator consumes attributes from claims returned by Azure AD B2C and can retrieve attributes from connected identity systems such as LDAP directories and databases. Those attributes are in HTTP headers and sent to the upstream on-premises application.

+Use the instructions in the following sections to configure an Orchestrator instance.

+- **Operating System**: REHL 7.7 or higher, CentOS 7+

+- **Disk**: 10 GB (small)

+- **Memory**: 16 GB

+- **Ports**: 22 (SSH/SCP), 443, 80

+- **Root access**: For install/administrative tasks

+- **Maverics Identity Orchestrator**: Runs as user `maverics` under `systemd`

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

+1. Obtain the latest Maverics RPM package.

+2. Place the package on the system you'd like to install Maverics. If you're copying to a remote host, use SSH [scp](https://www.ssh.com/ssh/scp/).

+3. Run the following command. Use your filename to replace `maverics.rpm`.

+ By default, Maverics is in the `/usr/local/bin` directory.

+4. Maverics runs as a service under `systemd`.

+5. To verify Maverics service is running, run the following command:

+6. The following message (or similar) appears.

+> [!NOTE]

+> If Maverics fails to start, execute the following command:

+ The most recent log entry appears in the output.

+7. The default `maverics.yaml` file is created in the `/etc/maverics` directory.

+8. Configure your Orchestrator to protect the application.

+9. Integrate with Azure AD B2C, and store.

+10. Retrieve secrets from [Azure Key Vault](https://azure.microsoft.com/services/key-vault/?OCID=AID2100131_SEM_bf7bdd52c7b91367064882c1ce4d83a9:G:s&ef_id=bf7bdd52c7b91367064882c1ce4d83a9:G:s&msclkid=bf7bdd52c7b91367064882c1ce4d83a9).

+11. Define the location from where the Orchestrator reads its configuration.

+Configure your Orchestrator instances with environment variables.

+This environment variable informs the Orchestrator instance what YAML configuration files to use, and where to find them during startup or restart. Set the environment variable in `/etc/maverics/maverics.env`.

+### Create the Orchestrator TLS configuration

+The `tls` field in `maverics.yaml` declares the transport layer security configurations your Orchestrator instance uses. Connectors use TLS objects and the Orchestrator server.

+The `maverics` key is reserved for the Orchestrator server. Use other keys to inject a TLS object into a connector.

+Orchestrators use Connectors to integrate with authentication and attribute providers. The Orchestrators App Gateway uses the Azure AD B2C connector as an authentication and attribute provider. Azure AD B2C uses the social IdP for authentication and then provides attributes to the Orchestrator, passing them in claims set in HTTP headers.

+The Connector configuration corresponds to the app registered in the Azure AD B2C tenant.

+1. From your app config, copy the Client ID, Client secret, and redirect URI into your tenant.

+2. Enter a Connector name (example is `azureADB2C`).

+3. Set the connector `type` to be `azure`.

+4. Make a note of the Connector name. You'll use this value in other configuration parameters.

+5. Set the `authType` to `oidc`.

+6. For the `oauthClientID` parameter, set the Client ID you copied.

+7. For the `oauthClientSecret` parameter, set the Client secret you copied.

+8. For the `oauthRedirectURL` parameter, set the redirect URI you copied.

+9. The Azure AD B2C OIDC Connector uses the OIDC endpoint to discover metadata, including URLs and signing keys. For the tenant endpoint, use `oidcWellKnownURL`.

+An authentication provider determines authentication for users who don't present a valid session during an app resource request. Azure AD B2C tenant configuration determines how users are challenged for credentials, while it applies other authentication policies. An example is to require a second factor to complete authentication and decide what is returned to the Orchestrator App Gateway, after authentication.

+The value for the `authProvider` must match your Connector `name` value.

+### Protect on-premises apps with an Orchestrator App Gateway

+The Orchestrator App Gateway configuration declares how Azure AD B2C protects your application and how users access the app.

+1. Enter an App gateway name.

+2. Set the `location`. The example uses the app root `/`.

+3. Define the protected application in `upstream`. Use the host:port convention: `https://example.com:8080`.

+5. Define the HTTP header names and attribute values for the application to establish authentication and control. Header names typically correspond to app configuration. Attribute values are namespaced by the Connector. In the example, values returned from Azure AD B2C are prefixed with the Connector name `azureADB2C`. The suffix is the attribute name with the required value, for example `given_name`.

+6. Set the policies. Three actions are defined: `allowUnauthenticated`, `allowAnyAuthenticated`, and `allowIfAny`. Each action is associated with a `resource`. Policy is evaluated for that `resource`.

+>`headers` and `policies` use JavaScript or GoLang service extensions to implement arbitrary logic.

+### Azure Key Vault as secrets provider

+Secure the secrets your Orchestrator uses to connect to Azure AD B2C, and other identity systems. Maverics load secrets in plain text out of `maverics.yaml`, however, in this tutorial, use Azure Key Vault as the secrets provider.

+Follow the instructions in, [Quickstart: Set and retrieve a secret from Azure Key Vault using the Azure portal](../key-vault/secrets/quick-create-portal.md). Add your secrets to the vault and make a note of the `SECRET NAME` for each secret. For example, `AzureADB2CClientSecret`.

+The value in the angle brackets must correspond to the `SECRET NAME` given to a secret in your Azure Key Vault.

+To load secrets from Azure Key Vault, set the environment variable `MAVERICS_SECRET_PROVIDER` in the file `/etc/maverics/maverics.env`, with the credentials found in the azure-credentials.json file. Use the following pattern:

+### Complete the configuration

+The following information illustrates how Orchestrator configuration appears.

+2. The Orchestrator redirects to the user flow page.

+3. From the list, select the IdP.

+4. Enter credentials, including an MFA token, if required by the IdP.

+5. You're redirected to Azure AD B2C, which forwards the app request to the Orchestrator redirect URI.

+6. The Orchestrator evaluates policies, and calculates headers.

+7. The requested application appears.

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

+- [Tutorial: Create user flows and custom policies in Azure Active Directory B2C](tutorial-create-user-flows.md?pivots=b2c-custom-policy)

+# Tutorial to configure Azure Active Directory B2C with WhoIAM

+In this tutorial, learn how to configure WhoIAM Branded Identity Management System (BRIMS) in your environment and integrate it with Azure Active Directory B2C (Azure AD B2C). The BRIMS apps and services are deployed in your environment. They provide user verification with voice, SMS, and email. BRIMS works with your identity and access management solution and is platform-agnostic.

+Learn more: [WhoIAM, Products and Services, Branded Identity Management System](https://www.whoiam.ai/brims/)

+- An Azure AD subscription

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

+- [An Azure AD B2C tenant](./tutorial-create-tenant.md) linked to your Azure subscription

+- A WhoIAM trial account

+ - Go to [WhoIAM, Contact us](https://www.whoiam.ai/contact-us/) to get started

+- **Azure AD B2C tenant** - The authorization server that verifies user credentials, based on custom policies, know as the identity provider (IdP)

+- **Administration portal** - To manage clients and their configurations

+- **API service** - To expose various features through endpoints

+- **Azure Cosmos DB** - The back end for the BRIMS administration portal and API service

+The following diagram shows the implementation architecture.

+ 

+1. The user signs up or signs in to request an app that uses Azure AD B2C as IdP

+2. The user requests ownership verification of their email, phone, or they use voice as biometric verification

+3. Azure AD B2C calls to the BRIMS API service and passes the user attributes

+4. BRIMS interacts with the user in their own language

+5. After verification, BRIMS returns a token to Azure AD B2C, which grants access, or doesn't.

+2. Configure the following Azure

+ * [Key Vault](https://azure.microsoft.com/services/key-vault/): Store passwords

+ * [App Service](https://azure.microsoft.com/services/app-service/): Host the BRIMS API and admin portal services

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

+ * [Azure Cosmos DB](https://azure.microsoft.com/services/cosmos-db/): Store and retrieve settings

+ * [Application Insights overview](../azure-monitor/app/app-insights-overview.md) (optional): Sign in to the API and the portal

+4. Follow the documentation to configure your app. Use BRIMS for user identity verification. Azure AD B2C custom policy samples are in the BRIMS sign-up documentation.

+For more information about WhoIAM BRIMS, request documentation on [WhoIAM, Contact Us](https://www.whoiam.ai/brims/).

+1. Open the Azure AD B2C tenant.

+2. Under **Policies**, select **Identity Experience Framework**.

+3. Select the created **SignUpSignIn**.

+4. Select **Run user flow**.

+5. For **Application**, select the registered app (example is JWT).

+6. For **Reply URL**, select the **redirect URL**.

+7. Select **Run user flow**.

+8. Complete the sign-up flow

+9. Create an account.

+10. After the user attribute is created, the BRIMS service is called.

+> [!TIP]

+> If the flow is incomplete, confirm the user is saved in the directory.

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

+- [Tutorial: Create user flows and custom policies in Azure Active Directory B2C](tutorial-create-user-flows.md?pivots=b2c-custom-policy)

+ Title: Tutorial - Configure Zscaler Private access with Azure Active Directory B2C

+In this tutorial, learn how to integrate Azure Active Directory B2C (Azure AD B2C) authentication with Zscaler Private Access (ZPA). ZPA is policy-based, secure access to private applications and assets without the overhead or security risks of a virtual private network (VPN). Zscaler secure hybrid access reduces attack surface for consumer-facing applications when combined with Azure AD B2C.

+Learn more: Go to [Zscaler](https://www.zscaler.com/products/zscaler-private-access) and select Products & Solutions, Products.

+- An Azure subscription

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

+- [An Azure AD B2C tenant](./tutorial-create-tenant.md) linked to your Azure subscription

+- A ZPA subscription

+ - Go to [Azure Marketplace, Zscaler Private Access](https://azuremarketplace.microsoft.com/marketplace/apps/aad.zscalerprivateaccess?tab=Overview)

+- **Azure AD B2C** - The identity provider (IdP) that verifies user credentials

+- **ZPA** - Secures web applications by enforcing Zero Trust access

+ - See, [Zero Trust defined](https://www.microsoft.com/security/blog/2018/12/17/zero-trust-part-1-identity-and-access-management/#:~:text=Azure%20Active%20Directory%20%28Azure%20AD%29%20provides%20the%20strong%2C,to%20express%20their%20access%20requirements%20in%20simple%20terms)

+- **Web application** - Hosts the service users access

+ 

+1. A user arrives at the ZPA portal, or a ZPA browser-access application, to request access

+2. ZPA collects user attributes. ZPA performs a SAML redirect to the Azure AD B2C sign-in page.

+3. New users sign up and create an account. Current users sign in with credentials. Azure AD B2C validates user identity.

+4. Azure AD B2C redirects the user to ZPA with the SAML assertion, which ZPA verifies. ZPA sets the user context.

+5. ZPA evaluates access policies. The request is allowed or it isn't.

+This tutorial assumes ZPA is installed and running.

+To get started with ZPA, go to help.zscaler.com for [Step-by-Step Configuration Guide for ZPA](https://help.zscaler.com/zpa/step-step-configuration-guide-zpa).

+## Integrate ZPA with Azure AD B2C

+### Configure Azure AD B2C as an IdP on ZPA

+Configure Azure AD B2C as an IdP on ZPA.

+For more information, see [Configuring an IdP for single sign-on](https://help.zscaler.com/zpa/configuring-idp-single-sign).

+1. Sign in to the [ZPA Admin portal](https://admin.private.zscaler.com).

+2. Go to **Administration** > **IdP Configuration**.

+3. Select **Add IdP Configuration**.

+4. The **Add IdP Configuration** pane appears.

+ 

+5. Select the **IdP Information** tab

+6. In the **Name** box, enter **Azure AD B2C**.

+7. Under **Single Sign-On**, select **User**.

+8. In the **Domains** drop-down list, select the authentication domains to associate with the IdP.

+9. Select **Next**.

+10. Select the **SP Metadata** tab.

+11. Under **Service Provider URL**, copy the value to use later.

+12. Under **Service Provider Entity ID**, copy the value to user later.

+ 

+13. Select **Pause**.

+### Configure custom policies in Azure AD B2C

+>[!IMPORTANT]

+>Configure custom policies in Azure AD B2C if you havenΓÇÖt configured custom policies.

+For more information, see [Tutorial: Create user flows and custom policies in Azure Active Directory B2C](./tutorial-create-user-flows.md?pivots=b2c-custom-policy).

+### Register ZPA as a SAML application in Azure AD B2C

+1. [Register a SAML application in Azure AD B2C](./saml-service-provider.md).

+2. During registration, in **Upload your policy**, copy the IdP SAML metadata URL used by Azure AD B2C to use later.

+3. Follow the instructions until **Configure your application in Azure AD B2C**.

+4. For step 4.2, update the app manifest properties

+ * For **identifierUris**, enter the Service Provider Entity ID you copied

+ * For **samlMetadataUrl**, skip this entry

+ * For **replyUrlsWithType**, enter the Service Provider URL you copied

+ * For **logoutUrl**, skip this entry

+The remaining steps aren't required.

+### Extract the IdP SAML metadata from Azure AD B2C

+1. Obtain a SAML metadata URL in the following format:

+ `https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/Samlp/metadata`

+> [!NOTE]

+> `<tenant-name>` is your Azure AD B2C tenant, and `<policy-name>` is the custom SAML policy that you created.

+> The URL might be:

+> `https://safemarch.b2clogin.com/safemarch.onmicrosoft.com/B2C_1A_signup_signin_saml/Samlp/metadata`.

+2. Open a web browser.

+3. Go to the SAML metadata URL.

+4. Right-click on the page.

+5. Select **Save as**.

+6. Save the file to your computer to use later.

+### Complete IdP configuration on ZPA

+To complete the IdP configuration:

+1. Go to the [ZPA Admin portal](https://admin.private.zscaler.com).

+2. Select **Administration** > **IdP Configuration**.

+3. Select the IdP you configured, and then select **Resume**.

+4. On the **Add IdP Configuration** pane, select the **Create IdP** tab.

+5. Under **IdP Metadata File**, upload the metadata file you saved.

+6. Under **Status**, verify the configuration is **Enabled**.

+7. Select **Save**.

+ 

+To confirm SAML authentication, go to a ZPA user portal or a browser-access application, and test the sign-up or sign-in process.

+- [Tutorial: Create user flows and custom policies in Azure Active Directory B2C](./tutorial-create-user-flows.md?pivots=b2c-custom-policy)

+- [Step-by-Step Configuration Guide for ZPA](https://help.zscaler.com/zpa/step-step-configuration-guide-zpa)

+- [Configuring an IdP for single sign-on](https://help.zscaler.com/zpa/configuring-idp-single-sign)

+https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/your-policy/samlp/metadata?idptp=your-technical-profile

+You're now ready to add the inbound policy in Azure API Management that validates API calls. By adding a [JSON web token (JWT) validation](../api-management/validate-jwt-policy.md) policy that verifies the audience and issuer in an access token, you can ensure that only API calls with a valid token are accepted.

+## December 2022

+### New articles

+- [Build a global identity solution with funnel-based approach](azure-ad-b2c-global-identity-funnel-based-design.md)

+- [Azure Active Directory B2C global identity framework proof of concept for funnel-based configuration](azure-ad-b2c-global-identity-proof-of-concept-funnel.md)

+- [Azure Active Directory B2C global identity framework proof of concept for region-based configuration](azure-ad-b2c-global-identity-proof-of-concept-regional.md)

+- [Build a global identity solution with region-based approach](azure-ad-b2c-global-identity-region-based-design.md)

+- [Azure Active Directory B2C global identity framework](azure-ad-b2c-global-identity-solutions.md)

+### Updated articles

+- [Set up a resource owner password credentials flow in Azure Active Directory B2C](add-ropc-policy.md)

+- [Use API connectors to customize and extend sign-up user flows and custom policies with external identity data sources](api-connectors-overview.md)

+- [Azure Active Directory B2C: Region availability & data residency](data-residency.md)

+- [Tutorial: Configure Experian with Azure Active Directory B2C](partner-experian.md)

+- [Tutorial: Configure Microsoft Dynamics 365 Fraud Protection with Azure Active Directory B2C](partner-dynamics-365-fraud-protection.md)

+- [Tutorial: Configure Azure Active Directory B2C with Datawiza to provide secure hybrid access](partner-datawiza.md)

+- [Configure TheAccessHub Admin Tool with Azure Active Directory B2C](partner-n8identity.md)

+- [Tutorial: Configure Cloudflare Web Application Firewall with Azure Active Directory B2C](partner-cloudflare.md)

+- [Set up a password reset flow in Azure Active Directory B2C](add-password-reset-policy.md)

+- [What is Azure Active Directory B2C?](overview.md)

+- [Technical and feature overview of Azure Active Directory B2C](technical-overview.md)

+- [Register a single-page application (SPA) in Azure Active Directory B2C](tutorial-register-spa.md)

+- LDAP signing

+- LDAP channel binding

+ - **TLS 1.2 Only Mode**

+ - **NTLM v1 Authentication**

+ - **NTLM Password Synchronization**

+ - **Kerberos RC4 Encryption**

+ - **Kerberos Armoring**

+ - **LDAP Signing**

+ - **LDAP Channel Binding**

+> After you create a managed domain, you can't move it to a different subscription, resource group, or region. Take care to select the most appropriate subscription, resource group, and region when you deploy the managed domain.

+> You can't move the managed domain to a different subscription, resource group, or region after you create it. Take care to select the most appropriate subscription, resource group, and region when you deploy the managed domain.

+>[!NOTE]

+>After all authentication methods are fully migrated, the following elements of the legacy SSPR policy remain active:

+> - The **Number of methods required to reset** control: admins can continue to change how many authentication methods must be verified before a user can perform SSPR.

+> - The SSPR administrator policy: admins can continue to register and use any methods listed under the legacy SSPR administrator policy or methods they're enabled to use in the Authentication methods policy.

+>

+> In the future, both of these features will be integrated with the Authentication methods policy.

+| Crayonic | ![y] | ![n]| ![y]| ![y]| ![n] | https://www.crayonic.com/keyvault |

+| Identiv | ![n] | ![y]| ![y]| ![n]| ![n] | https://www.identiv.com/products/logical-access-control/utrust-fido2-security-keys/nfc |

+| Movenda | ![y] | ![n]| ![y]| ![y]| ![n] | https://www.movenda.com/en/authentication/fido2/overview |

+| Lifecycle Workflows (preview) | | | | | ΓùÅ |

+If you're using Remote Desktop Gateway and the user is registered for OTP code along with Microsoft Authenticator push notifications, the user won't be able to meet the Azure AD MFA challenge and Remote Desktop Gateway sign-in will fail. In this case, you can set OVERRIDE_NUMBER_MATCHING_WITH_TOP = FALSE to fall back to push notifications with Microsoft Authenticator.

+Yes, currently you can disable number matching. We highly recommend that you enable number matching for all users in your tenant to protect yourself from MFA fatigue attacks. To protect the ecosystem and mitigate these threats, Microsoft will enable number matching for all tenants starting February 27, 2023. After protection is enabled by default, users can't opt out of number matching in Microsoft Authenticator push notifications.

+**Why donΓÇÖt some users see a nudge when there is a conditional access policy for "Register security information"?**

+A nudge won't appear if a user is in scope for a conditional access policy that blocks access to the **Register security information** page.

+| SSPR_0029: We are unable to reset your password due to an error in your on-premises configuration. Please contact your admin and ask them to investigate. | Problem: Password writeback has been enabled following all of the required steps, but when attempting to change a password you receive "SSPR_0029: Your organization hasnΓÇÖt properly set up the on-premises configuration for password reset." Checking the event logs on the Azure AD Connect system shows that the management agent credential was denied access.Possible Solution: Use RSOP on the Azure AD Connect system and your domain controllers to see if the policy "Network access: Restrict clients allowed to make remote calls to SAM" found under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options is enabled. Edit the policy to include the MSOL_XXXXXXX management account as an allowed user. For more information, see [Troubleshoot error SSPR_0029: Your organization hasn't properly set up the on-premises configuration for password reset](/troubleshoot/azure/active-directory/password-writeback-error-code-sspr-0029).|

+ 1. Select **Grant access**, **Require multifactor authentication** and **Require password change**.

+Sign in logs contain information on Success as well as failure events. Use filters to narrow your search. For example, if a user signed in to Teams, use the Application filter and set it to Teams. Admins may need to check the sign-ins from both interactive and non-interactive tabs to locate the specific sign-in. To further narrow the search, admins may apply multiple filters.

+The first time the user is required to share their location from the Microsoft Authenticator app, the user will receive a notification in the app. The user will need to open the app and grant location permissions.

+Every hour the user is accessing resources covered by the policy they will need to approve a push notification from the app.

+Conditional Access policies have historically applied only to users when they access apps and services like SharePoint online or the Azure portal. We're now extending support for Conditional Access policies to be applied to service principals owned by the organization. We call this capability Conditional Access for workload identities.

+> Workload Identities Premium licenses are required to create or modify Conditional Access policies scoped to service principals.

+> In directories without appropriate licenses, Conditional Access policies created prior to the release of Workload Identities Premium will be available for deletion only.

+For more information, see [Primary Refresh Tokens](../devices/concept-primary-refresh-token.md).

+When creating a claims-mapping policy, you can also emit a claim from a directory extension attribute in tokens. Use _ExtensionID_ for the extension attribute instead of _ID_ in the `ClaimsSchema` element. For more information about using extension attributes, see [Using directory extension attributes](active-directory-schema-extensions.md).

+ Title: Customize app JSON Web Token (JWT) claims (Preview)

+description: Learn how to customize the claims issued by Microsoft identity platform in the JSON web token (JWT) token for enterprise applications.

+# Customize claims issued in the JSON web token (JWT) for enterprise applications (Preview)

+The Microsoft identity platform supports single sign-on (SSO) with most enterprise applications, including both applications pre-integrated in the Azure AD app gallery and custom applications. When a user authenticates to an application through the Microsoft identity platform using the OIDC protocol, the Microsoft identity platform sends a token to the application. And then, the application validates and uses the token to log the user in instead of prompting for a username and password.

+These JSON Web tokens (JWT) used by OIDC & OAuth applications (preview) contain pieces of information about the user known as *claims*. A *claim* is information that an identity provider states about a user inside the token they issue for that user.

+In an [OIDC response](v2-protocols-oidc.md), *claims* data is typically contained in the ID Token issued by the identity provider in the form of a JWT.

+## View or edit claims

+Besides [optional claims](active-directory-optional-claims.md), you can view, create or edit the attributes and claims issued in the OIDC token to the application. To edit claims, open the application in Azure portal through the Enterprise Applications experience. Then select **Single sign-on** blade in the left-hand menu and open the **Attributes & Claims** section.

+Claims customization may be required for various reasons by an application. A good example is when an application has been written to require a different set of claim URIs or claim values. Using the **Attributes & Claims** section you can add or remove a claim for your application. You can also create a custom claim that is specific for an application based on the use case.

+You can also assign any constant (static) value to any claims, which you define in Azure AD. The following steps outline how to assign a constant value:

+1. In the [Azure portal](https://portal.azure.com/), on the **Attributes & Claims** section, Select **Edit** to edit the claims.

+1. Select the required claim that you want to modify.

+1. Enter the constant value without quotes in the **Source attribute** as per your organization, and then select **Save**.

+The constant value is displayed on the Attributes overview.

+## Special claims transformations

+You can use the following special claims transformations functions.

+| Function | Description |

+|-|-|

+| **ExtractMailPrefix()** | Removes the domain suffix from either the email address or the user principal name. This function extracts only the first part of the user name being passed through (for example, "joe_smith" instead of joe_smith@contoso.com). |

+| **ToLower()** | Converts the characters of the selected attribute into lowercase characters. |

+| **ToUpper()** | Converts the characters of the selected attribute into uppercase characters. |

+## Add application-specific claims

+To add application-specific claims:

+1. In **User Attributes & Claims**, select **Add new claim** to open the **Manage user claims** page.

+1. Enter the **name** of the claims. The value doesn't strictly need to follow a URI pattern. If you need a URI pattern, you can put that in the **Namespace** field.

+1. Select the **Source** where the claim is going to retrieve its value. You can select a user attribute from the source attribute dropdown or apply a transformation to the user attribute before emitting it as a claim.

+### Claim transformations

+To apply a transformation to a user attribute:

+1. In **Manage claim**, select *Transformation* as the claim source to open the **Manage transformation** page.

+1. Select the function from the transformation dropdown. Depending on the function selected, you'll have to provide parameters and a constant value to evaluate in the transformation. Refer to the following table for more information about the available functions.

+1. **Treat source as multivalued** is a checkbox indicating whether the transform should be applied to all values or just the first. By default, transformations are only applied to the first element in a multi-value claim, by checking this box it ensures it's applied to all. This checkbox is only be enabled for multi-valued attributes, for example `user.proxyaddresses`.

+1. To apply multiple transformations, select **Add transformation**. You can apply a maximum of two transformations to a claim. For example, you could first extract the email prefix of the `user.mail`. Then, make the string upper case.

+ :::image type="content" source="./media/active-directory-jwt-claims-customization/sso-saml-multiple-claims-transformation.png" alt-text="Screenshot of claims transformation.":::

+You can use the following functions to transform claims.

+| Function | Description |

+|-|-|

+| **ExtractMailPrefix()** | Removes the domain suffix from either the email address or the user principal name. This function extracts only the first part of the user name being passed through (for example, "joe_smith" instead of joe_smith@contoso.com). |

+| **Join()** | Creates a new value by joining two attributes. Optionally, you can use a separator between the two attributes. For NameID claim transformation, the Join() function has specific behavior when the transformation input has a domain part. It removes the domain part from input before joining it with the separator and the selected parameter. For example, if the input of the transformation is 'joe_smith@contoso.com' and the separator is '@' and the parameter is 'fabrikam.com', this input combination results in 'joe_smith@fabrikam.com'. |

+| **ToLowercase()** | Converts the characters of the selected attribute into lowercase characters. |

+| **ToUppercase()** | Converts the characters of the selected attribute into uppercase characters. |

+| **Contains()** | Outputs an attribute or constant if the input matches the specified value. Otherwise, you can specify another output if there's no match. <br/>For example, if you want to emit a claim where the value is the user's email address if it contains the domain "@contoso.com", otherwise you want to output the user principal name. To perform this function, you configure the following values:<br/>*Parameter 1(input)*: user.email<br/>*Value*: "@contoso.com"<br/>Parameter 2 (output): user.email<br/>Parameter 3 (output if there's no match): user.userprincipalname |

+| **EndWith()** | Outputs an attribute or constant if the input ends with the specified value. Otherwise, you can specify another output if there's no match.<br/>For example, if you want to emit a claim where the value is the user's employee ID if the employee ID ends with "000", otherwise you want to output an extension attribute. To perform this function, you configure the following values:<br/>*Parameter 1(input)*: user.employeeid<br/>*Value*: "000"<br/>Parameter 2 (output): user.employeeid<br/>Parameter 3 (output if there's no match): user.extensionattribute1 |

+| **StartWith()** | Outputs an attribute or constant if the input starts with the specified value. Otherwise, you can specify another output if there's no match.<br/>For example, if you want to emit a claim where the value is the user's employee ID if the country/region starts with "US", otherwise you want to output an extension attribute. To perform this function, you configure the following values:<br/>*Parameter 1(input)*: user.country<br/>*Value*: "US"<br/>Parameter 2 (output): user.employeeid<br/>Parameter 3 (output if there's no match): user.extensionattribute1 |

+| **Extract() - After matching** | Returns the substring after it matches the specified value.<br/>For example, if the input's value is "Finance_BSimon", the matching value is "Finance_", then the claim's output is "BSimon". |

+| **Extract() - Before matching** | Returns the substring until it matches the specified value.<br/>For example, if the input's value is "BSimon_US", the matching value is "_US", then the claim's output is "BSimon". |

+| **Extract() - Between matching** | Returns the substring until it matches the specified value.<br/>For example, if the input's value is "Finance_BSimon_US", the first matching value is "Finance\_", the second matching value is "\_US", then the claim's output is "BSimon". |

+| **ExtractAlpha() - Prefix** | Returns the prefix alphabetical part of the string.<br/>For example, if the input's value is "BSimon_123", then it returns "BSimon". |

+| **ExtractAlpha() - Suffix** | Returns the suffix alphabetical part of the string.<br/>For example, if the input's value is "123_Simon", then it returns "Simon". |

+| **ExtractNumeric() - Prefix** | Returns the prefix numerical part of the string.<br/>For example, if the input's value is "123_BSimon", then it returns "123". |

+| **ExtractNumeric() - Suffix** | Returns the suffix numerical part of the string.<br/>For example, if the input's value is "BSimon_123", then it returns "123". |

+| **IfEmpty()** | Outputs an attribute or constant if the input is null or empty.<br/>For example, if you want to output an attribute stored in an extensionattribute if the employee ID for a given user is empty. To perform this function, you configure the following values:<br/>Parameter 1(input): user.employeeid<br/>Parameter 2 (output): user.extensionattribute1<br/>Parameter 3 (output if there's no match): user.employeeid |

+| **IfNotEmpty()** | Outputs an attribute or constant if the input isn't null or empty.<br/>For example, if you want to output an attribute stored in an extensionattribute if the employee ID for a given user isn't empty. To perform this function, you configure the following values:<br/>Parameter 1(input): user.employeeid<br/>Parameter 2 (output): user.extensionattribute1 |

+| **Substring() - Fixed Length** (Preview)| Extracts parts of a string claim type, beginning at the character at the specified position, and returns the specified number of characters.<br/>SourceClaim - The claim source of the transform that should be executed.<br/>StartIndex - The zero-based starting character position of a substring in this instance.<br/>Length - The length in characters of the substring.<br/>For example:<br/>sourceClaim - PleaseExtractThisNow<br/>StartIndex - 6<br/>Length - 11<br/>Output: ExtractThis |

+| **Substring() - EndOfString** (Preview) | Extracts parts of a string claim type, beginning at the character at the specified position, and returns the rest of the claim from the specified start index. <br/>SourceClaim - The claim source of the transform that should be executed.<br/>StartIndex - The zero-based starting character position of a substring in this instance.<br/>For example:<br/>sourceClaim - PleaseExtractThisNow<br/>StartIndex - 6<br/>Output: ExtractThisNow |

+| **RegexReplace()** (Preview) | RegexReplace() transformation accepts as input parameters:<br/>- Parameter 1: a user attribute as regex input<br/>- An option to trust the source as multivalued<br/>- Regex pattern<br/>- Replacement pattern. The replacement pattern may contain static text format along with a reference that points to regex output groups and more input parameters.<br/><br/>More instructions about how to use the RegexReplace() transformation are described later in this article. |

+If you need other transformations, submit your idea in the [feedback forum in Azure AD](https://feedback.azure.com/d365community/forum/22920db1-ad25-ec11-b6e6-000d3a4f0789) under the *SaaS application* category.

+## Regex-based claims transformation

+The following image shows an example of the first level of transformation:

+The following table provides information about the first level of transformations. The actions listed in the table correspond to the labels in the previous image. Select **Edit** to open the claims transformation blade.

+| Action | Field | Description |

+| :-- | :- | :- |

+| 1 | Transformation | Select the **RegexReplace()** option from the **Transformation** options to use the regex-based claims transformation method for claims transformation. |

+| 2 | Parameter 1 | The input for the regular expression transformation. For example, user.mail that has a user email address such as `admin@fabrikam.com`. |

+| 3 | Treat source as multivalued | Some input user attributes can be multi-value user attributes. If the selected user attribute supports multiple values and the user wants to use multiple values for the transformation, they need to select **Treat source as multivalued**. If selected, all values are used for the regex match, otherwise only the first value is used. |

+| 4 | Regex pattern | A regular expression that is evaluated against the value of user attribute selected as *Parameter 1*. For example a regular expression to extract the user alias from the user's email address would be represented as `(?'domain'^.*?)(?i)(\@fabrikam\.com)$`. |

+| 5 | Add additional parameter | More than one user attribute can be used for the transformation. The values of the attributes would then be merged with regex transformation output. Up to five additional parameters are supported. |

+| 6 | Replacement pattern | The replacement pattern is the text template, which contains placeholders for regex outcome. All group names must be wrapped inside the curly braces such as {group-name}. Let's say the administration wants to use user alias with some other domain name, for example `xyz.com` and merge country name with it. In this case, the replacement pattern would be `{country}.{domain}@xyz.com`, where `{country}` is the value of input parameter and `{domain}` is the group output from the regular expression evaluation. In such a case, the expected outcome is `US.swmal@xyz.com`. |

+The following image shows an example of the second level of transformation:

+The following table provides information about the second level of transformations. The actions listed in the table correspond to the labels in the previous image.

+| Action | Field | Description |

+| :-- | :- | :- |

+| 1 | Transformation | Regex-based claims transformations aren't limited to the first transformation and can be used as the second level transformation as well. Any other transformation method can be used as the first transformation. |

+| 2 | Parameter 1 | If **RegexReplace()** is selected as a second level transformation, output of first level transformation is used as an input for the second level transformation. The second level regex expression should match the output of the first transformation or the transformation won't be applied. |

+| 3 | Regex pattern | **Regex pattern** is the regular expression for the second level transformation. |

+| 4 | Parameter input | User attribute inputs for the second level transformations. |

+| 5 | Parameter input | Administrators can delete the selected input parameter if they don't need it anymore. |

+| 6 | Replacement pattern | The replacement pattern is the text template, which contains placeholders for regex outcome group name, input parameter group name, and static text value. All group names must be wrapped inside the curly braces such as `{group-name}`. Let's say the administration wants to use user alias with some other domain name, for example `xyz.com` and merge country name with it. In this case, the replacement pattern would be `{country}.{domain}@xyz.com`, where `{country}` is the value of input parameter and `{domain}` is the group output from the regular expression evaluation. In such a case, the expected outcome is `US.swmal@xyz.com`. |

+| 7 | Test transformation | The RegexReplace() transformation is evaluated only if the value of the selected user attribute for *Parameter 1* matches with the regular expression provided in the **Regex pattern** textbox. If they don't match, the default claim value is added to the token. To validate regular expression against the input parameter value, a test experience is available within the transform blade. This test experience operates on dummy values only. When additional input parameters are used, the name of the parameter is added to the test result instead of the actual value. To access the test section, select **Test transformation**. |

+The following image shows an example of testing the transformations:

+The following table provides information about testing the transformations. The actions listed in the table correspond to the labels in the previous image.

+| Action | Field | Description |

+| :-- | :- | :- |

+| 1 | Test transformation | Select the close or (X) button to hide the test section and re-render the **Test transformation** button again on the blade. |

+| 2 | Test regex input | Accepts input that is used for the regular expression test evaluation. In case regex-based claims transformation is configured as a second level transformation, a value is provided that would be the expected output of the first transformation. |

+| 3 | Run test | After the test regex input is provided and the **Regex pattern**, **Replacement pattern** and **Input parameters** are configured, the expression can be evaluated by selecting **Run test**. |

+| 4 | Test transformation result | If evaluation succeeds, an output of test transformation will be rendered against the **Test transformation result** label. |

+| 5 | Remove transformation | The second level transformation can be removed by selecting **Remove transformation**. |

+| 6 | Specify output if no match | When a regex input value is configured against the *Parameter 1* that doesn't match the **Regular expression**, the transformation is skipped. In such cases, the alternate user attribute can be configured, which is added to the token for the claim by checking **Specify output if no match**. |

+| 7 | Parameter 3 | If an alternate user attribute needs to be returned when there's no match and **Specify output if no match** is checked, an alternate user attribute can be selected using the dropdown. This dropdown is available against **Parameter 3 (output if no match)**. |

+| 8 | Summary | At the bottom of the blade, a full summary of the format is displayed that explains the meaning of the transformation in simple text. |

+| 9 | Add | After the configuration settings for the transformation are verified, it can be saved to a claims policy by selecting **Add**. Changes won't be saved unless **Save** is selected on the **Manage Claim** blade. |

+RegexReplace() transformation is also available for the group claims transformations.

+### Transformation validations

+When the following conditions occur after **Add** or **Run test** is selected, a message is displayed that provides more information about the issue:

+* Input parameters with duplicate user attributes aren't allowed.

+* Unused input parameters found. Defined input parameters should have respective usage into the Replacement pattern text.

+* The provided test regex input doesn't match with the provided regular expression.

+* The source for the groups into the replacement pattern isn't found.

+## Emit claims based on conditions

+You can specify the source of a claim based on user type and the group to which the user belongs.

+The user type can be:

+* **Any** - All users are allowed to access the application.

+* **Members**: Native member of the tenant

+* **All guests**: User is brought over from an external organization with or without Azure AD.

+* **AAD guests**: Guest user belongs to another organization using Azure AD.

+* **External guests**: Guest user belongs to an external organization that doesn't have Azure AD.

+One scenario where the user type is helpful is when the source of a claim is different for a guest and an employee accessing an application. You can specify that if the user is an employee, the NameID is sourced from user.email. If the user is a guest, then the NameID is sourced from user.extensionattribute1.

+To add a claim condition:

+1. In **Manage claim**, expand the Claim conditions.

+1. Select the user type.

+1. Select the group(s) to which the user should belong. You can select up to 50 unique groups across all claims for a given application.

+1. Select the **Source** where the claim is going to retrieve its value. You can select a user attribute from the source attribute dropdown or apply a transformation to the user attribute before emitting it as a claim.

+The order in which you add the conditions are important. Azure AD first evaluates all conditions with source `Attribute` and then evaluates all conditions with source `Transformation` to decide which value to emit in the claim. Conditions with the same source are evaluated from top to bottom. The last value, which matches the expression is emitted in the claim. Transformations such as `IsNotEmpty` and `Contains` act like restrictions.

+For example, Britta Simon is a guest user in the Contoso tenant. Britta belongs to another organization that also uses Azure AD. Given the following configuration for the Fabrikam application, when Britta tries to sign in to Fabrikam, the Microsoft identity platform evaluates the conditions.

+First, the Microsoft identity platform verifies whether Britta's user type is **All guests**. Because this is true, the Microsoft identity platform assigns the source for the claim to `user.extensionattribute1`. Second, the Microsoft identity platform verifies whether Britta's user type is **AAD guests**, because this is also true, the Microsoft identity platform assigns the source for the claim to `user.mail`. Finally, the claim is emitted with a value of `user.mail` for Britta.

+As another example, consider when Britta Simon tries to sign in and the following configuration is used. Azure AD first evaluates all conditions with source `Attribute`. Because Britta's user type is **AAD guests**, `user.mail` is assigned as the source for the claim. Next, Azure AD evaluates the transformations. Because Britta is a guest, `user.extensionattribute1` is now the new source for the claim. Because Britta is in **AAD guests**, `user.othermail` is now the source for this claim. Finally, the claim is emitted with a value of `user.othermail` for Britta.

+As a final example, consider what happens if Britta has no `user.othermail` configured or it's empty. In both cases the condition entry is ignored, and the claim falls back to `user.extensionattribute1` instead.

+## Advanced claims options

+Advanced claims options can be configured for OIDC applications to expose the same claim as SAML tokens and vice versa for applications that intend to use the same claim for both SAML2.0 and OIDC response tokens.

+Advanced claim options can be configured by checking the box under **Advanced Claims Options** in the **Manage claims** blade.

+## Next steps

+* [Configure single sign-on on applications that aren't in the Azure AD application gallery](../manage-apps/configure-saml-single-sign-on.md)

+3) Emit group names in the format of samAccountName for on-premises synced groups and display name for cloud groups in SAML and OIDC ID Tokens for the groups assigned to the application:

+ Title: Customize SAML token claims

+The Microsoft identity platform supports single sign-on (SSO) with most enterprise applications, including both applications pre-integrated in the Azure Active Directory (Azure AD) application gallery and custom applications. When a user authenticates to an application through the Microsoft identity platform using the SAML 2.0 protocol, the Microsoft identity platform sends a token to the application. And then, the application validates and uses the token to log the user in instead of prompting for a username and password.

+These SAML tokens contain pieces of information about the user known as *claims*. A *claim* is information that an identity provider states about a user inside the token they issue for that user. In a [SAML token](https://en.wikipedia.org/wiki/SAML_2.0), *claims* data is typically contained in the SAML Attribute Statement. The user's unique ID is typically represented in the SAML Subject also referred to as the name identifier (nameID).

+By default, the Microsoft identity platform issues a SAML token to an application that contains a `NameIdentifier` claim with a value of the user's username (also known as the user principal name) in Azure AD, which can uniquely identify the user. The SAML token also contains other claims that include the user's email address, first name, and last name.

+## View or edit claims

+To view or edit the claims issued in the SAML token to the application, open the application in Azure portal. Then open the **Attributes & Claims** section.

+## Edit nameID

+ :::image type="content" source="./media/active-directory-saml-claims-customization/saml-sso-manage-user-claims.png" alt-text="Screenshot of editing the NameID (name identifier) value in the Azure portal.":::

+If the SAML request contains the element NameIDPolicy with a specific format, then the Microsoft identity platform honors the format in the request.

+If the SAML request doesn't contain an element for NameIDPolicy, then the Microsoft identity platform issues the NameID with the format you specify. If no format is specified, the Microsoft identity platform uses the default source format associated with the claim source selected. If a transformation results in a null or illegal value, Azure AD sends a persistent pairwise identifier in the nameIdentifier.

+From the **Choose name identifier format** dropdown, select one of the options in the following table.

+| **Default** | Microsoft identity platform uses the default source format. |

+| **Persistent** | Microsoft identity platform uses Persistent as the NameID format. |

+| **Email address** | Microsoft identity platform uses EmailAddress as the NameID format. |

+| **Unspecified** | Microsoft identity platform uses Unspecified as the NameID format. |

+|**Windows domain qualified name**| Microsoft identity platform uses the WindowsDomainQualifiedName format.|

+| pairwiseid | Persistent form of user identifier |

+For more information about identifier values, see [Table 3: Valid ID values per source](reference-claims-mapping-policy-type.md#table-3-valid-id-values-per-source).

+Any constant (static) value can be assigned to any claim that is defined in Azure AD. The following steps outline how to assign a constant value:

+1. In the [Azure portal](https://portal.azure.com/), in the **User Attributes & Claims** section, select **Edit** to edit the claims.

+1. Select the required claim that you want to modify.

+ :::image type="content" source="./media/active-directory-saml-claims-customization/organization-attribute.png" alt-text="Screenshot of the organization Attributes & Claims section in the Azure portal.":::

+1. The constant value will be displayed as shown in the following image.

+ :::image type="content" source="./media/active-directory-saml-claims-customization/edit-attributes-claims.png" alt-text="Screenshot of editing in the Attributes & Claims section in the Azure portal.":::

+## Special claims transformations

+You can use the following special claims transformations functions.

+| **ExtractMailPrefix()** | Removes the domain suffix from either the email address or the user principal name. This function extracts only the first part of the user name being passed through (for example, "joe_smith" instead of joe_smith@contoso.com). |

+## Add application-specific claims

+1. Select the function from the transformation dropdown. Depending on the function selected, you'll have to provide parameters and a constant value to evaluate in the transformation. Refer to the following table for more information about the available functions.

+1. **Treat source as multivalued** is a checkbox indicating whether the transform should be applied to all values or just the first. By default, transformations are only applied to the first element in a multi-value claim, by checking this box it ensures it's applied to all. This checkbox is only be enabled for multi-valued attributes, for example `user.proxyaddresses`.

+1. To apply multiple transformations, select **Add transformation**. You can apply a maximum of two transformations to a claim. For example, you could first extract the email prefix of the `user.mail`. Then, make the string upper case.

+ :::image type="content" source="./media/active-directory-saml-claims-customization/sso-saml-multiple-claims-transformation.png" alt-text="Screenshot of claims transformation.":::

+| **ExtractMailPrefix()** | Removes the domain suffix from either the email address or the user principal name. This function extracts only the first part of the user name being passed through (for example, "joe_smith" instead of joe_smith@contoso.com). |

+| **Join()** | Creates a new value by joining two attributes. Optionally, you can use a separator between the two attributes. For NameID claim transformation, the Join() function has specific behavior when the transformation input has a domain part. It removes the domain part from input before joining it with the separator and the selected parameter. For example, if the input of the transformation is 'joe_smith@contoso.com' and the separator is '@' and the parameter is 'fabrikam.com', this input combination results in 'joe_smith@fabrikam.com'. |

+| **Contains()** | Outputs an attribute or constant if the input matches the specified value. Otherwise, you can specify another output if there's no match. <br/>For example, if you want to emit a claim where the value is the user's email address if it contains the domain "@contoso.com", otherwise you want to output the user principal name. To perform this function, you configure the following values:<br/>*Parameter 1(input)*: user.email<br/>*Value*: "@contoso.com"<br/>Parameter 2 (output): user.email<br/>Parameter 3 (output if there's no match): user.userprincipalname |

+| **EndWith()** | Outputs an attribute or constant if the input ends with the specified value. Otherwise, you can specify another output if there's no match.<br/>For example, if you want to emit a claim where the value is the user's employee ID if the employee ID ends with "000", otherwise you want to output an extension attribute. To perform this function, you configure the following values:<br/>*Parameter 1(input)*: user.employeeid<br/>*Value*: "000"<br/>Parameter 2 (output): user.employeeid<br/>Parameter 3 (output if there's no match): user.extensionattribute1 |

+| **StartWith()** | Outputs an attribute or constant if the input starts with the specified value. Otherwise, you can specify another output if there's no match.<br/>For example, if you want to emit a claim where the value is the user's employee ID if the country/region starts with "US", otherwise you want to output an extension attribute. To perform this function, you configure the following values:<br/>*Parameter 1(input)*: user.country<br/>*Value*: "US"<br/>Parameter 2 (output): user.employeeid<br/>Parameter 3 (output if there's no match): user.extensionattribute1 |

+| **IfEmpty()** | Outputs an attribute or constant if the input is null or empty.<br/>For example, if you want to output an attribute stored in an extensionattribute if the employee ID for a given user is empty. To perform this function, you configure the following values:<br/>Parameter 1(input): user.employeeid<br/>Parameter 2 (output): user.extensionattribute1<br/>Parameter 3 (output if there's no match): user.employeeid |

+| **IfNotEmpty()** | Outputs an attribute or constant if the input isn't null or empty.<br/>For example, if you want to output an attribute stored in an extensionattribute if the employee ID for a given user isn't empty. To perform this function, you configure the following values:<br/>Parameter 1(input): user.employeeid<br/>Parameter 2 (output): user.extensionattribute1 |

+| **Substring() - Fixed Length** (Preview)| Extracts parts of a string claim type, beginning at the character at the specified position, and returns the specified number of characters.<br/>SourceClaim - The claim source of the transform that should be executed.<br/>StartIndex - The zero-based starting character position of a substring in this instance.<br/>Length - The length in characters of the substring.<br/>For example:<br/>sourceClaim - PleaseExtractThisNow<br/>StartIndex - 6<br/>Length - 11<br/>Output: ExtractThis |

+| **Substring() - EndOfString** (Preview) | Extracts parts of a string claim type, beginning at the character at the specified position, and returns the rest of the claim from the specified start index. <br/>SourceClaim - The claim source of the transform that should be executed.<br/>StartIndex - The zero-based starting character position of a substring in this instance.<br/>For example:<br/>sourceClaim - PleaseExtractThisNow<br/>StartIndex - 6<br/>Output: ExtractThisNow |

+| **RegexReplace()** (Preview) | RegexReplace() transformation accepts as input parameters:<br/>- Parameter 1: a user attribute as regex input<br/>- An option to trust the source as multivalued<br/>- Regex pattern<br/>- Replacement pattern. The replacement pattern may contain static text format along with a reference that points to regex output groups and more input parameters.<br/><br/>More instructions about how to use the RegexReplace() transformation are described later in this article. |

+If you need other transformations, submit your idea in the [feedback forum in Azure AD](https://feedback.azure.com/d365community/forum/22920db1-ad25-ec11-b6e6-000d3a4f0789) under the *SaaS application* category.

+## Regex-based claims transformation

+The following image shows an example of the first level of transformation:

+The following table provides information about the first level of transformations. The actions listed in the table correspond to the labels in the previous image. Select **Edit** to open the claims transformation blade.

+| Action | Field | Description |

+| :-- | :- | :- |

+| 1 | Transformation | Select the **RegexReplace()** option from the **Transformation** options to use the regex-based claims transformation method for claims transformation. |

+| 2 | Parameter 1 | The input for the regular expression transformation. For example, user.mail that has a user email address such as `admin@fabrikam.com`. |

+| 3 | Treat source as multivalued | Some input user attributes can be multi-value user attributes. If the selected user attribute supports multiple values and the user wants to use multiple values for the transformation, they need to select **Treat source as multivalued**. If selected, all values are used for the regex match, otherwise only the first value is used. |

+| 4 | Regex pattern | A regular expression that is evaluated against the value of user attribute selected as *Parameter 1*. For example a regular expression to extract the user alias from the user's email address would be represented as `(?'domain'^.*?)(?i)(\@fabrikam\.com)$`. |

+| 5 | Add additional parameter | More than one user attribute can be used for the transformation. The values of the attributes would then be merged with regex transformation output. Up to five additional parameters are supported. |

+| 6 | Replacement pattern | The replacement pattern is the text template, which contains placeholders for regex outcome. All group names must be wrapped inside the curly braces such as `{group-name}`. Let's say the administration wants to use user alias with some other domain name, for example `xyz.com` and merge country name with it. In this case, the replacement pattern would be `{country}.{domain}@xyz.com`, where `{country}` is the value of input parameter and `{domain}` is the group output from the regular expression evaluation. In such a case, the expected outcome is `US.swmal@xyz.com`. |

+The following image shows an example of the second level of transformation:

+The following table provides information about the second level of transformations. The actions listed in the table correspond to the labels in the previous image.

+| Action | Field | Description |

+| :-- | :- | :- |

+| 1 | Transformation | Regex-based claims transformations aren't limited to the first transformation and can be used as the second level transformation as well. Any other transformation method can be used as the first transformation. |

+| 2 | Parameter 1 | If **RegexReplace()** is selected as a second level transformation, output of first level transformation is used as an input for the second level transformation. The second level regex expression should match the output of the first transformation or the transformation won't be applied. |

+| 3 | Regex pattern | **Regex pattern** is the regular expression for the second level transformation. |

+| 4 | Parameter input | User attribute inputs for the second level transformations. |

+| 5 | Parameter input | Administrators can delete the selected input parameter if they don't need it anymore. |

+| 6 | Replacement pattern | The replacement pattern is the text template, which contains placeholders for regex outcome group name, input parameter group name, and static text value. All group names must be wrapped inside the curly braces such as `{group-name}`. Let's say the administration wants to use user alias with some other domain name, for example `xyz.com` and merge country name with it. In this case, the replacement pattern would be `{country}.{domain}@xyz.com`, where `{country}` is the value of input parameter and {domain} is the group output from the regular expression evaluation. In such a case, the expected outcome is `US.swmal@xyz.com`. |

+| 7 | Test transformation | The RegexReplace() transformation is evaluated only if the value of the selected user attribute for *Parameter 1* matches with the regular expression provided in the **Regex pattern** textbox. If they don't match, the default claim value is added to the token. To validate regular expression against the input parameter value, a test experience is available within the transform blade. This test experience operates on dummy values only. When additional input parameters are used, the name of the parameter is added to the test result instead of the actual value. To access the test section, select **Test transformation**. |

+The following image shows an example of testing the transformations:

+The following table provides information about testing the transformations. The actions listed in the table correspond to the labels in the previous image.

+| Action | Field | Description |

+| :-- | :- | :- |

+| 1 | Test transformation | Select the close or (X) button to hide the test section and re-render the **Test transformation** button again on the blade. |

+| 2 | Test regex input | Accepts input that is used for the regular expression test evaluation. In case regex-based claims transformation is configured as a second level transformation, a value is provided that would be the expected output of the first transformation. |

+| 3 | Run test | After the test regex input is provided and the **Regex pattern**, **Replacement pattern** and **Input parameters** are configured, the expression can be evaluated by selecting **Run test**. |

+| 4 | Test transformation result | If evaluation succeeds, an output of test transformation will be rendered against the **Test transformation result** label. |

+| 5 | Remove transformation | The second level transformation can be removed by selecting **Remove transformation**. |

+| 6 | Specify output if no match | When a regex input value is configured against the *Parameter 1* that doesn't match the **Regular expression**, the transformation is skipped. In such cases, the alternate user attribute can be configured, which is added to the token for the claim by checking **Specify output if no match**. |

+| 7 | Parameter 3 | If an alternate user attribute needs to be returned when there's no match and **Specify output if no match** is checked, an alternate user attribute can be selected using the dropdown. This dropdown is available against **Parameter 3 (output if no match)**. |

+| 8 | Summary | At the bottom of the blade, a full summary of the format is displayed that explains the meaning of the transformation in simple text. |

+| 9 | Add | After the configuration settings for the transformation are verified, it can be saved to a claims policy by selecting **Add**. Changes won't be saved unless **Save** is selected on the **Manage Claim** blade. |

+RegexReplace() transformation is also available for the group claims transformations.

+### RegexReplace() transformation validations

+When the following conditions occur after **Add** or **Run test** is selected, a message is displayed that provides more information about the issue:

+* Input parameters with duplicate user attributes aren't allowed.

+* Unused input parameters found. Defined input parameters should have respective usage into the Replacement pattern text.

+* The provided test regex input doesn't match with the provided regular expression.

+* The source for the groups into the replacement pattern isn't found.

+The `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn` claim is part of the [SAML restricted claim set](reference-claims-mapping-policy-type.md#table-2-saml-restricted-claim-set), so you can't add it in the **Attributes & Claims** section. As a workaround, you can add it as an [optional claim](active-directory-optional-claims.md) through **App registrations** in the Azure portal.

+Open the application in **App registrations**, select **Token configuration**, and then select **Add optional claim**. Select the **SAML** token type, choose **upn** from the list, and then click **Add** to add the claim to the token.

+## Emit claims based on conditions

+You can specify the source of a claim based on user type and the group to which the user belongs.

+* **Any** - All users are allowed to access the application.

+* **Members**: Native member of the tenant

+* **All guests**: User is brought over from an external organization with or without Azure AD.

+* **AAD guests**: Guest user belongs to another organization using Azure AD.

+* **External guests**: Guest user belongs to an external organization that doesn't have Azure AD.

+One scenario where the user type is helpful is when the source of a claim is different for a guest and an employee accessing an application. You can specify that if the user is an employee, the NameID is sourced from user.email. If the user is a guest, then the NameID is sourced from user.extensionattribute1.

+1. Select the user type.

+1. Select the group(s) to which the user should belong. You can select up to 50 unique groups across all claims for a given application.

+1. Select the **Source** where the claim is going to retrieve its value. You can select a user attribute from the source attribute dropdown or apply a transformation to the user attribute before emitting it as a claim.

+The order in which you add the conditions are important. Azure AD first evaluates all conditions with source `Attribute` and then evaluates all conditions with source `Transformation` to decide which value to emit in the claim. Conditions with the same source are evaluated from top to bottom. The last value, which matches the expression is emitted in the claim. Transformations such as `IsNotEmpty` and `Contains` act like restrictions.

+For example, Britta Simon is a guest user in the Contoso tenant. Britta belongs to another organization that also uses Azure AD. Given the following configuration for the Fabrikam application, when Britta tries to sign in to Fabrikam, the Microsoft identity platform evaluates the conditions.

+First, the Microsoft identity platform verifies whether Britta's user type is **All guests**. Because this is true, the Microsoft identity platform assigns the source for the claim to `user.extensionattribute1`. Second, the Microsoft identity platform verifies whether Britta's user type is **AAD guests**, because this is also true, the Microsoft identity platform assigns the source for the claim to `user.mail`. Finally, the claim is emitted with a value of `user.mail` for Britta.

+As another example, consider when Britta Simon tries to sign in and the following configuration is used. Azure AD first evaluates all conditions with source `Attribute`. Because Britta's user type is **AAD guests**, `user.mail` is assigned as the source for the claim. Next, Azure AD evaluates the transformations. Because Britta is a guest, `user.extensionattribute1` is now the new source for the claim. Because Britta is in **AAD guests**, `user.othermail` is now the source for this claim. Finally, the claim is emitted with a value of `user.othermail` for Britta.

+As a final example, consider what happens if Britta has no `user.othermail` configured or it's empty. In both cases the condition entry is ignored, and the claim falls back to `user.extensionattribute1` instead.

+## Advanced SAML claims options

+Advanced claims options can be configured for SAML2.0 applications to expose the same claim to OIDC tokens and vice versa for applications that intend to use the same claim for both SAML2.0 and OIDC response tokens.

+Advanced claim options can be configured by checking the box under **Advanced SAML Claims Options** in the **Manage claims** blade.

+The following table lists other advanced options that can be configured for an application.

+| Append application ID to issuer | Automatically adds the application ID to the issuer claim. This option ensures a unique claim value for each instance when there are multiple instances of the same application. This setting is ignored if a custom signing key isn't configured for the application. |

+| Include attribute name format | If selected, Azure Active Directory adds an attribute called `NameFormat` that describes the format of the name to restricted, core, and optional claims for the application. For more information, see, [Claims mapping policy type](reference-claims-mapping-policy-type.md#claim-sets) |

+* [Configure single sign-on for applications that aren't in the Azure AD application gallery](../manage-apps/configure-saml-single-sign-on.md)

+Role-based access control (RBAC) allows certain users or groups to have specific permissions to access and manage resources. Application RBAC differs from [Azure role-based access control](../../role-based-access-control/overview.md) and [Azure AD role-based access control](../roles/custom-overview.md#understand-azure-ad-role-based-access-control). Azure custom roles and built-in roles are both part of Azure RBAC, which is used to help manage Azure resources. Azure AD RBAC is used to manage Azure AD resources. This article explains application-specific RBAC. For information about implementing application-specific RBAC, see [How to add app roles to your application and receive them in the token](./howto-add-app-roles-in-azure-ad-apps.md).

+Have an idea for improving the Microsoft identity platform? Browse and vote for ideas submitted by others or submit your own:

+An appΓÇÖs publisher domain informs users where their information is being sent. The publisher domain also acts as an input or prerequisite for [publisher verification](publisher-verification-overview.md). Depending on when the app was registered and the status of the Publisher Verification, it would be displayed directly to the user on the [application's consent prompt](application-consent-experience.md). An applicationΓÇÖs publisher domain is displayed to users (depending on the state of Publisher Verification) on the consent UX to let users know where their information is being sent for trustworthiness.

+In an app's consent prompt, either the publisher domain or the publisher verification status appears. Which information is shown depends on whether the app is a [multitenant app](/azure/architecture/guide/multitenant/overview), when the app was registered, and the app's publisher verification status.

+## Understand multitenant apps

+Certain web APIs such as the Azure Resource Manager API (`https://management.core.windows.net/`) expect a trailing forward slash ('/') in the audience claim (`aud`) of the access token. In this case, pass the scope as `https://management.core.windows.net//user_impersonation`, including the double forward slash ('//').

+In your tenant, you'll need separate app registrations for the web app and the web API. For app registration and exposing the web API scope, follow the steps in the scenario [A web app that authenticates users and calls web APIs](/azure/active-directory/develop/scenario-web-app-call-api-overview).

+| AADSTS500011 | InvalidResourceServicePrincipalNotFound - The resource principal named {name} was not found in the tenant named {tenant}. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant. If you expect the app to be installed, you may need to provide administrator permissions to add it. Check with the developers of the resource and application to understand what the right setup for your tenant is. |

+| AADSTS50013 | InvalidAssertion - Assertion is invalid because of various reasons - The token issuer doesn't match the api version within its valid time range -expired -malformed - Refresh token in the assertion isn't a primary refresh token. Contact the app developer. |

+| AADSTS50014 | GuestUserInPendingState - The user account doesnΓÇÖt exist in the directory. An application likely chose the wrong tenant to sign into, and the currently logged in user was prevented from doing so since they did not exist in your tenant. If this user should be able to log in, add them as a guest. For further information, please visit [add B2B users](/azure/active-directory/b2b/add-users-administrator). |

+| AADSTS50020 | UserUnauthorized - Users are unauthorized to call this endpoint. User account '{email}' from identity provider '{idp}' does not exist in tenant '{tenant}' and cannot access the application '{appid}'({appName}) in that tenant. This account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account. If this user should be a member of the tenant, they should be invited via the [B2B system](/azure/active-directory/b2b/add-users-administrator). For additional information, visit [AADSTS50020](/troubleshoot/azure/active-directory/error-code-aadsts50020-user-account-identity-provider-does-not-exist). |

+| AADSTS50034 | UserAccountNotFound - To sign into this application, the account must be added to the directory. This error can occur because the user mis-typed their username, or isn't in the tenant. An application may have chosen the wrong tenant to sign into, and the currently logged in user was prevented from doing so since they did not exist in your tenant. If this user should be able to log in, add them as a guest. See docs here: [Add B2B users](/azure/active-directory/external-identities/add-users-administrator). |

+| AADSTS50076 | UserStrongAuthClientAuthNRequired - Due to a configuration change made by the admin such as a Conditional Access policy, per-user enforcement, or because you moved to a new location, the user must use multi-factor authentication to access the resource. Retry with a new authorize request for the resource. |

+| AADSTS50079 | UserStrongAuthEnrollmentRequired - Due to a configuration change made by the admin such as a Conditional Access policy, per-user enforcement, or because the user moved to a new location, the user is required to use multi-factor authentication. Either a managed user needs to register security info to complete multi-factor authentication, or a federated user needs to get the multi-factor claim from the federated identity provider. |

+| AADSTS50126 | InvalidUserNameOrPassword - Error validating credentials due to invalid username or password. The user didn't enter the right credentials. It's expected to see some number of these errors in your logs due to users making mistakes. |

+| AADSTS50146 | MissingCustomSigningKey - This app is required to be configured with an app-specific signing key. It is either not configured with one, or the key has expired or isn't yet valid. Please contact the owner of the application. |

+| AADSTS51004 | UserAccountNotInDirectory - The user account doesnΓÇÖt exist in the directory. An application likely chose the wrong tenant to sign into, and the currently logged in user was prevented from doing so since they did not exist in your tenant. If this user should be able to log in, add them as a guest. For further information, please visit [add B2B users](/azure/active-directory/b2b/add-users-administrator). |

+| AADSTS53000 | DeviceNotCompliant - Conditional Access policy requires a compliant device, and the device isn't compliant. The user must enroll their device with an approved MDM provider like Intune. For additional information, please visit [Conditional Access device remediation](/azure/active-directory/conditional-access/troubleshoot-conditional-access). |

+| AADSTS53003 | BlockedByConditionalAccess - Access has been blocked by Conditional Access policies. The access policy does not allow token issuance. If this is unexpected, see the conditional access policy that applied to this request in the Azure Portal or contact your administrator. For additional information, please visit [troubleshooting sign-in with Conditional Access](/azure/active-directory/conditional-access/troubleshoot-conditional-access). |

+| AADSTS530034 | DelegatedAdminBlockedDueToSuspiciousActivity - A delegated administrator was blocked from accessing the tenant due to account risk in their home tenant. |

+| AADSTS700011 | UnauthorizedClientAppNotFoundInOrgIdTenant - Application with identifier {appIdentifier} was not found in the directory. A client application requested a token from your tenant, but the client app doesn't exist in your tenant, so the call failed. |

+| AADSTS700082 | ExpiredOrRevokedGrantInactiveToken - The refresh token has expired due to inactivity. The token was issued on {issueDate} and was inactive for {time}. Expected part of the token lifecycle - the user went an extended period of time without using the application, so the token was expired when the app attempted to refresh it. |

+| AADSTS80014 | OnPremisePasswordValidationAuthenticationAgentTimeout - Validation request responded after maximum elapsed time exceeded. Open a support ticket with the error code, correlation ID, and timestamp to get more details on this error. |

+| AADSTS90002 | InvalidTenantName - The tenant name wasn't found in the data store. Check to make sure you have the correct tenant ID. The application developer will receive this error if their app attempts to sign into a tenant that we cannot find. Often, this is because a cross-cloud app was used against the wrong cloud, or the developer attempted to sign in to a tenant derived from an email address, but the domain isn't registered. |

+| AADSTS900561 | BadResourceRequestInvalidRequest - The endpoint only accepts {valid_verbs} requests. Received a {invalid_verb} request. {valid_verbs} represents a list of HTTP verbs supported by the endpoint (for example, POST), {invalid_verb} is an HTTP verb used in the current request (for example, GET). This can be due to developer error, or due to users pressing the back button in their browser, triggering a bad request. It can be ignored. |

+| AADSTS90072 | PassThroughUserMfaError - The external account that the user signs in with doesn't exist on the tenant that they signed into; so the user can't satisfy the MFA requirements for the tenant. This error also might occur if the users are synced, but there is a mismatch in the ImmutableID (sourceAnchor) attribute between Active Directory and Azure AD. The account must be added as an external user in the tenant first. Sign out and sign in with a different Azure AD user account. For more information, please visit [configuring external identities](/azure/active-directory/external-identities/external-identities-overview). |

+# Configure SAML app multi-instancing for an application in Azure Active Directory

+App multi-instancing refers to the need for the configuration of multiple instances of the same application within a tenant. For example, the organization has multiple Amazon Web Services accounts, each of which needs a separate service principal to handle instance-specific claims mapping (adding the AccountID claim for that AWS tenant) and roles assignment. Or the customer has multiple instances of Box, which doesn't need special claims mapping, but does need separate service principals for separate signing keys.

+## IDP versus SP initiated SSO

+A user can sign-in to an application one of two ways, either through the application directly, which is known as service provider (SP) initiated single sign-on (SSO), or by going directly to the identity provider (IDP), known as IDP initiated SSO. Depending on which approach is used within your organization you'll need to follow the appropriate instructions below.

+## SP Initiated

+In the SAML request of SP initiated SSO, the Issuer specified is usually the App ID Uri. Utilizing App ID Uri doesn't allow the customer to distinguish which instance of an application is being targeted when using SP initiated SSO.

+## SP Initiated Configuration Instructions

+Update the SAML single sign-on service URL configured within the service provider for each instance to include the service principal guid as part of the URL. For example, the general SSO sign-in URL for SAML would have been `https://login.microsoftonline.com/<tenantid>/saml2`, the URL can now be updated to target a specific service principal as follows `https://login.microsoftonline.com/<tenantid>/saml2/<issuer>`.

+Only service principal identifiers in GUID format are accepted for the `issuer` value. The service principal identifiers override the issuer in the SAML request and response, and the rest of the flow is completed as usual. There's one exception: if the application requires the request to be signed, the request is rejected even if the signature was valid. The rejection is done to avoid any security risks with functionally overriding values in a signed request.

+## IDP Initiated

+The IDP initiated feature exposes two settings for each application.

+- An **audience override** option exposed for configuration by using claims mapping or the portal. The intended use case is applications that require the same audience for multiple instances. This setting is ignored if no custom signing key is configured for the application.

+- An **issuer with application id** flag to indicate the issuer should be unique for each application instead of unique for each tenant. This setting is ignored if no custom signing key is configured for the application.

+## IDP Initiated Configuration Instructions

+1. Open any SSO enabled enterprise app and navigate to the SAML single sign on blade.

+1. Select **Edit** on the **User Attributes & Claims** panel.

+1. Configure both options according to your preferences and then select **Save**.

+While developing an application, authorize access with the groups claim. To learn more, see how to [configure group claims for applications with Azure AD](../hybrid/how-to-connect-fed-group-claims.md).

+- Understand if [implicit flow is required](./v2-oauth2-implicit-grant-flow.md#suitable-scenarios-for-the-oauth2-implicit-grant). Don't use implicit flow unless explicitly required.

+dotnet new --install Microsoft.Identity.Web.ProjectTemplates

+## December 2022

+### New articles

+- [Block workload identity federation on managed identities using a policy](workload-identity-federation-block-using-azure-policy.md)

+- [Troubleshooting the configured permissions limits](troubleshoot-required-resource-access-limits.md)

+### Updated articles

+- [Quickstart: Protect an ASP.NET Core web API with the Microsoft identity platform](quickstart-v2-aspnet-core-web-api.md)

+- [Quickstart: Get a token and call the Microsoft Graph API by using a console app's identity](quickstart-v2-netcore-daemon.md)

+- [Tutorial: Sign in users and call a protected API from a Blazor WebAssembly app](tutorial-blazor-webassembly.md)

+- [A web API that calls web APIs: Code configuration](scenario-web-api-call-api-app-configuration.md)

+- [Web app that signs in users: Code configuration](scenario-web-app-sign-user-app-configuration.md)

+- [Web app that signs in users: App registration](scenario-web-app-sign-user-app-registration.md)

+- [Microsoft identity platform docs: What's new](whats-new-docs.md)

+- [Tutorial: Create a Blazor Server app that uses the Microsoft identity platform for authentication](tutorial-blazor-server.md)

+ let aadAudience = "api://AzureADTokenExchange"

+ const jwt = axios({

+ url: "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience="

+ + aadAudience,

+ method: "GET",

+ headers: {

+ "Metadata-Flavor": "Google"

+ }}).then(response => {

+ console.log("AXIOS RESPONSE");

+ return response.data;

+ });

+ return jwt;

+ .then(function(aadToken) {

+ // return in form expected by TokenCredential.getToken

+ let returnToken = {

+ token: aadToken.accessToken,

+ expiresOnTimestamp: aadToken.expiresOn.getTime(),

+ };

+ return (returnToken);

+ })

+ .catch(function(error) {

+ // error stuff

+ }

+The Microsoft identity platform stores only the first 100 signing keys when they're downloaded from the external IdP's OIDC endpoint. If the external IdP exposes more than 100 signing keys, you may experience errors when using Workload Identity Federation.

+- For information about the required format of JWTs created by external identity providers, read about the [assertion format](active-directory-certificate-credentials.md#assertion-format).

+- Use Azure Policy to deploy and audit policies to require Azure AD login for Windows VMs and to flag the use of unapproved local accounts on the VMs.

+> Windows Hello for Business PIN authentication with RDP has been supported for several versions of Windows 10. Support for biometric authentication with RDP was added in Windows 10 version 1809. Using Windows Hello for Business authentication during RDP is available for deployments that use a certificate trust model or key trust model.

+You can enable users to create and manage their own security groups or Microsoft 365 groups in Azure Active Directory (Azure AD), part of Microsoft Entra. The owner of the group can approve or deny membership requests, and can delegate control of group membership. Self-service group management features are not available for [mail-enabled security groups or distribution lists](../fundamentals/concept-learn-about-groups.md).

+## Self-service group membership

+You can allow users to create security groups, which are used to manage access to shared resources. Security groups can be created by users in Azure portals, using Azure AD PowerShell, or from the [MyApps Groups Access panel](https://account.activedirectory.windowsazure.com/r#/groups). Only the group's owners can update membership, but you can provide group owners the ability to approve or deny membership requests from the MyApp Groups Access panel. Security groups created by self-service through the MyApps Groups Access panel are available to join for all users, whether owner-approved or auto-approved. In the MyApps Groups Access panel, you can change membership options when you create the group.

+Microsoft 365 groups, which provide collaboration opportunities for your users, can be created in any of the Microsoft 365 applications, such as SharePoint, Microsoft Teams, and Planner. Microsoft 365 groups can also be created in Azure portals, using Azure AD PowerShell, or from the MyApp Groups Access panel. For more information on the difference between security groups and Microsoft 365 groups, see [Learn about groups](../fundamentals/concept-learn-about-groups.md#what-to-know-before-creating-a-group)

+[Azure AD PowerShell](../enterprise-users/groups-settings-cmdlets.md) | Only owners can add members<br>Visible but not available to join in MyApp Groups Access panel | Open to join for all users

+[Azure portal](https://portal.azure.com) | Only owners can add members<br>Visible but not available to join in MyApp Groups Access panel<br>Owner is not assigned automatically at group creation | Open to join for all users

+[MyApps Groups Access panel](https://account.activedirectory.windowsazure.com/r#/joinGroups) | Open to join for all users<br>Membership options can be changed when the group is created | Open to join for all users<br>Membership options can be changed when the group is created

+ An example is an administrator who is managing access to a Software as a Service (SaaS) application that the company is using. Managing these access rights is becoming cumbersome, so this administrator asks the business owner to create a new group. The administrator assigns access for the application to the new group, and adds to the group all people already accessing the application. The business owner then can add more users, and those users are automatically provisioned to the application. The business owner doesn't need to wait for the administrator to manage access for users. If the administrator grants the same permission to a manager in a different business group, that person can also manage access for their own group members. Neither the business owner nor the manager can view or manage each other's group memberships. The administrator can still see all users who have access to the application and block access rights if needed.

+ An example of this scenario is two users who both have SharePoint Online sites that they set up independently. They want to give each other's teams access to their sites. To accomplish this, they can create one group in Azure AD, and in SharePoint Online each of them selects that group to provide access to their sites. When someone wants access, they request it from the MyApp Groups Access Panel, and after approval they get access to both SharePoint Online sites automatically. Later, one of them decides that all people accessing the site should also get access to a particular SaaS application. The administrator of the SaaS application can add access rights for the application to the SharePoint Online site. From then on, any requests that get approved give access to the two SharePoint Online sites and also to this SaaS application.

+> An Azure Active Directory Premium (P1 or P2) license is required for users to request to join a security group or Microsoft 365 group and for owners to approve or deny membership requests. Without an Azure Active Directory Premium license, users can still manage their groups in the MyApp Groups Access panel, but they can't create a group that requires owner approval and they can't request to join a group.

+The group settings enable you to control who can create security and Microsoft 365 groups.

+Some Microsoft services aren't available in all locations. For group license assignment, any users without a usage location specified inherit the location of the directory. If you have users in multiple locations, make sure to reflect that correctly in your user resources before adding users to groups with licenses. Before a license can be assigned to a user, the administrator should specify the **Usage location** property on the user.

+1. Sign in to the [Azure portal](https://portal.azure.com) in the **User Administrator** role.

+1. Go to **Azure AD** > **Users** and select a user.

+1. Select **Edit properties**.

+1. Select the **Settings** tab and enter a location for the user.

+1. Select the **Save** button.

+> Group license assignment will never modify an existing usage location value on a user. We recommend that you always set usage location as part of your user creation flow in Azure AD (for example, via [Azure AD Connect](../hybrid/whatis-azure-ad-connect.md) configuration). Following such a process ensures the result of license assignment is always correct, and users do not receive services in locations that are not allowed.

+You can use group-based licensing with any security group, including dynamic groups. Dynamic groups run rules against user resource attributes to automatically add and remove members. Attributes can be department, job title, work location, or other custom attribute. Each group is assigned the licenses that you want members to receive. If an attribute changes, the member leaves the group, and the licenses are removed.

+You can assign the attribute on-premises and sync it with Azure AD, or you can manage the attribute directly in the cloud.

+- Multiple licenses for the same product can overlap, and they result in all enabled services being applied to the user. An example could be that *M365-P1* contains the foundational services to deploy to all users, and *M365-P2* contains the P2 services to deploy only to some users. You can add a user to one or both groups and only use one license for the product.

+- Select a license to view more details, including information about which services are enabled for the user by the group license assignment.

+When a user inherits a license from a group, you can't directly remove or modify that license in the user's properties. You can change the license assignment only in the group and the changes are then propagated to all group members. If you need to assign other features to a user that has their license from a group license assignment, you must create another group to assign the other features to the user.

+When you use group-based licensing, consider the following scenarios:

+- Group members inherit licenses assigned to the group.

+- License options for group-based licenses must be changed at the group level.

+- If different license options need to be assigned to a user, create a new group, assign a license to the group, then add the user to that group.

+- Users still use only one license of a product if different license options for that product are used in the different group-based licenses.

+When you use direct assignment, the following operations are allowed:

+- Licenses not already assigned through group-based licensing can be changed for an individual user.

+- Other services can be enabled, as part of a directly assigned license.

+- Directly assigned licenses can be removed and donΓÇÖt affect a user's inherited licenses.

+When Microsoft adds a new service to a product license plan, it's enabled by default in all groups to which you've assigned the product license. Users in your organization who are subscribed to notifications about product changes will receive emails ahead of time notifying them about the upcoming service additions.

+Here's an example of what this process may look like:

+1. Originally, you assigned the *Microsoft 365 E5* product to several groups. One of those groups, called *Microsoft 365 E5 - Exchange only* was designed to enable only the *Exchange Online (Plan 2)* service for its members.

+2. You received a notification from Microsoft that the E5 product will be extended with a new service - *Microsoft Stream*. When the service becomes available in your organization, you can complete the following steps:

+3. Go to [**Azure Active Directory > Licenses > All products**](https://portal.azure.com/#blade/Microsoft_AAD_IAM/LicensesMenuBlade/Products) and select *Microsoft 365 Enterprise E5*, then select **Licensed Groups** to view a list of all groups with that product.

+4. Select the group you want to review (in this case, *Microsoft 365 E5 - Exchange only*). The **Licenses** tab opens. Select the E5 license to view all enabled services.

+5. If you want to disable the new service in this group, select the On/Off toggle next to the service, and select the **Save** button to confirm the change. Azure AD will now process all users in the group to apply the change; any new users added to the group won't have the *Microsoft Stream* service enabled.

+3. Use the *AccountSkuId* value for the license you're interested in with [this PowerShell script](licensing-ps-examples.md#check-if-user-license-is-assigned-directly-or-inherited-from-a-group). A list populates the users who have this license and information about how the license is assigned.

+Audit logs related to group-based licensing can be accessed from the Audit logs in the Groups or Licensing areas of Azure AD or use the following filter combinations from the main Audit logs:

+- **Service**: Core Directory

+- **Category**: GroupManagement or UserManagement

+

+### Find out who modified a license

+1. To see the logs for group license changes, use the following Audit log filter options:

+ - **Service**: Core Directory

+ - **Category**: GroupManagement

+ - **Activity**: Set group license

+1. Select a row in the resulting table to view the details.

+1. Select the **Modified Properties** tab see the old and new values for the license agreement.

+The following example shows the filter settings listed above, plus the *Target* filter set to all groups that start with "EMS."

+

+To see license changes for a specific user, use the following filters:

+- **Service**: Core Directory

+- **Category**: UserManagement

+- **Activity**: Change user license

+### Find out when group changes started and finished processing

+When a license changes on a group, Azure AD will start applying the changes to all users, but the changes could take time to process.

+1. To see when groups started processing, use the following filters:

+ - **Service**: Core Directory

+ - **Category**: GroupManagement

+ - **Activity**: Start applying group based license to users

+1. Select a row in the resulting table to view the details.

+1. Select the **Modified Properties** tab see the license changes that were picked up for processing.

+ - Use these details if you're making multiple changes to a group and aren't sure which license processed.

+ - The actor for the operation is *Microsoft Azure AD Group-Based Licensing*, which is a system account that is used to execute all group license changes.

+To see when groups finished processing, change the **Activity** filter to *Finish applying group based license to users*. In this case, the **Modified Properties** field contains a summary of the results, which is useful to quickly check if processing resulted in any errors. Sample output:

+> ```

+> Modified Properties

+> ...

+> Name : Result

+> Old Value : []

+> New Value : [Users successfully assigned licenses: 6, Users for whom license assignment failed: 0.];

+> ```

+To see the complete log for how a group was processed, including all user changes, add the following filters:

+- **Target**: Group name

+- **Initiated By (Actor)**: Microsoft Azure AD Group-Based Licensing (case-sensitive)

+- **Date Range** (optional): Custom range for when you know a specific group started and finished processing

+This sample output shows the start and finish of processing the license change.

+

+It isn't possible to delete a group with an active license assigned. An administrator could delete a group not realizing that it will cause licenses to be removed from users. For this reason we require any licenses to be removed from the group first, before it can be deleted.

+When trying to delete a group in the Azure portal, you may see an error notification like this:

+You may see similar errors when trying to delete the group through PowerShell or Graph API. If you're using a group synced from on-premises, Azure AD Connect may also report errors if it's failing to delete the group in Azure AD. In all such cases, make sure to check if there are any licenses assigned to the group, and remove them first.

+- Group-based licensing currently doesn't support groups that contain other groups (nested groups). If you apply a license to a nested group, only the immediate first-level user members of the group have the licenses applied.

+- The [Microsoft 365 admin center](https://admin.microsoft.com) doesn't currently support group-based licensing. If a user inherits a license from a group, this license appears in the Office admin portal as a regular user license. If you try to modify that license or try to remove the license, the portal returns an error message. Inherited group licenses can't be modified directly on a user.

+- When licenses are assigned or modified for a large group (for example, 100,000 users), it could affect performance. Specifically, the volume of changes generated by Azure AD automation might negatively affect the performance of your directory synchronization between Azure AD and on-premises systems.

+- If you're using dynamic groups to manage your userΓÇÖs membership, verify that the user is part of the group, which is necessary for license assignment. If not, [check processing status for the membership rule](groups-create-rule.md) of the dynamic group.

+- In certain high load situations, it may take a long time to process license changes for groups or membership changes to groups with existing licenses. If you see your changes take more than 24 hours to process group size of 60 K users or less, please [open a support ticket](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/supportRequest) to allow us to investigate.

+- License management automation doesn't automatically react to all types of changes in the environment. For example, you might have run out of licenses, causing some users to be in an error state. To free up the available seat count, you can remove some directly assigned licenses from other users. However, the system doesn't automatically react to this change and fix users in that error state.

+ As a workaround to these types of limitations, you can go to **Azure AD** > **Groups** > select a group > select **Licenses** > select **Reprocess**. This command processes all users in that group and resolves the error states, if possible.

+Invitation emails are a critical component to bring partners on board as B2B collaboration users in Azure AD. ItΓÇÖs [not required that you send an email to invite someone using B2B collaboration](redemption-experience.md#redemption-through-a-direct-link), but it gives the user all the information they need to decide if they accept your invite or not. It also gives them a link they can always refer to in the future when they need to return to your resources.

+## December 2022

+### Updated articles

+- [Azure Active Directory B2B collaboration invitation redemption](redemption-experience.md)

+- [Azure Active Directory B2B collaboration API and customization](customize-invitation-api.md)

+- [Azure Active Directory External Identities: What's new](whats-new-docs.md)

+- [Auditing and reporting a B2B collaboration user](auditing-and-reporting.md)

+description: Learn methods to discover the current state of your collaboration

+Before you learn about the current state of your external collaboration, determine a security posture. Consider centralized vs. delegated control, also governance, regulatory, and compliance targets.

+Learn more: [Determine your security posture for external users](1-secure-access-posture.md)

+Users in your organization likely collaborate with users from other organizations. Collaboration can occur with productivity applications like Microsoft 365, by email, or sharing resources with external users. The foundation of your governance plan can include:

+* Users initiating external collaboration

+* Collaboration with external users and organizations

+* Access granted to external users

+## Users initiating external collaboration

+Users seeking external collaboration know the applications needed for their work, and when access ends. Therefore, determine users with delegated permission to invite external users, create access packages, and complete access reviews.

+To find collaborating users:

+* [Microsoft 365, audit log activities](/microsoft-365/compliance/audit-log-activities?view=o365-worldwide&preserve-view=true)

+* [Auditing and reporting a B2B collaboration user](../external-identities/auditing-and-reporting.md)

+## Collaboration with external users and organizations

+External users might be Azure AD B2B users with partner-managed credentials, or external users with locally provisioned credentials. Typically, these users are a UserType of Guest. See, [B2B collaboration overview](../external-identities/what-is-b2b.md).

+You can enumerate guest users with:

+* [Microsoft Graph API](/graph/api/user-list?tabs=http)

+* [PowerShell](/graph/api/user-list?tabs=http)

+* [Azure portal](../enterprise-users/users-bulk-download.md)

+There are tools to identify Azure AD B2B collaboration, external Azure AD tenants and users accessing applications:

+* [PowerShell module](https://github.com/AzureAD/MSIdentityTools/wiki/Get-MSIDCrossTenantAccessActivity)

+* [Azure Monitor workbook](../reports-monitoring/workbook-cross-tenant-access-activity.md)

+### Email domains and companyName property

+Determine external organizations with the domain names of external user email addresses. This discovery might not be possible with consumer identity providers such as Google. We recommend you write the companyName attribute to identify external organizations.

+### Allowlist, blocklist, and entitlement management

+For your organization to collaborate with, or block, specific organizations, at the tenant level, there is allowlist or blocklist. Use this feature to control B2B invitations and redemptions regardless of source (such as Microsoft Teams, SharePoint, or the Azure portal). See, [Allow or block invitations to B2B users from specific organizations](../external-identities/allow-deny-list.md).

+If you use entitlement management, you can confine access packages to a subset of partners with the **Specific connected organizations** option, under New access packages, in Identity Governance.

+ 

+## External user access

+After you have an inventory of external users and organizations, determine the access to grant to these users. You can use the Microsoft Graph API to determine Azure AD group membership or application assignment.

+* [Working with groups in Microsoft Graph](/graph/api/resources/groups-overview?context=graph%2Fcontext&view=graph-rest-1.0&preserve-view=true)

+* [Applications API overview](/graph/applications-concept-overview?view=graph-rest-1.0&preserve-view=true)

+### Enumerate application permissions

+Investigate access to your sensitive apps for awareness about external access. See, [Grant or revoke API permissions programmatically](/graph/permissions-grant-via-msgraph?view=graph-rest-1.0&tabs=http&pivots=grant-application-permissions&preserve-view=true).

+### Detect informal sharing

+If your email and network plans are enabled, you can investigate content sharing through email or unauthorized software as a service (SaaS) apps.

+* Identify, prevent, and monitor accidental sharing

+ * [Learn about data loss prevention](/microsoft-365/compliance/dlp-learn-about-dlp?view=o365-worldwide&preserve-view=true )

+* Identify unauthorized apps

+ * [Microsoft Defender for Cloud Apps](/security/business/siem-and-xdr/microsoft-defender-cloud-apps?rtc=1)

+## Next steps

+* [Determine your security posture for external access](1-secure-access-posture.md)

+* [Create a security plan for external access](3-secure-access-plan.md)

+* [Securing external access with groups](4-secure-access-groups.md)

+* [Transition to governed collaboration with Azure Active Directory B2B collaboration](5-secure-access-b2b.md)

+* [Manage external access with entitlement management](6-secure-access-entitlement-managment.md)

+* [Manage external access with Conditional Access policies](7-secure-access-conditional-access.md)

+* [Control access with sensitivity labels](8-secure-access-sensitivity-labels.md)

+* [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business](9-secure-access-teams-sharepoint.md)

+description: Plan the security for external access to your organization's resources.

+Before you create an external-access security plan, ensure the following conditions are met.

+* [Determine your security posture for external access](1-secure-access-posture.md)

+* [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+For your security plan, document the following information:

+* Applications and resources to be grouped for access

+* Sign-in conditions for external users

+ * Device state, sign-in location, client application requirements, and user risk

+* Policies that determine when to review and remove access

+* User populations to be grouped for a similar experience

+After you document the information, use Microsoft identity and access management policies, or another identity provider (IdP) to implement the plan.

+## Resources to be grouped for access

+To group resources for access:

+* Microsoft Teams groups files, conversation threads, and other resources. Formulate an external access strategy for Microsoft Teams.

+ * See, [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business](9-secure-access-teams-sharepoint.md)

+* Use entitlement management access packages to create and delegate management of packages of applications, groups, teams, SharePoint sites, etc.

+ * [Create a new access package in entitlement management](/azure/active-directory/governance/entitlement-management-access-package-create)

+* Apply Conditional Access policies to up to 250 applications, with the same access requirements

+ * [What is Conditional Access?](/azure/active-directory/conditional-access/overview)

+* Use Cross Tenant Access Settings Inbound Access to define access for application groups of external users

+ * [Overview: Cross-tenant access with Azure AD External Identities](/azure/active-directory/external-identities/cross-tenant-access-overview)

+Document the applications to be grouped. Considerations include:

+* **Risk profile** - Assess the risk if a bad actor gains access to an application.

+ * Identify application as high, medium, or low risk. Avoid grouping high-risk with low-risk.

+ * Document applications that can't be shared with external users

+* **Compliance frameworks** - Determine compliance frameworks for apps

+ * Identify access and review requirements

+* **Applications for roles or departments** - Assess applications to be grouped for a role or department access

+* **Collaboration applications** - Identify collaboration applications external users can access, such as Teams and SharePoint

+ * For productivity applications, external users might have licenses, or you might provide access

+For application and resource group access by external users, document the following information:

+* Descriptive group name, for example High_Risk_External_Access_Finance

+* Applications and resources in the group

+* Application and resource owners and contact information

+* Access is controlled by IT, or delegated to a business owner

+* Prerequisites for access: background check, training, etc.

+* Compliance requirements to access resources

+* Challenges, for example multi-factor authentication (MFA) for some resources

+* Cadence for reviews, by whom, and where it's documented

+> [!TIP]

+> Use this type of governance plan for internal access.

+## Document sign-in conditions for external users

+Determine the sign-in requirements for external users who request access. Base requirements on the resource risk profile, and the user's risk assessment during sign-in. Configure sign-in conditions using Conditional Access: a condition and an outcome. For example, you can require MFA.

+Learn more: [What is Conditional Access?](../conditional-access/overview.md)

+**Resource risk-profile sign-in conditions**

+Consider the following risk-based policies to trigger MFA.

+* **Low** - MFA for some application sets

+* **Medium** - MFA when other risks are present

+* **High** - External users always use MFA

+Learn more:

+* [Tutorial: Enforce multi-factor authentication for B2B guest users](../external-identities/b2b-tutorial-require-mfa.md)

+* Trust MFA from external tenants

+ * See, [Configure cross-tenant access settings for B2B collaboration, Modify inbound access settings](../external-identities/cross-tenant-access-settings-b2b-collaboration.md#modify-inbound-access-settings)

+### User and device sign-in conditions

+Use the following table to help assess policy to address risk.

+| User or sign-in risk| Proposed policy |

+| | |

+| Identity protection is high risk| Require user to change password |

+| Network location| To access confidential projects, require sign-in from an IP address range |

+To use device state as policy input, the device is registered or joined to your tenant. Configure cross-tenant access settings must be configured to trust the device claims from the home tenant. See, [Modify inbound access settings](../external-identities/cross-tenant-access-settings-b2b-collaboration.md#modify-inbound-access-settings).

+You can use identity-protection risk policies. However, mitigate issue in the user home tenant. See, [Common Conditional Access policy: Sign-in risk-based multifactor authentication](../conditional-access/howto-conditional-access-policy-risk.md).

+For network locations, you can restrict access to IP addresses ranges you own. Use this method if external partners access applications while at your location. See, [Conditional Access: Block access by location](../conditional-access/howto-conditional-access-policy-location.md)

+Document policies that dictate when to review resource access, and remove account access for external users. Inputs might include:

+* Compliance frameworks requirements

+Your policies will be customized, however consider the following parameters:

+* **Entitlement management access reviews**:

+ * [Change lifecycle settings for an access package in entitlement management](../governance/entitlement-management-access-package-lifecycle-policy.md)

+ * [Create an access review of an access package in entitlement management](../governance/entitlement-management-access-reviews-create.md)

+ * [Add a connected organization in entitlement management](../governance/entitlement-management-organization.md): group users from a partner and schedule reviews

+* **Microsoft 365 groups**:

+ * [Microsoft 365 group expiration policy](/microsoft-365/solutions/microsoft-365-groups-expiration-policy?view=o365-worldwide&preserve-view=true)

+* **Options**:

+ * If external users don't use access packages or Microsoft 365 groups, determine when accounts become inactive or deleted

+ * Remove sign-in for accounts that don't sign in for 90 days

+ * Regularly assess access for external users

+## Access control methods

+Some features, for example entitlement management, are available with an Azure AD Premium 2 (P2) license. Microsoft 365 E5 and Office 365 E5 licenses include Azure AD P2 licenses.

+Other combinations of Microsoft 365, Office 365, and Azure AD have functionality to manage external users. See, [Microsoft 365 guidance for security & compliance](/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-365-security-compliance-licensing-guidance).

+> Licenses are for one user. Therefore users, administrators, and business owners can have delegated access control. This scenario can occur with Azure AD P2 or Microsoft 365 E5, and you don't have to enable licenses for all users. The first 50,000 external users are free. If you don't enable P2 licenses for other internal users, they can't use entitlement management.

+## Govern access with Azure AD P2 and Microsoft 365 or Office 365 E5

+Azure AD P2 and Microsoft 365 E5 have all the security and governance tools.

+### Provision, sign-in, review access, and deprovision access

+Entries in bold are recommended.

+| Feature| Provision external users| Enforce sign-in requirements| Review access| Deprovision access |

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

+| Azure AD B2B collaboration| Invite via email, one-time password (OTP), self-service|N/A| **Periodic partner review**| Remove account<br>Restrict sign-in |

+| Entitlement management| **Add user by assignment or self-service access**|N/A| Access reviews|**Expiration of, or removal from, access package**|

+| Office 365 groups|N/A|N/A| Review group memberships| Group expiration or deletion<br> Removal from group |

+| Azure AD security groups|N/A| **Conditional Access policies**: Add external users to security groups as needed|N/A| N/A|

+### Resource access

+

+Entries in bold are recommended.

+|Feature | App and resource access| SharePoint and OneDrive access| Teams access| Email and document security |

+| Entitlement management| **Add user by assignment or self-service access**| **Access packages**| **Access packages**| N/A|

+| Office 365 Group|N/A | Access to site(s) and group content| Access to teams and group content|N/A|

+| Sensitivity labels|N/A| **Manually and automatically classify and restrict access**| **Manually and automatically classify and restrict access**| **Manually and automatically classify and restrict access** |

+| Azure AD security groups| **Conditional Access policies for access not included in access packages**|N/A|N/A|N/A|

+### Entitlement management 

+Use entitlement management to provision and deprovision access to groups and teams, applications, and SharePoint sites. Define the connected organizations allowed access, self-service requests, and approval workflows. To ensure access ends correctly, define expiration policies and access reviews for packages.

+Learn more: [Create a new access package in entitlement management](../governance/entitlement-management-access-package-create.md)

+## Governance with Azure AD P1, Microsoft 365, Office 365 E3

+### Provision, sign-in, review access, and deprovision access

+Items in bold are recommended.

+| Azure AD B2B collaboration| **Invite by email, OTP, self-service**| Direct B2B federation| **Periodic partner review**| Remove account<br>Restrict sign-in |

+| Microsoft 365 or Office 365 groups|N/A|N/A|N/A|Group expiration or deletion<br>Removal from group |

+| Security groups|N/A| **Add external users to security groups (org, team, project, etc.)**|N/A| N/A|

+| Conditional Access policies|N/A| **Sign-in Conditional Access policies for external users**|N/A|N/A|

+### Resource access

+|Feature | App and resource access| SharePoint and OneDrive access| Teams access| Email and document security |

+| Microsoft 365 or Office 365 groups|N/A| **Access to group site(s) and associated content**|**Access to Microsoft 365 group teams and associated content**|N/A|

+| Sensitivity labels|N/A| Manually classify and restrict access| Manually classify and restrict access| Manually classify to restrict and encrypt |

+| Conditional Access policies| Conditional Access policies for access control|N/A|N/A|N/A|

+| Other methods|N/A| Restrict SharePoint site access with security groups<br>Disallow direct sharing| **Restrict external invitations from a team**|N/A|

+* [Determine your security posture for external access](1-secure-access-posture.md)

+* [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+* [Securing external access with groups](4-secure-access-groups.md)

+* [Transition to governed collaboration with Azure Active Directory B2B collaboration](5-secure-access-b2b.md)

+* [Manage external access with entitlement management](6-secure-access-entitlement-managment.md)

+* [Secure access with Conditional Access policies](7-secure-access-conditional-access.md)

+* [Control access with sensitivity labels](8-secure-access-sensitivity-labels.md)

+* [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business](9-secure-access-teams-sharepoint.md)

+Understanding collaboration helps secure external access to your resources. We recommend you read the following articles, first:

+* [Determine your security posture for external access](1-secure-access-posture.md)

+* [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+* [Create a security plan for external access](3-secure-access-plan.md)

+* [Securing external access with groups](4-secure-access-groups.md)

+Use the information in this article to move external collaboration into Azure Active Directory B2B (Azure AD B2B) collaboration.

+* See, [B2B collaboration overview](../external-identities/what-is-b2b.md)

+* Learn about: [External Identities in Azure Active Directory](../external-identities/external-identities-overview.md)

+## Control collaboration

+You can limit the organizations your users collaborate with (inbound and outbound), and who in your organization can invite guests. Most organizations permit business units to decide collaboration, and delegate approval and oversight. For example, organizations in government, education, and financial often don't permit open collaboration. You can use Azure AD features to control collaboration.

+You can control access your tenant, by deploying one or more of the following solutions:

+- **External Collaboration Settings** ΓÇô Restrict the email domains that invitations got to

+- **Cross Tenant Access Settings** ΓÇô Control application access by guests by user, group, or tenant (inbound). Control external Azure AD tenant and application access for users (outbound)

+- **Connected Organizations** ΓÇô Determine what organizations can request Access Packages in Entitlement Management

+Document the organizations you collaborate with, and organization users' domains, if needed. Domain-based restrictions might be impractical. One collaboration partner can have multiple domains, and a partner can add domains. For example, a partner with multiple business units, with separate domains, and add more domains as they configure synchronization.

+If your users use Azure AD B2B, you can discover the external Azure AD tenants they're collaborating, with via the sign-in logs, PowerShell, or a workbook. Learn more:

+* [Get MsIdCrossTenantAccessActivity](https://github.com/AzureAD/MSIdentityTools/wiki/Get-MSIDCrossTenantAccessActivity)

+* [Cross-tenant access activity workbook](../reports-monitoring/workbook-cross-tenant-access-activity.md)

+You can enable future collaboration with:

+- External organizations (most inclusive)

+- External organizations (but not denied organizations)

+- Specific external organizations (most restrictive)

+> If your collaboration settings are highly restrictive, your users might go outside the collaboration framework. We recommend you enable a broad collaboration that your security requirements allow.

+Limits to one domain can prevent authorized collaboration with organizations that have other unrelated domains. For example, the initial point of contact with Contoso might be a US-based employee with email that has a .com domain. However if you allow only the com domain. you can omit Canadian employees who have the ca domain.

+You can allow specific collaboration partners for a subset of users. For example, a university restricts student accounts from accessing external tenants, but allows faculty to collaborate with external organizations.

+### Allowlist and blocklist with External Collaboration Settings

+You can use an allowlist or blocklist to from specific organizations. You can use only an allow or a blocklist, not both.

+* **Allowlist** - Limit collaboration to a list of domains. All other domains are on the blocklist.

+* **Blocklist** - Allow collaboration with domains not on the blocklist

+Learn more: [Allow or block invitations to B2B users from specific organizations](../external-identities/allow-deny-list.md)

+> These lists don't apply to users in your directory. By default, they don't apply to OneDrive for Business and SharePoint allowlist or blocklists. These lists are separate, but you can enable [SharePoint-OneDrive B2B integration](/sharepoint/sharepoint-azureb2b-integration.md).

+Some organizations have a blocklist of bad-actor domains from a managed security provider. For example, if the organization does business with Contoso and uses a com domain, an unrelated organization can use the org domain, and attempt a phishing attack.

+### Cross Tenant Access Settings

+You can control inbound and outbound access using Cross Tenant Access Settings. In addition, you can trust multi-factor authentication (MFA), a compliant device, and hybrid Azure Active Directory joined device (HAADJ) claims from external Azure AD tenants. When you configure an organizational policy, it applies to the Azure AD tenant and covers users in that tenant, regardless of domain suffix.

+You can enable collaboration across Microsoft clouds such as Microsoft Azure operated by 21Vianet (Azure China) or Microsoft Azure Government. Determine if your collaboration partners reside in a different Microsoft cloud. Learn more: [Configure Microsoft cloud settings for B2B collaboration (Preview)](../external-identities/cross-cloud-settings.md).

+You can allow inbound access to specific tenants (allowlist), and set the default policy to block access. You then create organizational policies that allow access by user, group, or application.

+You can block access to tenants (blocklist). Set the default policy to Allow and then create organizational policies that block access to some tenants.

+> Cross Tenant Access Settings Inbound Access does not prevent invitations from being sent or redeemed. However, it does control applications access and whether a token is issued to the guest user. If the guest can redeem an invitation, policy blocks application access.

+To control external organizations users access, configure outbound access policies similarly to inbound access: allowlist and blocklist. Configure default and organization-specific policies.

+Learn more: [Configure cross-tenant access settings for B2B collaboration](../external-identities/cross-tenant-access-settings-b2b-collaboration.md)

+> [!NOTE]

+> Cross Tenant Access Settings apply to Azure AD tenants. To control access for partners not using Azure AD, use External Collaboration Settings.

+### Entitlement Management and Connected Organizations

+Use Entitlement Management to ensure automatic guest-lifecycle governance. Create Access Packages and publish them to external users or to Connected Organizations, which support Azure AD tenants and other domains. When you create an Access Package restrict access to specific Connected Organizations.

+Learn more: [What is entitlement management?](../governance/entitlement-management-overview.md)

+## Control external user access

+To begin collaboration, invite or enable a partner to access resources. Users gain access by:

+* [Azure Active Directory B2B collaboration invitation redemption](../external-identities/redemption-experience.md)

+* [Self-service sign-up](../external-identities/self-service-sign-up-overview.md)

+* [Requesting access to an access package in entitlement management](../governance/entitlement-management-request-access.md)

+When you enable Azure AD B2B, you can invite guest users with links and email invitations. Self service sign-up, and publishing Access Packages to the My Access portal, require more configuration.

+> [!NOTE]

+> Self service sign-up enforces no allowlist or blocklist in External Collaboration Settings. Use Cross Tenant Access Settings. You can integrate allowlists and blocklists with self service sign-up using custom API connectors. See, [Add an API connector to a user flow](../external-identities/self-service-sign-up-add-api-connector.md).

+### Guest user invitations

+* Most restrictive: Allow only administrators and users with the Guest Inviter role

+ * See, [Configure external collaboration settings](../external-identities/external-collaboration-settings-configure.md)

+* If security requirements permit, allow all UserType of Member to invite guests

+* Determine if UserType of Guest, the default Azure AD B2B user account, can invite guests

+ 

+### External users information

+Use Azure AD entitlement management to configure questions that external users answer. The questions appear to approvers to help them make a decision. You can configure sets of questions for each access package policy, so approvers have relevant information for access they approve. For example, ask vendors for their vendor contract number.

+Learn more: [Change approval and requestor information settings for an access package in entitlement management](../governance/entitlement-management-access-package-approval-policy.md)

+If you use a self-service portal, use API connectors to collect user attributes during sign-up. Use the attributes to assign access. You can create custom attributes in the Azure portal and use them in your self-service sign-up user flows. Read and write these attributes by using the Microsoft Graph API.

+Learn more:

+* [Use API connectors to customize and extend self-service sign-up](../external-identities/api-connectors-overview.md)

+* [Manage Azure AD B2C with Microsoft Graph](../../active-directory-b2c/microsoft-graph-operations.md)

+### Troubleshoot invitation redemption to Azure AD users

+Invited guest users from a collaboration partner can have trouble redeeming an invitation.

+* User domain isn't on an allowlist

+* The partnerΓÇÖs home tenant restrictions prevent external collaboration

+* The user isn't in partner Azure AD tenant. For example, users at contoso.com are in Active Directory.

+ * They can redeem invitations with the email one-time password (OTP).

+ * See, [Azure Active Directory B2B collaboration invitation redemption](../external-identities/redemption-experience.md)

+## External users access

+Generally, there are resources you can share with external users, and some you can't. You can control what external users access. See, [Manage external access with Entitlement Management](6-secure-access-entitlement-managment.md).

+By default, guest users see information and attributes about tenant members and other partners, including group memberships. Consider limiting external user access to this information.

+ 

+We recommend the following guest-user restrictions.

+* Limit guest access to browsing groups and other properties in the directory

+ * Use the external collaboration settings to restrict guests from reading groups they aren't members of

+* Block access to employee-only apps

+ * Create a Conditional Access policy to block access to Azure AD-integrated applications for non-guest users

+* Block access to the Azure portal

+ * You can make needed exceptions

+ * Create a Conditional Access policy with All guest and external users. Implement a policy to block access.

+Learn more: [Conditional Access: Cloud apps, actions, and authentication context](../conditional-access/concept-conditional-access-cloud-apps.md)

+## Remove users who don't need access

+Establish a process to review and remove users who don't need access. Include external users in your tenant as guests, and users with member accounts.

+Learn more: [Use Azure AD Identity Governance to review and remove external users who no longer have resource access](../governance/access-reviews-external-users.md)

+Some organizations add external users as members (vendors, partners, and contractors). Assign an attribute, or username:

+* Vendors: **v-**

+* Partners: **p-**

+* Contractors: **c-**

+Evaluate external users with member accounts to determine access. You might have guest users not invited through Entitlement Management or Azure AD B2B

+To find these users:

+* [Use Azure AD Identity Governance to review and remove external users who no longer have resource access](../governance/access-reviews-external-users.md)

+* Use a sample PowerShell script on [access-reviews-samples/ExternalIdentityUse/](https://github.com/microsoft/access-reviews-samples/tree/master/ExternalIdentityUse)

+## Transition current external users to B2B

+If you don't use Azure AD B2B, you likely have non-employee users in your tenant. We recommend you transition these accounts to Azure AD B2B external user accounts and then change their UserType to Guest. Use Azure AD and Microsoft 365 to handle external users.

+Include or exclude:

+* Guest users in Conditional Access policies

+* Guest users in Access Packages and Access Reviews

+* External access to Teams, SharePoint, and other resources

+You can transition these internal users while maintaining current access, UPN, and group memberships. See [Invite external users to B2B collaboration](../external-identities/invite-internal-users.md).

+## Decommission collaboration methods

+To complete the transition to governed collaboration, decommission unwanted collaboration methods. Decommissioning is based on the level of control to exert on collaboration, and the security posture. See, [Determine your security posture for external access](1-secure-access-posture.md).

+### Microsoft Teams invitation

+By default, Teams allows external access. The organization can communicate with external domains. To restrict or allow domains for Teams, use the [Teams admin center](https://admin.teams.microsoft.com/company-wide-settings/external-communications).

+### Sharing through SharePoint and OneDrive

+Sharing through SharePoint and OneDrive adds users not in the Entitlement Management process.

+* [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business](9-secure-access-teams-sharepoint.md)

+* [Block OneDrive use from Office](/office365/troubleshoot/group-policy/block-onedrive-use-from-office.md)

+### Documents in email

+Users send documents to external users by email. You can use sensitivity labels to restrict and encrypt access to documents. See, [Learn about sensitivity labels](/microsoft-365/compliance/sensitivity-labels?view=o365-worldwide&preserve-view=true).

+Your users likely use Google Docs, DropBox, Slack, or Zoom. You can block use of these tools from a corporate network, at the firewall level, and with mobile application management for organization-managed devices. However, this action blocks sanctioned instances and doesn't block access from unmanaged devices. Block tools you donΓÇÖt want, and create policies for no unsanctioned usage.

+For more information on governing applications, see:

+* [Governing connected apps](/defender-cloud-apps/governance-actions)

+* [Govern discovered apps](/defender-cloud-apps/governance-discovery)

+* [Determine your security posture for external access](1-secure-access-posture.md)

+* [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+* [Create a security plan for external access](3-secure-access-plan.md)

+* [Securing external access with groups](4-secure-access-groups.md)

+* [Manage external access with Entitlement Management](6-secure-access-entitlement-managment.md)

+* [Manage external access with Conditional Access policies](7-secure-access-conditional-access.md)

+* [Control access with sensitivity labels](8-secure-access-sensitivity-labels.md)

+* [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business](9-secure-access-teams-sharepoint.md)

+* **Microsoft 365 Multi Geo** - Microsoft 365 Multi-Geo provides customers with the ability to expand their Microsoft 365 presence to multiple geographic countries/regions within a single existing Microsoft 365 tenant. Azure Active Directory will egress customer data to perform backup authentication to the locations configured by the customer. Types of customer data include user and device account data, branding data, and service configuration data (application, policy, and group).

+ Title: Azure Active Directory deployment plans

+description: Guidance on Azure Active Directory deployment, such as authentication, devices, hybrid scenarios, governance, and more.

+Use the following guidance to help deploy Azure Active Directory (Azure AD). Learn about business value, planning considerations, and operational procedures. You can use a browser Print to PDF function to create offline documentation.

+## Your stakeholders

+When beginning your deployment plans, include your key stakeholders. Identify and document stakeholders, roles, responsibilities. Titles and roles can differ from one organization to another, however the ownership areas are similar.

+|Role |Responsibility |

+|Sponsor|An enterprise senior leader with authority to approve and/or assign budget and resources. The sponsor is the connection between managers and the executive team.|

+|End user|The people for whom the service is implemented. Users can participate in a pilot program.|

+|IT Support Manager|Provides input on the supportability of proposed changesΓÇ»|

+|Identity architect or Azure Global Administrator|Defines how the change aligns with identity management infrastructure|

+|Application business owner |Owns the affected application(s), which might include access management. Provides input on the user experience.

+|Security owner|Confirms the change plan meets security requirements|

+|Compliance manager|Ensures compliance with corporate, industry, or governmental requirements|

+### RACI

+RACI is an acronym derived from four key responsibilities:

+* **Responsible**

+* **Accountable**

+* **Consulted**

+* **Informed**

+Use these terms to clarify and define roles and responsibilities in your project, and for other cross-functional or departmental projects and processes.

+## Authentication

+Use the following list to plan for authentication deployment.

+* **Azure AD multi-factor authentication (MFA)** - Using admin-approved authentication methods, Azure AD MFA helps safeguard access to your data and applications while meeting the demand for a simple sign-in process:

+ * See the video, [How to configure and enforce multi-factor authentication in your tenant](https://www.youtube.com/watch?v=qNndxl7gqVM)

+ * See, [Plan an Azure Active Directory Multi-Factor Authentication deployment](../authentication/howto-mfa-getstarted.md)

+* **Conditional Access** - Implement automated access-control decisions for users to access cloud apps, based on conditions:

+ * See, [What is Conditional Access?](/azure/active-directory/conditional-access/overview)

+ * See, [Plan a Conditional Access deployment](../conditional-access/plan-conditional-access.md)

+* **Azure AD self-service password reset (SSPR)** - Help users reset a password without administrator intervention:

+ * See, [Passwordless authentication options for Azure AD](/articles/active-directory/authentication/concept-authentication-passwordless.md)

+ * See, [Plan an Azure Active Directory self-service password reset deployment](../authentication/howto-sspr-deployment.md)

+* **Passordless authentication** - Implement passwordless authentication using the Microsoft Authenticator app or FIDO2 Security keys:

+ * See, [Enable passwordless sign-in with Microsoft Authenticator](/azure/active-directory/authentication/howto-authentication-passwordless-phone)

+ * See, [Plan a passwordless authentication deployment in Azure Active Directory](../authentication/howto-authentication-passwordless-deployment.md)

+## Applications and devices

+Use the following list to help deploy applications and devices.

+* **Single sign-on (SSO)** - Enable user access to apps and resources while signing in once, without being required to enter credentials again:

+ * See, [What is SSO in Azure AD?](/articles/active-directory/manage-apps/what-is-single-sign-on.md)

+ * See, [Plan a SSO deployment](../manage-apps/plan-sso-deployment.md)

+* **My Apps portal** - A web-based portal to discover and access applications. Enable user productivity with self-service, for instance requesting access to groups, or managing access to resources on behalf of others.

+ * See, [My Apps portal overview](/azure/active-directory/manage-apps/myapps-overview)

+* **Devices** - Evaluate device integration methods with Azure AD, choose the implementation plan, and more.

+ * See, [Plan your Azure Active Directory device deployment](../devices/plan-device-deployment.md)

+## Hybrid scenarios

+The following list describes features and services for productivity gains in hybrid scenarios.

+* **Active Directory Federation Services (AD FS)** - Migrate user authentication from federation to cloud with pass-through authentication or password hash sync:

+ * See, [What is federation with Azure AD?](/articles/active-directory/hybrid/whatis-fed.md)

+ * See, [Migrate from federation to cloud authentication](../hybrid/migrate-from-federation-to-cloud-authentication.md)

+* **Azure AD Application Proxy** - Enable employees to be productive at any place or time, and from a device. Learn about software as a service (SaaS) apps in the cloud and corporate apps on-premises. Azure AD Application Proxy enables access without virtual private networks (VPNs) or demilitarized zones (DMZs):

+ * See, [Remote access to on-premises applications through Azure AD Application Proxy](/articles/active-directory/app-proxy/application-proxy.md)

+ * See, [Plan an Azure AD Application Proxy deployment](../app-proxy/application-proxy-deployment-plan.md)

+* **Seamless single sign-on (Seamless SSO)** - Use Seamless SSO for user sign-in, on corporate devices connected to a corporate network. Users don't need to enter passwords to sign in to Azure AD, and usually don't need to enter usernames. Authorized users access cloud-based apps without extra on-premises components:

+ * See, [Azure Active Directory SSO: Quickstart](../hybrid/how-to-connect-sso-quick-start.md)

+ * See, [Azure Active Directory Seamless SSO: Technical deep dive](/articles/active-directory/hybrid/how-to-connect-sso-how-it-works.md)

+## Users

+* **User identities** - Learn about automation to create, maintain, and remove user identities in cloud apps, such as Dropbox, Salesforce, ServiceNow, and more.

+ * See, [Plan an automatic user provisioning deployment in Azure Active Directory](../app-provisioning/plan-auto-user-provisioning.md)

+* **Identity governance** - Create identity governance and enhance business processes that rely on identity data. With HR products, such as Workday or Successfactors, manage employee and contingent-staff identity lifecycle with rules. These rules map Joiner-Mover-Leaver processes, such as New Hire, Terminate, Transfer, to IT actions such as Create, Enable, Disable.

+ * See, [Plan cloud HR application to Azure Active Directory user provisioning](../app-provisioning/plan-cloud-hr-provision.md)

+* **Azure AD B2B collaboration** - Improve external-user collaboration with secure access to applications:

+ * See, [B2B collaboration overview](/azure/active-directory/external-identities/what-is-b2b)

+ * See, [Plan an Azure Active Directory B2B collaboration deployment](../fundamentals/secure-external-access-resources.md)

+## Governance and reporting

+Use the following list to learn about governance and reporting. Items in the list refer to Microsoft Entra.

+Learn more: [Secure access for a connected worldΓÇömeet Microsoft Entra](https://www.microsoft.com/en-us/security/blog/?p=114039)

+* **Privileged identity management (PIM)** - Manage privileged administrative roles across Azure AD, Azure resources, and other Microsoft Online Services. Use it for just-in-time access, request approval workflows, and fully integrated access reviews to help prevent malicious activities:

+ * See, [Start using Privileged Identity Management](/azure/active-directory/privileged-identity-management/pim-getting-started)

+ * See, [Plan a Privileged Identity Management deployment](../privileged-identity-management/pim-deployment-plan.md)

+* **Reporting and monitoring** - Your Azure AD reporting and monitoring solution design has dependencies and constraints: legal, security, operations, environment, and processes.

+ * See, [Azure Active Directory reporting and monitoring deployment dependencies](../reports-monitoring/plan-monitoring-and-reporting.md)

+* **Access reviews** - Understand and manage access to resources:

+ * See, [What are access reviews?](/articles/active-directory/governance/access-reviews-overview.md)

+ * See, [Plan a Microsoft Entra access reviews deployment](../governance/deploy-access-reviews.md)

+* **Identity governance** - Meet your compliance and risk management objectives for access to critical applications. Learn how to enforce accurate access.

+ * See, [Govern access for applications in your environment](../governance/identity-governance-applications-prepare.md)

+

+Learn more: [Azure governance documentation](/azure/governance/)

+## Best practices for a pilot

+Use pilots to test with a small group, before making a change for larger groups, or everyone. Ensure each use case in your organization is tested.

+### Pilot: Phase 1

+In your first phase, target IT, usability, and other users who can test and provide feedback. Use this feedback to gain insights on potential issues for support staff, and to develop communications and instructions you send to all users.

+### Pilot: Phase 2

+Widen the pilot to larger groups of users by using dynamic membership, or by manually adding users to the targeted group(s).

+Learn more: [Dynamic membership rules for groups in Azure Active Directory](../enterprise-users/groups-dynamic-membership.md)]

+ Title: Azure Active Directory B2C deployment plans

+description: Azure Active Directory B2C deployment guide for planning, implementation, and monitoring

+Azure Active Directory B2C (Azure AD B2C) is an identity and access management solution that can ease integration with your infrastructure. Use the following guidance to help understand requirements and compliance throughout an Azure AD B2C deployment.

+### Requirements

+- Assess the primary reason to turn off systems

+ - See, [What is Azure Active Directory B2C?](../../active-directory-b2c/overview.md)

+- For a new application, plan the design of the Customer Identity Access Management (CIAM) system

+ - See, [Planning and design](../../active-directory-b2c/best-practices.md#planning-and-design)

+- Identify customer locations and create a tenant in the corresponding datacenter

+ - See, [Tutorial: Create an Azure Active Directory B2C tenant](../../active-directory-b2c/tutorial-create-tenant.md)

+- Confirm your application types and supported technologies:

+ - [Overview of the Microsoft Authentication Library (MSAL)](../develop/msal-overview.md)

+ - [Develop with open source languages, frameworks, databases, and tools in Azure](https://azure.microsoft.com/free/open-source/search/?OCID=AID2200277_SEM_f63bcafc4d5f1d7378bfaa2085b249f9:G:s&ef_id=f63bcafc4d5f1d7378bfaa2085b249f9:G:s&msclkid=f63bcafc4d5f1d7378bfaa2085b249f9).

+ - For back-end services, use the [client credentials](../develop/msal-authentication-flows.md#client-credentials) flow

+- To migrate from an identity provider (IdP):

+ - [Seamless migration](../../active-directory-b2c/user-migration.md#seamless-migration)

+ - Go to [azure-ad-b2c-user-migration](https://github.com/azure-ad-b2c/user-migration)

+- Select protocols

+ - If you use Kerberos, Microsoft Windows NT LAN Manager (NTLM), and Web Services Federation (WS-Fed), see the video, [Azure Active Directory: Application and identity migration to Azure AD B2C](https://www.bing.com/videos/search?q=application+migration+in+azure+ad+b2c&docid=608034225244808069&mid=E21B87D02347A8260128E21B87D02347A8260128&view=detail&FORM=VIRE)

+After migration, your applications can support modern identity protocols such as OAuth 2.0 and OpenID Connect (OIDC).

+Technology project success depends on managing expectations, outcomes, and responsibilities.

+- Identify the application architect, technical program manager, and owner

+- Create a distribution list (DL) to communicate with the Microsoft account or engineering teams

+ - Ask questions, get answers, and receive notifications

+- Identify a partner or resource outside your organization to support you

+Learn more: [Include the right stakeholders](./active-directory-deployment-plans.md)

+### Communications

+Communicate proactively and regularly with your users about pending and current changes. Inform them about how the experience changes, when it changes, and provide a contact for support.

+### Timelines

+Help set realistic expectations and make contingency plans to meet key milestones:

+- Pilot date

+- Launch date

+- Dates that affect delivery

+- Dependencies

+* **Deploy applications and user identities** - Deploy client application and migrate user identities

+* **Client application onboarding and deliverables** - Onboard the client application and test the solution

+* **Security** - Enhance the identity solution security

+* **Compliance** - Address regulatory requirements

+* **User experience** - Enable a user-friendly service

+* Before your applications interact with Azure AD B2C, register them in a tenant you manage

+ * See, [Tutorial: Create an Azure Active Directory B2C tenant](../../active-directory-b2c/tutorial-create-tenant.md)

+* For authorization, use the Identity Experience Framework (IEF) sample user journeys

+ * See, [Azure Active Directory B2C: Custom CIAM User Journeys](https://github.com/azure-ad-b2c/samples#local-account-policy-enhancements)

+* Use policy-based control for cloud-native environments

+ * Go to openpolicyagent.org to learn about [Open Policy Agent](https://www.openpolicyagent.org/) (OPA)

+Learn more with the Microsoft Identity PDF, [Gaining expertise with Azure AD B2C](https://aka.ms/learnaadb2c), a course for developers.

+### Checklist for personas, permissions, delegation, and calls

+* Identify the personas that access to your application

+* Define how you manage system permissions and entitlements today, and in the future

+* Confirm you have a permission store and if there are permissions to add to the directory

+* Define how you manage delegated administration

+ * For example, your customers' customers management

+* Verify your application calls an API Manager (APIM)

+ * There might be a need to call from the IdP before the application is issued a token

+Azure AD B2C projects start with one or more client applications.

+* [The new App registrations experience for Azure Active Directory B2C](../../active-directory-b2c/app-registrations-training-guide.md)

+ * Refer to [Azure Active Directory B2C code samples](../../active-directory-b2c/integrate-with-app-code-samples.md) for implementation

+* Set up your user journey based on custom user flows

+ * [Comparing user flows and custom policies](../../active-directory-b2c/user-flow-overview.md#comparing-user-flows-and-custom-policies)

+ * [Add an identity provider to your Azure Active Directory B2C tenant](../../active-directory-b2c/add-identity-provider.md)

+ * [Migrate users to Azure AD B2C](../../active-directory-b2c/user-migration.md)

+ * [Azure Active Directory B2C: Custom CIAM User Journeys](https://github.com/azure-ad-b2c/samples) for advanced scenarios

+### Application deployment checklist

+* Applications included in the CIAM deployment

+* Applications in use

+ * For example, web applications, APIs, single-page apps (SPAs), or native mobile applications

+* Authentication in use:

+ * For example, forms federated with SAML, or federated with OIDC

+ * If OIDC, confirm the response type: code or id_token

+* Determine where front-end and back-end applications are hosted: on-premises, cloud, or hybrid-cloud

+* Confirm the platforms or languages in use:

+ * For example ASP.NET, Java, and Node.js

+ * See, [Quickstart: Set up sign in for an ASP.NET application using Azure AD B2C](../../active-directory-b2c/quickstart-web-app-dotnet.md)

+* Verify where user attributes are stored

+ * For example, Lightweight Directory Access Protocol (LDAP) or databases

+### User identity deployment checklist

+* Confirm the number of users accessing applications

+* Determine the IdP types needed:

+ * For example, Facebook, local account, and Active Directory Federation Services (AD FS)

+ * See, [Active Directory Federation Services](/windows-server/identity/active-directory-federation-services)

+* Outline the claim schema required from your application, Azure AD B2C, and IdPs if applicable

+ * See, [ClaimsSchema](../../active-directory-b2c/claimsschema.md)

+* Determine the information to collect during sign-in and sign-up

+ * [Set up a sign-up and sign-in flow in Azure Active Directory B2C](../../active-directory-b2c/add-sign-up-and-sign-in-policy.md?pivots=b2c-user-flow)

+Use the following checklist for onboarding an application

+|Area|Description|

+|||

+|Application target user group | Select among end customers, business customers, or a digital service. </br>Determine a need for employee sign-in.|

+|Application business value| Understand the business need and/or goal to determine the best Azure AD B2C solution and integration with other client applications.|

+|Your identity groups| Cluster identities into groups with requirements, such as business-to-consumer (B2C), business-to-business (B2B) business-to-employee (B2E), and business-to-machine (B2M) for IoT device sign-in and service accounts.|

+|Identity provider (IdP)| See, [Select an identity provider](../../active-directory-b2c/add-identity-provider.md#select-an-identity-provider). For example, for a customer-to-customer (C2C) mobile app use an easy sign-in process. </br>B2C with digital services has compliance requirements. </br>Consider email sign-in. |

+|Regulatory constraints | Determine a need for remote profiles or privacy policies. |

+|Sign-in and sign-up flow | Confirm email verification or email verification during sign-up. </br>For check-out processes, see [How it works: Azure AD Multi-Factor Authentication](../authentication/concept-mfa-howitworks.md). </br>See the video, [Azure AD: Azure AD B2C user migration using Microsoft Graph API](https://www.youtube.com/watch?v=c8rN1ZaR7wk&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=4). |

+|Application and authentication protocol| Implement client applications such as Web application, single-page application (SPA), or native. </br>Authentication protocols for client application and Azure AD B2C: OAuth, OIDC, and SAML. </br>See the video, [Azure AD: Protecting Web APIs with Azure AD](https://www.youtube.com/watch?v=r2TIVBCm7v4&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=9).|

+| User migration | Confirm if you'll [migrate users to Azure AD B2C](../../active-directory-b2c/user-migration.md): Just-in-time (JIT) migration and bulk import/export. </br>See the video, [Azure Active Directory: Azure AD B2C user migration strategies](https://www.youtube.com/watch?v=lCWR6PGUgz0&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=2).|

+Use the following checklist for delivery.

+|Area| Description|

+|||

+|Protocol information| Gather the base path, policies, and metadata URL of both variants. </br>Specify attributes such as sample sign-in, client application ID, secrets, and redirects.|

+|Application samples | See, [Azure Active Directory B2C code samples](../../active-directory-b2c/integrate-with-app-code-samples.md).|

+|Penetration testing | Inform your operations team about pen tests, then test user flows including the OAuth implementation. </br>See, [Penetration testing](../../security/fundamentals/pen-testing.md) and [Penetration testing rules of engagement](https://www.microsoft.com/msrc/pentest-rules-of-engagement).

+| Unit testing | Unit test and generate tokens. </br>See, [Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials](../develop/v2-oauth-ropc.md). </br>If you reach the Azure AD B2C token limit, see [Azure AD B2C: File Support Requests](../../active-directory-b2c/support-options.md). </br>Reuse tokens to reduce investigation on your infrastructure. </br>[Set up a resource owner password credentials flow in Azure Active Directory B2C](../../active-directory-b2c/add-ropc-policy.md?pivots=b2c-user-flow&tabs=app-reg-ga).|

+| Load testing | Learn about [Azure AD B2C service limits and restrictions](../../active-directory-b2c/service-limits.md). </br>Calculate the expected authentications and user sign-ins per month. </br>Assess high load traffic durations and business reasons: holiday, migration, and event. </br>Determine expected peak rates for sign-up, traffic, and geographic distribution, for example per second.

+Use the following checklist to enhance application security.

+* Authentication method, such as multi-factor authentication (MFA):

+ * MFA is recommended for users that trigger high-value transactions or other risk events. For example, banking, finance, and check-out processes.

+ * See, [What authentication and verification methods are available in Azure AD?](../authentication/concept-authentication-methods.md)

+* Confirm use of anti-bot mechanisms

+* Assess the risk of attempts to create a fraudulent account or sign-in

+ * See, [Tutorial: Configure Microsoft Dynamics 365 Fraud Protection with Azure Active Directory B2C](../../active-directory-b2c/partner-dynamics-365-fraud-protection.md)

+* Confirm needed conditional postures as part of sign-in or sign-up

+#### Conditional Access and identity protection

+* The modern security perimeter now extends beyond an organization's network. The perimeter includes user and device identity.

+ * See, [What is Conditional Access?](../conditional-access/overview.md)

+* Enhance the security of Azure AD B2C with Azure AD identity protection

+ * See, [Identity Protection and Conditional Access in Azure AD B2C](../../active-directory-b2c/conditional-access-identity-protection-overview.md)

+To help comply with regulatory requirements and enhance back-end system security you can use virtual networks (VNets), IP restrictions, Web Application Firewall (WAF), etc. Consider the following requirements:

+* Your regulatory compliance requirements

+ * For example, Payment Card Industry Data Security Standard (PCI-DSS)

+ * Go to pcisecuritystandards.org to learn more about the [PCI Security Standards Council](https://www.pcisecuritystandards.org/)

+* Data storage into a separate database store

+ * Determine if this information can't be written into the directory

+Use the following checklist to help define user experience requirements.

+* Identify integrations to extend CIAM capabilities and build seamless end-user experiences

+ * [Azure Active Directory B2C ISV partners](../../active-directory-b2c/partner-gallery.md)

+* Use screenshots and user stories to show the application end-user experience

+ * For example, screenshots of sign-in, sign-up, sign-up/sign-in (SUSI), profile edit, and password reset

+* Look for hints passed through by using queryString parameters in your CIAM solution

+* For high user-experience customization, consider a using front-end developer

+* In Azure AD B2C, you can customize HTML and CSS

+ * See, [Guidelines for using JavaScript](../../active-directory-b2c/javascript-and-page-layout.md?pivots=b2c-custom-policy#guidelines-for-using-javascript)

+* Implement an embedded experience by using iframe support:

+ * See, [Embedded sign-up or sign-in experience](../../active-directory-b2c/embedded-login.md?pivots=b2c-custom-policy)

+ * For a single-page application, use a second sign-in HTML page that loads into the `<iframe>` element

+## Monitoring auditing, and logging

+Use the following checklist for monitoring, auditing, and logging.

+* Monitoring

+ * [Monitor Azure AD B2C with Azure Monitor](../../active-directory-b2c/azure-monitor.md)

+ * See the video [Azure Active Directory: Monitoring and reporting Azure AD B2C using Azure Monitor](https://www.youtube.com/watch?v=Mu9GQy-CbXI&list=PL3ZTgFEc7LyuJ8YRSGXBUVItCPnQz3YX0&index=1)

+* Auditing and logging

+ * [Accessing Azure AD B2C audit logs](../../active-directory-b2c/view-audit-logs.md)

+## Resources

+- [Register a Microsoft Graph application](../../active-directory-b2c/microsoft-graph-get-started.md)

+- [Manage Azure AD B2C with Microsoft Graph](../../active-directory-b2c/microsoft-graph-operations.md)

+[Recommendations and best practices for Azure Active Directory B2C](../../active-directory-b2c/best-practices.md)

+Azure AD is an Identity as a Service (IDaaS) solution that stores and manages identity and access data in the cloud. You can use the data to enable and manage access to cloud services, achieve mobility scenarios, and secure your organization. An instance of the Azure AD service, called a [tenant](/azure/active-directory/develop/developer-glossary#tenant), is an isolated set of directory object data that the customer provisions and owns.

+The Core Store is made up of tenants stored in scale units, each of which contains multiple tenants. Update or retrieval data operations in the Azure AD Core Store relate to a single tenant, based on the userΓÇÖs security token, which achieves tenant isolation. Scale units are assigned to a geo-location. Each geo-location uses two or more Azure regions to store the data. In each Azure region, a scale unit data is replicated in the physical data centers for resiliency and performance.

+Azure AD is available in the following clouds

+* Public

+* US government

+In the public cloud, you're prompted to select a location at the time of tenant creation (for example, signing up for Office 365 or Azure, or creating more Azure AD instances through the Azure portal). Azure AD maps the selection to a geo-location and a single scale unit in it. Tenant location canΓÇÖt be changed after itΓÇÖs set.

+The location selected during tenant creation will map to one of the following geo-locations:

+* Australia

+* Asia/Pacific

+* Europe, Middle East, and Africa (EMEA)

+* Japan

+* North America

+* Worldwide

+Azure AD handles Core Store data based on usability, performance, residency and/or other requirements based on geo-location. The term residency indicates Microsoft provides assurance the data isnΓÇÖt persisted outside the geo-location.

+Azure AD replicates each tenant through its scale unit, across data centers, based on the following criteria:

+* Azure AD Core Store data, stored in data centers closest to the tenant-residency location, to reduce latency and provide fast user sign-in times

+* Azure AD Core Store data stored in geographically isolated data centers to assure availability during unforeseen single-datacenter, catastrophic events

+* Compliance with data residency, or other requirements, for specific customers and geo-locations

+Use the following table to see Azure AD cloud solution models based on infrastructure, data location, and operational sovereignty.

+|Model|Locations|Data location|Operations personnel|Put a tenant in this model|

+||||||

+|Public geo located|North America, EMEA, Japan, Asia/Pacific|At rest, in the target location. Exceptions by service or feature|Operated by Microsoft. Microsoft datacenter personnel must pass a background check.|Create the tenant in the sign-up experience. Choose the location for data residency.|

+|Public worldwide|Worldwide|All locations|Operated by Microsoft. Microsoft datacenter personnel must pass a background check.|Tenant creation available via official support channel and subject to Microsoft discretion.|

+|Sovereign or national clouds|US government, China|At rest, in the target location. No exceptions.|Operated by a data custodian (1). Personnel are screened according to requirements.|Each national cloud instance has a sign-up experience.|

+(1) **Data custodians**: Data centers in the US government cloud are operated by Microsoft. In China, Azure AD is operated through a partnership with [21Vianet](/microsoft-365/admin/services-in-china/services-in-china?redirectSourcePath=%252fen-us%252farticle%252fLearn-about-Office-365-operated-by-21Vianet-a8ab5061-3346-4da0-bb7c-5260822b53ae&view=o365-21vianet&viewFallbackFrom=o365-worldwide&preserve-view=true).

+* [Customer data storage and processing for European customers in Azure AD](/azure/active-directory/fundamentals/active-directory-data-storage-eu)

+|Azure AD Authentication Service|This service is stateless. The data for authentication is in the Azure AD Core Store. It has no directory data. Azure AD Authentication Service generates log data in Azure storage, and in the data center where the service instance runs. When users attempt to authenticate using Azure AD, theyΓÇÖre routed to an instance in the geographically nearest data center that is part of its Azure AD logical region. |In geo location|

+|Azure AD Identity and Access Management (IAM) Services|**User and management experiences**: The Azure AD management experience is stateless and has no directory data. It generates log and usage data stored in Azure Tables storage. The user experience is like the Azure portal. <br>**Identity management business logic and reporting services**: These services have locally cached data storage for groups and users. The services generate log and usage data that goes to Azure Tables storage, Azure SQL, and in Microsoft Elastic Search reporting services. |In geo location|

+|Azure AD Domain Services|See regions where Azure AD Domain Services is published on [Products available by region](https://azure.microsoft.com/regions/services/). The service holds system metadata globally in Azure Tables, and it contains no personal data.|In geo location|

+|Azure AD Connect Health|Azure AD Connect Health generates alerts and reports in Azure Tables storage and blob storage.|In geo location|

+|Azure AD dynamic membership for groups, Azure AD self-service group management|Azure Tables storage holds dynamic membership rule definitions.|In geo location|

+|Azure AD Application Proxy|Azure AD Application Proxy stores metadata about the tenant, connector machines, and configuration data in Azure SQL.|In geo location|

+|Azure AD password writeback in Azure AD Connect|During initial configuration, Azure AD Connect generates an asymmetric keypair, using the RivestΓÇôShamirΓÇôAdleman (RSA) cryptosystem. It then sends the public key to the self-service password reset (SSPR) cloud service, which performs two operations: </br></br>1. Creates two Azure Service Bus relays for the Azure AD Connect on-premises service to communicate securely with the SSPR service </br> 2. Generates an Advanced Encryption Standard (AES) key, K1 </br></br> The Azure Service Bus relay locations, corresponding listener keys, and a copy of the AES key (K1) goes to Azure AD Connect in the response. Future communications between SSPR and Azure AD Connect occur over the new ServiceBus channel and are encrypted using SSL. </br> New password resets, submitted during operation, are encrypted with the RSA public key generated by the client during onboarding. The private key on the Azure AD Connect machine decrypts them, which prevents pipeline subsystems from accessing the plaintext password. </br> The AES key encrypts the message payload (encrypted passwords, more data, and metadata), which prevents malicious ServiceBus attackers from tampering with the payload, even with full access to the internal ServiceBus channel. </br> For password writeback, Azure AD Connect need keys and data: </br></br> - The AES key (K1) that encrypts the reset payload, or change requests from the SSPR service to Azure AD Connect, via the ServiceBus pipeline </br> - The private key, from the asymmetric key pair that decrypts the passwords, in reset or change request payloads </br> - The ServiceBus listener keys </br></br> The AES key (K1) and the asymmetric keypair rotate a minimum of every 180 days, a duration you can change during certain onboarding or offboarding configuration events. An example is a customer disables and re-enables password writeback, which might occur during component upgrade during service and maintenance. </br> The writeback keys and data stored in the Azure AD Connect database are encrypted by data protection application programming interfaces (DPAPI) (CALG_AES_256). The result is the master ADSync encryption key stored in the Windows Credential Vault in the context of the ADSync on-premises service account. The Windows Credential Vault supplies automatic secret re-encryption as the password for the service account changes. To reset the service account password invalidates secrets in the Windows Credential Vault for the service account. Manual changes to a new service account might invalidate the stored secrets.</br> By default, the ADSync service runs in the context of a virtual service account. The account might be customized during installation to a least-privileged domain service account, a managed service account (MSA), or a group managed service account (gMSA). While virtual and managed service accounts have automatic password rotation, customers manage password rotation for a custom provisioned domain account. As noted, to reset the password causes loss of stored secrets. |In geo location|

+|Azure AD Device Registration Service |Azure AD Device Registration Service has computer and device lifecycle management in the directory, which enable scenarios such as device-state conditional access, and mobile device management.|In geo location|

+|Azure AD provisioning|Azure AD provisioning creates, removes, and updates users in systems, such as software as service (SaaS) applications. It manages user creation in Azure AD and on-premises AD from cloud HR sources, like Workday. The service stores its configuration in an Azure Cosmos DB, which stores the group membership data for the user directory it keeps. Cosmos DB replicates the database to multiple datacenters in the same region as the tenant, which isolates the data, according to the Azure AD cloud solution model. Replication creates high availability and multiple reading and writing endpoints. Cosmos DB has encryption on the database information, and the encryption keys are stored in the secrets storage for Microsoft.|In geo location|

+|Azure AD business-to-business (B2B) collaboration|Azure AD B2B collaboration has no directory data. Users and other directory objects in a B2B relationship, with another tenant, result in user data copied in other tenants, which might have data residency implications.|In geo location|

+|Azure AD Identity Protection|Azure AD Identity Protection uses real-time user log-in data, with multiple signals from company and industry sources, to feed its machine-learning systems that detect anomalous logins. Personal data is scrubbed from real-time log-in data before itΓÇÖs passed to the machine learning system. The remaining log-in data identifies potentially risky usernames and logins. After analysis, the data goes to Microsoft reporting systems. Risky logins and usernames appear in reporting for Administrators.|In geo location|

+|Azure AD managed identities for Azure resources|Azure AD managed identities for Azure resources with managed identities systems can authenticate to Azure services, without storing credentials. Rather than use username and password, managed identities authenticate to Azure services with certificates. The service writes certificates it issues in Azure Cosmos DB in the East US region, which fail over to another region, as needed. Azure Cosmos DB geo-redundancy occurs by global data replication. Database replication puts a read-only copy in each region that Azure AD managed identities runs. To learn more, see [Azure services that can use managed identities to access other services](/azure/active-directory/managed-identities-azure-resources/managed-identities-status#azure-services-that-support-managed-identities-for-azure-resources). Microsoft isolates each Cosmos DB instance in an Azure AD cloud solution model. </br> The resource provider, such as the virtual machine (VM) host, stores the certificate for authentication, and identity flows, with other Azure services. The service stores its master key to access Azure Cosmos DB in a datacenter secrets management service. Azure Key Vault stores the master encryption keys.|In geo location|

+|Azure Active Directory B2C |[Azure AD B2C](/azure/active-directory-b2c/data-residency) is an identity management service to customize and manage how customers sign up, sign in, and manage their profiles when using applications. B2C uses the Core Store to keep user identity information. The Core Store database follows known storage, replication, deletion, and data-residency rules. B2C uses an Azure Cosmos DB system to store service policies and secrets. Cosmos DB has encryption and replication services on database information. Its encryption key is stored in the secrets storage for Microsoft. Microsoft isolates Cosmos DB instances in an Azure AD cloud solution model.|Customer-selectable geo location|

+For more information on data residency in Microsoft Cloud offerings, see the following articles:

+| Read attribute definitions | | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |

+| <ul><li>Read all attribute sets in a tenant</li><li>Read all attribute definitions in a tenant</li><li>Read all attribute assignments in a tenant for users</li><li>Read all attribute assignments in a tenant for applications (service principals)</li></ul> | [Attribute Assignment Reader](../roles/permissions-reference.md#attribute-assignment-reader) | <br/>Tenant |

+| <ul><li>Read attribute definitions in a scoped attribute set</li><li>Read attribute assignments that use attributes in a scoped attribute set for users</li><li>Read attribute assignments that use attributes in a scoped attribute set for applications (service principals)</li><li>**Cannot** read attributes in other attribute sets</li><li>**Cannot** read attribute assignments that use attributes in other attribute sets</li></ul> | [Attribute Assignment Reader](../roles/permissions-reference.md#attribute-assignment-reader) | <br/>Attribute set |

+Secure collaboration with your external partners ensures they have correct access to internal resources, and for the expected duration. Learn about governance practices to reduce security risks, meet compliance goals, and ensure accurate access.

+Governed collaboration improves clarity of ownership of access, reduces exposure of sensitive resources, and enables you to attest to access policy.

+* Manage external organizations, and their users who access resources

+* Ensure access is correct, reviewed, and time bound

+* Empower business owners to manage collaboration with delegation

+Traditionally, organizations use one of two methods to collaborate:

+* Create locally managed credentials for external users, or

+* Establish federations with partner identity providers (IdP)

+Both methods have drawbacks. For more information, see the following table.

+|-|||

+| Security | - Access continues after external user terminates<br> - UserType is Member by default, which grants too much default access | - No user-level visibility <br> - Unknown partner security posture|

+| Expense | - Password and multi-factor authentication (MFA) management<br> - Onboarding process<br> - Identity cleanup<br> - Overhead of running a separate directory | Small partners can't afford the infrastructure, lack expertise, and might user consumer email|

+| Complexity | Partner users manage more credentials | Complexity grows with each new partner, and increased for partners|

+Azure Active Directory (Azure AD) B2B integrates with other tools in Azure AD, and Microsoft 365 services. Azure AD B2B simplifies collaboration, reduces expense, and increases security.

+Azure AD B2B benefits:

+- If the home identity is disabled or deleted, external users can't access resources

+- User home IdP handles authentication and credential management

+- Resource tenant controls guest-user access and authorization

+- Collaborate with users who have an email address, but no infrastructure

+- IT departments don't connect out-of-band to set up access or federation

+- Guest user access is protected by the same security processes as internal users

+- Clear end-user experience with no extra credentials required

+- Users collaborate with partners without IT department involvement

+- Guest default permissions in the Azure AD directory aren't limited or highly restricted

+* [Determine your security posture for external access](1-secure-access-posture.md)

+* [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)

+* [Create a security plan for external access](3-secure-access-plan.md)

+* [Securing external access with groups](4-secure-access-groups.md)

+* [Transition to governed collaboration with Azure Active Directory B2B collaboration](5-secure-access-b2b.md)

+* [Manage external access with entitlement management](6-secure-access-entitlement-managment.md)

+* [Secure access with Conditional Access policies](7-secure-access-conditional-access.md)

+* [Control access with sensitivity labels](8-secure-access-sensitivity-labels.md)

+* [Secure external access to Microsoft Teams, SharePoint, and OneDrive for Business](9-secure-access-teams-sharepoint.md)

+Previously, the number of groups you could use when you conditionally change claims based on group membership within any single application configuration was limited to 10. The use of group membership conditions in SSO claims configuration has now increased to a maximum of 50 groups. For more information on how to configure claims, refer to [Enterprise Applications SSO claims configuration](../develop/active-directory-saml-claims-customization.md).

+1. On the workflows screen, select **Custom task extension**.

+1. On the custom task extensions page, select **Create custom task extension**.

+1. On the basics page you, enter a unique display name and description for the custom task extension and select **Next**.

+The following document provides an overview of a workflow created using Lifecycle Workflows. Workflows automate tasks based on the joiner-mover-leaver(JML) cycle of lifecycle management, and split tasks for users into categories of where they fall in the lifecycle of an organization. These categories extend into templates, where they can be quickly customized to suit the needs of users in your organization. For more information, see: [What are Lifecycle Workflows?](what-are-lifecycle-workflows.md).

+ [](media/understanding-lifecycle-workflows/workflow-2.png#lightbox)

+A workflow can be broken down into the following three main parts:

+|General information|This portion of a workflow covers basic information such as display name, and a description of what the workflow does.|

+|Execution conditions| Defines when(trigger), and for who(scope), a scheduled workflow will run. For more information on these two parameters, see [Trigger details](understanding-lifecycle-workflows.md#trigger-details) and [Configure Scope](understanding-lifecycle-workflows.md#configure-scope).|

+Creating a workflow via the Azure portal requires the use of a template. A Lifecycle Workflow template is a framework that is used for pre-defined tasks, and helps automate the creation of a workflow.

+The template, depending on its category, will define which tasks are available to be used, and then guide you through the creation of the workflow. The template provides input for basic description, execution conditions, and task information.

+>Depending on the template you select, the options that will be available may vary. The images in this document uses the [**Onboarding pre-hire employee**](lifecycle-workflow-templates.md#onboard-pre-hire-employee) template to illustrate the parts of a workflow.

+## Workflow overview

+Every workflow has its own overview section, where you can either take quick actions with the workflow, or view its details. This overview section is split into the three following parts:

+- Basic Information

+- My Feed

+- Quick Action

+In this section you'll learn what each section tells you, and what actions you'll be able to take from this information.

+### Basic Information

+When selecting a workflow, the overview provides you a list of basic details in the **Basic Information** section. These basic details provide you information such as the workflow category, its ID, when it was modified, and when it's scheduled to run again. This information is important in providing quick details surrounding its current usage for administrative purposes. Basic information is also live data, meaning any quick change action that you take place on the overview page, is shown immediately within this section.

+Within the **Basic Information** you can view the following information:

+ |Category|A string identifying the category of the workflow.|

+ |Date Created|The date and time the workflow was created.|

+ |Workflow ID|A unique identifier for the workflow.|

+ |Schedule|Defines if the workflow is currently scheduled to run.|

+ |Last run date|The last date and time the workflow ran.|

+ |Last Modified|The last date and time the workflow was modified.|

+### My Feed

+The **My Feed** section of the workflow overview contains a quick peek into when and how the workflow ran. This section also allows you to quickly jump to the target areas for more information. The following information is provided:

+- Next target run: The date and time of the next scheduled workflow run.

+- Total processed users: The total number of users processed by the workflow.

+- Processed users with failures: The total users processed with failed status by the workflow.

+- Failed tasks: The total number of failed

+- Number of tasks: The total number of tasks within the workflow.

+- Current version: How many new versions of the workflow have been created.

+### Quick Action

+The **Quick Action** section allows you to quickly take action with your workflow. These quick actions can either be making the workflow do something, or used for history or editing purposes. The following actions you can take are:

+- Run on Demand: Allows you to quickly run the workflow on demand. For more information on this process, see: [Run a workflow on-demand](on-demand-workflow.md)

+- Edit tasks: Allows you to add, delete, edit, or reorder tasks within the workflow. For more information on this process, see: [Edit the tasks of a workflow using the Azure portal](manage-workflow-tasks.md#edit-the-tasks-of-a-workflow-using-the-azure-portal)

+- View Workflow History: Allows you to view the history of the workflow. For more information on the three history perspectives, see: [Lifecycle Workflows history](lifecycle-workflow-history.md)

+Actions taken from the overview of a workflow allow you to quickly complete tasks, which can normally be done via the manage section of a workflow.

+[](media/understanding-lifecycle-workflows/workflow-11.png#lightbox)

+## Workflow basics

+After selecting a template, on the basics screen:

+ - Provide the information that will be used in the description portion of the workflow.

+ - The trigger, defines when of the execution condition.

+ [](media/understanding-lifecycle-workflows/workflow-4.png#lightbox)

+## Trigger details

+The trigger of a workflow defines when a scheduled workflow will run for users in scope for the workflow. The trigger is a combination of a time-based attribute, and an offset value. For example, if the attribute is employeeHireDate and offsetInDays is -1, then the workflow should trigger one day before the employee hire date. The value can range between -60 and 60 days.

+The time-based attribute can be either one of two values, which are automatically chosen based on the template in which you select during the creation of your workflow. The two values can be:

+- employeeHireDate: If the template is a joiner workflow.

+- employeeLeaveDateTime: If the template is a leaver workflow.

+These two values must be set within Azure AD for users. For more information on this process, see [How to synchronize attributes for Lifecycle workflows](how-to-lifecycle-workflow-sync-attributes.md)

+The offset determines how many days before or after the time-based attribute the workflow should be triggered. For example, if the attribute is employeeHireDate and offsetInDays is 7, then the workflow should trigger one week(7 days) before the employee hire date. The offsetInDays value can be as far ahead, or behind, as 60.

+## Configure scope

+[](media/understanding-lifecycle-workflows/workflow-5.png#lightbox)

+The scope defines for who the scheduled workflow will run. Configuring this parameter allows you to further narrow down the users for whom the workflow is to be executed.

+The scope is made up of the following two parts:

+- Scope type: Always preset as Rule based.

+- Rule: Where you can set expressions on user properties that define for whom the scheduled workflow will run. You can add extra expressions using **And, And not, Or, Or not** to create complex conditionals, and apply the workflow more granularly across your organization. Lifecycle Workflows supports a [rich set of user properties](/graph/api/resources/identitygovernance-rulebasedsubjectset#supported-user-properties-and-query-parameters) for configuring the scope.

+[](media/understanding-lifecycle-workflows/workflow-8.png#lightbox)

+For a detailed guide on setting the execution conditions for a workflow, see: [Create a lifecycle workflow.](create-lifecycle-workflow.md)

+## Scheduling

+While newly created workflows are enabled by default, scheduling is an option that must be enabled manually. To verify whether the workflow is scheduled, you can view the **Scheduled** column.

+Once scheduling is enabled, the workflow will be evaluated every three hours to determine whether or not it should run based on the execution conditions.

+To view a detailed guide on scheduling a workflow, see: [Customize the schedule of workflows](customize-workflow-schedule.md).

+> A workflow that is run on demand for a user does not take into account whether or not a user meets the workflow's execution conditions. It will apply the tasks regardless of whether the execution conditions are met by the user or not.

+For more information, see: [Run a workflow on-demand](on-demand-workflow.md)

+## History

+When you've selected a workflow, you can view its historical information through the lens of its users, runs, and tasks. Being able to view information specifically from these viewpoints allows you to quickly narrow down specific information about how a workflow was processed.

+For more information, see: [Lifecycle Workflows history](lifecycle-workflow-history.md)

+Workflow versions are separate workflows built using the same information of an original workflow, but with either the tasks or scope updated, so that they're reported differently within logs. Workflow versions can change the actions or even scope of an existing workflow.

+For more information, see: [Lifecycle Workflows Versioning](lifecycle-workflow-versioning.md)

+The User Principal Name (UPN) attribute is an internet communication standard for user accounts. A UPN consists of a prefix (user account name) and a suffix (DNS domain name). The prefix joins the suffix using the "\@" symbol. For example, someone@example.com. Ensure the UPN is unique among security principal objects in a directory forest.

+>This article assumes the UPN is the user identifier. It addresses UPN-change planning, and recovering from issues that might result from changes.

+>For developers, we recommend you use the user objectID as the immutable identifier, rather than UPN or email addresses.

+## UPN and their changes

+Sign-in pages often prompt users to enter an email address, when the value is their UPN. Therefore, change user UPN when their primary email address changes. User primary email address might change:

+* Rebranding

+* Employee moves to another division

+* Mergers and acquisitions

+* Employee name change

+### UPN change types

+Change the prefix, suffix, or both.

+* **Change the prefix**:

+ * BSimon@contoso.com becomes BJohnson@contoso.com

+ * Bsimon@contoso.com becomes Britta.Simon@contoso.com

+* **Changing the suffix**:

+ * Britta.Simon@contoso.com becomes Britta.Simon@contosolabs.com, or

+ * Britta.Simon@corp.contoso.com becomes Britta.Simon@labs.contoso.com

+We recommend you change user UPN when their primary email address changes. During initial synchronization from Active Directory to Azure AD, ensure user emails are identical to their UPNs.

+### UPNs in Active Directory

+In Active Directory, the default UPN suffix is the domain DNS name where you created the user account. In most cases, you register this domain name as the enterprise domain. If you create the user account in the contoso.com domain, the default UPN is: username@contoso.com. However, you can add more UPN suffixes by using Active Directory domains and trusts. Learn more: [Add your custom domain name using the Azure Active Directory portal](../fundamentals/add-custom-domain.md).

+For example, if you add labs.contoso.com and change the user UPNs and email to reflect that, the result is: username@labs.contoso.com.

+>[!IMPORTANT]

+> If you change the suffix in Active Directory, add and verify a matching custom domain name in Azure AD.

+> [Add your custom domain name using the Azure Active Directory portal](../fundamentals/add-custom-domain.md)

+ 

+### UPNs in Azure Active Directory

+Users sign in to Azure AD with their userPrincipalName attribute value.

+When you use Azure AD with on-premises Active Directory, user accounts are synchronized by using the Azure AD Connect service. The Azure AD Connect wizard uses the userPrincipalName attribute from the on-premises Active Directory as the UPN in Azure AD. You can change it to a different attribute in a custom installation.

+>[!NOTE]

+> Define a process for when you update a User Principal Name (UPN) of a user, or for your organization.

+When you synchronize user accounts from Active Directory to Azure AD, ensure the UPNs in Active Directory map to verified domains in Azure AD.

+ 

+If the userPrincipalName attribute value doesn't correspond to a verified domain in Azure AD, synchronization replaces the suffix with .onmicrosoft.com.

+### Bulk UPN change rollout

+Use our best practices to test bulk UPN changes. Have a tested roll-back plan for reverting UPNs if issues can't be resolved. After your pilot is running, target small user sets, with organizational roles, and sets of apps or devices. This process helps you understand the user experience. Include this information in your communications to stakeholders and users.

+Learn more: [Azure Active Directory deployment plans](../fundamentals/active-directory-deployment-plans.md)

+Create a procedure to change UPNs for individual users. We recommend a procedure that includes documentation about known issues and workarounds.

+Read the following sections for known issues and workarounds during UPN change.

+## Apps known issues and workarounds

+Software as a service (SaaS) and line of business (LoB) applications often rely on UPNs to find users and store user profile information, including roles. Applications potentially affected by UNP changes use just-in-time (JIT) provisioning to create a user profile when users initially sign in to the app.

+Learn more:

+* [What is SaaS?](https://azure.microsoft.com/overview/what-is-saas/)

+* [What is app provisioning in Azure Active Directory?](../app-provisioning/user-provisioning.md)

+### Known issues

+Changing user UPN can break the relationship between the Azure AD user and the user profile on the application. If the application uses JIT provisioning, it might create a new user profile. Then, the application administrator makes manual changes to fix the relationship.

+### Workarounds

+Use automated app provisioning in Azure AD to create, maintain, and remove user identities in supported cloud applications. Configure automated user provisioning on your applications to update UPNs on the applications. Test the applications to validate they aren't affected by UPN changes. If you're a developer, consider adding SCIM support to your application to enable automatic user provisioning.

+Learn more:

+* [What is app provisioning in Azure Active Directory?](../app-provisioning/user-provisioning.md)

+* [Tutorial: Develop and plan provisioning for a SCIM endpoint in Azure Active Directory](../app-provisioning/use-scim-to-provision-users-and-groups.md)

+## Managed devices known issues and workarounds

+If you bring your devices to Azure AD, you maximize user productivity with single sign-on (SSO) across cloud and on-premises resources.

+Learn more: [What is a device identity?](../devices/overview.md)

+### Azure AD joined devices

+Azure AD joined devices are joined to Azure AD. Users sign in to the device using their organization identity.

+Learn more: [Azure AD joined devices](../devices/concept-azure-ad-join.md)

+### Known issues and resolution

+Users might experience single sign-on issues with applications that depend on Azure AD for authentication. This issue was fixed in the Windows 10 May-2020 update (2004).

+### Workaround

+Allow enough time for the UPN change to sync to Azure AD. After you verify the new UPN appears in the Azure portal, ask the user to select the "Other user" tile to sign in with their new UPN. You can verify using PowerShell. See, [Get-AzureADUser](/powershell/module/azuread/get-azureaduser?view=azureadps-2.0&preserve-view=true). After users sign in with a new UPN, references to the old UPN might appear on the **Access work or school** Windows setting.

+ 

+### Hybrid Azure AD joined devices

+Hybrid Azure AD joined devices are joined to Active Directory and Azure AD. You can implement Hybrid Azure AD join if your environment has an on-premises Active Directory footprint.

+

+Learn more: [Hybrid Azure AD joined devices](../devices/concept-azure-ad-join-hybrid.md)

+### Known issues and resolution

+Windows 10 Hybrid Azure AD joined devices are likely to experience unexpected restarts and access issues. If users sign in to Windows before the new UPN synchronizes to Azure AD, or they continue using a Windows session, they might experience single sign-on (SSO) issues with apps that use Azure AD for authentication. This situation occurs if Conditional Access is configured to enforce the use of hybrid joined devices to access resources.

+In addition, the following message can appear, which forces a restart after one minute:

+Your PC will automatically restart in one minute. Windows ran into a problem and needs to restart. You should close this message now and save your work.

+This issue was fixed in the Windows 10 May-2020 update (2004).

+### Workaround

+1. Unjoin the device from Azure AD and restart.

+2. The device joins Azure AD.

+3. The user signs in by selecting the **Other user** tile.

+To unjoin a device from Azure AD, run the following command at a command prompt: dsregcmd/leave

+>[!NOTE]

+>The user re-enrolls for Windows Hello for Business, if it's in use.

+>[!TIP]

+>Windows 7 and 8.1 devices are not affected by this issue.

+## Mobile Application Management app protection policies

+### Known issues

+Your organization might use Mobile Application Management (MAM) to protect corporate data in apps on user devices. MAM app protection policies aren't resilient during UPN changes, which can break the connection between MAM enrollments and active users in MAM integrated applications. This scenario could leave data in an unprotected state.

+Learn more:

+* [App protection policies overview](/mem/intune/apps/app-protection-policy)

+* [Frequently asked questions about MAM and app protection](/mem/intune/apps/mam-faq)

+### Workaround

+IT admins can wipe data from affected devices, after UPN changes. This forces users to reauthenticate and reenroll with new UPNs.

+Learn more: [How to wipe only corporate data from Intune-managed apps](/mem/intune/apps/apps-selective-wipe)

+Your organization might require the Microsoft Authenticator app to sign in and access applications and data. Although a username might appear in the app, the account isn't a verification method until the user completes registration.

+Learn more: [How to use the Microsoft Authenticator app](https://support.microsoft.com/account-billing/how-to-use-the-microsoft-authenticator-app-9783c865-0308-42fb-a519-8cf666fe0acc)

+Microsoft Authenticator app has four main functions:

+* **Multi-factor authentication** with push notification or verification code

+* **Authentication broker** on iOS and Android devices fir SSO for applications using brokered authentication

+ * [Enable cross-app SSO on Android using MSAL](../develop/msal-android-single-sign-on.md)

+* **Device registration** or workplace join, to Azure AD, which is a requirement for Intune App Protection and Device Enrolment/Management

+* **Phone sign in**, which requires MFA and device registration

+### Multi-factor authentication with Android devices

+Use the Microsoft Authenticator app for out-of-band verification. Instead of an automated phone call, or SMS, to the user during sign-in, MFA pushes a notification to the Microsoft Authenticator app on the user device. The user selects **Approve**, or the user enters a PIN or biometric and selects **Authenticate**.

+Learn more: [How it works: Azure AD Multi-Factor Authentication](../authentication/concept-mfa-howitworks.md)

+When you change user UPN, the old UPN appears on the user account and notification might not be received. Use verification codes.

+Learn more: [Common questions about the Microsoft Authenticator app](/account-billing/common-problems-with-the-microsoft-authenticator-app-12d283d1-bcef-4875-9ae5-ac360e2945dd)

+If notification appears, instruct the user to dismiss it, open the Authenticator app, select **Check for notifications** and approve the MFA prompt. The UPN on the account updates. Note the updated UPN might appear as a new account. This change is due to other Authenticator functionality. For more information, see the known issues in this article.

+On Android and iOS. brokers like Microsoft Authenticator enable:

+* **SSO** - Users don't sign in to each application

+* **Device identification** - The broker accesses the device certificate created on the device when it was workplace-joined

+* **Application identification verification** - When an application calls the broker, it passes its redirect URL, and the broker verifies it

+In addition, applications can participate in other features:

+* [Azure AD Conditional Access documentation](../conditional-access/index.yml)

+* [Use Microsoft Authenticator or Intune Company Portal on Xamarin applications](../develop/msal-net-use-brokers-with-xamarin-apps.md).

+### Known issues

+Due to a mismatch, between the login_hint passed by the application and the UPN stored on the broker, the user experiences more interactive authentication prompts on new applications that use broker-assisted sign-in.

+### Workaround

+The user manually removes the account from Microsoft Authenticator and starts a new sign-in from a broker-assisted application. The account is added after initial authentication.

+The Microsoft Authenticator app registers the device in Azure AD, which allows the device to authenticate to Azure AD. This registration is a requirement for:

+* Intune app protection

+* Intune device enrollment

+* Phone sign-in

+### Known issues

+If you change UPN, a new account with the new UPN appears on the Microsoft Authenticator app. The account with the old UPN remains listed. Also, the old UPN appears on the Device Registration section in app settings. There's no change in functionality of Device Registration or dependant scenarios.

+### Workaround

+To remove references to the old UPN on the Microsoft Authenticator app, the user removes the old and new accounts from Microsoft Authenticator, re-registers for MFA, and rejoins the device.

+User phone sign-in for users to sign in to Azure AD without a password. To enable this feature, the user registers for MFA using the Authenticator app and then enables phone sign-in on Authenticator. The device registers with Azure AD.

+### Known issues

+Users can't use phone sign-in because they don't receive notification. If the user selects **Check for Notifications**, an error appears.

+### Workaround

+The user selects the drop-down menu on the account enabled for phone sign-in. Next, the user selects **Disable phone sign-in**. Phone sign-in can be re-enabled.

+## Security key (FIDO2) known issues and workarounds

+### Known issues

+When multiple users are registered on the same key, the sign-in screen shows account selection where the old UPN appears. Sign-in with security keys isn't affected by UPN changes.

+### Workaround

+To remove references to old UPNs, users reset the security key and re-register.

+Learn more: [Enable passwordless security key sign-in, Known issue, UPN changes](../authentication/howto-authentication-passwordless-security-key.md#known-issues)

+Learn more: [How UPN changes affect the OneDrive URL and OneDrive features](/sharepoint/upn-changes)

+Use Teams Meeting Notes to take and share notes.

+Learn more: [Take meeting notes in Teams](/office/take-meeting-notes-in-teams-3eadf032-0ef8-4d60-9e21-0691d317d103).

+### Known issues

+When a user UPN changes, meeting notes created under the old UPN are not accessible with Microsoft Teams or the Meeting Notes URL.

+### Workaround

+After the UPN change, users can recover meeting notes by downloading them from OneDrive

+1. Go to **My Files**.

+2. Select **Microsoft Teams Data**.

+3. Select **Wiki**.

+New meeting notes created after the UPN change aren't affected.

+ 1. Select **Grant access**, **Require multifactor authentication** and **Require password change**.

+| Risk policies | Sign-in and user risk policies (via Identity Protection or Conditional Access) | No | No | Yes |

+There are several possible reasons why the app didn't accept the response from Azure AD. If there's an error message or code displayed, use the following resources to diagnose the error:

+If the application expects another format for the **NameID** (User Identifier) attribute, see the [Edit nameID](../develop/active-directory-saml-claims-customization.md#edit-nameid) section to change the NameID format.

+description: Describes in detail the benefits and what you need to do to migrate your application authentication to Azure Active Directory (Azure AD).

+This article describes the benefits and how to plan for migrating your application authentication to Azure AD. It's intended for Azure administrators and identity professionals.

+The process is broken into four phases, each with detailed planning and exit criteria, and designed to help you plan your migration strategy and understand how Azure AD authentication supports your organizational goals.

+- Through a company homepage or portal

+- By bookmarking on their browsers

+- Through a vendorΓÇÖs URL for software as a service (SaaS) apps

+- Links pushed directly to userΓÇÖs desktops or mobile devices via a mobile device/application management (MDM/ MAM) solution

+To ensure that the users can easily and securely access applications, your goal is to have a single set of access controls and policies across your on-premises and cloud environments.

+

+Azure AD has a [full suite of identity management capabilities](../fundamentals/active-directory-whatis.md#which-features-work-in-azure-ad). Standardizing your app authentication and authorization to Azure AD gets you the benefits that these capabilities provide.

+Your organization may have multiple Identity Access Management (IAM) solutions in place. Migrating to one Azure AD infrastructure is an opportunity to reduce dependencies on IAM licenses (on-premises or in the cloud) and infrastructure costs. In cases where you may have already paid for Azure AD via Microsoft 365 licenses, there's no reason to pay the added cost of another IAM solution.

+With Azure AD, you can reduce infrastructure costs by:

+- Decoupling apps from the on-premises credential approach in your tenant by [setting up Azure AD as the trusted universal identity provider](../hybrid/plan-connect-user-signin.md#choosing-the-user-sign-in-method-for-your-organization).

+- Improve end-user [single sign-on (SSO)](./what-is-single-sign-on.md) experience through seamless and secure access to any application, from any device and any location.

+To comply with regulatory requirements, enforce corporate access policies and monitor user access to applications and associated data using integrated audit tools and APIs. With Azure AD, you can monitor application sign-ins through reports that use [Security Incident and Event Monitoring (SIEM) tools](../reports-monitoring/plan-monitoring-and-reporting.md). You can access the reports from the portal or APIs, and programmatically audit who has access to your applications and remove access to inactive users via access reviews.

+When technology projects fail, it's often due to mismatched expectations, the right stakeholders not being involved, or a lack of communication. Ensure your success by planning the project itself.

+| **Identity Architect / Azure AD App Administrator** | They're responsible for the following:<br /> - design the solution in cooperation with stakeholders<br /> - document the solution design and operational procedures for handoff to the operations team<br /> - manage the pre-production and production environments |

+Effective business engagement and communication are the keys to success. It's important to give stakeholders and end-users an avenue to get information and keep informed of schedule updates. Educate everyone about the value of the migration, what the expected timelines are, and how to plan for any temporary business disruption. Use multiple avenues such as briefing sessions, emails, one-to-one meetings, banners, and townhalls.

+In the following table you'll find the minimum suggested communication to keep your stakeholders informed:

+#### Plan phases and project strategy

+| **Complete / Sign Off** | Deploy the changes for the app to the production environment and execute against the production Azure AD tenant |

+The first decision point in an application migration is which apps to migrate, which if any should remain, and which apps to deprecate. There is always an opportunity to deprecate the apps that you will not use in your organization. There are several ways to find apps in your organization. While discovering apps, ensure you are including in-development and planned apps. Use Azure AD for authentication in all future apps.

+Using Active Directory Federation Services (AD FS) To gather a correct app inventory:

+ - Use the [Get-AzureRMWebApp](/powershell/module/azurerm.websites/get-azurermwebapp) cmdlet to get information about your Azure Web Apps.D

+We recommend updating the authentication stack code for these applications from the legacy protocol (such as Windows-Integrated Authentication, Kerberos Constrained Delegation, HTTP Headers-based authentication) to a modern protocol (such as SAML or OpenID Connect).

+- Their **functionality is highly redundant** with other systems

+- There is **no business owner**

+- There is clearly **no usage**

+DonΓÇÖt forget about your external partners. Make sure that they participate in migration schedules and testing. Finally, ensure they have a way to access your helpdesk if there were breaking issues.

+While some apps are easy to migrate, others may take longer due to multiple servers or instances. For example, SharePoint migration may take longer due to custom sign-in pages.

+- Make apps discoverable

+- Point your user to the [MyApps](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510#download-and-install-the-my-apps-secure-sign-in-extension)portal experience. Here, they can access all cloud-based apps, apps you make available by using [Azure AD Connect](../hybrid/whatis-azure-ad-connect.md), and apps using [Application Proxy](../app-proxy/application-proxy.md) provided they have permissions to access those apps.

+- [Hide applications from end-users](./hide-application-from-user-portal.md) (default Microsoft apps or other apps) to make the apps they do need more discoverable

+#### Let users access apps from their mobile devices

+Users can access the MyApps portal with Intune-managed browser on their [iOS](./hide-application-from-user-portal.md) 7.0 or later or [Android](./hide-application-from-user-portal.md) devices.

+Users can download an Intune-managed browser:

+- **For Android devices**, from the [Google play store](https://play.google.com/store/apps/details?id=com.microsoft.intune)

+#### Let users open their apps from a browser extension

+- Search for their apps and have their most-recently-used apps appear

+- Automatically convert internal URLs that you have configured in [Application Proxy](../app-proxy/application-proxy.md) to the appropriate external URLs. Your users can now work with the links they are familiar with no matter where they are.

+#### Let users open their apps from Office.com

+- **Azure Support:** You can call [Microsoft Support](https://azure.microsoft.com/support) and open a ticket for any Azure Identity deployment issue depending on your Enterprise Agreement with Microsoft.

+- Allow access to trusted applications that meet certain criteria and that protect against those applications that don't:

+ - [Configure user consent settings](./configure-user-consent.md?tabs=azure-portal) to allow users to only consent to applications that meet certain criteria, such as applications developed by your organization or from verified publishers and only for low risk permissions you select.

+ - Use applications that have been publisher verified. [Publisher verification](../develop/publisher-verification-overview.md) helps administrators and users understand the authenticity of application developers through a Microsoft supported vetting process. Even if an application does have a verified publisher, it is still important to review the consent prompt to understand and evaluate the request. For example, reviewing the permissions being requested to ensure they align with the scenario the app is requesting them to enable, additional app and publisher details on the consent prompt, etc.

+Azure Active Directory (Azure AD) supports modern authentication protocols that help keep applications secure. However, many business applications work in a protected corporate network, and some use legacy authentication methods. As companies build Zero Trust strategies and support hybrid and cloud environments, there are solutions that connect apps to Azure AD and provide authentication for legacy applications.

+Learn more: [Zero Trust Deployment Guide for Microsoft Azure Active Directory](/security/blog/2020/04/30/zero-trust-deployment-guide-azure-active-directory/)

+Azure AD natively supports modern protocols:

+* Security Assertion Markup Language (SAML)

+* Web Service Federation (WS-Fed)

+* OpenID Connect (OIDC)

+Azure Active Directory Application Proxy, or Azure AD App Proxy supports Kerberos and header-based authentication. Other protocols, like Secure Shell (SSH), (Microsoft Windows NT LAN Manager) NTLM, Lightweight Directory Access Protocol (LDAP), and cookies, aren't supported. But, independent software vendors (ISVs) can create solutions to connect these applications with Azure AD.

+ISVs can help customers discover and migrate software as a service (SaaS) applications into Azure AD. They can connect apps that use legacy authentication methods with Azure AD. Customers can consolidate onto Azure AD to simplify their app management and implement Zero Trust principles.

+## Solution overview

+The solution that you build can include the following parts:

+* **App discovery** - Often, customers aren't aware of every application in use

+ * Application discovery finds applications, facilitating app integrating with Azure AD

+* **App migration** - Create a workflow to integrate apps with Azure AD without using the Azure AD portal

+ * Integrate apps that customers use today

+* **Legacy authentication support** - Connect apps with legacy authentication methods and single sign-on (SSO)

+* **Conditional Access** - Enable customers to apply Azure AD policies to apps in your solution without using the Azure AD portal

+Learn more: [What is Conditional Access?](../conditional-access/overview.md)

+See the following sections for technical considerations and recommendations.

+## Publishing applications to Azure Marketplace

+Azure Marketplace is a trusted source of applications for IT admins. Applications are compatible with Azure AD and support SSO, automate user provisioning, and integrate into customer tenants with automated app registration.

+You can pre-integrate your application with Azure AD to support SSO and automated provisioning. See, [Submit a request to publish your application in Azure Active Directory application gallery](../manage-apps/v2-howto-app-gallery-listing.md).

+We recommend you become a verified publisher, so customers know you're the trusted publisher. See, [Publisher verification](../develop/publisher-verification-overview.md).

+## Enable single sign-on for IT admins

+There are several ways to enable SSO for IT administrators to your solution. See, [Plan a single sign-on deployment, SSO options](/azure/active-directory/manage-apps/plan-sso-deployment#single-sign-on-options).

+Microsoft Graph uses OIDC/OAuth. Customers use OIDC to sign in to your solution. Use the JSON Web Token (JWT) Azure AD issues to interact with Microsoft Graph. See, [OpenID Connect on the Microsoft identity platform](../develop/v2-protocols-oidc.md).

+If your solution uses SAML for IT administrator SSO, the SAML token won't enable your solution to interact with Microsoft Graph. You can use SAML for IT administrator SSO, but your solution needs to support OIDC integration with Azure AD, so it can get a JWT from Azure AD to interact with Microsoft Graph. See, [How the Microsoft identity platform uses the SAML protocol](/azure/active-directory/develop/active-directory-saml-protocol-reference).

+You can use one of the following SAML approaches:

+* **Recommended SAML approach**: Create a new registration in Azure Marketplace, which is an OIDC app. Customers add the SAML and OIDC apps to their tenant. If your application isn't in the Azure AD gallery, you can start with a non-gallery multi-tenant app.

+ * [Configure an OpenID Connect OAuth application from Azure AD app gallery](../saas-apps/openidoauth-tutorial.md)

+ * [Making your application multi-tenant](../develop/howto-convert-app-to-be-multi-tenant.md)

+* **Alternate SAML approach**: Customers can create an OIDC application registration in their Azure AD tenant and set the URIs, endpoints, and permissions

+Use the client credentials grant type, which requires the solution to allow customers to enter a client ID and secret. The solution also requires you store this information. Get a JWT from Azure AD, and then use it to interact with Microsoft Graph. See, [Get a token](../develop/v2-oauth2-client-creds-grant-flow.md#get-a-token). We recommend you repare customer documentation about how to create application registration in their Azure AD tenant. Include endpoints, URIs, and permissions.

+> [!NOTE]

+> Before applications are used for IT administrator or user SSO, the customer IT administrator must consent to the application in their tenant. See, [Grant tenant-wide admin consent to an application](./grant-admin-consent.md).

+## Authentication flows

+The solution authentication flows support the following scenarios:

+- The customer IT administrator signs in with SSO to administer your solution

+- The customer IT administrator uses your solution to integrate applications with Azure AD with Microsoft Graph

+- Users sign in to legacy applications secured by your solution and Azure AD

+### Your customer IT administrator does single sign-on to your solution

+Your solution can use SAML or OIDC for SSO, when the customer IT administrator signs in. We recommend the IT administrator signs in to your solution with their Azure AD credentials, which enables use of current security controls. Integrate your with Azure AD for SSO through SAML or OIDC.

+The following diagram illustrates the user authentication flow:

+ 

+1. The IT administrator signs in to your solution with their Azure AD credentials

+2. The solution redirects the IT administrator to Azure AD with a SAML or an OIDC sign-in request

+3. Azure AD authenticates the IT administrator and redirects them to your solution, with a SAML token or JWT to be authorized in your solution

+### IT administrators integrate applications with Azure AD

+IT administrators integrate applications with Azure AD by using your solution, which employs Microsoft Graph to create application registrations and Azure AD Conditional Access policies.

+The following diagram illustrates the user authentication flow:

+ 

+1. The IT administrator signs in to your solution with their Azure AD credentials

+2. The solution redirects the IT administrator to Azure AD with a SAML or an OIDC sign-in request

+3. Azure AD authenticates the IT administrator and redirects them to your solution with a SAML token or JWT for authorization

+4. When the IT administrator integrates an application with Azure AD, the solution calls Microsoft Graph with their JWT to register applications, or apply Azure AD Conditional Access policies

+### Users sign in to the applications

+When users sign in to applications, they use OIDC or SAML. If the applications need to interact with Microsoft Graph or Azure AD-protected API, we recommend you configure them to use OICD. This configuration ensures the JWT is applied to interact with Microsoft Graph. If there's no need for applications to interact with Microsoft Graph, or Azure AD protected APIs, then use SAML.

+The following diagram shows user authentication flow:

+ 

+1. The user signs in to an application

+2. The solution redirects the user to Azure AD with a SAML or an OIDC sign-in request

+3. Azure AD authenticates the user and redirects them to your solution with a SAML token or JWT for authorization

+4. The solution allows the request by using the application protocol

+## Microsoft Graph API

+We recommend use of the following APIs. Use Azure AD to configure delegated permissions or application permissions. For this solution, use delegated permissions.

+* **Applications templates API** - In Azure Marketplace, use this API to find a matching application template

+ * Permissions required: Application.Read.All

+* **Application registration API** - Create OIDC or SAML application registrations for users to sign in to applications secured with your solution

+ * Permissions required: Application.Read.All, Application.ReadWrite.All

+* **Service principal API** - After you register the app, update the service principal object to set SSO properties

+ * Permissions required: Application.ReadWrite.All, Directory.AccessAsUser.All, AppRoleAssignment.ReadWrite.All (for assignment)

+* **Conditional Access API** - Apply Azure AD Conditional Access policies to user applications

+ * Permissions required: Policy.Read.All, Policy.ReadWrite.ConditionalAccess, and Application.Read.All

+Learn more [Use the Microsoft Graph API](/graph/use-the-api?context=graph%2Fapi%2F1.0&view=graph-rest-1.0&preserve-view=true)

+## Microsoft Graph API scenarios

+Use the following information to implement application registrations, connect legacy applications, and enable Conditional Access policies. Learn to automate admin consent, get the token-signing certificate, and assign users and groups.

+### Use Microsoft Graph API to register apps with Azure AD

+#### Add apps in Azure Marketplace

+Some applications your customers use are in the [Azure Marketplace](https://azuremarketplace.microsoft.com/marketplace/apps). You can create a solution that adds applications to the customer tenant. Use the following example with Microsoft Graph API to search Azure Marketplace for a template.

+> [!NOTE]

+> In Application Templates API, the display name is case-sensitive.

+

+If you find a match from the API call, capture the ID. Make the following API call and provide a display name for the application in the JSON body:

+After you make the API call, you generate a service principal object. Capture the application ID and the service principal ID to use in the next API calls.

+Patch the service principal object with the SAML protocol and a login URL:

+Patch the application object with redirect URIs and the identifier URIs:

+#### Add apps not in Azure Marketplace

+If there's no match in Azure Marketplace, or to integrate a custom application, register a custom application in Azure AD with the template ID: 8adf8e6e-67b2-4cf2-a259-e3dc5476c621. Then, make the following API call and provide an application display name in the JSON body:

+After you make the API call, you generate a service principal object. Capture the application ID and the service principal ID to use in the next API calls.

+Patch the service principal object with the SAML protocol and a login URL:

+Patch the application object with redirect URIs and identifier URIs:

+#### Use Azure AD single sign-on

+After the SaaS applications are registered in Azure AD, the applications need to start using Azure AD as the identity provider (IdP):

+- **Applications support one-click SSO** - Azure AD enables the applications. In the Azure portal, the customer performs one-click SSO with the administrative credentials for the supported SaaS applications.

+ - Learn more: [One-click app configuration of single sign-on](./one-click-sso-tutorial.md)

+- **Applications don't support one-click SSO** - The customer enables the applications to use Azure AD.

+ - [Tutorials for integrating SaaS applications with Azure Active Directory](../saas-apps/tutorial-list.md)

+### Connect apps to Azure AD with legacy authentication

+Your solution can enable the customer to use SSO and Azure Active Directory features, even unsupported applications. To allow access with legacy protocols, your application calls Azure AD to authenticate the user and apply Azure AD Conditional Access policies. Enable this integration from your console. Create a SAML or an OIDC application registration between your solution and Azure AD.

+Use the following custom application template ID: 8adf8e6e-67b2-4cf2-a259-e3dc5476c621. Then, make the following API call and provide a display name in the JSON body:

+After you make the API call, you generate a service principal object. Capture the application ID and the service principal ID to use in the next API calls.

+Patch the service principal object with the SAML protocol and a login URL:

+Patch the application object with redirect URIs and identifier URIs:

+Use the following template ID for a custom application: 8adf8e6e-67b2-4cf2-a259-e3dc5476c621. Make the following API call and provide a display name in the JSON body:

+From the API call, capture the application ID and the service principal ID to use in the next API calls.

+> The API permissions in the `resourceAccess` node grant the application the openid, User.Read, and offline_access permissions, which enable sign-in. See, [Overview of Microsoft Graph permissions](/graph/permissions-overview).

+Customers and partners can use the Microsoft Graph API to create or apply Conditional Access policies to customer applications. For partners, customers can apply these policies from your solution without using the Azure portal. There are two options to apply Azure AD Conditional Access policies:

+- Assign the application to a Conditional Access policy

+- Create a new Conditional Access policy and assign the application to it

+#### Use a Conditional Access policy

+For a list of Conditional Access policies, run the following query. Get the policy object ID to modify.

+To patch the policy, include the application object ID to be in scope of `includeApplications`, in the JSON body:

+Add the application object ID to be in scope of `includeApplications`, in the JSON body:

+To create new Azure AD Conditional Access policies, see [Conditional Access: Programmatic access](../conditional-access/howto-conditional-access-apis.md).

+If the customer is adding applications from your solution to Azure AD, you can automate administrator consent with Microsoft Graph. You need the application service principal object ID you created in API calls, and the Microsoft Graph service principal object ID from the customer tenant.

+Get the Microsoft Graph service principal object ID by making the following API call:

+To automate admin consent, make the following API call:

+To get the public portion of the token-signing certificate, use `GET` from the Azure AD metadata endpoint for the application:

+After you publish the application to Azure AD, you can assign the app to users and groups to ensure it appears on the My Apps portal. This assignment is on the service principal object generated when you created the application. See, [My Apps portal overview](/azure/active-directory/manage-apps/myapps-overview).

+Get `AppRole` instances the application might have associated with it. It's common for SaaS applications to have various `AppRole` instances associated with them. Typically, for custom applications, there's one default `AppRole` instance. Get the `AppRole` instance ID you want to assign:

+From Azure AD, get the user or group object ID that you want to assign to the application. Take the app role ID from the previous API call and submit it with the patch body on the service principal:

+To help protect legacy applications, while using networking and delivery controllers, Microsoft has partnerships with the following application delivery controller (ADC) providers.

+* **Akamai Enterprise Application Access**

+ * [Tutorial: Azure AD SSO integration with Akamai](../saas-apps/akamai-tutorial.md)

+* **Citrix ADC**

+ * [Tutorial: Azure AD SSO integration with Citrix ADC SAML Connector for Azure AD (Kerberos-based authentication)](../saas-apps/citrix-netscaler-tutorial.md)

+* **F5 BIG-IP Access Policy Manager**

+ * [Tutorial: Azure AD SSO integration with Citrix ADC SAML Connector for Azure AD (Kerberos-based authentication)](./f5-aad-integration.md)

+* **Kemp LoadMaster**

+ * [Tutorial: Azure AD SSO integration with Kemp LoadMaster Azure AD integration](../saas-apps/kemp-tutorial.md)

+* **Pulse Secure Virtual Traffic Manager**

+ * [Tutorial: Azure AD SSO integration with Pulse Secure Virtual Traffic Manager](../saas-apps/pulse-secure-virtual-traffic-manager-tutorial.md)

+The following VPN solution providers connect with Azure AD to enable modern authentication and authorization methods like SSO and multifactor authentication (MFA).

+* **Cisco AnyConnect**

+ * [Tutorial: Azure AD SSO integration with Cisco AnyConnect](../saas-apps/cisco-anyconnect.md)

+* **Fortinet FortiGate**

+ * [Tutorial: Azure AD SSO integration with FortiGate SSL VPN](../saas-apps/fortigate-ssl-vpn-tutorial.md)

+* **F5 BIG-IP Access Policy Manager**

+ * [Tutorial: Configure F5 BIG-IP SSL-VPN for Azure AD SSO](./f5-aad-password-less-vpn.md)

+* **Palo Alto Networks GlobalProtect**

+ * [Tutorial: Azure AD SSO integration with Palo Alto Networks - Admin UI](../saas-apps/paloaltoadmin-tutorial.md)

+* **Pulse Connect Secure**

+ * [Tutorial: Azure AD SSO integration with Pulse Secure PCS](../saas-apps/pulse-secure-pcs-tutorial.md)

+The following software-defined perimeter (SDP) solutions providers connect with Azure AD for authentication and authorization methods like SSO and MFA.

+* **Datawiza Access Broker**

+ * [Tutorial: Configure Secure Hybrid Access with Azure AD and Datawiza](./datawiza-with-azure-ad.md)

+* **Perimeter 81**

+ * [Tutorial: Azure AD SSO integration with Perimeter 81](../saas-apps/perimeter-81-tutorial.md)

+* **Silverfort Authentication Platform**

+ * [Tutorial: Configure Secure Hybrid Access with Azure AD and Silverfort](./silverfort-azure-ad-integration.md)

+* **Strata Maverics Identity Orchestrator**

+ * [Integrate Azure AD SSO with Maverics Identity Orchestrator SAML Connector](../saas-apps/maverics-identity-orchestrator-saml-connector-tutorial.md)

+* **Zscaler Private Access**

+ * [Tutorial: Integrate Zscaler Private Access with Azure AD](../saas-apps/zscalerprivateaccess-tutorial.md)

+## December 2022

+### Updated articles

+- [Grant consent on behalf of a single user by using PowerShell](grant-consent-single-user.md)

+- [Tutorial: Configure F5 BIG-IP SSL-VPN for Azure AD SSO](f5-aad-password-less-vpn.md)

+- [Integrate F5 BIG-IP with Azure Active Directory](f5-aad-integration.md)

+- [Azure Active Directory application management: What's new](whats-new-docs.md)

+- [Deploy F5 BIG-IP Virtual Edition VM in Azure](f5-bigip-deployment-guide.md)

+- [End-user experiences for applications](end-user-experiences.md)

+- [Tutorial: Migrate your applications from Okta to Azure Active Directory](migrate-applications-from-okta-to-azure-active-directory.md)

+- [Tutorial: Configure F5 BIG-IP Access Policy Manager for Kerberos authentication](f5-big-ip-kerberos-advanced.md)

+- [Tutorial: Configure F5 BIG-IP Easy Button for Kerberos single sign-on](f5-big-ip-kerberos-easy-button.md)

+- [Tutorial: Configure F5 BIG-IP Easy Button for header-based and LDAP single sign-on](f5-big-ip-ldap-header-easybutton.md)

+Access Reviews for **Service Principals** requires an Entra Workload Identities Premium plan in addition to Azure AD Premium P2 license.

+When technology projects fail, itΓÇÖs typically because of mismatched expectations on impact, outcomes, and responsibilities. To avoid these pitfalls, [ensure that youΓÇÖre engaging the right stakeholders](../fundamentals/active-directory-deployment-plans.md) and that stakeholder roles in the project are well understood.

+>[!NOTE]

+>To see Conditional Access data in the sign-ins log, you need to be a user in one of the following roles:

+Company Administrator, Global Reader, Security Administrator, Security Reader, Conditional Access Administrator .

+# Customer intent: For an Azure AD administrator to monitor logs and report on access

+# Azure Active Directory reporting and monitoring deployment dependencies

+Your Azure Active Directory (Azure AD) reporting and monitoring solution depends on legal, security, operational requirements, and your environment's processes. Use the following sections to learn about design options and deployment strategy.

+## Benefits of Azure AD reporting and monitoring

+Azure AD reporting has a view, and logs, of Azure AD activity in your environment: sign-in and audit events, also changes to your directory.

+Use data output to:

+* [Azure Monitor data platform](../../azure-monitor/data-platform.md)

+* [Azure Monitor naming and terminology changes](../../azure-monitor/terminology.md)

+* [How long does Azure AD store reporting data?](./reference-reports-data-retention.md)

+## Stakeholders, communications, and documentation

+### Engage stakeholders

+Successful projects align expectations, outcomes, and responsibilities. See, [Azure Active Directory deployment plans](../fundamentals/active-directory-deployment-plans.md). Document and communicate stakeholder roles that require input and accountability.

+### Communications plan

+Tell your users when, and how, their experience will change. Provide contact information for support.

+### Considerations

+* **Retention** - Log retention: store audit logs and sign in logs of Azure AD longer than 30 days

+* **Analytics** - Logs are searchable with analytic tools

+* **Operational and security insights** - Provide access to application usage, sign-in errors, self-service usage, trends, etc.

+* **SIEM integration** - Integrate and stream Azure AD sign-in logs and audit logs to SIEM systems

+### Monitoring solution architecture

+With Azure AD monitoring, you can route Azure AD activity logs and retain them for long-term reporting and analysis to gain environment insights, and integrate it with SIEM tools. Use the following decision flow chart to help select an architecture.

+ 

+#### Archive logs in a storage account

+You can keep logs longer than the default retention period by routing them to an Azure storage account.

+ > [!IMPORTANT]

+ > Use this archival method if there is no need to integrate logs with a SIEM system, or no need for ongoing queries and analysis. You can use on-demand searches.

+Learn more:

+* [How long does Azure AD store reporting data?](./reference-reports-data-retention.md)

+* [Tutorial: Archive Azure AD logs to an Azure storage account](./quickstart-azure-monitor-route-logs-to-storage-account.md)

+* [Integrate Azure AD logs with Azure Monitor logs](./howto-integrate-activity-logs-with-log-analytics.md).

+* [Analyze Azure AD activity logs with Azure Monitor logs](/MicrosoftDocs/azure-docs/blob/main/articles/active-directory/reports-monitoring/howto-analyze-activity-logs-log-analytics.md).

+| December | 99.978% | 99.999% |

+> | Delete device | [Cloud Device Administrator](permissions-reference.md#cloud-device-administrator) | [Intune Administrator](permissions-reference.md#intune-administrator) |

+> | Disable device | [Cloud Device Administrator](permissions-reference.md#cloud-device-administrator) | [Intune Administrator](permissions-reference.md#intune-administrator) |

+> | Enable device | [Cloud Device Administrator](permissions-reference.md#cloud-device-administrator) | [Intune Administrator](permissions-reference.md#intune-administrator) |

+> | Read BitLocker keys | [Cloud Device Administrator](permissions-reference.md#cloud-device-administrator) | [Helpdesk Administrator](permissions-reference.md#helpdesk-administrator)<br/>[Intune Administrator](permissions-reference.md#intune-administrator)<br/>[Security Administrator](permissions-reference.md#security-administrator)<br/>[Security Reader](permissions-reference.md#security-reader) |

+1. On the **Set up single sign-on with SAML** page, In the **SAML Signing Certificate** section, click copy button to copy **App Federation Metadata Url** and save it on your computer.

+ 

+1. On the **Upload your metadata file** wizard, choose **Paste XML Link** option to paste the **App Federation Metadata URL** value, which you have copied from Azure portal and click **Validate**.

+ >[!NOTE]

+ > Alternatively, you can also upload the **Federation Metadata XML** file by clicking on the **Upload XML File** option.

+1. On the **Amazon connection data** wizard, please confirm your IDP has configured and click **Continue**.

+* Click on **Test this application** in Azure portal. This will redirect to Amazon Business Sign-on URL where you can initiate the login flow.

+* Go to the Amazon Business Single Sign-on URL directly and initiate the login flow from there.

+You can also use Microsoft My Apps to test the application in any mode. When you click the Amazon Business tile in the My Apps, if configured in SP mode you would be redirected to the application sign-on page for initiating the login flow and if configured in IDP mode, you should be automatically signed in to the Amazon Business for which you set up the SSO. For more information about the My Apps, see [Introduction to the My Apps](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510).

+ Title: 'Tutorial: Azure Active Directory SSO integration with Atlassian Cloud'

+# Tutorial: Azure Active Directory SSO integration with Atlassian Cloud

+* Click on **Test this application** in Azure portal. This will redirect to Atlassian Cloud Sign-on URL where you can initiate the login flow.

+You can also use Microsoft My Apps to test the application in any mode. When you click the Atlassian Cloud tile in the My Apps, if configured in SP mode you would be redirected to the application sign-on page for initiating the login flow and if configured in IDP mode, you should be automatically signed in to the Atlassian Cloud for which you set up the SSO. For more information about the My Apps, see [Introduction to the My Apps](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510).

+1. On the **Set up single sign-on with SAML** page, In the **SAML Signing Certificate** section, click copy button to copy **App Federation Metadata Url** and save it on your computer.

+ 

+2. Go to **Admin > Microsoft OneNote > Authentication**.

+3. Choose an authentication service as **SAML**.

+ 

+4. On the **Current Provider** page, perform the following steps:

+ 

+ a. In **IdP Metadata URI** textbox, paste the value of **App Federation Metadata URL** value, which you have copied from Azure portal.

+ b. Click **Save**.

+2. Go to **Admin > Microsoft OneNote > People**.

+3. Click **+People**.

+4. On the Add a New User dialog page, perform the following steps:

+ 

+ c. Click **Add User**.

+* Click on **Test this application** in Azure portal. This will redirect to Canvas Sign on URL where you can initiate the login flow.

+* Go to Canvas Sign on URL directly and initiate the login flow from there.

+ Title: 'Tutorial: Azure Active Directory SSO integration with CCH Tagetik'

+# Tutorial: Azure Active Directory SSO integration with CCH Tagetik

+ 

+1. On the **Basic SAML Configuration** section, perform the following steps:

+1. Perform the following step if you wish to configure the application in **SP** initiated mode:

+ `https://<CUSTOMER_NAME>.saastagetik.com/prod/`

+ 

+ 

+* Click on **Test this application** in Azure portal. This will redirect to CCH Tagetik Sign-on URL where you can initiate the login flow.

+You can also use Microsoft My Apps to test the application in any mode. When you click the CCH Tagetik tile in the My Apps, if configured in SP mode you would be redirected to the application sign-on page for initiating the login flow and if configured in IDP mode, you should be automatically signed in to the CCH Tagetik for which you set up the SSO. For more information about the My Apps, see [Introduction to the My Apps](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510).

+1. In the applications list, select **Facebook Work Accounts**.

+1. Select the **Provisioning** tab.

+1. Set the **Provisioning Mode** to **Automatic**.

+1. Under the **Admin Credentials** section, click on **Authorize**. You will be redirected to **Facebook Work Accounts**'s authorization page. Input your Facebook Work Accounts username and click on the **Continue** button. Click **Test Connection** to ensure Azure AD can connect to Facebook Work Accounts. If the connection fails, ensure your Facebook Work Accounts account has Admin permissions and try again.

+ :::image type="content" source="media/facebook-work-accounts-provisioning-tutorial/azure-connect.png" alt-text="Screenshot shows the Facebook Work Accounts authorization page.":::

+1. In the **Notification Email** field, enter the email address of a person or group who should receive the provisioning error notifications and select the **Send an email notification when a failure occurs** check box.

+1. Select **Save**.

+1. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Facebook Work Accounts**.

+1. Review the user attributes that are synchronized from Azure AD to Facebook Work Accounts in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in Facebook Work Accounts for update operations. If you choose to change the [matching target attribute](../app-provisioning/customize-application-attributes.md), you will need to ensure that the Facebook Work Accounts API supports filtering users based on that attribute. Select the **Save** button to commit any changes.

+1. To configure scoping filters, refer to the following instructions provided in the [Scoping filter tutorial](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+1. To enable the Azure AD provisioning service for Facebook Work Accounts, change the **Provisioning Status** to **On** in the **Settings** section.

+1. Define the users and/or groups that you would like to provision to Facebook Work Accounts by choosing the desired values in **Scope** in the **Settings** section.

+ 

+1. When you are ready to provision, click **Save**.

+ Title: 'Tutorial: Azure Active Directory SSO integration with JFrog Artifactory'

+# Tutorial: Azure Active Directory SSO integration with JFrog Artifactory

+ 

+ - For Artifactory Self-hosted: `https://<FQDN>/artifactory/webapp/saml/loginResponse`

+1. Perform the following step if you wish to configure the application in **SP** initiated mode:

+ - For Artifactory Self-hosted: `https://<FQDN>/<servername>/webapp/`

+1. In the **Set up Single Sign-On with SAML** page, in the **SAML Signing Certificate** section, locate the **Certificate (Base64)** and select **Download** to download the certificate and save it on your computer.

+ 

+1. Configure the Artifactory (SAML Service Provider Name) with the 'Identifier' field (see step 4). In the **Set up JFrog Artifactory** section, copy the appropriate URL(s) based on your requirement.

+ - For Artifactory Self-hosted: `https://<FQDN>/artifactory/webapp/saml/loginResponse`

+ 

+To configure single sign-on on **JFrog Artifactory** side, you need to send the downloaded **Certificate (Base64)** and appropriate copied URLs from Azure portal to [JFrog Artifactory support team](https://support.jfrog.com). They set this setting to have the SAML SSO connection set properly on both sides.

+* Click on **Test this application** in Azure portal. This will redirect to JFrog Artifactory Sign-on URL where you can initiate the login flow.

+You can also use Microsoft My Apps to test the application in any mode. When you click the JFrog Artifactory tile in the My Apps, if configured in SP mode you would be redirected to the application sign-on page for initiating the login flow and if configured in IDP mode, you should be automatically signed in to the JFrog Artifactory for which you set up the SSO. For more information about the My Apps, see [Introduction to the My Apps](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510).

+This tutorial describes the steps you need to perform in both Netpresenter Next and Azure Active Directory (Azure AD) to configure automatic user provisioning. When configured, Azure AD automatically provisions and de-provisions users and groups to [Netpresenter Next](https://www.Netpresenter.com/) using the Azure AD Provisioning service. For important details on what this service does, how it works, and frequently asked questions, see [Automate user provisioning and deprovisioning to SaaS applications with Azure Active Directory](../app-provisioning/user-provisioning.md).

+1. Determine who will be in [scope for provisioning](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+1. Determine what data to [map between Azure AD and Netpresenter Next](../app-provisioning/customize-application-attributes.md).

+1. Click on cogwheel icon to go to settings page.

+1. In the settings page, click on **System** to open the submenu and click on **Azure AD**.

+1. Click on the **Generate Token** button.

+1. Save the **SCIM Endpoint URL** and **Token** at a secure place, you'll need it in the **Step 5**.

+ 

+1. **Optional:** Under **Sign in options**, you can enable or disable 'Force sign in with Microsoft'. If enabled, users with an Azure AD account will lose the ability to sign in with their local account.

+Add Netpresenter Next from the Azure AD application gallery to start managing provisioning to Netpresenter Next. If you have previously setup Netpresenter Next for SSO, you can use the same application. However it's recommended that you create a separate app when testing out the integration initially. Learn more about adding an application from the gallery [here](../manage-apps/add-application-portal.md).

+## Step 4. Define who will be in scope for provisioning

+The Azure AD provisioning service allows you to scope who will be provisioned based on assignment to the application and or based on attributes of the user / group. If you choose to scope who will be provisioned to your app based on assignment, you can use the following [steps](../manage-apps/assign-user-or-group-access-portal.md) to assign users and groups to the application. If you choose to scope who will be provisioned based solely on attributes of the user or group, you can use a scoping filter as described [here](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+1. In the applications list, select **Netpresenter Next**.

+1. Select the **Provisioning** tab.

+1. Set the **Provisioning Mode** to **Automatic**.

+1. Under the **Admin Credentials** section, input your Netpresenter Next Tenant URL and Secret Token. Click **Test Connection** to ensure Azure AD can connect to Netpresenter Next. If the connection fails, ensure your Netpresenter Next account has Admin permissions and try again.

+ 

+1. In the **Notification Email** field, enter the email address of a person or group who should receive the provisioning error notifications and select the **Send an email notification when a failure occurs** check box.

+1. Select **Save**.

+1. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Netpresenter Next**.

+1. Review the user attributes that are synchronized from Azure AD to Netpresenter Next in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in Netpresenter Next for update operations. If you choose to change the [matching target attribute](../app-provisioning/customize-application-attributes.md), you'll need to ensure that the Netpresenter Next API supports filtering users based on that attribute. Select the **Save** button to commit any changes.

+1. To configure scoping filters, refer to the following instructions provided in the [Scoping filter tutorial](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

+1. To enable the Azure AD provisioning service for Netpresenter Next, change the **Provisioning Status** to **On** in the **Settings** section.

+1. Define the users and/or groups that you would like to provision to Netpresenter Next by choosing the desired values in **Scope** in the **Settings** section.

+ 

+1. When you're ready to provision, click **Save**.

+This operation starts the initial synchronization cycle of all users and groups defined in **Scope** in the **Settings** section. The initial cycle takes longer to perform than subsequent cycles, which occur approximately every 40 minutes as long as the Azure AD provisioning service is running.

+1. Check the [progress bar](../app-provisioning/application-provisioning-when-will-provisioning-finish-specific-user.md) to see the status of the provisioning cycle and how close it is to completion

+1. If the provisioning configuration seems to be in an unhealthy state, the application will go into quarantine. Learn more about quarantine states [here](../app-provisioning/application-provisioning-quarantine-status.md).

+1. Sign in to your [OfficeSpace Software Admin Console](https://support.officespacesoftware.com/s/). Navigate to **Settings > Connectors**.

+* [Learn how to review logs and get reports on provisioning activity](../app-provisioning/check-status-user-account-provisioning.md)

+* Azure AD Cloud Application Administrator or Application Administrator role.

+* OpenText XM Fax and XM SendSecure subscription.

+* OpenText XM Fax and XM SendSecure administrator account.

+* OpenText XM Fax and XM SendSecure supports **SP-initiated** SSO.

+ | `https://login.xmedius.com/{account}` |

+ | `https://login.xmedius.eu/{account}` |

+ | `https://login.xmedius.ca/{account}` |

+In this section, you'll create a test user in the Azure portal called B.Simon:

+ 1. In the **User name** field, enter the user name in the following format: username@companydomain.extension. For example, `B.Simon@contoso.com`.

+In this section, you'll enable B.Simon to use Azure single sign-on by granting access to OpenText XM Fax and XM SendSecure:

+ a. In the **Issuer (Identity Provider)** textbox, paste the **Azure AD Identifier** value which you have copied from the Azure portal.

+

+ b. In the **Sign In URL** textbox, paste the **Login URL** value which you have copied from the Azure portal.

+ c. Open the downloaded **Certificate (Base64)** from the Azure portal into Notepad and paste the content into the **X.509 Signing Certificate** textbox.

+ d. click **Save**.

+Create a user called Britta Simon at OpenText XM Fax and XM SendSecure. Make sure the email is set to "B.Simon@contoso.com".

+> [!NOTE]

+> Users must be created and activated before you use single sign-on.

+In this section, you test your Azure AD single sign-on configuration with the following options.

+* You can use Microsoft My Apps. When you click the OpenText XM Fax and XM SendSecure tile in the My Apps portal, this will redirect to OpenText XM Fax and XM SendSecure Sign-on URL. For more information about the My Apps portal, see [Introduction to the My Apps portal](../user-help/my-apps-portal-end-user-access.md).

+You'll need to log in to your Tranxfer application with the company administrator account.

+1. Go to **Settings -> SAML** and paste **App Federation Metadata Url** to **Metadata URL** field.

+1. If you want to give specific permissions to different user groups, you can match Azure AD groups to common **Tranxfer** permissions. To do so, fill in Azure AD group ID for each permission:

+ a. SEND permission to send files.

+ b. RECEIVE to receive files.

+ c. SEND + RECEIVE both of the above.

+ d. ADMIN company administration permission but not sending nor receiving files.

+ e. FULL all of the above.

+ 

+1. If you want to give any user of your organization, the simple Send and Receive permission no matter which groups they have, enable the **Empty groups with permission** option.

+1. If you want only match permissions by groups but don't want to import Azure AD groups to Tranxfer groups enable the **Disable import groups** option.

+If you find any problems, please contact [Tranxfer support team](mailto:soporte@tranxfer.com). The support team will assist you in configuring the single sign-on on the application.

+For details, see [Traffic Forwarding Using PAC Files](https://docs.trendmicro.com/en-us/enterprise/trend-micro-web-security-online-help/administration/pac-files/traffic-forwarding-u.aspx).

+ 

+ 

+ 

+Notes:

+* These instructions assume you are using the new [Single Sign On/Just-in-Time Provisioning feature from Veracode](https://docs.veracode.com/r/Signing_On). To activate this feature if it is not already active, please contact Veracode Support.

+* These instructions are valid for all [Veracode regions](https://docs.veracode.com/r/Region_Domains_for_Veracode_APIs).

+1. In a different web browser window, sign in to your Veracode company site as an administrator.

+ 

+1. In the **SAML Certificate** section, perform the following steps:

+ 

+ c. Note the values of the three URLs (**SAML Assertion URL**, **SAML Audience URL**, **Relay state URL**).

+ d. Click **Save**.

+

+1. Take the values of the **SAML Assertion URL**, **SAML Audience URL** and **Relay state URL** and update them in the Azure Active Directory settings for the Veracode integration.

+1. Select the **JIT Provisioning** tab.

+ 

+1. In the **Organization Settings** section, toggle the **Configure Default Settings for Just-in-Time user provisioning** setting to **On**.

+1. In the **Basic Settings** section, for **User Data Updates**, select **Prefer Veracode User Data**.

+1. In the **Access Settings** section, under **User Roles**, select from the following For more information about Veracode user roles, see the [Veracode Documentation](https://docs.veracode.com/r/c_role_permissions):

+ 

+# Tutorial: Azure Active Directory SSO integration with WebCE

+ a. In the **Identifier** textbox, type a URL using the following pattern:

+ `https://www.webce.com`

+ `https://www.webce.com/<RootPortalFolder>/login`

+* Click on **Test this application** in Azure portal. This will redirect to WebCE Sign-on URL where you can initiate the login flow.

+* Go to WebCE Sign-on URL directly and initiate the login flow from there.

+* You can use Microsoft My Apps. When you click the WebCE tile in the My Apps, this will redirect to WebCE Sign-on URL. For more information about the My Apps, see [Introduction to the My Apps](../user-help/my-apps-portal-end-user-access.md).

+

+ d. Fill the **Logout-URL** box with the value that's displayed behind the label **Logout URL** on the **Zenya SAML2 info** page. This page is still open in your other browser tab.

+* DoD CMMC website - [Office of the Under Secretary of Defense for Acquisition & Sustainment Cybersecurity Maturity Model Certification](https://dodcio.defense.gov/CMMC/)

+* Microsoft Download Center - [Microsoft Product Placemat for CMMC 2.0 (preview)](https://www.microsoft.com/download/details.aspx?id=102536)

+The following table provides a list of practice statement and objectives, and Azure AD guidance and recommendations to enable you to meet these requirements with Azure AD.

+| CMMC practice statement and objectives | Azure AD guidance and recommendations |

+| AU.L2-3.3.1<br><br>**Practice statement:** Create and retain system audit logs and records to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.<br><br>**Objectives:**<br>Determine if:<br>[a.] audit logs (for example, event types to be logged) to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity are specified;<br>[b.] the content of audit records needed to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity is defined;<br>[c.] audit records are created (generated);<br>[d.] audit records, once created, contain the defined content;<br>[e.] retention requirements for audit records are defined; and<br>[f.] audit records are retained as defined.<br><br>AU.L2-3.3.2<br><br>**Practice statement:** Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.<br><br>**Objectives:**<br>Determine if:<br>[a.] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined; and<br>[b.] audit records, once created, contain the defined content. | All operations are audited within the Azure AD audit logs. Each audit log entry contains a userΓÇÖs immutable objectID that can be used to uniquely trace an individual system user to each action. You can collect and analyze logs by using a Security Information and Event Management (SIEM) solution such as Microsoft Sentinel. Alternatively, you can use Azure Event Hubs to integrate logs with third-party SIEM solutions to enable monitoring and notification.<br>[Audit activity reports in the Azure Active Directory portal](/azure/active-directory/reports-monitoring/concept-audit-logs.md)<br>[Connect Azure Active Directory data to Microsoft Sentinel](/azure/sentinel/connect-azure-active-directory)<br>[Tutorial: Stream logs to an Azure event hub](/azure/active-directory/reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

+| AU.L2-3.3.4<br><br>**Practice statement:** Alert if an audit logging process fails.<br><br>**Objectives:**<br>Determine if:<br>[a.] personnel or roles to be alerted if an audit logging process failure is identified;<br>[b.] types of audit logging process failures for which alert will be generated are defined; and<br>[c] identified personnel or roles are alerted in the event of an audit logging process failure. | Azure Service Health notifies you about Azure service incidents so you can take action to mitigate downtime. Configure customizable cloud alerts for Azure Active Directory. <br>[What is Azure Service Health?](/azure/service-health/overview.md)<br>[Three ways to get notified about Azure service issues](https://azure.microsoft.com/blog/three-ways-to-get-notified-about-azure-service-issues/)<br>[Azure Service Health](https://azure.microsoft.com/get-started/azure-portal/service-health/) |

+| AU.L2-3.3.6<br><br>**Practice statement:** Provide audit record reduction and report generation to support on-demand analysis and reporting.<br><br>**Objectives:**<br>Determine if:<br>[a.] an audit record reduction capability that supports on-demand analysis is provided; and<br>[b.] a report generation capability that supports on-demand reporting is provided. | Ensure Azure AD events are included in event logging strategy. You can collect and analyze logs by using a Security Information and Event Management (SIEM) solution such as Microsoft Sentinel. Alternatively, you can use Azure Event Hubs to integrate logs with third-party SIEM solutions to enable monitoring and notification. Use Azure AD entitlement management with access reviews to ensure compliance status of accounts. <br>[Audit activity reports in the Azure Active Directory portal](/azure/active-directory/reports-monitoring/concept-audit-logs.md)<br>[Connect Azure Active Directory data to Microsoft Sentinel](/azure/sentinel/connect-azure-active-directory.md)<br>[Tutorial: Stream logs to an Azure event hub](/azure/active-directory/reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

+| AU.L2-3.3.8<br><br>**Practice statement:** Protect audit information and audit logging tools from unauthorized access, modification, and deletion.<br><br>**Objectives:**<br>Determine if:<br>[a.] audit information is protected from unauthorized access;<br>[b.] audit information is protected from unauthorized modification;<br>[c.] audit information is protected from unauthorized deletion;<br>[d.] audit logging tools are protected from unauthorized access;<br>[e.] audit logging tools are protected from unauthorized modification; and<br>[f.] audit logging tools are protected from unauthorized deletion.<br><br>AU.L2-3.3.9<br><br>**Practice statement:** Limit management of audit logging functionality to a subset of privileged users.<br><br>**Objectives:**<br>Determine if:<br>[a.] a subset of privileged users granted access to manage audit logging functionality is defined; and<br>[b.] management of audit logging functionality is limited to the defined subset of privileged users. | Azure AD logs are retained by default for 30 days. These logs are unable to modified or deleted and are only accessible to limited set of privileged roles.<br>[Sign-in logs in Azure Active Directory](/azure/active-directory/reports-monitoring/concept-sign-ins.md)<br>[Audit logs in Azure Active Directory](/azure/active-directory/reports-monitoring/concept-audit-logs.md)

+The following table provides a list of practice statement and objectives, and Azure AD guidance and recommendations to enable you to meet these requirements with Azure AD.

+| CMMC practice statement and objectives | Azure AD guidance and recommendations |

+| CM.L2-3.4.2<br><br>**Practice statement:** Establish and enforce security configuration settings for information technology products employed in organizational systems.<br><br>**Objectives:**<br>Determine if:<br>[a.] security configuration settings for information technology products employed in the system are established and included in the baseline configuration; and<br>[b.] security configuration settings for information technology products employed in the system are enforced. | Adopt a zero-trust security posture. Use conditional access policies to restrict access to compliant devices. Configure policy settings on the device to enforce security configuration settings on the device with MDM solutions such as Microsoft Intune. Microsoft Endpoint Configuration Manager(MECM) or group policy objects can also be considered in hybrid deployments and combined with conditional access require hybrid Azure AD joined device.<br><br>**Zero-trust**<br>[Securing identity with Zero Trust](/security/zero-trust/identity.md)<br><br>**Conditional access**<br>[What is conditional access in Azure AD?](/azure/active-directory/conditional-access/overview.md)<br>[Grant controls in Conditional Access policy](/azure/active-directory/conditional-access/concept-conditional-access-grant.md)<br><br>**Device policies**<br>[What is Microsoft Intune?](/mem/intune/fundamentals/what-is-intune.md)<br>[What is Defender for Cloud Apps?](/cloud-app-security/what-is-cloud-app-security.md)<br>[What is app management in Microsoft Intune?](/mem/intune/apps/app-management.md)<br>[Microsoft Endpoint Manager overview](/mem/endpoint-manager-overview.md) |

+| CM.L2-3.4.5<br><br>**Practice statement:** Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.<br><br>**Objectives:**<br>Determine if:<br>[a.] physical access restrictions associated with changes to the system are defined;<br>[b.] physical access restrictions associated with changes to the system are documented;<br>[c.] physical access restrictions associated with changes to the system are approved;<br>[d.] physical access restrictions associated with changes to the system are enforced;<br>[e.] logical access restrictions associated with changes to the system are defined;<br>[f.] logical access restrictions associated with changes to the system are documented;<br>[g.] logical access restrictions associated with changes to the system are approved; and<br>[h.] logical access restrictions associated with changes to the system are enforced. | Azure Active Directory (Azure AD) is a cloud-based identity and access management service. Customers don't have physical access to the Azure AD datacenters. As such, each physical access restriction is satisfied by Microsoft and inherited by the customers of Azure AD. Implement Azure AD role based access controls. Eliminate standing privileged access, provide just in time access with approval workflows with Privileged Identity Management.<br>[Overview of Azure Active Directory role-based access control (RBAC)](/azure/active-directory/roles/custom-overview.md)<br>[What is Privileged Identity Management?](/azure/active-directory/privileged-identity-management/pim-configure.md)<br>[Approve or deny requests for Azure AD roles in PIM](/azure/active-directory/privileged-identity-management/azure-ad-pim-approval-workflow.md) |

+| CM.L2-3.4.6<br><br>**Practice statement:** Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.<br><br>**Objectives:**<br>Determine if:<br>[a.] essential system capabilities are defined based on the principle of least functionality; and<br>[b.] the system is configured to provide only the defined essential capabilities. | Configure device management solutions (Such as Microsoft Intune) to implement a custom security baseline applied to organizational systems to remove non-essential applications and disable unnecessary services. Leave only the fewest capabilities necessary for the systems to operate effectively. Configure conditional access to restrict access to compliant or hybrid Azure AD joined devices. <br>[What is Microsoft Intune](/mem/intune/fundamentals/what-is-intune.md)<br>[Require device to be marked as compliant](../conditional-access/require-managed-devices.md)<br>[Grant controls in Conditional Access policy - Require hybrid Azure AD joined device](../conditional-access/concept-conditional-access-grant.md) |

+| CM.L2-3.4.7<br><br>**Practice statement:** Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.<br><br>**Objectives:**<br>Determine if:<br>[a.]essential programs are defined;<br>[b.] the use of nonessential programs is defined;<br>[c.] the use of nonessential programs is restricted, disabled, or prevented as defined;<br>[d.] essential functions are defined;<br>[e.] the use of nonessential functions is defined;<br>[f.] the use of nonessential functions is restricted, disabled, or prevented as defined;<br>[g.] essential ports are defined;<br>[h.] the use of nonessential ports is defined;<br>[i.] the use of nonessential ports is restricted, disabled, or prevented as defined;<br>[j.] essential protocols are defined;<br>[k.] the use of nonessential protocols is defined;<br>[l.] the use of nonessential protocols is restricted, disabled, or prevented as defined;<br>[m.] essential services are defined;<br>[n.] the use of nonessential services is defined; and<br>[o.] the use of nonessential services is restricted, disabled, or prevented as defined. | Use Application Administrator role to delegate authorized use of essential applications. Use App Roles or group claims to manage least privilege access within application. Configure user consent to require admin approval and don't allow group owner consent. Configure Admin consent request workflows to enable users to request access to applications that require admin consent. Use Microsoft Defender for Cloud Apps to identify unsanctioned/unknown application use. Use this telemetry to then determine essential/non-essential apps.<br>[Azure AD built-in roles - Application Administrator](/azure/active-directory/roles/permissions-reference.md)<br>[Azure AD App Roles - App Roles vs. Groups ](/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps.md)<br>[Configure how users consent to applications](/azure/active-directory/manage-apps/configure-user-consent?tabs=azure-portal.md)<br>[Configure group owner consent to apps accessing group data](/azure/active-directory/manage-apps/configure-user-consent-groups?tabs=azure-portal.md)<br>[Configure the admin consent workflow](/azure/active-directory/manage-apps/configure-admin-consent-workflow.md)<br>[What is Defender for Cloud Apps?](/defender-cloud-apps/what-is-defender-for-cloud-apps.d)<br>[Discover and manage Shadow IT tutorial](/defender-cloud-apps/tutorial-shadow-it.md) |

+| CM.L2-3.4.8<br><br>**Practice statement:** Apply deny-by-exception (blocklist) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (allowlist) policy to allow the execution of authorized software.<br><br>**Objectives:**<br>Determine if:<br>[a.] a policy specifying whether allowlist or blocklist is to be implemented is specified;<br>[b.] the software allowed to execute under allowlist or denied use under blocklist is specified; and<br>[c.] allowlist to allow the execution of authorized software or blocklist to prevent the use of unauthorized software is implemented as specified.<br><br>CM.L2-3.4.9<br><br>**Practice statement:** Control and monitor user-installed software.<br><br>**Objectives:**<br>Determine if:<br>[a.] a policy for controlling the installation of software by users is established;<br>[b.] installation of software by users is controlled based on the established policy; and<br>[c.] installation of software by users is monitored. | Configure MDM/configuration management policy to prevent the use of unauthorized software. Configure conditional access grant controls to require compliant or hybrid joined device to incorporate device compliance with MDM/configuration management policy into the conditional access authorization decision.<br>[What is Microsoft Intune](/mem/intune/fundamentals/what-is-intune.md)<br>[Conditional Access - Require compliant or hybrid joined devices](/azure/active-directory/conditional-access/howto-conditional-access-policy-compliant-device.md) |

+The following table provides a list of practice statement and objectives, and Azure AD guidance and recommendations to enable you to meet these requirements with Azure AD.

+| CMMC practice statement and objectives | Azure AD guidance and recommendations |

+| IR.L2-3.6.1<br><br>**Practice statement:** Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.<br><br>**Objectives:**<br>Determine if:<br>[a.] an operational incident-handling capability is established;<br>[b.] the operational incident-handling capability includes preparation;<br>[c.] the operational incident-handling capability includes detection;<br>[d.] the operational incident-handling capability includes analysis;<br>[e.] the operational incident-handling capability includes containment;<br>[f.] the operational incident-handling capability includes recovery; and<br>[g.] the operational incident-handling capability includes user response activities. | Implement incident handling and monitoring capabilities. The audit logs record all configuration changes. Authentication and authorization events are audited within the sign-in logs, and any detected risks are audited in the Identity Protection logs. You can stream each of these logs directly into a SIEM solution, such as Microsoft Sentinel. Alternatively, use Azure Event Hubs to integrate logs with third-party SIEM solutions.<br><br>**Audit events**<br>[Audit activity reports in the Azure Active Directory portal](/azure/active-directory/reports-monitoring/concept-audit-logs.md)<br>[Sign-in activity reports in the Azure Active Directory portal](/azure/active-directory/reports-monitoring/concept-sign-ins.md)<br>[How To: Investigate risk](/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk.md)<br><br>**SIEM integrations**<br>[Microsoft Sentinel : Connect data from Azure Active Directory (Azure AD)](/azure/sentinel/connect-azure-active-directory.md)[Stream to Azure event hub and other SIEMs](/azure/active-directory/reports-monitoring/tutorial-azure-monitor-stream-logs-to-event-hub.md) |

+The following table provides a list of practice statement and objectives, and Azure AD guidance and recommendations to enable you to meet these requirements with Azure AD.

+| CMMC practice statement and objectives | Azure AD guidance and recommendations |

+| MA.L2-3.7.5<br><br>**Practice statement:** Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.<br><br>**Objectives:**<br>Determine if:<br>[a.] multifactor authentication is used to establish nonlocal maintenance sessions via external network connections; and<br>[b.] nonlocal maintenance sessions established via external network connections are terminated when nonlocal maintenance is complete.| Accounts assigned administrative rights are targeted by attackers, including accounts used to establish non-local maintenance sessions. Requiring multifactor authentication (MFA) on those accounts is an easy way to reduce the risk of those accounts being compromised.<br>[Conditional Access - Require MFA for administrators](../conditional-access/howto-conditional-access-policy-admin-mfa.md) |

+| MP.L2-3.8.7<br><br>**Practice statement:** Control the use of removable media on system components.<br><br>**Objectives:**<br>Determine if:<br>[a.] the use of removable media on system components is controlled. | Configure device management policies via MDM (such as Microsoft Intune), Microsoft Endpoint Manager (MEM) or group policy objects (GPO) to control the use of removable media on systems. Deploy and manage Removable Storage Access Control using Intune or Group Policy. Configure Conditional Access policies to enforce device compliance.<br><br>**Conditional Access**<br>[Require device to be marked as compliant](/azure/active-directory/conditional-access/concept-conditional-access-grant#require-device-to-be-marked-as-compliant.md)<br>[Require hybrid Azure AD joined device](/conditional-access/concept-conditional-access-grant#require-hybrid-azure-ad-joined-device.md)<br><br>**Intune**<br>[Device compliance policies in Microsoft Intune](/mem/intune/protect/device-compliance-get-started.md)<br><br>**Removable storage access control**<br>[Deploy and manage Removable Storage Access Control using Intune](/microsoft-365/security/defender-endpoint/deploy-manage-removable-storage-intune?view=o365-worldwide&preserve-view=true)<br>[Deploy and manage Removable Storage Access Control using group policy](/microsoft-365/security/defender-endpoint/deploy-manage-removable-storage-group-policy?view=o365-worldwide&preserve-view=true) |

+The following table provides a list of practice statement and objectives, and Azure AD guidance and recommendations to enable you to meet these requirements with Azure AD.

+| CMMC practice statement and objectives | Azure AD guidance and recommendations |

+| PS.L2-3.9.2<br><br>**Practice statement:** Ensure that organizational systems containing CUI are protected during and after personnel actions such as terminations and transfers.<br><br>**Objectives:**<br>Determine if:<br>[a.] a policy and/or process for terminating system access and any credentials coincident with personnel actions is established;<br>[b.] system access and credentials are terminated consistent with personnel actions such as termination or transfer; and<br>[c] the system is protected during and after personnel transfer actions. | Configure provisioning (including disablement upon termination) of accounts in Azure AD from external HR systems, on-premises Active Directory, or directly in the cloud. Terminate all system access by revoking existing sessions.<br><br>**Account provisioning**<br>[What is identity provisioning with Azure AD?](/azure/active-directory/cloud-sync/what-is-provisioning.md)<br>[Azure AD Connect sync: Understand and customize synchronization](/azure/active-directory/hybrid/how-to-connect-sync-whatis.md)<br>[What is Azure AD Connect cloud sync?](/azure/active-directory/cloud-sync/what-is-cloud-sync.md)<br><br>**Revoke all associated authenticators**<br>[Revoke user access in an emergency in Azure Active Directory](/azure/active-directory/enterprise-users/users-revoke-access.md) |

+The following table provides a list of practice statement and objectives, and Azure AD guidance and recommendations to enable you to meet these requirements with Azure AD.

+| CMMC practice statement and objectives | Azure AD guidance and recommendations |

+| SC.L2-3.13.3<br><br>**Practice statement:** Separate user functionality form system management functionality. <br><br>**Objectives:**<br>Determine if:<br>[a.] user functionality is identified;<br>[b.] system management functionality is identified; and<br>[c.] user functionality is separated from system management functionality. | Maintain separate user accounts in Azure Active Directory for everyday productivity use and administrative or system/privileged management. Privileged accounts should be cloud-only or managed accounts and not synchronized from on-premises to protect the cloud environment from on-premises compromise. System/privileged access should only be permitted from a security hardened privileged access workstation (PAW). Configure Conditional Access device filters to restrict access to administrative applications from PAWs that are enabled using Azure Virtual Desktops.<br>[Why are privileged access devices important](/security/compass/privileged-access-devices.md)<br>[Device Roles and Profiles](/security/compass/privileged-access-devices.md)<br>[Filter for devices as a condition in Conditional Access policy](../conditional-access/concept-condition-filters-for-devices.md)<br>[Azure Virtual Desktop](https://azure.microsoft.com/products/virtual-desktop/) |

+| SC.L2-3.13.4<br><br>**Practice statement:** Prevent unauthorized and unintended information transfer via shared system resources.<br><br>**Objectives:**<br>Determine if:<br>[a.] unauthorized and unintended information transfer via shared system resources is prevented. | Configure device management policies via MDM (such as Microsoft Intune), Microsoft Endpoint Manager (MEM) or group policy objects (GPO) to ensure devices are compliant with system hardening procedures. Include compliance with company policy regarding software patches to prevent attackers from exploiting flaws.<br><br>Configure Conditional Access policies to enforce device compliance.<br><br>**Conditional Access**<br>[Require device to be marked as compliant](/azure/active-directory/conditional-access/concept-conditional-access-grant.md)<br>[Require hybrid Azure AD joined device](/azure/active-directory/conditional-access/concept-conditional-access-grant.md)<br><br>**InTune**<br>[Device compliance policies in Microsoft Intune](/mem/intune/protect/device-compliance-get-started.md) |

+| SC.L2-3.13.13<br><br>**Practice statement:** Control and monitor the use of mobile code.<br><br>**Objectives:**<br>Determine if:<br>[a.] use of mobile code is controlled; and<br>[b.] use of mobile code is monitored. | Configure device management policies via MDM (such as Microsoft Intune), Microsoft Endpoint Manager (MEM) or group policy objects (GPO) to disable the use of mobile code. Where use of mobile code is required monitor the use with endpoint security such as Microsoft Defender for Endpoint.<br><br>Configure Conditional Access policies to enforce device compliance.<br><br>**Conditional Access**<br>[Require device to be marked as compliant](/azure/active-directory/conditional-access/concept-conditional-access-grant.md)<br>[Require hybrid Azure AD joined device](/azure/active-directory/conditional-access/concept-conditional-access-grant.md)<br><br>**InTune**<br>[Device compliance policies in Microsoft Intune](/mem/intune/protect/device-compliance-get-started.md)<br><br>**Defender for Endpoint**<br>[Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint?view=o365-worldwide&preserve-view=true) |

+The following table provides a list of practice statement and objectives, and Azure AD guidance and recommendations to enable you to meet these requirements with Azure AD.

+| CMMC practice statement and objectives | Azure AD guidance and recommendations |

+| SI.L2-3.14.7<br><br>**Practice statement:**<br><br>**Objectives:** Identify unauthorized use of organizational systems.<br>Determine if:<br>[a.] authorized use of the system is defined; and<br>[b.] unauthorized use of the system is identified. | Consolidate telemetry: Azure AD logs to stream to SIEM, such as Azure Sentinel Configure device management policies via MDM (such as Microsoft Intune), Microsoft Endpoint Manager (MEM), or group policy objects (GPO) to require Intrusion Detection/Protection (IDS/IPS) such as Microsoft Defender for Endpoint is installed and in use. Use telemetry provided by the IDS/IPS to identify unusual activities or conditions related to inbound and outbound communications traffic or unauthorized use.<br><br>Configure Conditional Access policies to enforce device compliance.<br><br>**Conditional Access**<br>[Require device to be marked as compliant](/azure/active-directory/conditional-access/concept-conditional-access-grant.md)<br>[Require hybrid Azure AD joined device](/azure/active-directory/conditional-access/concept-conditional-access-grant.md)<br><br>**InTune**<br>[Device compliance policies in Microsoft Intune](/mem/intune/protect/device-compliance-get-started.md)<br><br>**Defender for Endpoint**<br>[Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint?view=o365-worldwide&preserve-view=true) |

+## Install the aks-preview Azure CLI extension

+To install the aks-preview extension, run the following command:

+```azurecli

+```

+Run the following command to update to the latest version of the extension released:

+```azurecli

+## Register the 'EnableAPIServerVnetIntegrationPreview' feature flag

+Register the `EnableAPIServerVnetIntegrationPreview` feature flag by using the [az feature register][az-feature-register] command, as shown in the following example:

+It takes a few minutes for the status to show *Registered*. Verify the registration status by using the [az feature show][az-feature-show] command:

+az feature show --namespace "Microsoft.ContainerService" --name "EnableAPIServerVnetIntegrationPreview"

+When the status reflects *Registered*, refresh the registration of the *Microsoft.ContainerService* resource provider by using the [az provider register][az-provider-register] command:

+[az-provider-register]: /cli/azure/provider#az-provider-register

+[az-feature-register]: /cli/azure/feature#az-feature-register

+[az-feature-list]: /cli/azure/feature#az-feature-list

+[az-feature-show]: /cli/azure/feature#az-feature-show

+[az-extension-add]: /cli/azure/extension#az-extension-add

+[az-extension-update]: /cli/azure/extension#az-extension-update

+> Azure Blob CSI driver only supports NFS 3.0 protocol for Kubernetes versions 1.25 on AKS.

+It takes a few minutes for the status to show *Registered*. Verify the registration status by using the [az feature show][az-feature-show] command:

+az feature show --namespace "Microsoft.ContainerService" --name "AzureOverlayPreview"

+When the status reflects *Registered*, refresh the registration of the *Microsoft.ContainerService* resource provider by using the [az provider register][az-provider-register] command:

+To learn how to utilize AKS with your own Container Network Interface (CNI) plugin, see [Bring your own Container Network Interface (CNI) plugin](use-byo-cni.md).

+<!-- LINKS - internal -->

+[az-provider-register]: /cli/azure/provider#az-provider-register

+[az-feature-register]: /cli/azure/feature#az-feature-register

+[az-feature-show]: /cli/azure/feature#az-feature-show

+## Install the aks-preview Azure CLI extension

+To install the aks-preview extension, run the following command:

+```azurecli

+```

+Run the following command to update to the latest version of the extension released:

+```azurecli

+## Register the 'CiliumDataplanePreview' feature flag

+Register the `CiliumDataplanePreview` feature flag by using the [az feature register][az-feature-register] command, as shown in the following example:

+It takes a few minutes for the status to show *Registered*. Verify the registration status by using the [az feature show][az-feature-show] command:

+az feature show --namespace "Microsoft.ContainerService" --name "CiliumDataplanePreview"

+When the status reflects *Registered*, refresh the registration of the *Microsoft.ContainerService* resource provider by using the [az provider register][az-provider-register] command:

+[az-provider-register]: /cli/azure/provider#az-provider-register

+[az-feature-register]: /cli/azure/feature#az-feature-register

+[az-feature-show]: /cli/azure/feature#az-feature-show

+- [Enable the Blob storage CSI driver][enable-blob-csi-driver] on your AKS cluster.

+|volumeHandle | Specify a value the driver can use to uniquely identify the storage blob container in the cluster. | A recommended way to produce a unique value is to combine the globally unique storage account name and container name: {account-name}_{container-name}. Note: The # character is reserved for internal use and can't be used in a volume handle. | Yes ||

+ # make sure volumeid is unique for every identical storage blob container in the cluster

+ # character `#` is reserved for internal use and cannot be used in volumehandle

+ # make sure volumeid is unique for every identical storage blob container in the cluster

+ # character `#` is reserved for internal use and cannot be used in volumehandle

+[data-plane-api]: https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/azcore/internal/shared/shared.go

+ mountOptions: "dir_mode=0777,file_mode=0777,cache=strict,actimeo=30,nosharesock" # optional

+ volumeHandle: unique-volumeid # make sure volumeid is unique for every identical share in the cluster

+[nginx-ingress]: ingress-basic.md

+## Install the aks-preview Azure CLI extension

+To install the aks-preview extension, run the following command:

+```azurecli

+```

+Run the following command to update to the latest version of the extension released:

+```azurecli

+## Register the 'KubeProxyConfigurationPreview' feature flag

+Register the `KubeProxyConfigurationPreview` feature flag by using the [az feature register][az-feature-register] command, as shown in the following example:

+It takes a few minutes for the status to show *Registered*. Verify the registration status by using the [az feature show][az-feature-show] command:

+az feature show --namespace "Microsoft.ContainerService" --name "KubeProxyConfigurationPreview"

+When the status reflects *Registered*, refresh the registration of the *Microsoft.ContainerService* resource provider by using the [az provider register][az-provider-register] command:

+[aks-byo-cni]: use-byo-cni.md

+[az-provider-register]: /cli/azure/provider#az-provider-register

+[az-feature-register]: /cli/azure/feature#az-feature-register

+[az-feature-show]: /cli/azure/feature#az-feature-show

+## Install the aks-preview Azure CLI extension

+To install the aks-preview extension, run the following command:

+```azurecli

+az extension add --name aks-preview

+Run the following command to update to the latest version of the extension released:

+```azurecli

+az extension update --name aks-preview

+## Register the 'AKS-EnableDualStack' feature flag

+Register the `AKS-EnableDualStack` feature flag by using the [az feature register][az-feature-register] command, as shown in the following example:

+az feature register --namespace "Microsoft.ContainerService" --name "AKS-EnableDualStack"

+It takes a few minutes for the status to show *Registered*. Verify the registration status by using the [az feature show][az-feature-show] command:

+az feature show --namespace "Microsoft.ContainerService" --name "AKS-EnableDualStack"

+```

+When the status reflects *Registered*, refresh the registration of the *Microsoft.ContainerService* resource provider by using the [az provider register][az-provider-register] command:

+```azurecli-interactive

+az provider register --namespace Microsoft.ContainerService

+[user-assigned managed identity]: use-managed-identity.md#bring-your-own-control-plane-mi

+[az-provider-register]: /cli/azure/provider#az-provider-register

+[az-feature-register]: /cli/azure/feature#az-feature-register

+[az-feature-show]: /cli/azure/feature#az-feature-show

+## Limitations

+## Install the aks-preview Azure CLI extension

+To install the aks-preview extension, run the following command:

+```

+Run the following command to update to the latest version of the extension released:

+```azurecli

+## Register the 'CustomCATrustPreview' feature flag

+Register the `CustomCATrustPreview` feature flag by using the [az feature register][az-feature-register] command, as shown in the following example:

+It takes a few minutes for the status to show *Registered*. Verify the registration status by using the [az feature show][az-feature-show] command:

+```azurecli-interactive

+az feature show --namespace "Microsoft.ContainerService" --name "CustomCATrustPreview"

+When the status reflects *Registered*, refresh the registration of the *Microsoft.ContainerService* resource provider by using the [az provider register][az-provider-register] command:

+```azurecli-interactive

+[az-feature-show]: /cli/azure/feature#az-feature-show

+[aks-rm-template]: /azure/templates/microsoft.containerservice/2022-09-01/managedclusters

+First, install the aks-preview Azure CLI extension by running the following command:

+az extension add --name aks-preview

+Run the following command to update to the latest version of the extension released:

+az extension update --name aks-preview

+Then, register the `GPUDedicatedVHDPreview` feature flag by using the [az feature register][az-feature-register] command, as shown in the following example:

+```azurecli-interactive

+az feature register --namespace "Microsoft.ContainerService" --name "GPUDedicatedVHDPreview"

+It takes a few minutes for the status to show *Registered*. Verify the registration status by using the [az feature show][az-feature-show] command:

+```azurecli-interactive

+az feature show --namespace "Microsoft.ContainerService" --name "GPUDedicatedVHDPreview"

+When the status reflects *Registered*, refresh the registration of the *Microsoft.ContainerService* resource provider by using the [az provider register][az-provider-register] command:

+```azurecli-interactive

+az provider register --namespace Microsoft.ContainerService

+[az-provider-register]: /cli/azure/provider#az-provider-register

+[az-feature-register]: /cli/azure/feature#az-feature-register

+[az-feature-show]: /cli/azure/feature#az-feature-show

+- Using * as wildcard attached to a domain suffix for noProxy

+The latest version of the Azure CLI. Run `az --version` to find the version, and run `az upgrade` to upgrade the version. If you need to install or upgrade, see [Install Azure CLI][install-azure-cli].

+## Configuring an HTTP proxy using the Azure CLI

+* `httpProxy`: A proxy URL to use for creating HTTP connections outside the cluster. The URL scheme must be `http`.

+* `httpsProxy`: A proxy URL to use for creating HTTPS connections outside the cluster. If this isn't specified, then `httpProxy` is used for both HTTP and HTTPS connections.

+* `noProxy`: A list of destination domain names, domains, IP addresses or other network CIDRs to exclude proxying.

+* `trustedCa`: A string containing the `base64 encoded` alternative CA certificate content. Currently only the `PEM` format is supported.

+> [!IMPORTANT]

+> For compatibility with Go-based components that are part of the Kubernetes system, the certificate **must** support `Subject Alternative Names(SANs)` instead of the deprecated Common Name certs.

+> [!NOTE]

+> The CA certificate should be the base64 encoded string of the PEM format cert content.

+Create a file and provide values for *httpProxy*, *httpsProxy*, and *noProxy*. If your environment requires it, provide a value for *trustedCa*. Next, deploy a cluster, passing in your filename using the `http-proxy-config` flag.

+Deploying an AKS cluster with an HTTP proxy configured using an ARM template is straightforward. The same schema used for CLI deployment exists in the `Microsoft.ContainerService/managedClusters` definition under properties:

+In your template, provide values for *httpProxy*, *httpsProxy*, and *noProxy*. If necessary, provide a value for *trustedCa*. Deploy the template, and your cluster should initialize with your HTTP proxy configured on the nodes.

+Values for *httpProxy*, *httpsProxy*, and *noProxy* can't be changed after cluster creation. However, to support rolling CA certs, the value for *trustedCa* can be changed and applied to the cluster with the [az aks update][az-aks-update] command.

+For example, assuming a new file has been created with the base64 encoded string of the new CA cert called *aks-proxy-config-2.json*, the following action updates the cluster:

+The HTTP proxy with the Monitoring add-on supports the following configurations:

+The following configurations aren't supported:

+ - The Custom Metrics and Recommended Alerts features aren't supported when you use a proxy with trusted certificates

+ - Outbound proxy isn't supported with Azure Monitor Private Link Scope (AMPLS)

+For more information regarding the network requirements of AKS clusters, see [control egress traffic for cluster nodes in AKS][aks-egress].

+[install-azure-cli]: /cli/azure/install-azure-cli

+First, install the aks-preview extension by running the following command:

+```azurecli

+az extension add --name aks-preview

+```

+Run the following command to update to the latest version of the extension released:

+```azurecli

+az extension update --name aks-preview

+```

+Then register the `EnableImageCleanerPreview` feature flag by using the [az feature register][az-feature-register] command, as shown in the following example:

+It takes a few minutes for the status to show *Registered*. Verify the registration status by using the [az feature show][az-feature-show] command:

+az feature show --namespace "Microsoft.ContainerService" --name "EnableImageCleanerPreview"

+When the status reflects *Registered*, refresh the registration of the *Microsoft.ContainerService* resource provider by using the [az provider register][az-provider-register] command:

+A job named `eraser-aks-xxx`will be triggered which causes ImageCleaner to remove the desired images from all nodes.

+[az-feature-register]: /cli/azure/feature#az-feature-register

+[az-feature-show]: /cli/azure/feature#az-feature-show

+[az-provider-register]: /cli/azure/provider#az-provider-register

+[aks-best-practices]: best-practices.md

+## Install the aks-preview Azure CLI extension

+To install the aks-preview extension, run the following command:

+```azurecli

+az extension add --name aks-preview

+```

+Run the following command to update to the latest version of the extension released:

+az extension update --name aks-preview

+```

+## Register the 'AKS-KedaPreview' feature flag

+Register the `AKS-KedaPreview` feature flag by using the [az feature register][az-feature-register] command, as shown in the following example:

+```azurecli-interactive

+az feature register --namespace "Microsoft.ContainerService" --name "AKS-KedaPreview"

+It takes a few minutes for the status to show *Registered*. Verify the registration status by using the [az feature show][az-feature-show] command:

+az feature show --namespace "Microsoft.ContainerService" --name "AKS-KedaPreview"

+When the status reflects *Registered*, refresh the registration of the *Microsoft.ContainerService* resource provider by using the [az provider register][az-provider-register] command:

+[az-provider-register]: /cli/azure/provider#az-provider-register

+[az-feature-register]: /cli/azure/feature#az-feature-register

+[az-feature-show]: /cli/azure/feature#az-feature-show

+## Install the aks-preview Azure CLI extension

+To install the aks-preview extension, run the following command:

+az extension add --name aks-preview

+Run the following command to update to the latest version of the extension released:

+az extension update --name aks-preview

+```

+## Register the 'AKS-KedaPreview' feature flag

+Register the `AKS-KedaPreview` feature flag by using the [az feature register][az-feature-register] command, as shown in the following example:

+```azurecli-interactive

+az feature register --namespace "Microsoft.ContainerService" --name "AKS-KedaPreview"

+It takes a few minutes for the status to show *Registered*. Verify the registration status by using the [az feature show][az-feature-show] command:

+az feature show --namespace "Microsoft.ContainerService" --name "AKS-KedaPreview"

+When the status reflects *Registered*, refresh the registration of the *Microsoft.ContainerService* resource provider by using the [az provider register][az-provider-register] command:

+<!-- LINKS - internal -->

+[az-provider-register]: /cli/azure/provider#az-provider-register

+[az-feature-register]: /cli/azure/feature#az-feature-register

+[az-feature-show]: /cli/azure/feature#az-feature-show

+> - If your cluster is running Kubernetes version 1.24.0 or greater, the OSM add-on installs version *1.2.2* of OSM.

+> - If your cluster is running a version of Kubernetes between 1.23.5 and 1.24.0, the OSM add-on installs version *1.1.3* of OSM.

+> - If your cluster is running Kubernetes version 1.24.0 or greater, the OSM add-on installs version *1.2.2* of OSM.

+> - If your cluster is running a version of Kubernetes between 1.23.5 and 1.24.0, the OSM add-on installs version *1.1.3* of OSM.

+> - If your cluster is running Kubernetes version 1.24.0 or greater, the OSM add-on installs version *1.2.2* of OSM.

+> - If your cluster is running a version of Kubernetes between 1.23.5 and 1.24.0, the OSM add-on installs version *1.1.3* of OSM.

+> - If your cluster is running Kubernetes version 1.24.0 or greater, the OSM add-on installs version *1.2.2* of OSM.

+> - If your cluster is running a version of Kubernetes between 1.23.5 and 1.24.0, the OSM add-on installs version *1.1.3* of OSM.

+[barracuda-waf]: https://www.barracuda.com/products/webapplicationfirewall/models/

+[nodepool-upgrade]: use-multiple-node-pools.md#upgrade-a-node-pool

+## Prerequisites

+You must have the following resources installed:

+## Install the aks-preview Azure CLI extension

+To install the aks-preview extension, run the following command:

+az extension add --name aks-preview

+Run the following command to update to the latest version of the extension released:

+```azurecli

+az extension update --name aks-preview

+## Register the 'EnableCloudControllerManager' feature flag

+Register the `EnableCloudControllerManager` feature flag by using the [az feature register][az-feature-register] command, as shown in the following example:

+az feature register --namespace "Microsoft.ContainerService" --name "EnableCloudControllerManager"

+It takes a few minutes for the status to show *Registered*. Verify the registration status by using the [az feature show][az-feature-show] command:

+az feature show --namespace "Microsoft.ContainerService" --name "EnableCloudControllerManager"

+```

+When the status reflects *Registered*, refresh the registration of the *Microsoft.ContainerService* resource provider by using the [az provider register][az-provider-register] command:

+```azurecli-interactive

+az provider register --namespace Microsoft.ContainerService

+[az-feature-show]: /cli/azure/feature#az-feature-show

+ * [Network policies](use-network-policies.md#differences-between-azure-network-policy-manager-and-calico-network-policy-and-their-capabilities)

+ Title: Kubernetes on Azure tutorial - Deploy an application

+Kubernetes provides a distributed platform for containerized applications. You build and deploy your own applications and services into a Kubernetes cluster and let the cluster manage the availability and connectivity. In this tutorial, part four of seven, you deploy a sample application into a Kubernetes cluster. You learn how to:

+>

+> * Update a Kubernetes manifest file.

+> * Run an application in Kubernetes.

+> * Test the application.

+In later tutorials, you'll scale out and update your application.

+This quickstart assumes you have a basic understanding of Kubernetes concepts. For more information, see [Kubernetes core concepts for Azure Kubernetes Service (AKS)][kubernetes-concepts].

+> AKS clusters can use GitOps for configuration management. GitOp enables declarations of your cluster's state, which are pushed to source control, to be applied to the cluster automatically. To learn how to use GitOps to deploy an application with an AKS cluster, see the [prerequisites for Azure Kubernetes Service clusters][gitops-flux-tutorial-aks] in the [GitOps with Flux v2][gitops-flux-tutorial] tutorial.

+In previous tutorials, you packaged an application into a container image, uploaded the image to Azure Container Registry, and created a Kubernetes cluster.

+To complete this tutorial, you need the pre-created `azure-vote-all-in-one-redis.yaml` Kubernetes manifest file. This file download was included with the application source code in a previous tutorial. Verify that you've cloned the repo and that you've changed directories into the cloned repo. If you haven't done these steps and would like to follow along, start with [Tutorial 1: Prepare an application for AKS][aks-tutorial-prepare-app].

+Get the ACR login server name using the [az acr list][az-acr-list] command.

+Get the ACR login server name using the [Get-AzContainerRegistry][get-azcontainerregistry] cmdlet.

+The sample manifest file from the git repo you cloned in the first tutorial uses the images from Microsoft Container Registry (*mcr.microsoft.com*). Make sure you're in the cloned *azure-voting-app-redis* directory, and then open the manifest file with a text editor, such as `vi`:

+Replace *mcr.microsoft.com* with your ACR login server name. You can find the image name on line 60 of the manifest file. The following example shows the default image name:

+Provide your own ACR login server name so your manifest file looks similar to the following example:

+To deploy your application, use the [`kubectl apply`][kubectl-apply] command, specifying the sample manifest file. This command parses the manifest file and creates the defined Kubernetes objects.

+To monitor progress, use the [`kubectl get service`][kubectl-get] command with the `--watch` argument.

+Initially the *EXTERNAL-IP* for the *azure-vote-front* service shows as *pending*.

+To see the application in action, open a web browser to the external IP address of your service.

+If the application doesn't load, it might be an authorization problem with your image registry. To view the status of your containers, use the `kubectl get pods` command. If you can't pull the container images, see [Authenticate with Azure Container Registry from Azure Kubernetes Service](cluster-container-registry-integration.md).

+In this tutorial, you deployed a sample Azure vote application to a Kubernetes cluster in AKS. You learned how to:

+>

+> * Update a Kubernetes manifest file.

+> * Run an application in Kubernetes.

+> * Test the application.

+In the next tutorial, you'll learn how to scale a Kubernetes application and the underlying Kubernetes infrastructure.