If you are using an Office 365 ProPlus version prior to 1808, along with Windows 10 1703 or later, you may have an issue where Office applications do not use SSO to sign in, and after users enter their email address, they then have to enter their username and password again in the ADFS login form. This is due to issues with Web Account Manager (WAM), which is used for authentication instead Azure Active Directory Authentication Library (ADAL) with Office 365 ProPlus on recent versions of Windows. Other issues we have seen include:
- Being unable to obtain a license for Office at all, and Office going into reduced functionality mode, especially if you are using Shared Computer Activation
- Activation issues after changing password or UPN
- Repeated requests to enter passwords
- Showing users a screen asking if they want to add the account to Windows
Fortunately, there is a fix for this, which is listed in a Microsoft article, which lists several symptoms but doesn’t specifically mention SSO issues.
Firstly, if you are running a Windows 10 build later than 1703, you will be using ADAL. So firstly, make sure you have this enabled in your ADFS infrastructure.
Enable ADAL Enable WS-Trust 1.3 for Desktop Client SSO ADAL
In your ADFS console, check the following endpoint shows enabled (/adfs/services/trust/13/windowstransport):
If not, run the following PowerShell command on your ADFS server to enable the endpoint for WS-Trust 1.3:
Enable-AdfsEndpoint -TargetAddressPath "/adfs/services/trust/13/windowstransport"Apply the ADAL registry fix
Now you may find that SSO still does not work, and that users get a second username and password prompt, instead of SSO taking care of it. This is documented here: https://support.microsoft.com/en-us/help/4025962/can-t-sign-in-after-update-to-office-2016-build-16-0-7967-on-windows-1
Update: Microsoft do not now list this reg key in this article, however this still resolves SSO issues for many users.
Create a Group Policy Object to add the following registry value at user login, or test using a reg file:
Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity] "DisableADALatopWAMOverride"=dword:00000001
In both test and production, this reverted the Office sign in process to the proper behaviour, SSO is seamless and transparent, the user never has to enter their credentials.
If you still have issues, enable logging as follows:
To gather more verbose logging details, set the following registry keys.
For Sign-in/Activation issues:
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Logging]
“EnableLogging”=dword:00000001
Reproduce the issue and gather the logs for review. The logs will be stored under %temp% for Sign-in/Activation issues.
Let us know in the comments if this helps you out!
Also see https://cloudrun.co.uk/single-sign-on-ssowith-chrome-firefox-and-adfs-4-0/
