Search User Login Menu

Dreaded DTD Error When Authenticating to SharePoint Online

Doctor SharePoint

Dreaded DTD Error When Authenticating to SharePoint Online

Have you ever encountered the CSOM error "for security reasons DTD is prohibited in this XML document..." when executing a PowerShell scripts against SharePoint Online?  This error can be a frustrating issue to solve.  Below are some solutions that have been successful in resolving this error message or issues similar to it.

  • When working on a script for a client, the issue we encountered was that the credentials provided in a script were not being federated.  In other words, the username was not in the form "", but rather "".  Try providing the "*" account and if that works try again with the federated account. To further diagnose what was going on, I used Fiddler to compare the request/response trace from a successful authentication and one where this error occurs. It turns out that somewhere internally a request is made to msoid.<full-domain> where <full-domain> is the bit after the @ symbol from the username provided. In the case where this value is of the * variety, a 502 error (no DNS entry) is returned with no request body and the authentication proceeds successfully. In the other case, the ‘msoid’ URL is resolved and a response with a request body is returned. In my case the response was a 301 error (permanent relocation), however I read of cases where a 200 (success) has been received. Importantly to note, is that the response, success or otherwise, returns an HTML body containing a DTD (Document Type Declaration), and in turn produces the rather unhelpful error message. So how do you fix it? Well one way is to provide an entry in your hosts file which ensure that the msoid URL will be invalid. I found that providing a local host entry for it worked. Your hosts file can be found here: C:\Windows\System32\drivers\etc. I added a line which looks like the following:

After adding this line, the authentication credentials were properly federated.  Interestingly enough, when I removed this line from the host file, the credentials continued to work.  Its suggested that you try authenticating with the "*" account first before editing the host file on the workstation where you are running the script.

  • The error message has also ben encountered when working remotely from home.  In this case I found a solution on a TechNet forum where a user made a change to their network connection DNS configuration.  Generally, my network connection is configured to obtain the settings automatically, but I changed the DNS server settings to manual and added these two server addresses: /  With this change, I was able to successfully pass my credentials to Office 365.

I home these two potential solutions saves someone from hours of frustration! 

If you continue to have authentication failures, you may want to try the -WebLogin connection, described in this article:  From the Operating Room: PowerShell for SPO with MFA


Questions? Please send your questions or make an appointment today for a consult via email to

2392 Rate this article:
No rating
Please login or register to post comments.
Back To Top