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
 <del>~~~~~~~~~~~</del>~~ 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&amp;FailedURI=http%3A%2F%2Fmsoid.sympmarc.com%2FFPUrl.xml&amp;FailureMode=1&amp;Implementation=&amp;AddInType=4&amp;Version=pywr1.0&amp;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+="&amp;w="+x+"&amp;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 me@sympmarc.onmicrosoft.com, 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.

from Marc D Anderson’s Blog https://ift.tt/2P3MnT9
via IFTTT