Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
###Notice: many issues / bugs reported are actually related to the PnP Core Library which is used behind the scenes. Consider carefully where to report an issue:###
Reporting an Issue or Missing Feature
Issue in authenticating to the SharePoint Site
We are a tenant which uses Multi-factor authentication and PnP PowerShell Authentication used to be working as expected 3 weeks back. Now, we are having an issue and the error is
We are using PnP PowerShell in unattended mode and now the complete process is in stand still mode. When we use the code,
We should get the PnP PowerShell Module connected to SharePoint Site
Steps to reproduce behavior
when we execute
Which version of the PnP-PowerShell Cmdlets are you using?
What is the version of the Cmdlet module you are running?
(you can retrieve this by executing
Binary 2.26.18... SharePointPnPPowerShellOnline
How did you install the PnP-PowerShell Cmdlets?
The only way around this is by using an app only approach. E.g. create either on SharePoint or Azure AD an app-only id and secret or certificate and use that to authenticate. Alternatively create a service account which does not require multi-factor authentication, but from a security standpoint this is maybe not the right approach.
We have not changed the connection approaches behind the scenes in PnP PowerShell or PnP Sites Core (which is the underlying library behind many of the PnP PowerShell Cmdlets), so it if worked until a few weeks ago I assume a change in the authentication process was made to your tenant.
Thank you @erwinvanhunen for the super quick response and the recommendation . Do you mind giving me a lead on app-only-id for authenticating a PowerShell authentication. We are a bit grey in that area on how to achieve that. Any links / articles which you are aware of; it would be great if you can share that.
Change in the tenant level authentication is what we are assuming and the concerned team is looking into that. What we wanted to make sure is to have any kind of modification done from the PowerShell standpoint in O365 level. That is the reason we had raised as an issue.
Found this Article. http://sharepointviews.com/the-underlying-connection-was-closed/
Basically, a mismatch in security protocol. Microsoft announced that they will be moving to TLS 1.2 for encryption on October 31, 2018 for Office 365. Here is a Microsoft support article Preparing for the mandatory use of TLS 1.2 in Office 365 explaining this.
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;
I found via testing on another server that the new version of SharePointPNPPoerShellOnline module enables tls 1.2 by default when you run the Connect cmdlet. This was not happening for me; however, as I had a previous version of the module installed. I had to manually remove the current and previous versions of the module and reinstall the module via Install-Module cmdlet.
Now, my default setting still does not include tls 1.2 ([System.Net.ServicePointManager]::SecurityProtocol) until I run the connect cmdlet with the current version of the module installed.