+| **value** |Required | String | Date time string in [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html) format. If the date variable is in a different format, use [FormatDateTime](#formatdatetime) function to convert the date to ISO 8601 format. |

+ Title: Using Azure Front Door to provide geo-acceleration

+description: How to optimize performance for global connectivity scenarios using Azure Front Door (for Geo-Acceleration) with Azure Active Directory Application Proxy.

+# Using Azure Front Door to achieve geo-acceleration

+This article explains how to configure Azure Active Directory (Azure AD) Application Proxy to work with Azure Front Door (AFD) to achieve reduce latency and better performance.

+

+## What is Azure Front Door?

+Azure Front Door helps deliver low-latency, high-throughput content at scale from the cloud or on-premises infrastructure to users anywhere. Accelerate static and dynamic content delivery with a unified platform built on the massively scalable Microsoft private global network. For more information about Azure Front Door, see [What is Azure Front Door?][front-door-overview].

+## Deployment steps

+This article guides you through the steps to securely expose a web application on the Internet, by integrating the Azure AD Application Proxy with Azure Front Door. In this guide we'll be using the Azure portal. The reference architecture for this deployment is represented below.

+

+## Prerequisites

+- A Front Door Service ΓÇô Standard or Classic tier

+- Apps that exist in a single region.

+- A custom domain to use for the application.

+- For licensing information, Application Proxy is available through an Azure AD Premium subscription. Refer here for a full listing of licensing options and features: [Azure Active Directory Pricing](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing)

+### Application Proxy Configuration

+Follow these steps to configure Application Proxy for Front Door:

+1. Install connector for the location that your app instances will be in (For example US West). For the connector group assign the connector to the right region (For example North America).

+2. Set up your app instance with Application Proxy as follows:

+ - Set the Internal URL to the address users access the app from the internal network, for example contoso.org

+ - Set the External URL to the domain address you want the users to access the app from. For this you must configure a custom domain for our application here, for example, contoso.org. Reference: [Custom domains in Azure Active Directory Application Proxy][appproxy-custom-domain]

+ - Assign the application to the appropriate connector group (For example: North America)

+ - Note down the URL generated by Application Proxy to access the application. For example, contoso.msappproxy.net

+ - For the application configure a CNAME Entry in your DNS provider which points the external URL to the Front DoorΓÇÖs endpoint, for example ΓÇÿcontoso.orgΓÇÖ to contoso.msappproxy.net

+3. In the Front Door service, utilize the URL generated for the app by Application Proxy as a backend for the backend pool. For example, contoso.msappproxy.net

+#### Sample Application Proxy Configuration

+The following table shows a sample Application Proxy configuration. The sample scenario uses the sample application domain www.contoso.org as the External URL.

+| | Configuration | Additional Information |

+|- | -- | - |

+| **Internal URL** | nam.contoso.com | |

+| **External URL** | contoso.org | Configure a custom domain for users to access the app from.|

+| **Connector group** | North America | Select the connector group in the geo closest to where the app instance will be in for optimized performance.|

+### Front Door Configuration

+Azure Front Door is offered in different tiers including Standard, Premium and Classic. Select a tier based on the preference. For more information on tier comparison, refer here: [Azure Front Door tier comparison][front-door-tier]

+For Front Door Standard Tier

+The configuration steps that follow refer to the following definitions:

+- Endpoint name: A globally unique name for the endpoint. You can onboard custom domains as well. For example, front door endpoint name: contoso-nam that will generate the Endpoint host name contoso-nam.azurefd.net and utilize custom domain host name: contoso.org

+- Origin: Origins are your application servers. Front door will route your client requests to origins, based on the type, ports, priority, and weight you specify here

+- Origin Type: The type of resource you want to add. Front Door supports auto-discovery of your application backends from App Service, Cloud Service, or Storage. If you want a different resource in Azure or even a non-Azure backend, select Custom host. For example Custom host for have a backend of an Application Proxy service

+- Origin host name: This represents the backend origin host name. For example, contoso.msappproxy.net

+- Origin host header: This represented the host header value being sent to the backend for each request. For example, contoso.org. For more information refer here: [Origins and origin groups ΓÇô Azure Front Door][front-door-origin]

+Follow these steps to configure the Front Door Service (Standard):

+1. Create a Front Door (Standard) with the configuration below:

+ - Add an Endpoint name for generating the Front DoorΓÇÖs default domain i.e. azurefd.net. For example, contoso-nam that generated the Endpoint hostname contoso-nam.azurefd.net

+ - Add an Origin Type for the type of backend resource. For example Custom here for the Application Proxy resource

+ - Add an Origin host name to represent the backend host name. For example, contoso.msappproxy.net

+ - Optional: Enable Caching for the routing rule for Front Door to cache your static content.

+2. Verify if the deployment is complete and the Front Door Service is ready

+3. To give your Front Door service a user-friendly domain host name URL, create a CNAME record with your DNS provider for your Application Proxy External URL that points to Front DoorΓÇÖs domain host name (generated by the Front Door service). For example, contoso.org points to contoso.azurefd.net Reference: [How to add a custom domain - Azure Front Door][front-door-custom-domain]

+4. As per the reference, on the Front Door Service Dashboard navigate to Front Door Manager and add a Domain with the Custom Hostname. For example, contoso.org

+5. Navigate to the Origin groups in the Front Door Service Dashboard, select the origin name and validate the Origin host header matches the domain of the backend. For example here the Origin host header should be: contoso.org

+| | Configuration | Additional Information |

+|- | -- | - |

+| **Endpoint Name** | ΓÇó Endpoint name: contoso-nam <br /> ΓÇó Front door generated Hostname: <br /> contoso-nam.azurefd.net <br /> ΓÇó Custom Domain Hostname: contoso.org| A custom domain host name must be utilized here.|

+| **Origin hostname** | contoso.msappproxy.net | The URL generated for the app by Application Proxy must be utilized here.|

+| **Connector group** | North America | Select the connector group in the geo closest to where the app instance will be in for optimized performance.|

+## Next steps

+To prevent false positives, learn how to [Customize Web Application Firewall rules](../../web-application-firewall/ag/application-gateway-customize-waf-rules-portal.md), configure [Web Application Firewall exclusion lists](../../web-application-firewall/ag/application-gateway-waf-configuration.md?tabs=portal), or [Web Application Firewall custom rules](../../web-application-firewall/ag/create-custom-waf-rules.md).

+[front-door-overview]: ../../frontdoor/front-door-overview.md

+[front-door-origin]: ../../frontdoor/origin.md?pivots=front-door-standard-premium#origin-host-header

+[front-door-tier]: ../../frontdoor/standard-premium/tier-comparison.md

+[front-door-custom-domain]: ../../frontdoor/standard-premium/how-to-add-custom-domain.md

+[appproxy-custom-domain]: ./application-proxy-configure-custom-domain.md

+[private-dns]: ../../dns/private-dns-getstarted-portal.md

+[waf-logs]: ../../application-gateway/application-gateway-diagnostics.md#firewall-log

+For more information on configuring the option to let users remain signed-in, see [Customize your Azure AD sign-in page](../fundamentals/active-directory-users-profile-azure-portal.md#learn-about-the-stay-signed-in-prompt).

+- Review your AD FS access control policies and make sure none requires MFA to be performed on-premises as part of the authentication process.

+- [Migrate to cloud authentication using Staged Rollout](../hybrid/how-to-connect-staged-rollout.md)

+* An account with privileges to create Conditional Access policies.

+#### Permissions

+Conditional Access policies can be created or modified by anyone assigned the following roles:

+- Conditional Access Administrator

+- Security Administrator

+- Global Administrator

+Conditional Access policies can be read by anyone assigned the following roles:

+- Security Reader

+- Global Reader

+Create a risk-based Conditional Access policy that applies to service principals.

+import msal from "@azure/msal-browser"

+ logLevel: msal.LogLevel.Verbose,

+ loggerCallback: (level, message, containsPii) => {

+ case msal.LogLevel.Error:

+ case msal.LogLevel.Info:

+ case msal.LogLevel.Verbose:

+ case msal.LogLevel.Warning:

+ },

+};

+To understand 'Why MSAL?', it's important to first understand the differences between Microsoft identity platform (v2.0) and Azure Active Directory (v1.0) endpoints. The v1.0 endpoint is used by Azure AD Authentication Library (ADAL) while the v2.0 endpoint is used by Microsoft Authentication Library (MSAL). If you've developed apps against the v1.0 endpoint in the past, you're likely using ADAL. Since the v2.0 endpoint has changed significantly enough, the new library (MSAL) was built for the new endpoint entirely.

+The following diagram shows the v2.0 vs v1.0 endpoint experience at a high level, including the app registration experience, SDKs, endpoints, and supported identities.

+

+MSAL leverages all the [benefits of Microsoft identity platform (v2.0) endpoint](../azuread-dev/azure-ad-endpoint-comparison.md).

+MSAL is designed to enable a secure solution without developers having to worry about the implementation details. it simplifies and manages acquiring, managing, caching, and refreshing tokens, and uses best practices for resilience. We recommend you use MSAL to [increase the resilience of authentication and authorization in client applications that you develop](../fundamentals/resilience-client-app.md?tabs=csharp#use-the-microsoft-authentication-library-msal).

+## Additional Capabilities of MSAL over ADAL

+- Auth broker support ΓÇô Device-based Conditional Access policy

+- Proof of possession tokens

+- Azure AD certificate-based authentication (CBA) on mobile

+- System browsers on mobile devices

+- Where ADAL had only authentication context class, MSAL exposes the notion of a collection of client apps (public client and confidential client).

+MSAL Supports a wide range of application types and scenarios. Please refer to [Microsoft Authentication Library support for several application types](reference-v2-libraries.md#single-page-application-spa).

+ADAL to MSAL Migration Guide for different platforms are available in the following link.

+- [Migrate to MSAL iOS and MacOS](migrate-objc-adal-msal.md)

+- [Migrate to MSAL Java](migrate-adal-msal-java.md)

+- [Migrate to MSAL .Net](msal-net-migration.md)

+- [Migrate to MSAL Node](msal-node-migration.md)

+- [Migrate to MSAL Python](migrate-python-adal-msal.md)

+[n]: media/common/no.png

+> When you set up an Azure Active Directory (Azure AD) account, you create a tenant. This is a digital representation of your organization. It's primarily associated with a domain, like Microsoft.com. If you want to learn how applications can work with multiple tenants, refer to the [application model](/azure/active-directory/develop/application-model).

+ public void onAccountChanged(@Nullable IAccount priorAccount, @Nullable Iaccount currentAccount)

+>[!NOTE]

+>In this screen you now may also choose to **Pause processing**. Previously, this option was only available through the modification of the membershipRuleProcessingState property. Global admins, group admins, user admins, and Intune admins can manage this setting and can pause and resume dynamic group processing. Group owners without the correct roles do not have the rights needed to edit this setting.

+- **On-premises:** Accounts synced from Windows Server Active Directory include other values not applicable to Azure AD accounts.

+### Learn about the 'Stay signed in?' prompt

+The **Stay signed in?** prompt appears after a user successfully signs in. This process is known as **Keep me signed in** (KMSI). If a user answers **Yes** to this prompt, the KMSI service gives them a persistent [refresh token](../develop/developer-glossary.md#refresh-token). For federated tenants, the prompt will show after the user successfully authenticates with the federated identity service.

+The following diagram shows the user sign-in flow for a managed tenant and federated tenant using the KMSI in prompt. This flow contains smart logic so that the **Stay signed in?** option won't be displayed if the machine learning system detects a high-risk sign-in or a sign-in from a shared device.

+KMSI is only available on the default custom branding. It can't be added to language-specific branding. Some features of SharePoint Online and Office 2010 depend on users being able to choose to remain signed in. If you uncheck the **Show option to remain signed in** option, your users may see other unexpected prompts during the sign-in process.

+

+Configuring the 'keep me signed in' (KMSI) option requires one of the following licenses:

+- Azure AD Premium 1

+- Azure AD Premium 2

+- Office 365 (for Office apps)

+- Microsoft 365

+#### Troubleshoot 'Stay signed in?' issues

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

+

+Details about the sign-in error are found in the **Sign-in logs** in Azure AD. Select the impacted user from the list and locate the details below in the **Basic info** section.

+* **Sign in error code**: 50140

+* **Failure reason**: This error occurred due to "Keep me signed in" interrupt when the user was signing in.

+You can stop users from seeing the interrupt by setting the **Show option to remain signed in** setting to **No** in the advanced branding settings. This setting disables the KMSI prompt for all users in your Azure AD directory.

+You also can use the [persistent browser session controls in Conditional Access](../conditional-access/howto-conditional-access-session-lifetime.md) to prevent users from seeing the KMSI prompt. This option allows you to disable the KMSI prompt for a select group of users (such as the global administrators) without affecting sign-in behavior for everyone else in the directory.

+To ensure that the KMSI prompt is shown only when it can benefit the user, the KMSI prompt is intentionally not shown in the following scenarios:

+* User is signed in via seamless SSO and integrated Windows authentication (IWA)

+* User is signed in via Active Directory Federation Services and IWA

+* User is a guest in the tenant

+* User's risk score is high

+* Sign-in occurs during user or admin consent flow

+* Persistent browser session control is configured in a conditional access policy

+When users authenticate into your corporate intranet or web-based applications, Azure Active Directory (Azure AD) provides the identity and access management (IAM) service. You can add company branding that applies to all these sign-in experiences to create a consistent experience for your users.

+This article covers how to customize the company branding for sign-in experiences for your users.

+An updated experience for adding company branding is available as an Azure AD preview feature. To opt in and explore the new experience, go to **Azure AD** > **Preview features** and enable the **Enhanced Company Branding** feature. Check out the updated documentation on [how to customize branding](how-to-customize-branding.md).

+Adding custom branding requires one of the following licenses:

+ - **Show option to remain signed in** You can choose to let your users remain signed in to Azure AD until explicitly signing out. If you uncheck this option, users must sign in each time the browser is closed and reopened. For more information, see the [Add or update a user's profile](active-directory-users-profile-azure-portal.md#learn-about-the-stay-signed-in-prompt) article.

+1. Sign in to the [Azure portal](https://portal.azure.com/) using a Global Administrator account for the directory.

+ Title: Add company branding to your organization's sign-in page (preview) - Azure AD

+description: Instructions about how to add your organization's branding to the sign-in experience.

+# Configure your company branding (preview)

+When users authenticate into your corporate intranet or web-based applications, Azure Active Directory (Azure AD) provides the identity and access management (IAM) service. You can add company branding that applies to all these sign-in experiences to create a consistent experience for your users.

+The updated experience for adding company branding covered in this article is available as an Azure AD preview feature. To opt in and explore the new experience, go to **Azure AD** > **Preview features** and enable the **Enhanced Company Branding** feature.

+For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

+Instructions for the legacy company branding customization process can be found in the [Customize branding](customize-branding.md) article.

+## License requirements

+Adding custom branding requires one of the following licenses:

+- Azure AD Premium 1

+- Azure AD Premium 2

+- Office 365 (for Office apps)

+For more information about licensing and editions, see the [Sign up for Azure AD Premium](active-directory-get-started-premium.md) article.

+Azure AD Premium editions are available for customers in China using the worldwide instance of Azure AD. Azure AD Premium editions aren't currently supported in the Azure service operated by 21Vianet in China

+## Before you begin

+You can customize the sign-in pages when users access your organization's tenant-specific apps, such as `https://outlook.com/woodgrove.com`, or when passing a domain variable, such as `https://passwordreset.microsoftonline.com/?whr=woodgrove.com`.

+Custom branding appears after users authenticate for the first time. Users that start the sign-in process at a site like www\.office.com won't see the branding. After the first sign-in, the branding may take at least 15 minutes to appear.

+**All branding elements are optional. Default settings will remain, if left unchanged.** For example, if you specify a banner logo but no background image, the sign-in page shows your logo with a default background image from the destination site such as Microsoft 365. Additionally, sign-in page branding doesn't carry over to personal Microsoft accounts. If your users or guests authenticate using a personal Microsoft account, the sign-in page won't reflect the branding of your organization.

+**Images have different image and file size requirements.** Take note of the image requirements for each option. You may need to use a photo editor to create the right size images. The preferred image type for all images is PNG, but JPG is accepted.

+1. Sign in to the [Azure portal](https://portal.azure.com/) using a Global Administrator account for the directory.

+2. Go to **Azure Active Directory** > **Company branding** > **Customize**.

+ - If you currently have a customized sign-in experience, you'll see an **Edit** button.

+ 

+The sign-in experience process is grouped into sections. At the end of each section, select the **Review + create** button to review what you have selected and submit your changes or the **Next** button to move to the next section.

+

+## Basics

+- **Favicon**: Select a PNG or JPG of your logo that appears in the web browser tab.

+- **Background image**: Select a PNG or JPG to display as the main image on your sign-in page. This image will scale and crop according to the window size, but may be partially blocked by the sign-in prompt.

+- **Page background color**: If the background image isn't able to load because of a slower connection, your selected background color appears instead.

+## Layout

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

+ - Choose one of two **Templates**: Full-screen or partial-screen background. The full-screen background could obscure your background image, so choose the partial-screen background if your background image is important.

+ - The details of the **Header** and **Footer** options are set on the next two sections of the process.

+- **Custom CSS**: Upload custom CSS to replace the Microsoft default style of the page. [Download the CSS template](https://download.microsoft.com/download/7/2/7/727f287a-125d-4368-a673-a785907ac5ab/custom-styles-template.css).

+## Header

+If you haven't enabled the header, go to the **Layout** section and select **Show header**. Once enabled, select a PNG or JPG to display in the header of the sign-in page.

+## Footer

+If you haven't enabled the footer, go to the **Layout** section and select **Show footer**. Once enabled, adjust the following settings.

+- **Show 'Privacy & Cookies'**: This option is selected by default and displays the [Microsoft 'Privacy & Cookies'](https://privacy.microsoft.com/privacystatement) link.

+

+ Uncheck this option to hide the default Microsoft link. Optionally provide your own **Display text** and **URL**. The text and links don't have to be related to privacy and cookies.

+- **Show 'Terms of Use'**: This option is also elected by default and displays the [Microsoft 'Terms of Use'](https://www.microsoft.com/servicesagreement/) link.

+ Uncheck this option to hide the default Microsoft link. Optionally provide your own **Display text** and **URL**. The text and links don't have to be related to your terms of use.

+ >[!IMPORTANT]

+ >The default Microsoft 'Terms of Use' link is not the same as the Conditional Access Terms of Use. Seeing the terms here doesn't mean you've accepted those terms and conditions.

+ 

+## Sign-in form

+- **Banner logo**: Select a PNG or JPG image file of a banner-sized logo (short and wide) to appear on the sign-in pages.

+- **Square logo (light theme)**: Select a square PNG or JPG image file of your logo to be used in browsers that are using a light color theme. This logo is used to represent your organization on the Azure AD web interface and in Windows.

+- **Square logo (dark theme)** Select a square PNG or JPG image file of your logo to be used in browsers that are using a dark color theme. This logo is used to represent your organization on the Azure AD web interface and in Windows. If your logo looks good on light and dark backgrounds, there's no need to add a dark theme logo.

+- **Username hint text**: Enter hint text for the username input field on the sign-in page. If guests use the same sign-in page, we don't recommend using hint text here.

+- **Sign-in page text**: Enter text that appears on the bottom of the sign-in page. You can use this text to communicate additional information, such as the phone number to your help desk or a legal statement. This page is public, so don't provide sensitive information here. This text must be Unicode and can't exceed 1024 characters.

+ To begin a new paragraph, use the enter key twice. You can also change text formatting to include bold, italics, an underline, or clickable link. Use the following syntax to add formatting to text:

+ > Hyperlink: `[text](link)`

+

+ > Bold: `**text**` or `__text__`

+

+ > Italics: `*text*` or `_text_`

+

+ > Underline: `++text++`

+

+ > [!IMPORTANT]

+ > Hyperlinks that are added to the sign-in page text render as text in native environments, such as desktop and mobile applications.

+- **Self-service password reset**:

+ - Show self-service password reset (SSPR): Select the checkbox to turn on SSPR.

+ - Common URL: Enter the destination URL for where your users will reset their passwords. This URL appears on the username and password collection screens.

+ - Username collection display text: Replace the default text with your own custom username collection text.

+ - Password collection display text: Replace the default text with your own customer password collection text.

+## Review

+All of the available options appear in one list so you can review everything you've customized or left at the default setting. When you're done, select the **Create** button.

+Once your default sign-in experience is created, select the **Edit** button to make any changes. You can't delete a default sign-in experience after it's created, but you can remove all custom settings.

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

+To create an inclusive experience for all of your users, you can customize the sign-in experience based on browser language.

+1. Sign in to the [Azure portal](https://portal.azure.com/) using a Global Administrator account for the directory.

+2. Go to **Azure Active Directory** > **Company branding** > **Add browser language**.

+The process for customizing the experience is the same as the [default sign-in experience](#basics) process, except you must select a language from the dropdown list in the **Basics** section. We recommend adding custom text in the same areas as your default sign-in experience.

+## Next steps

+- [Learn more about default user permissions in Azure AD](../fundamentals/users-default-permissions.md)

+- [Manage the 'stay signed in' prompt](active-directory-users-profile-azure-portal.md#learn-about-the-stay-signed-in-prompt)

+When you upgrade to Azure AD P1 or P2 from a free version of Azure AD, the reports associated with P1 and P2 will begin to retain and display data from your tenant. You should expect a delay of roughly 24 hours from when you upgrade your tenant before all premium reporting features show data. Many premium reporting features will only begin retaining data after this 24 hour period following your upgrade to P1 or P2.

+* [Azure Active Directory risk detections](../identity-protection/overview-identity-protection.md)

+> [!VIDEO https://www.microsoft.com/en-us/videoplayer/embed/RE5cbi8]

+ b. In the **Reply URL** text box, type the URL: `https://app.keepabl.com/users/saml/auth`