#SharePointProblems | Koskila.net

Solutions are worthless unless shared! Antti K. Koskela's Personal Professional Blog

Fixing the "For security reasons DTD is prohibited in this XML document." issue

koskila
Reading Time 4 min
Word Count 569 words
Comments 5 comments
Rating 5 (3 votes)
View

This post describes a couple of ways to fix the issue "For security reasons DTD is prohibited in this XML document". At least for me, it appeared when trying to access SharePoint Online using Powershell or a console program using OfficeDev.PnP (which in turn uses CSOM).

Error

When running any piece of code, whether in PowerShell, .exe console, or anything else than the code behind relies on .NET Framework, you get an error like this:

For security reasons DTD is prohibited in this XML document. To enable DTD processing set the ProhibitDtd property on XmlReaderSettings to false and pass the settings into XmlReader.Create method.

It could come from, for example, running Connect-SPOnline on PowerShell. Ours was first caused by the custom console app, but then also by running Powershell.

Reason for the problem

There are a number of issues that can cause this, and hence there are a few different solutions.

We got the error when we were supposed to provision certain artifacts on SharePoint online using PowerShell, based on an XML document describing the steps - think PnP provisioning templates. This led us to think it was somehow related to the XML file in question. This seemed logical.

However, the error itself just denies the processing of an XML document with DTD and doesn't tell what this document actually is. Besides, why would a document with a DTD (Document Type Definition, typically used to describe the schema and structure of the document) suddenly become invalid, while it worked just the day before?

Well, of course, because it actually had nothing to do with our implementation!

This happened on multiple different machines, and multiple different network connections, with any XML input, but just against one tenant (others worked) - so we figured it has to be about some configuration on that particular tenant or data center. Furthermore, Connect-SPOService (to admin site) worked, but Connect-SPOnline to normal site failed.

That's curious, right?

Solutions

As per usual with issues in SharePoint Online, there are multiple different solutions.
The third option worked for us, but I've read online and our internal resources that the other solutions have helped other people (even though they didn't help us), so I'm including them here.

  1. A conflict between cmdlets(?)

    One colleague had fixed this by switching from Windows Powershell to SharePoint Online Management Shell. Didn't help us.

  2. Is it a DNS issue? It's always a DNS issue, isn't it?

    Connecting to Microsoft's data centers might be trickier than you'd think. Interwebs is filled with stories about Microsoft just returning unresolvable DNS entries, which messes up the script, or your ISP might be trying to help and just makes the issue worse (by offering a "DNS help"-page which just omits the actual exception)

    This might be fixed by changing to Google's DNS (8.8.8.8), adding new entries to the host's file, disabling ISP or router features, or just simply running the program/script somewhere else - try Azure virtual machine, for example.

  3. It's not DNS messing up? Then maybe it's IPv6!

    This was weird, but disabling IPv6 finally solved our issues

Weird issue, but in the end, an easy solution.

Normally, I'd make those entries into links, but apparently, Gutenberg (WordPress's new editor) crashes if I do that, so I'm just not gonna. Sorry!

Comments

Interactive comments not implemented yet. Showing legacy comments migrated from WordPress.
2020-06-26 20:13:46)
This can also be caused by the LightSpeed web filtering agent, which may, in effect, basically be "DNS". The worst part of that is that it may be something the SharePoint admin has zero control or even influence over.
2020-07-01 00:27:11
Thanks for your comment! Yeah, I can absolutely see this happening. Quite a bother - and not everyone has the time (or even the possibility) to use a VPN or spin up a VM in Azure just to run a few commands!
elrod johnson
2020-10-06 04:24:27)
option 3 (disable ipv6) did it for me. i already had dns set to google. here's some powershell to disable ipv6. courtesy of Eric Herlitz. note that this disables ipv6 on ALL adapters. maybe not necessary.
## to disable ipv6:
Get-NetAdapter | 
    ForEach-Object { Disable-NetAdapterBinding             -InterfaceAlias $_.Name
            -ComponentID 'ms_tcpip6' }
            
## to verify disabled ipv6:
Get-NetAdapter | 
    ForEach-Object { Get-NetAdapterBinding             -InterfaceAlias $_.Name
            -ComponentID 'ms_tcpip6' }
2020-10-10 21:35:15
Thanks for your comment, Elrod! Always good to have a programmatical way for a task - much appreciated. 😊