SharePoint Designer and Modern Authentication

Published 03-22-2019 10:24 AM 39.6K Views

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 and the Type must be REG_DWORD:

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 December 2019, those entries are:



SharePoint Designer 2013

August 2, 2016



Office 2013

September 10, 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.







Hi Walter,

Basic/Legacy authentication has been turned off on our Microsoft 365 SharePoint site.  So I updated my registry key as required so I could use SharePoint Designer 2013.



However ....  I can not seem to get my SPD 2013 to authenticate to SharePoint using modern authentication.  The login window just keeps refreshing, with no error message, and it is the 'old' login form.



Following your wonderfully documented verification methods, I used Fiddler as you suggested to trace the headers, and I see that SharePoint Designer 2013 never ever sends the "Authorization: Bearer" header.  I only see the legacy headers (X-IDCRL_ACCEPTED and X-FORMS_BASED_AUTH_ACCEPTED)  which would explain why I can't authenticate.


But I do not understand why SharePoint Designer never advertises that it supports modern authentication.  Is there something else that I need to change besides the Identity registry key?


I actually even uninstalled then reinstalled SP 2013, running Windows Update to make sure it got all the required updates.


I verified that all the dll's you mentioned are current:

ADAL.dll = 1.0.2019.909

MSO.dll = 15.0.5127.1000

CSI.dll = 15.0.4941.1000

SPDESIGN.EXE = 15.0.5849.1000


As a note, when I looked at the list of DLLs in process explorer, ADAL.dll was not in the list.  MSO and CSI were.


I have cleared my Credentials through Credential Manager. 


I deleted files in the following folders:

\appdata\roaming\Microsoft\web server extensions\Cache


\appdata\local\sharepoint designer\proxyassemblycache


I also cleared the "Cache site data across SharePoint Designer sessions" application option checkbox in SPD 2013 (File > Options > General > Application Options)


Also tried logging into SharePoint first, getting into Classic mode, then trying the 'edit in SharePoint Designer' icon.  However, that simply took me to the Microsoft download page for sharepoint designer ??!!?


If I go ahead and re-enable basic authentication, all is well and I can get in.  But from everything I'm reading, including your article, it looks like I should be able to do this even with the modern authentication.


I am on a Windows 7, and we authenticate to Azure AD, using AD Connect to sync our on-premises Active Directory.  I currently have multi-factor authentication also turned on, but I don't think I am even getting that far.  I have global admin privileges.


Any ideas ?



Betty Stolwyk








Regular Visitor

Same problem here

Senior Member

Why not simlpy bring another actual version of SharePoint Designer (at least for onPrem environments)? I mean, it is hard to explain to a custumer, why they have to use a 2013(!) client "administrating" a 2016 or even 2019 environment. It's even harder to understand why Microsoft let the SPD die.


@airliner - Agreed!  

Occasional Contributor

All the download links inside the KB articles you linked are now dead ! :facepalm:


@Betty Stolwyk and @Saul Silva - I recently worked with a customer experiencing authentication failures in SPD due to information cached by the WebClient service (the Windows service responsible for the WebDAV calls).  On their system they could use Modern auth with SPD the first attempt after a reboot, but if they closed SPD and relaunched it it would fail going forward.  We found that restarting the WebClient service before launching SPD worked consistently for them. I'm curious if you are experiencing the same issue.  You can restart the WebClient service in Services.msc or you can create a simple bat file that can be run as Administrator with the following contents:
net stop webclient
net start webclient



@Grzegorz Wierzbicki  - Thanks - I'll follow-up internally.


Update - I've followed-up internally and this should be fixed soon.  In the meantime, if you need to download a file right now this is an issue with the word "downloads" vs. "download" in the URLs. If you get a 404 you can remove the "s" from downloads and it should work.


For example, from: Download update KB3114721 for 32-bit version of SharePoint Designer 2013

Change this:

To this:

Occasional Contributor

@Walter Warren 

The links are fixed now :)

Many thanks for a fast response!

Occasional Contributor

@Walter Warren 

KB4462201 links are still broken (or again?)

Established Member

Following this document from top to bottom got my issue resolved. 

Occasional Contributor
I already have the KB installed, and just change the registry and it's working.

@Walter Warren I have to apologize about not responding to your thoughtful suggestion.  I had gotten sidetracked and even more so now.  I believe I did a quick test of that and it made no difference.  Some configuration changes have happened since I reported this though, so I will really need to start from scratch again looking at this.  And that won't be happening for awhile!  But even though it would not appear so, I do appreciate your quick response and suggestion.  :)



Occasional Visitor

This worked like charm. Thanks so much.

Just to summarize the steps for other users:

  1. Open IE and check the site first and keep login
  2. Check all the dlls are updated or not
  3. Check ADAL registry settings set to 1
  4. Update all patches
  5. Restart your system
  6. Connect IE again and keep login
  7. Open SPD and connect now. It will WORK


Ravi Thapliyal

Version history
Last update:
‎Apr 30 2021 12:42 PM
Updated by: