search

pnp / PnP-PowerShell

SharePoint PnP PowerShell CmdLets
https://pnp.github.io/powershell
Other
987 stars 662 forks source link

Exception: Connect-PnPOnline when LegacyAuthProtocolsEnabled = $False #2747

Open matsla opened 4 years ago

matsla commented 4 years ago

When using Connect-PnPOnline with username and password and LegacyAuthProtocolsEnabled = $False we get following error, below. As we are using this in a deamon process we cant use the UseWebLogin switch. We are not able to connect using an Azure AD App due to Application Permission can only be assined to all sites in tenant.

Can this issue be corrected? Any work arounds to get this working with username & password and LegacyAuthProtocolsEnabled = $False?

Connect-PnPOnline -url https://xxxx.sharepoint.com/ Connect-PnPOnline : Exception has been thrown by the target of an invocation.

Exception has been thrown by the target of an invocation.

Stacktrace : at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at OfficeDevPnP.Core.PnPClientContext.<>c__DisplayClass12_0.b0(Object oSender, WebRequestEventArgs webRequestEventArgs) at System.EventHandler`1.Invoke(Object sender, TEventArgs e) at Microsoft.SharePoint.Client.ClientRuntimeContext.OnExecutingWebRequest(WebRequestEventArgs args) at Microsoft.SharePoint.Client.ClientContext.GetWebRequestExecutor() at Microsoft.SharePoint.Client.ClientContext.db.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.SharePoint.Client.ClientContext.d8.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.SharePoint.Client.ClientContext.d4.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at Microsoft.SharePoint.Client.ClientContextExtensions.d__7.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.SharePoint.Client.ClientContextExtensions.ExecuteQueryRetry(ClientRuntimeContext clientContext, Int32 retryCount, Int32 delay, String userAgent) at SharePointPnP.PowerShell.Commands.Base.SPOnlineConnectionHelper.InstantiateSPOnlineConnection(Uri url, PSCredential credentials, PSHost host, Boolean currentCredentials, Int32 minimalHealthScore, Int32 retryCount, Int32 retryWait, Int32 requestTimeout, String tenantAdminUrl, Boolean disableTelemetry, Boolean skipAdminCheck, ClientAuthenticationMode authenticationMode) at SharePointPnP.PowerShell.Commands.Base.ConnectOnline.ProcessRecord() at System.Management.Automation.CommandProcessor.ProcessRecord() ScriptLineNumber : 1

Which version of the PnP-PowerShell Cmdlets are you using?

ghost commented 4 years ago

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

KoenZomers commented 4 years ago

@matsla Recommended option of connecting is by creating an AAD app registration. Simply create one in your tenant and do not assign it any rights in AAD. Take the application/client id AAD generated for it, go to your SharePoint site, add to the URL /_layouts/appinv.aspx, paste in the client Id from AAD and you can give it fine tuned permissions, just for that list/document library/web/site collection.

Let me know if you require more detailed steps to get this done.

matsla commented 4 years ago

@KoenZomers this is a option if you have to support one SharePoint site. In my scenario we need to support > 1000 SharePoint site. We have a backgroud job to ensure correct metadata on all documents for each SharePoint site.

This options seems to work better in my scenario: Create an Azure AD App with Delegated permission for all SP Sites using a deamon account (Dedicated Azure AD Account). This will also work when LegacyAuthProtocolsEnabled = $False

KoenZomers commented 4 years ago

@matsla, correct, that could work, but it would require you to request permission for the app registration to all of their SharePoint Online sites. If that's fine by the ones who own the tenants, then you're good to go indeed. Likely needless to say, but be very careful with the PFX you connect to that app registration. You definitely don't want that to fall into the wrong hands.

matsla commented 4 years ago

@KoenZomers yes, thanks for the advice.

But is it possible for PnP Powershell/PnP Core to support Connect-PnPOnline with username and password when LegacyAuthProtocolsEnabled = $False ?

We have a lot of customizations that use this approch and when customers use LegacyAuthProtocolsEnabled = $False this will be an issue.

KoenZomers commented 4 years ago

@matsla, no, that will not be possible. Connecting with just a username and password relies on SharePointOnlineAuthentication, which is effectively a legacy authentication protocol and considered very insecure and therefore highly recommended against to enable this on any tenant.

matsla commented 4 years ago

@KoenZomers thanks for the input. I instead to use a dedicated Azure AD service account to acquire tokens for both Graph API /Sharepoint with an Azure AD App with delegated permissions.

If this is considered very insecure it's intresting when you create a new M365 tenant why LegacyAuthProtocolsEnabled is set to $True.

KoenZomers commented 4 years ago

@matsla Good question. Not sure why it's still enabled by default. Perhaps to allow for clients not capable of using modern authentication to connect as well? I heard a rumor recently that the standard mail client on iOS still uses legacy authentication and is still very popular amongst users of that platform.

SjoerdV commented 4 years ago

@KoenZomers I am having trouble reconciling this issue #1725 with your explanation in this issue. In my understanding:

using the second option does allow all Conditional Access possibilities for the account to be triggered (and monitored) and as long as MFA is not being forced, you can use this account in unattended solutions. I have no issues with this manner of connecting and also prevent (among others) the issue that is being proposed here: #2618

Also I have a Block Legacy Authentication CA policy configured which also works just fine allowing the PowerShell connection when modern auth is being used.

Would be great if you could comment on this, maybe I am doing or interpreting something not in the right way. Thanks!