Office 2013/2016 Client Authentication with SharePoint and ADFS

Office Error Featured

Recently one of my customers started rolling out office 2016 to their employees who were previously using office 2010. Though the office 2016 upgrade was going smooth, we started getting complains from a few users regarding multiple credentials popups.

Problem Statement

The customer had SharePoint 2016 configured with ADFS 3.0 authentication. Users who got migrated to Office 2016 suddenly started getting these authentication prompts when editing office documents which were opened from SharePoint document libraries. An ideal case was – they open the document for editing, leave it open for some time, say 1-2 hours, they get back and when they try to save, they would get this – “You are required to sign in to upload your changes to this location”

Office Error

To make this worse, when they click on “Sign In” button, a windows credentials pop up would appear, which wouldn’t accept even the correct credentials. After a few attempts, even that window would disappear, leaving the document unsaved.

NTLM Prompt

These pop-ups were coming even in outlook where users had synchronized lists/libraries/calendars.

Investigations

As always, the investigation started with google and this article came up quickly. This seemed like a perfect match to the issue in hand. So, we looked into the ADFS configuration as explained in this link within that article. But that was already configured as required.

Next we setup the trace, again as per the same article, but got no entries related to our issue.

So, even though in that article, the problem statement was almost similar, the solution was no where close!

Some Progress

After some more research, it started appearing that it has to do with how Office 2016 handles “Modern Authentication”. This term appeared a number of times in various posts/comments. When researched further, this is what came up “Modern authentication brings Active Directory Authentication Library (ADAL)-based sign-in to Office client apps across platforms. This enables sign-in features such as Multi-Factor Authentication (MFA), SAML-based third-party Identity Providers with Office client applications, smart card and certificate-based authentication, and it removes the need for Outlook to use the basic authentication protocol.

Now, we were getting somewhere 🙂 A little more digging and this appeared – How modern authentication works for Office 2013 and Office 2016 client apps. Here it becomes interesting. There are some conflicting information available about whether ADFS 3.0 supports modern authentication or not.

This article written in June 2015 mentions it does but this one clearly mentions “modern authentication isn’t supported by the Office 2016 clients with SharePoint Server 2016, such as when it is used for Active Directory Federation Services (AD FS) 3.0 installations.

So, I decided to give both a try.

Solution Attempt 1

It would be great if we could just get modern authentication working and as explained in this article that seemed to be an easy change. Office 2016 clients use “windowstransport” endpoint to communicate with ADFS for modern authentication.  Office and ADAL clients target the WS-Trust 1.3 version of the endpoint for windows integrated authentication which is not enabled by default in ADFS 3.0. By default WS-Trust 2005 version is enabled only.

ADFS Windows Transport EndPoint 2013
So, we need to enable that by running the PowerShell command in ADFS Server.

Enable-AdfsEndpoint -TargetAddressPath "/adfs/services/trust/13/windowstransport"

And that’s it. Verified, if Office 2016 clients were now able to connect using modern authentication and pop-ups were gone. Unfortunately, they weren’t. Nothing changed after enabling this ADFS endpoint. Office 2016 documents and Outlook continued to pop-up for credentials and wouldn’t accept even the correct one.

Time for the other alternative now.

Solution Attempt 2

As it came up during the investigations that Office 2016 tries to use modern authentication by default, which was not the case with Office 2010. Since, this problem started to appear only for users who were upgraded to Office 2016, the goal was to revert to Classic Authentication now.

Step 1

First, we need to ensure that SharePoint site has been added in trusted zone in IE and the option “Automatic log-on with current username and password” is selected under Security Settings –> User Authentication –> Logon.

IE Trusted Login

Step 2

Now we need to configure SharePoint Server 2016 to suppress modern authentication in Office 2016 clients. This is straightforward but requires SharePoint 2016 Feature Pack 1 to be installed.

Just open the SharePoint 2016 Management Shell and Run the following commands

$sts = Get-SPSecurityTokenServiceConfig
$sts.SuppressModernAuthForOfficeClients = $true
$sts.Update()

Once the above commands are execute, perform IISReset on all the SP servers.

iisreset /restart

and Restart SharePoint Timer Job

Net Stop SPTimerV4
Net Start SPTimerV4

You would notice that the multiple pop-up issue with Word, Excel and PowerPoint are not now. Whenever, these clients need to re-authenticate, you would see a small ADFS login page appearing and disappearing quickly if you are connected to corporate network. In that case, these clients can now do Windows Integrated  Authentication. If you are not connected to corporate network, the ADFS login page will remain and you need to type in the credentials.

ADFS Login Page

But, for some reason Outlook 2016, still doesn’t work. It would continue to popup for credentials and won’t accept even the correct one when it tries to send/receive with any synced list/library!

Step 3

To fix this, we need to update a registry entry on client machines on which outlook is installed. Of course in a corporate environment, this registry change needs to be applied using a Group Policy to all client machines.

Open Registry using RegEdit and

  • Go to HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity
  • Check if EnableADAL key is present
  • If not present then create new REG_DWORD 32 bit key with name EnableADAL and value 0

And that’s it, all your office 2016 clients will stop complaining now and work transparently with SharePoint documents when connected to company network. If accessing from outside network, you could see an ADFS login screen which would accept the correct credentials.

 

Enjoy,
Anupam

 

You may also like

2 comments

  1. Thank you so very much for your help. We are a large organization using SharePoint with Office 365 and have encountered this issue. Just performing Step 3 of Solution Attempt 2 (the registry change) resolved all of our issues.

    Really appreciate your blog and the recommendations!

  2. I am looking for a java program that uploads file to sharepoint which uses My companys STS ADFS Token for authentication. I know about apache HTTP Client but I don’t know how the Auth mechanism works, any hint?

Leave a Reply

Your email address will not be published. Required fields are marked *

4 × 2 =