Home
Microsoft

I’ve seen a few requests from customers encountering authentication issues with SharePoint Designer 2013 after disabling legacy authentication (IDCRL) in SharePoint Online. While SharePoint Designer wasn’t natively designed to work with Modern Authentication (ADAL) there are updates available that allow it to work.

 

Most Office 2013 applications will be able to successfully use modern authentication once the EnableADAL=1 registry key has been set as documented in this article:

 

Enable Modern Authentication for Office 2013 on Windows devices

https://support.office.com/en-us/article/Enable-Modern-Authentication-for-Office-2013-on-Windows-dev...

 

But SharePoint Designer has additional requirements that need to be met before it will attempt to use Modern Authentication. Without meeting all the requirements, the typical experience will be a repeated authentication challenge with a generic credential dialog like this:

 

1 SPD_Legacy_Challenge.png

 

When successfully authenticating with SharePoint Online, the "Sign in" dialog should look like this:

SPD_Modern_Challenge.png

 

 

 

 

Modern Authentication (ADAL) support

For SharePoint Designer to attempt modern authentication the following requirements must be met:

 

1. The EnableADAL registry key referenced earlier must be set to 1:

HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Identity\EnableADAL = 1

Regedit_EnableADAL.png

 

2. The following files must be at least these minimum versions:

ADAL.dll - 1.0.1933.710 or greater

MSO.dll - 15.0.4625.1000 or greater

CSI.dll - 15.0.4625.1000 or greater

 

By default, these DLL files will be in one of the following locations based on whether the 32-bit or 64-bit version of SharePoint Designer installed:

32-bit folder: C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE15\

64-bit folder: C:\Program Files\Common Files\Microsoft Shared\OFFICE15\

 

3. If these Office 2013 applications are installed, they should be at minimum:

GROOVE.EXE - 15.0.4625.1000 or greater

OUTLOOK.EXE - 15.0.4625.1000 or greater

 

By default, these EXE files will be in one of the following locations based on whether the 32-bit or 64-bit version of SharePoint Designer installed:

32-bit folder: C:\Program Files (x86)\Microsoft Office\Office15

64-bit folder: C:\Program Files\Microsoft Office\Office15

 

Need to identify which DLLs are actually loading?  See the Advanced Information section below.

 

Where to get the required patches

The first step is to run Windows Update on your computer and make sure all Office 2013 updates have been installed. If you can’t get the updates via Windows Update the following article provides links to the most recent updates for many of the Office 2013 components.

List of the most current .msp files for Office 2013 products

https://docs.microsoft.com/en-us/officeupdates/msp-files-office-2013  

 

You can search the article for “SPD”, “MSO” and “CSI” to find the latest patches for those components. As of March 2019, those entries are:

 

spd-x-none

SharePoint Designer 2013

August 2, 2016

3114721

mso-x-none

Office 2013

March 5, 2019

4462201

csi-x-none

Office 2013

July 11, 2017

3172545

 

ADAL.dll isn’t listed in that article, but the most recent update is available here:

 

ADAL.dll

Office 2013

June 14, 2016

KB3085565

 

 

 

Also note that SharePoint Designer, and other Office applications, cache credentials in Windows Credential Manager. If SharePoint Designer is still failing to authenticate after updating the files then close all Office 2013 applications, open Credential Manager (Control Panel -> User Accounts -> Manage Windows Credentials) and “Remove” all entries that begin with “MicrosoftOffice15”.

 

 

Advanced Information

 

How can I tell exactly which DLLs are being loaded by SharePoint Designer?

The “Process Explorer” tool is excellent for this:

https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

 

Make sure SharePoint Designer and Process Explorer are both running.

In Process Explorer select “SPDESIGN.EXE” in the “Process” list.

Click on the “View” menu and choose “Lower Pane View” > “DLLs”

Click on the “View” menu and choose “Select Columns” select the “DLL” tab and then check the “Version” checkbox.

Now you can easily verify the version and location of the DLLs.

For example, here is what x86 SharePoint Designer SP1 looks like. I sorted by the “Path” column and can easily see that ADAL.DLL and MSO.DLL are below the minimum requirement needed for Modern Authentication:

SPD_SP1_Process_Explorer.png

 

After running Windows Update and making sure the patches are installed it looks like this:

SPD_Patched_Process_Explorer.png

 

 

How can I tell if SharePoint Designer is attempting to use Modern Authentication?

Fiddler.exe from https://www.telerik.com/fiddler is a great tool for seeing the HTTP/HTTPS network traffic involved. To see the details of the HTTPS traffic you’ll first need to go to Tools -> Options -> HTTPS -> “Decrypt HTTPS traffic”.

 

Modern vs legacy authentication is negotiated when the client application attempts to connect to SharePoint Online. This negotiation is handled by headers that are added to the request. The client application will include headers advertising the authentication methods that it supports and SPO will return an HTTP 401 Unauthorized response with matching WWW-Authenticate headers for each of those methods that it also supports.

 

The legacy authentication headers are:

X-IDCRL_ACCEPTED: t

X-FORMS_BASED_AUTH_ACCEPTED: T

 

The modern authentication header is:

Authorization: Bearer

 

If the server doesn’t support any of the authentication methods the client advertised, then no WWW-Authenticate header will be returned, and the client will display a generic credential prompt which isn’t going to work with SPO.

 

Here is an example of what that looks like in Fiddler. You can see that SharePoint Designer (which appears as spdesign:9956 in the Process column) advertised that it supports legacy authentication only by including only the X-IDCRL_ACCEPTED: t header. Since legacy authentication is currently disabled in the SharePoint Online tenant the 401 response doesn’t include the WWW-Authenticate header necessary for the SharePoint Designer to move forward with authentication:

SPD Legacy Only.png

 

 

NOTE: The svchost process seen in this Fiddler trace is the WebClient Service making WebDAV calls attempting to populate the File Open dialog for SharePoint Designer. WebDAV can’t authenticate directly to SPO and instead needs to find an existing persistent cookie. I don’t have a persistent cookie and therefore all of those requests result in 401 Unauthroized responses as expected.

 

After running Windows Update and making sure my components are patched properly, Fiddler shows that SharePoint Designer advertised support for both Modern (Authorization: Bearer) and Legacy (X-IDCRL_ACCEPTED: t). Since my SharePoint Online tenant has blocked legacy authentication the 401 response includes only a WWW-Authenticate header for Modern / Bearer authentication which includes the information SharePoint Designer needs to proceed.

 

SPD_Patched_Fiddler_Modern.png