Error AADSTS165000 when launching portal.office.com

Question

We have several users reporting an AADSTS165000 error when launching portal.office.com from their work computers. This issue is present for a portion of our users across multiple devices and browsers, Edge and Chrome. During testing we tried the following links as alternatives but they all produce the same issue.

https://portal.office.com?domain_hint=domain.com

https://office.com/login?domain_hint=domain.com

https://microsoft365.com/login?domain_hint=domain.com

Clearing the browser cache will allow the user to login once before returning to the same error on next launch.

Other links including Office.com and outlook.office.com are functioning as a workaround but this does not provide a permanent solution. We require a working link that allows the user to access the main O365 portal page without having to click the sign-in button on the main office.com site.

We experienced this issue for a few hours on Friday and thought it was resolved but it was reported again this afternoon.

Error is as follows;

Request Id: 5c47017d-aca9-4d80-8838-7f1ccfe1ae00

Correlation Id: 479d28d7-bc57-423c-8ed2-d9e0b78d7991

Timestamp: 2023-06-20T21:32:04Z

Message: AADSTS165000: Invalid Request: The request did not include the required tokens for the user context. One or more of the user context values (cookies; form fields; headers) were not supplied, every request must include these values and maintain them across a complete single user flow.

Notable Details

Edge: 114.0.1823.51

Chrome: 114.0.5735.110

OS: Windows 10 22H2 (Desktops) and LTSC 1809 (VMware Horizon)

Antivirus: Crowdstrike

Thanks in advance for any help you can provide.

Answer 1

The issue only occurs in very specific situations.

When no other connection to Office apps has been made already (Teams, Outlook, Sharepoint, OneDrive, ...) and one tries to connect to https://portal.office.com (e.g. using the "Office Online" icon on desktop, you can get the error.

Our Home page connects to Sharepoint, so when a browser is opened first, our users do not get the error, but when no browser is open yet (and no other connection to Office Apps is active), when users try to connect to "Office Online" they seem to get the error.

We managed to find a workaround on this issue, normally when browsing to https://portal.office.com, after providing credentials, the landing page is https://www.microsoft365.com/?auth=2. When changing the URL behind the "Office Online" icon to this URL, our users do not get the error.

Looks like something has changed at Microsoft with the signon process on the "portal.office.com" website (as previous comments also have stated)

Answer 2

I have found a fix, or at least a workaround for this.
By a long process of trial and error using both Chrome and Edge I have found that the error is caused by a cookie that is coming from www.microsoft365.com.
By setting your browser to delete all cookies and site data from www.microsoft365.com the SSO process will work, because the offending cookie is not in place at the time of loading the browser.

In Chrome settings on the Privacy and Security > Cookies and other site data page there is an option for ‘Always clear cookies when windows are closed’ where individual sites can be added. Add www.microsoft365.com to this list.

The corresponding setting in Edge is - Settings > Cookies and site permissions > Manage and delete cookies and site data > Clear on Exit
Adding www.microsoft365.com to this list deletes cookies and site data and allows SSO to work every time.

Note that the www is important. Just adding microsoft365.com will not work. When adding the site to the list it must be www.microsoft365.com

I'm hoping now that I can find a way to apply this by GPO.

Answer 3

Double post

Answer 4

Hopefully this issue has been resolved for you as well but if not the cause was on the Microsoft side and you will need to place a support request through the Entra (Formerly AzureAD) support page.

The only details I could get from Microsoft were that they "ran diagnostics that are expected to resolve the issue" and "They are not permitted to disclose further information".

We have not had a report of the issue for over a week at this point and are considering the issue resolved.

Thanks to all who helped troubleshoot and provided workarounds.