Fix for SSO with Office 365 ProPlus (2016) and ADFS

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 listed at

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

In my testing, this reverted the Office sign in process to the proper behaviour, SSO is seamless and transparent, the user never has to enter their credentials.

Single Sign on (SSO) with Chrome & Firefox and ADFS 4.0

This is how to enable SSO with browsers other than IE and Edge using ADFS 4.0. This is done by adding the browser user agents to the ADFS config.

First, confirm the current config:

Get-AdfsProperties | select -ExpandProperty wiasupporteduseragents

MSIE 6.0
MSIE 7.0
MSIE 8.0
MSIE 9.0
MSIE 10.0
Windows Rights Management Client

Now we add Chrome, Firefox, and any other Mozilla compatible browser:

Set-AdfsProperties -WIASupportedUserAgents ((Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents) + "Mozilla/5.0")

Check the result:

MSIE 6.0
MSIE 7.0
MSIE 8.0
MSIE 9.0
MSIE 10.0
Windows Rights Management Client

Now, restart ADFS:

net stop adfssrv
net start adfssrv

Note that you could also add individual browsers instead of Mozilla/5.0 in case you wanted some browsers supported and not others. For example you might use Firefox for Global Admin users connecting to Office 365, so they can be signed into the Windows with one account, and use an Admin account to login to Office 365 using Firefox. So you could use something like this:

Set-AdfsProperties -WIASupportedUserAgents ((Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents) + "Chrome" + "Firefox")

Test using Chrome or Firefox, and you should find that SSO is working properly.

Note that Firefox also requires some client side configuration. Type in about:config and add the address of your ADFS server (e.g. to network.automatic-ntlm-auth.trusted-uris.



If you have any issues or want to remove this, you can reset the list to the default as follows:

Set-ADFSProperties -WIASupportedUserAgents @("MSAuthHost/1.0/In-Domain", "MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "MS_WorkFoldersClient","=~Windows\s*NT.*Edge")

Best practices for Office 365 Admin accounts

Administering Office 365 requires special consideration in order to ensure that your service is both manageable and secure. Optimal configuration requires a balance between security, usability, and availability, so all of these need to be considered when planning a strategy. However, the following is a general set of guidelines that can be applied to most deployments, whether they are federated or cloud only.

  • Create separate ‘Admin’ accounts for IT staff which are cloud accounts (using, don’t assign internal user accounts admin roles. When your domain is federated, these accounts will still work if there is any issue with ADFS.
  • Enable MFA for all Office 365 Admin accounts.
  • Set the password policy for cloud accounts so that it at least matches your on-premises password policy. Even if your domain is federated via ADFS, the password policy will apply to cloud only admin accounts. Note that you can only enforce password age and length, not complexity. If your on-premises policy is not particularly secure, set the policy to at least 10 characters long, and advise your admin users to use a mixture of capital and lower case letters, numbers and special characters. This won’t affect internal users, since the password policy is enforced by Active Directory.
  • Don’t assign admin accounts a license. It is not generally required, and this will prevent a mailbox being created and the accounts appearing in the GAL, which could cause confusion. However, there are some instances where a license may be required for Exchange or Intune admin functions which can make this problematic, in which case assign a license only when required.
  • Limited the number of Admin accounts, we generally recommend less than 5 in order to minimise attack surface.
  • Use  the principle of ‘least privilege’, use roles other than global admin e.g. Exchange Online Administrator, or helpdesk administrator where possible.
  • Review the Secure Score site periodically – and try and get your score as high as possible.
  • Have a separate admin account for scripting purposes, with no MFA but usually disabled. To do this set Sign In Status to Blocked, and only enable it when you need to run a script. Alternatively it is possible to use an MFA enabled account if you install the old PowerShell modules e.g. There are limitations with this however, and you will have to enter 2FA credentials every time you run the script, credentials cannot be stored in a variable.

Note that these recommendations are line with NCSC/CESG guidelines:

Microsoft Office 365 Security Guidance: Administrator good practice

Also see Security best practices for Office 365

Using this strategy has the following benefits:

  • Avoids Admin users having to use 2FA to sign in to Office on their desktops, which can be especially annoying if you are using Shared Computer Activation. Although this could be avoided using a conditional access policy.
  • It is more secure, the user is not signed in with a global admin account all the time.
  • The admin accounts can be used to resolve any issues with ADFS, which can prevent internal users from signing in.
  • Sometimes there may be no internal users who require admin access, if the tenant is managed by a third party. So using this strategy will work in any situation.

There are however drawbacks to this approach

  1. In order to administer Office 365, IT staff will need to use InPrivate or incognito browser mode, and connect to Office 365 with their 2FA. This is an inconvenience.
  2. The external accounts are available from the internet, which is not always the case with ADFS. This is mitigated through strong passwords and MFA.
  3. You need to make sure that Admin accounts are disabled when users leave, this is often overlooked. This requires robust leavers process for IT staff.