pnp
Changes in PnP Management Shell registration in Microsoft 365
Changes in PnP Management Shell registration in Microsoft 365
We are introducing changes on how the PnP PowerShell and CLI for Microsoft 365 can be used to connect to Microsoft 365, which might have an impact on your scripts and automation.
https://pnp.github.io/blog/post/changes-pnp-management-shell-registration/
The timeline is very tight for a change of this dimension. 3 months notice would be preferred. Is there plans to build on the documentation for the necessary changes?
Based on the available information I am currently unsure what impact this will have. From my understanding this will not affect the authentication that is normally used in unattended scenarios which is already using authentication using dedicated app registrations with secrets or certificates. However, what will happen when using the "-Interactive" parameter in the future, e.g. using "Connect-PnPOnline [yourtenant].sharepoint.com -Interactive"? Will this continue to work or will it be needed to provide additional parameters such as the ClientID of the App Registration in the future?
It would be really appreciated to get some more details about this, also about the specific permissions needed for the app to continue to work (the multi-tenant app currently has quite a lot).
Due to the very short timeframe I would like to make sure that we can prepare the needed as soon as possible to not expect any issues after 9th of September.
I assume any use of -Interactive after sept 9th is broken if new Entra ID app has not been set up. As mentioned, unattended use should not be affected since this requires an Entra ID app or managed identity.
I assume that via this: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins
I can query EntraID sign in logs to find the users who will be impacted by this, right? Is there any guidance on which values I should be searching for?
FYI: In this Video Erwin describes how to do the registration: https://www.youtube.com/watch?v=ecRZrHOucz4
Basically this confirms that starting from 9th of September it will be required to register an Entra ID App Registration with this command https://pnp.github.io/powershell/cmdlets/Register-PnPEntraIDAppForInteractiveLogin.html and use this app when connecting in interactive mode.
Whenever using the Interactive login it will be required to add the ClientID Parameter to the Connect-PnPOnline command, e.g. "Connect-PnPOnline [yourtenant].sharepoint.com -Interactive -ClientID <Client ID of the created App Registration>"
@mmascolino this can be checked in the Enterprise Application "PnP Management Shell" in Entra ID under Activity -> Sign-in Logs for interactive logins.
Additionaly for automation service account you can find in : Sign-in Logs -> User sign-ins (non-interactive) section
This is a bit of a nightmare. All our scripts running on client sites use -Interactive by default. Having thousands of people carry out emergency updates to scripts, which will now require a 36-char ClientID unique to each client, is the easy part. From past experience, convincing organizations to create their own Entra ID application takes weeks of review by multiple groups, which are not the group that maintains SharePoint, and asking them to create their own app and permissions rather than trusting PnP's multi-tenant app means lots of unknowns that they get pressured into doing quickly. It can't be done in a week or two.
Is someone facing an issue with cmdlet "Register-PnPEntraIDAppForInteractiveLogin" being stuck after authentication and "WARNING: No permissions specified, using default permissions" ? I'm using PowerShell 7.4.5 executed as administrator and 2.10.0 PnP module
I Asume when using Azure Functions with PnP PowerShell (ex. 2.4.0) using Managed Identity or Entra App registration using certificate with application permission this will continue to work after September 9 without any changes needed?
This will only be an issue in scripts after 9 September when using connect with -Interactive ?
I am trying to understand the purpose of the -SharePointApplicationPermissions and -GraphApplicationPermissions parameters in the Register-PnPEntraIDAppForInteractiveLogin command. If the sole purpose of using the app is for interactive login (i.e., user context with user permissions), why are these parameters needed?
And I would like to know if using the -GraphDelegatePermissions and -SharePointDelegatePermissions parameters with the required permissions will help exclude the default 4 delegated permissions (AllSites.FullControl, Group.ReadWrite.All, User.ReadWrite.All, TermStore.ReadWrite.All) that are automatically added when provisioning the app.
any automation done using app registration having appropriate SharePoint permission , uisng client id and certificate will not be impacted right ?
we need proper authentication steps because whatever i did on that youtube videos , it doesnt bring any result on subsites
I'm in agreement with @olemp. This was announced with only a short amount of time to react.
It would be great if we could extend this out to at least a month or two. A few weeks isn't enough time for this news to permeate out to the masses.
We created the App using the "Register-PnPAzureADApp" back in July 2021 and I checked App Authentication -> Supported Account Types -> Accounts in this Org Directory only -Single tenant. If we are using this App, would there be any impact on 9th September ?
Based on all the unclear documentations, it seems this change is ONLY going to impact interactive sign-in experience and NOT all other unattended options like using our own App Registrations with Client ID and Certificates, using Azure Functions Managed Identity or delegated scenarios using Client ID, Secret, UserID and Password... Can someone confirm this?
So, if we have 5 different Entra ID Apps with different permissions configured, we can continue to use those Apps for unattended scenarios?
Please extend the date for the multi tenant app deletion - the notice was too short and there was no notification (we are still using v1.12). This will have a major impact on our automation.
@zapftho - It impacts only the -Interactive scenario or Credentials scenario if you are using the PnP Multi tenant app. For unattended scenarios, no impact. The specific permissions that you would need would depend on which cmdlets you are using.
@harshdamaniahd - Paul Bullock has an article on this. https://pkbullock.com/blog/2024/permissions-for-pnp-management-shell-app . If you are using -ClientId + Cert , no impact.
@arconicajanes / @mikenikitin / @okms - totally get it. Unfortunately , this can't be extended.
@kumaranupam21 - if you are already using custom EntraID apps, no impact
@sdkchennai - if -GraphDelegatePermissions and -SharePointDelegatePermissions params are specified, it will overwrite the default permissions.
@matsla - you are correct. If using Managed identity or custom EntraID apps, no impact.
To make things easier and to ensure that you don't have to change/rewrite scripts quite a lot, we added support for environment variables. Specify the value of EntraID app in the variable and PnP will pick up the value from there and use in the code.
https://pnp.github.io/powershell/articles/defaultclientid.html
No tenant notifications stating that you have impacted services! Currently broken 1,000's of scripts that need to run around and update code. The entire handling of this is disrespectful to enterprise organizations needing to deal with change management.
Hello, we have created an open discussion around this :
https://github.com/pnp/powershell/discussions/4249
Please ask your questions about this change there , will try and answer them.
Hi, maybe I should learn a little more about how and when you post this updates. We didnt know about this changes, and it totaly ruined our day here : ) As we didnt know, it took several hours to get to this page. I love PnP, and use it a lot. But maybe a bigger window and some more communication would be better. thanks, and now.. I will get my coffee and will read it all, to solve it all.
A few weeks notice over the summer - when many IT orgs are a little short-staffed due to vacations... Not good planning.
Just learned about this post after researching why our connect-PNP is failing today. Was a notice sent out via Microsoft Message Center? I didn't see one and now I'm going to be fixing scripts all day.
yesterday 9/9/24 my PNP scripts stop working, lucky i found quickly the note https://pnp.github.io/powershell/articles/registerapplication.html
- Register app
change scripts from:
Connect-PnPOnline -Url $siteUrl -Credentials $credentials to Connect-PnPOnline $siteUrl -ClientId 89378578-cc3gvg6a-4fvtga5-acvtg-98745hufgh8 -Credentials $credentials
and all wotking!
thanks! what else you gonna ask for a free stuff?
I have scripts that connect with Credentials without MFA. Would I still use Interactive Access or should I switch to App Only Access?
This is a huge black mark on the PnP Community for me. I have thousands of scripts I use with PnP PowerShell and have had hundreds of clients who have registered the PnP PowerShell App so I can support them. It's going to take me hours per client to get them setup on the new way and some of them don't allow PowerShell Core to run yet, so PnP can no longer work for them. I understand the security reasons, however, how is the PnP Multi-Tenant App Registration any different then all of the other Multi-Tenant App Registration. This is really poor planning and communication.
@CollinHunterGOC - if you are using your own EntraID app for authentication via -ClientId parameter or ENTRAID_APP_ID env variable, then no need to change anything.
If it depends on the PnP Multi-tenant app, then you can create your own EntraID app and it should work as it is without issues unless there's some policies which prevent you from doing that.
Interactive and App-only , both are supported modes of Auth, totally up to you to determine what's best for your use case.
Unfortunately using other communication channels were not an option for this project, given that it's not a Microsoft owned project. We are however having now discussions on getting Message Center post out with the guidance, which is also mentioned in this blog post. This should go out today Wednesday 11th of September.
We do acknowledge that Message Center post at this point, is already too late for getting ready for the change advance. This option was not unfortunately available for the community until now, which caused challenges on ensuring worldwide visibility for the applied changes.
PnP PowerShell open-source team has been working enormously now to minimize the impact for the customers. Timeline and schedule was unfortunately given and they had no way to impact on that.
If you have any issues, please use the GitHub issue lists mentioned in the blog post, which are closely monitored, so that your questions can be answered as fast a possible.
Is there somewhere to subscribe for alerts about changes like this that are likely to cause breakages?
