Effect on customer websites and Microsoft services and products in Chrome version 80 or later
Previously, this article referenced Google Chrome Beta version 79. Google is scheduled to release a cookie behavior in Chrome Stable version 80. Chrome has updated their rollout timeline to indicate that this change will be rolled out in Chrome 80 starting the week of February 17. Chrome 80 will ship on February 4 and have this feature disabled by default. The feature will be enabled on a graduated schedule starting February 17.
The Stable release of the Google Chrome web browser (build 80, scheduled for release on February 4, 2020) will roll out a change to the default cookie behavior starting the week of February 17. Although the change is intended to discourage malicious cookie tracking and protect web applications, it's also expected to affect many applications and services that are based on open standards. This includes Microsoft cloud services.
Enterprise customers are encouraged to make sure that they're prepared for the change and are ready to implement mitigations by testing their applications (whether custom-developed or purchased). For more information, see the "Recommendations" section.
Microsoft is committed to addressing this change in behavior in its products and services before the Chrome 80 release date. This article discusses the guidance from both Microsoft and Google for installing the various updates that are required for products and libraries, and the guidance for testing and preparation. However, it's equally important that you test your own applications against this change in Chrome behavior and prepare your own websites and web applications as necessary.
Effect on customer applications
All Microsoft Cloud services are updated to comply with the new requirements made by Chrome, but some other applications may still be affected. Check the "Recommendations" section for some server products that will require updating by customers.
You should thoroughly test all applications by using Chrome Beta version 80 to verify the effect of this change. We expect that problems similar to the problems that this article describes will affect your applications. This is especially 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 betas 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 Chrome version 80 by having specific flags enabled. Doing this can, at least, help you discover the effect so that you can determine your best plan. For more information, see the "Testing guidelines" section.
Microsoft Edge browser on Chromium (version 80) will not be affected by these SameSite changes. You can read the Edge documentation to see the current plan for adapting this change.
Microsoft customers who use Active Directory Federation Services (AD FS) or Web Application Proxy must deploy one of the following Windows Server updates:
|Product||KB Number||Release Date|
|Windows Server 2019||KB 4534273||January 14, 2020|
|Windows Server 2016||KB 4534271||January 14, 2020|
|Windows Server 2012 R2||KB 4534309||January 14, 2020|
The following Microsoft server or client products must also be updated. The updates will be added to this article when they're available. We recommend that you revisit this article regularly for the latest updates.
|Product||KB Number||Release Date|
|Exchange Server||March 2020 Cumulative Update|
|SharePoint Server 2019||KB 4484259||February 11, 2020|
|SharePoint Server 2016||March 2020 Public Update|
|SharePoint Foundation 2013||March 2020 Public Update|
|SharePoint Server 2013||March 2020 Public Update|
|SharePoint Foundation 2010||March 2020 Public Update|
|SharePoint Server 2010||March 2020 Public Update|
|Skype for Business Server 2019||March 2020 Cumulative Update (CU 3)|
|Skype for Business Server 2015||April 2020 Cumulative Update (CU 11)|
You must test your applications for all the following scenarios, and determine the appropriate plan based on the outcome of the tests:
- Your application is unaffected by the SameSite changes. In this case, there's no action to take.
- Your application is affected, but your software developers can make the change in time to use the SameSite:None cookie settings. In this case, you should change your application by following the developer guidance in the "Testing guidelines" section.
- Your application is affected but can't be changed in time. For internal sites, the application can be excluded from the SameSite enforcement behavior in Chrome by using the LegacySameSiteCookieBehaviorEnabledForDomainList setting.
If enterprise customers learn that most of their apps are affected, or if they do not have enough time to test their apps before the graduated release of the feature starting on February 18, they're encouraged to disable the SameSite behavior in computers they govern. They can do this by using Group Policy, System Center Configuration Manager, or Microsoft Intune (or any Mobile Device Management software) until they can verify that the new behavior doesn't break basic scenarios in their apps.
Google has released the following enterprise controls that can be set to disable the SameSite enforcement behavior in Chrome:
- LegacySameSiteCookieBehaviorEnabled, which enables or disables this change.
- LegacySameSiteCookieBehaviorEnabledForDomainList, which allows Chrome to disable this policy on specific domains.
For enterprise customers who develop their applications on .NET Framework, we recommend that they update libraries and set the SameSite behavior intentionally to avoid unpredictable results that are caused by the change in the cookie behavior. To do this, see the guidance in the following Microsoft ASP.NET Blog article:
Also, see the following Google Chromium Blog article for developer guidance about this issue:
Customers who have affected sites that impact consumers or users who are not covered under their Enterprise policies must instruct those users to use a different browser (Edge, Firefox, Internet Explorer) or walk those users through how to disable the settings in Chrome (as shown in the next section) while they fix their applications.
Google has published this guidance for developers to prepare for the SameSite changes. Additionally, we recommend that you test your websites and apps by using the following approach.
Use Chrome Beta version 80 to test the scenarios:
Download Chrome Beta version 80:
Start Chrome by using the following additional command line flag:
Enable the SameSite flags. To do this, type Chrome://flags in the Address bar, search for SameSite, and then select Enabled for the following options.
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's known as SameSite.
The Chrome team had announced plans to roll out a change in the default behavior of the SameSite functionality starting in a release of Chrome version 78 Beta on October 18, 2019. This rollout will be moved to Chrome version 80 release on February 4, 2020. This change helps improve web security. However, it also breaks authentication flows that are based on the OpenID Connect standard. Therefore, well-established patterns of authentication won't work.
Checking the Chrome version
If you suspect that your users are using a Chrome version 76 or a later version that has SameSite enabled, you can check the version number by navigating to chrome://settings/help or by selecting the Chrome settings icon, and then selecting Help > About Google Chrome.
For the 77–79 versions of Chrome, check the Chrome://flags in the browser to see whether they have the flags enabled. The setting default will begin to change in Chrome version 80 on a graduated release.
Third-party information disclaimer
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.
Microsoft provides third-party contact information to help you find additional information about this topic. This contact information may change without notice. Microsoft does not guarantee the accuracy of third-party contact information.