Solving the `For security reasons DTD is prohibited in this XML document.’ PowerShell Error

This is more a Todd Klindt (@ToddKlindt) post than a me post, but hey – he was on vacation. I was trying to run some PowerShell on my new-ish tenant and was getting an error Todd and I had worked past before. Just a simple:

$adminSiteUrl = "https://sympmarc-admin.sharepoint.com"
Connect-PnPOnline -Url $adminSiteUrl -Credential sympmarc

…was giving me an error like this:

Connect-PnPOnline : For security reasons DTD is prohibited in this XML document. To enable   
 DTD processing set the DtdProcessing property on XmlReaderSettings to Parse and pass the     
 settings into XmlReader.Create method.
 At line:3 char:1
 Connect-PnPOnline -Url $adminSiteUrl -Credential sympmarc
 ~~~~~~~~~~~~~ CategoryInfo          : NotSpecified: (:) [Connect-PnPOnline], XmlException
 FullyQualifiedErrorId : System.Xml.XmlException,SharePointPnP.PowerShell.Commands.Bas  
 e.ConnectOnline

The problem was a combination of my new Office 365 tenant and my ISP, NOT the PowerShell, of course.

I figured out what the initial issue was by running Fiddler and capturing the traffic when I ran the Connect-PnPOnline cmdlet. Here’s what I saw:

HTTP/1.1 401 Unauthorized
 Content-Type: text/plain; charset=utf-8
 Server: Microsoft-IIS/10.0
 X-SharePointHealthScore: 4
 X-MSDAVEXT_Error: 917656; Access+denied.+Before+opening+files+in+this+location%2c+you+must+first+browse+to+the+web+site+and+select+the+option+to+login+automatically.
 SPRequestGuid: 8c8dfa9e-0055-0000-498e-df43e63fdd9e
 request-id: 8c8dfa9e-0055-0000-498e-df43e63fdd9e
 MS-CV: nvqNjFUAAABJjt9D5j/dng.0
 Strict-Transport-Security: max-age=31536000
 SPRequestDuration: 52
 SPIisLatency: 0
 X-Powered-By: ASP.NET
 MicrosoftSharePointTeamServices: 16.0.0.9124
 X-Content-Type-Options: nosniff
 X-MS-InvokeApp: 1; RequireReadOnly
 P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
 WWW-Authenticate: IDCRL Type="BPOSIDCRL", EndPoint="/_vti_bin/idcrl.svc/", RootDomain="sharepoint.com", Policy="MBI"
 Date: Thu, 15 Aug 2019 19:05:44 GMT
 Content-Length: 0
HTTP/1.1 200 OK
 Server: nginx
 Date: Thu, 15 Aug 2019 19:05:45 GMT
 Content-Type: text/html; charset=utf-8
 Transfer-Encoding: chunked
 Connection: close
 Expires: Thu, 15 Aug 2019 19:15:45 GMT
 Cache-Control: max-age=600
 X-Frame-Options: DENY
 372
 
url="http://finder.cox.net/main?ParticipantID=96e687opkbv4scrood8k84drs6gw5duf&FailedURI=http%3A%2F%2Fmsoid.sympmarc.com%2FFPUrl.xml&FailureMode=1&Implementation=&AddInType=4&Version=pywr1.0&ClientLocation=us";if(top.location!=location){var w=window,d=document,e=d.documentElement,b=d.body,x=w.innerWidth||e.clientWidth||b.clientWidth,y=w.innerHeight||e.clientHeight||b.clientHeight;url+="&w="+x+"&h="+y;}window.location.replace(url);

 0

I was getting an HTTP/1.1 401 Unauthorized – but I knew my credentials were correct and I had the right permissions. The big clue was the URL, which pointed to http://finder.cox.net. Obviously, that wasn’t the tenant I was working with, so what was up?

Well, Cox is my ISP right now and it was trying to be helpful. It tries to do DNS lookups for me and if it can’t find the site I’m trying to reach, it gives me a “helpful” message like this:

Cox helping me out
Cox helping me out

The PowerShell cmdlet was trying to parse the “helpful” page from Cox, and of course it had no idea what that page meant. The cmdlet was expecting to hear back from SharePoint, not Cox.

It turned out there were two issues:

  • I hadn’t added a domain to my new-ish tenant yet. So while I was fine using it as [email protected], there was no way for PowerShell to “hook into” the tenant correctly.
  • Once I added my domain to my tenant, I was missing a CNAME entry for MSOID in my DNS records at my registrar.

Here’s what the CNAME record needs to be:

Type: CNAME
Name: msoid
Content: clientconfig.microsoftonline-p.net

Once I took care of both the issues above, everything was copacetic.

In trying to track down the problem, I found several articles which should have helped me get to a resolution, but somehow they didn’t make sense to me. Now that I understand the issue better they make total sense, but I figured I’d do a post in case my take on it might be useful for someone.

Similar Posts

3 Comments

    1. yes this is a problem with many ISP providers…. Verizon as well. changing DNS to Open DNS or Google fixes this

      1. just another comment, if you switch your laptop Wifi to use alternative DNS and you go to an airport or Microsoft office where they redirect you typically won’t be able to connect and you won’t know why. Change back to dynamic DNS, authenticate and then switch it back.

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.