Export-M365DSCConfiguration: What to do in light of the PnP Management Shell app being deleted?

[nick-waterhouse]

Description of the issue

When authenticating against resources via the Connect-PnPOnline cmdlet, users who are making use of the default app registration will find that this no longer works as of September 9th. Further information can be found here and here.

The suggested fix to this is to upgrade to version 2.12.0 of PnP.PowerShell and use an environment variable to indicate the desired client ID to use. Problem is, this new version is for PowerShell 7, and I am using PowerShell 5.

It is also possible (even with version 1.12.0) to specify a -ClientId parameter when calling Connect-PnPOnline. If this workaround is the only viable method currently, is there any advice on how to do so? Using a custom app registration is discussed in Authentication and Permissions | Using your own Azure AD app, but there is no information regarding how the -ClientId parameter is to be passed to Connect-PnPOnline when invoking Export-M365DSCConfiguration.

Microsoft 365 DSC Version

V1.24.904.1

Which workloads are affected

OneDrive for Business, SharePoint Online

The DSC configuration

No response

Verbose logs showing the problem

For example:

Message: AADSTS700016: Application with identifier '31359c7f-bd7e-475c-86db-fdb8c937548e' was not 
found in the directory 'The [companyname]'. 
This can happen if the application has not been installed by the administrator 
of the tenant or consented to by any user in the tenant. 
You may have sent your authentication request to the wrong tenant.

Environment Information + PowerShell Version

OsName               : Microsoft Windows 11 Enterprise
OsOperatingSystemSKU : EnterpriseEdition
OsArchitecture       : 64-bit
WindowsVersion       : 2009
WindowsBuildLabEx    : 22000.1.amd64fre.co_release.210604-1628
OsLanguage           : en-GB
OsMuiLanguages       : {en-GB, en-US}

[ArtemPozharovDNSBelgium]

We ran into the same problem. Seems like we can do an export of everything except SharePoint and OneDrive.

[ajkenah]

I've raised the issue over on the MSCloudLoginAssistant project as well https://github.com/microsoft/MSCloudLoginAssistant/issues/193. I'm proposing to add some changes to the PNP connection class so that when you connect, it checks for the defined environment variables and then, adds the ClientId parameter and value to the connection string if found. It shouldn't be too much effort to code, but I'm just waiting on feedback from the project team to confirm if that's the right way forward.

[jenreiko]

Yup, I think what ended up working for me was setting to the client id variable of PnP in "C:\Program Files\WindowsPowerShell\Modules\MSCloudLoginAssistant\1.1.34\MSCloudLoginAssistant.psm1" $Script:MSCloudLoginConnectionProfile.PnP.ApplicationId = ‘clientid' Not ideal but it gets the job done.

Jen Sugawa She/Her Lead Security Engineer Foxcove 503.272.1404

Do what you love, we'll take care of the tech.

On Jan 29, 2025 at 6:26 PM -0800, ajkenah @.***>, wrote:

I've raised the issue over on the MSCloudLoginAssistant project as well microsoft/MSCloudLoginAssistant#193. I'm proposing to add some changes to the PNP connection class so that when you connect, it checks for the defined environment variables and then, adds the ClientId parameter and value to the connection string if found. It shouldn't be too much effort to code, but I'm just waiting on feedback from the project team to confirm if that's the right way forward. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[FabienTschanz]

@ajkenah @jenreiko What are the commands you previously used to export the configuration? I'm using a custom app registration like the following: Export-M365DSCConfiguration -Components @("SPOSite") -Path "D:\testbed" -ApplicationId <clientId> -TenantId tenant.onmicrosoft.com -CertificateThumbprint <certThumbprint>

Were you using the -Credential parameter for the export?

Edit: Should have looked at the issue first in the other repo... Clearly stating that this is the case. I'll take a look at it.

[Borgquite]

@ajkenah mentioned in https://github.com/microsoft/MSCloudLoginAssistant/issues/193 that his organisation only allow him to use credentials and delegated permissions - I don't think that's compatible with certificate thumbprints etc.

[ajkenah]

Yes. I'm using credentials. We have a locked down service account that we use for the backup. Half our IT department has access to create shared secrets or register certificates so we cant give sharepoint full access to the service principal. Its something were working through, but everything takes time...

[FabienTschanz]

Ok, so I had a look. In PowerShell 5.1, I am unable to make it work, even with a specified client id. Example:

$cred = Get-Credential
Connect-PnPOnline -Url tenant.sharepoint.com -Credentials $cred -ClientId <clientid> -Verbose
Connect-PnPOnline : A configuration issue is preventing authentication - check the error message from the server for details. You can modify the configuration in the application registration portal. See https://aka.ms/msal-net-invalid-client for details.  Original exception:
AADSTS7000218: The request body must contain the following parameter: 'client_assertion' or 'client_secret'. Trace ID: b4ac014b-9a24-49d0-9f4b-4dd872e45300 Correlation ID: 1cecf4e5-09a8-4f7e-8217-618fc11f64bc Timestamp: 2025-01-31 12:21:08Z
At line:1 char:1
+ Connect-PnPOnline -Url tenant.sharepoint.com -Credentials $cred -Clien ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Connect-PnPOnline], MsalServiceException
    + FullyQualifiedErrorId : Microsoft.Identity.Client.MsalServiceException,PnP.PowerShell.Commands.Base.ConnectOnline

I suspect this is because the version 1.12.0 we are using does not properly support this type of authentication.

[FabienTschanz]

@NikCharlebois What are your thoughts on this matter? I don't think we can switch to any newer version of the Sharepoint module because they would only be supported in PowerShell 7+. Since Microsoft365DSC requires Windows PowerShell (5.1) to be present for the LCM to work, we cannot upgrade.

[ricmestre]

Before connecting you needed to register the PnP app but that app was removed from all tenants [0], their recommendation is to create your own app manually or with Register-PnPAzureADApp.

Or you can just force the connection to use the still working app for SPO with something like the below, of course you'll need to grant it the required delegated or app permissions first.

Connect-PnPOnline -Credentials $creds -Url https://contoso-admin.sharepoint.com -SPOManagementShell

[0] https://pnp.github.io/blog/post/changes-pnp-management-shell-registration/

[FabienTschanz]

@ricmestre I see, so instead of using your own app registration (which doesn't seem to work with -Credential), a quick fix would be to append the -SPOManagementShell parameter to use the Microsoft Sharepoint Online Management Shell app registration of the tenant? Is this what you're saying?

[ricmestre]

I don't use credentials in my pipelines but that's what I just tried manually in the CLI and it worked

[FabienTschanz]

Just tested it myself with an updated version of MSCloudLoginAssistant and it seems to work as well. I'll raise a PR.

[ricmestre]

But did you actually tried to create an app for it? I just created one and was also able to use it using credentials.

Register-PnPAzureADApp -ApplicationName "PnP PowerShell" -Tenant contoso.onmicrosoft.com -Interactive -SharePointDelegatePermissions AllSites.FullControl -SharePointApplicationPermissions Sites.FullControl.All -GraphApplicationPermissions Group.ReadWrite.All -GraphDelegatePermissions Group.ReadWrite.All

Connect-PnPOnline -Url https://contoso-admin.sharepoint.com -ClientId $ClientId -Credentials $Creds

[FabienTschanz]

I tried to add the capability to my already existing application and it wasn't successful. Currently trying to do it just as you did.

Edit: After careful comparison (cough cough missed by far) I found that Register-PnPAzureADApp configures a couple more things than what's written in the documentation. Updated my app registration and now it works. Will include that in the PR too.

[ajkenah]

You can definitely connect with your own app on version 1.12.0. I had it working the other day. You need to ensure that the app is configured for credential based authentication as well. By default its turned off. Ill put the details in here tomorrow morning. It's a bit late here in Auz

[FabienTschanz]

https://github.com/microsoft/MSCloudLoginAssistant/pull/194 should fix this issue. The authentication using credentials only now uses the Microsoft Sharepoint Online Management Shell, and you now have the ability to specify a custom client id with Export-M365DSCConfiguration which will be used if present.

The corresponding PR here is #5705. As soon as this is merged and the next release is done (most likely next Wednesday), this should work again.

[ricmestre]

@FabienTschanz You should either use SPOManagementShell or ClientId and not both otherwise which one will it use? SPOManagementShell is just a shortcut for whatever ClientId is assigned to Microsoft's own app.

[FabienTschanz]

@ricmestre SPOManagementShell is only used if the authentication type is Credentials, otherwise if the authentication type is CredentialsWithApplicationId, only then it will use the provided Client Id.

[FabienTschanz]

With todays release, it should finally be ok. I goofed up and had to update a couple of things to make it work, but now it does.

[nick-waterhouse]

@FabienTschanz Coming back to this one, can you provide some instructions on what I should do to address the problem in my original post? I still get the same error message as before. I am using version 1.25.319.1 of the module.

[FabienTschanz]

@nick-waterhouse That's strange, I can authenticate without any issues using either a client id or credentials. Both work fine. Can you open a separate issue and post the verbose log as well as the command line you're using? Thank you.

[nick-waterhouse]

@FabienTschanz The error message is the same as in my original post. I can open up a separate issue if need be, but I just thought I'd get some advice on the what the new approach is for authenticating against PnP. The existing method won't work as a result of the changes made in September of last year to the App Registration that was used previously.

[FabienTschanz]

@nick-waterhouse The authentication method in MSCloudLoginAssistant was updated to use the SPOManagementShell app registration instead of the default one of PnP, which was removed last September. So it should actually work. I just checked with 1.25.326.1:

# Credentials
$cred = Get-Credential -UserName [email protected]
Export-M365DSCConfiguration -Components @("SPOTheme") -Path D:\testbed -Credential $cred -Verbose

# Alternative using application id with certificate
Export-M365DSCConfiguration -Components @("SPOTheme") -Path D:\testbed -ApplicationId $clientId -TenantId $tenantIdName -CertificateThumbprint $certThumbprint -Verbose

Both ways work without issues for me. Small edit: I can see the successful logins in the Sign-Ins blade of the Entra portal.

[nick-waterhouse]

@FabienTschanz So does this mean it is using a new App Registration? If so, do I need to create it first and how should I do this?

[FabienTschanz]

@nick-waterhouse The application already exists in every tenant, see https://learn.microsoft.com/en-us/power-platform/admin/apps-to-allow. But you won't be able to find it, it's somewhat hidden. If you check the sign-in logs when you're using credentials, then you should see the following entry:

If you want to use a specific application, you can either create it manually according to the guide posted earlier or with the dedicated cmdlet for it.

[nick-waterhouse]

@FabienTschanz If I run Export-M365DSCConfiguration -Components @("SPOTheme") -Path $outputDir -Credential $cred -Verbose I get the following error in the authentication dialog that pops:

AADSTS700016: Application with identifier '31359c7f-bd7e-475c-86db-fdb8c937548e' was not found in the directory '<tenant>'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.

If I close the dialog, it makes a different attempt to authenticate in a second dialog, which does work (I get a green tick next to Connecting to PnP). The export then appears to complete successfully, where the output looks as follows:

Configuration M365TenantConfig
{
    param (
        [parameter()]
        [System.Management.Automation.PSCredential]
        $Credential
    )

    if ($null -eq $Credential)
    {
        <# Credentials #>
        $Credscredential = Get-Credential -Message "Credentials"

    }
    else
    {
        $CredsCredential = $Credential
    }

    $OrganizationName = $CredsCredential.UserName.Split('@')[1]

    Import-DscResource -ModuleName 'Microsoft365DSC' -ModuleVersion '1.25.319.1'

    Node localhost
    {
    }
}

Does that look about right for the export of a SPOTheme?

I think it might have been that first error that threw me off - I'll keep an eye on this with next month's export. Thanks for your help with this one.

[FabienTschanz]

It's strange that you still see an error regarding the first application. That shouldn't appear there - Looking forward to your next export.