SharePoint Designer and Modern Authentication

This post has been republished via RSS; it originally appeared at: SharePoint Support Blog articles.

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


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:






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



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  


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:



SharePoint Designer 2013

August 2, 2016



Office 2013

March 5, 2019



Office 2013

July 11, 2017



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



Office 2013

June 14, 2016





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:


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:



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




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

Fiddler.exe from 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:




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.






Leave a Reply

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


This site uses Akismet to reduce spam. Learn how your comment data is processed.