Previously, this article referenced Chrome Beta version 78. However, version 78 will no longer experience this issue. Google rescheduled this change in behavior for Chrome Beta version 79.
The Beta release of the Google Chrome web browser (build 79, scheduled for release on October 31, 2019) features a change in how cookies are handled. Although the change was intended to discourage malicious cookie tracking, it is also expected to severely affect many applications and services that are based on open standards, including Microsoft cloud services. This change is expected to roll out to be the default Chrome behavior in release 80 that is targeted as a Stable release on February 4, 2020.
Enterprise customers are encouraged to test their applications (whether custom-developed or purchased) to make sure that they are prepared for the change and are ready to implement mitigations. (See the "Recommendations" section.)
Microsoft is committed to addressing this change in behavior in its products and services before February 4, 2020, rollout date. This article provides guidance from both Microsoft and Google for installing the various updates that are required for products and libraries, and guidance for testing and preparation. However, it is equally important that you test your own applications against this change in Chrome behavior and prepare your own websites and web applications as necessary.
Impact on users using Microsoft products and services
During our testing of this change in Microsoft products and services, we found the following scenarios to be severely affected by this change in behavior. We are working to remedy all these scenarios by the release date of the affected Chrome browser Stable build on February 4, 2020.
- The performance of all Microsoft services may be significantly decreased.
- Signing in to important sites such as the Azure portal fails and generates an error.
- Signing in to Microsoft Power BI enters a loop and eventually generates an error.
- Dynamics 365 sign-out fails.
- Dynamics integration with Skype, PowerApps, and Excel fails.
- In Office 365, notifications about email messages in the Office Suite do not work.
- In Microsoft Teams, tabbed access to other office services such as Stream within the Teams client does not work.
- Sign-out messages from certain sites indicate a successful sign-out. However, the cookie clearing process fails, and this keeps the user signed in.
- Signing in and signing out fails on many customer-developed websites that use some versions of Microsoft .NET Framework and .NET Core to process authentication tokens.
- Customer-developed applications that do silent sign-in flows by using MSAL or ADAL against Azure Active Directory (Azure AD), Azure AD B2C, or Microsoft Account are affected.
- Signing in to and signing out from Active Directory Federation Services (AD FS) when it is acting as a Federated partner to another Identity Provider is affected.
- Signing in to applications that are published behind Web Application Proxy (WAP) and AD FS and Applications are in different domains is affected.
Impact on customer applications
You should thoroughly test all your applications by using Chrome Beta version 77 to verify the effect of this issue. We expect that problems that are similar to the problems that are described in this article will affect your applications. This is particularly true for applications that use any web platform or technology that relies on cross-domain cookie sharing, such as apps that are embedded in other apps.
Chrome versions 78 and 79 have an improvement that delays the SameSite:Lax attribute enforcement for two minutes. However, using these versions for testing may mask other problems. Therefore, we recommend that you test by using version 77. This will help you to, at least, discover the effect so that you can determine the best course of action. For more information, see the "Testing guidelines" section.
We strongly recommend that you use the Stable release of the Chrome browser at this time and avoid using the Beta release in your production environments when you access Microsoft services.
If developers have to use the Beta release for website testing, we recommend that they use a different browser to access Microsoft services.
Test your applications for all the following scenarios, and determine the appropriate course of action based on the outcome of the tests:
- Your application is unaffected by SameSite changes. In this case, there is no action to take.
- Your application is affected but your application developers can make the change to use the SameSite:None cookie settings in time. In this case, you should change your application by following the developer guidance in the "Testing guidelines" section.
- Your application is affected but cannot be changed in time. For internal sites, the application can be excluded from SameSite enforcement behavior in Chrome by using the LegacySameSiteCookieBehaviorEnabledForDomainList setting.
Enterprise customers who find that most of their apps are affected, or who do have enough time to test their apps in the before the Chrome Stable release date are encouraged to disable the SameSite behavior in computers their govern by using Group Policy, System Center Configuration Manager, or Microsoft Intune (or any Mobile Device Management software) until they have finished testing and verified that the new behavior does not break essential scenarios in their apps.
Google has released the following enterprise controls that can be set to disable the SameSite enforcement behavior in Chrome:
For more information, see SameSite Updates on the Chromium Projects website.
For Enterprise customers who develop their applications on .NET Framework, we recommend that you follow the guidance in the following Microsoft ASP.NET Blog article to update libraries and set the SameSite behavior intentionally to avoid unpredictable results that are caused by the change in cookie behavior:
Also, see the following Google Chromium Blog article for developer guidance from Google about this issue:
For Microsoft customers who use AD FS or Web Application Proxy, a Windows Server update will be available on January 14, 2020, that will apply a similar fix for AD FS and WAP.
Google has published guidance for developers to prepare for SameSite changes in the following Chromium Blog article
Additionally, we recommend that you test your websites and apps by using the following approach:
- Use Chrome Beta version 77 to test the scenarios.
- Enable SameSite flags. To do this, follow these steps:
- In the Chrome browser, type Chrome://flags in the Address bar, and then press Enter.
- In the Search bar, type SameSite, and then press Enter.
- In the list for the third option ("Cookies without SameSite must be secure"), select Enabled.
The web community is working on a solution to address the abusive use of tracking cookies and cross-site request forgery through a standard that is known as SameSite.
The Chrome team had announced plans to roll out a change in the default behavior of the SameSite functionality in Chrome starting in Beta version 78 on October 18, 2019. This rollout was moved to the version 79 release in November 2019. Although we believe it to be well-intentioned, this change is expected to break authentication flows that are based on the OpenID Connect standard. Therefore, well-established patterns of authentication will not work.
How to check the Chrome version
If you suspect that your users are using Chrome version 79 or a later version that has SameSite enabled, you can check the version number by in the Chrome browser by navigating to Settings > Help > About Google Chrome.