UserMissingRequiredPermission when setting Connection-Direct-Consent-Bypass

[Neville]

Hi.  What's the missing ingredient in this recipe?

Create a PowerApp for a SharePoint Online (list named "Spotlight") and bypass the horrible-user-experience that prompts the "Almost there..." consent dialog.

Used a SharePoint Admin account that is also the "Spotlight" PowerApp Creator, Owner and Publisher...

Also ensuring that the account is an o365 Global Admin...

Also account has a P2 license (just in case)...

And ensuring account is the PowerApps Environment Admin...

On a local machine open PowerShell ISE as local admin, and successfully executive and authenitcate using...

Add-PowerAppsAccount

And (double-checking the App ID correct) then execute...

Set-AdminPowerAppApisToBypassConsent -AppName xxxxxxxx-xxxx-xxxx-xxxx-9af945177a94

And it returns this permissions error:

Invoke-WebRequest : {"error":{"code":"EnvironmentAccess","message":"The user with object id 'xxx' in tenant 'xxx' does not have access to permission 'Set PowerApps Connection Direct Consent Bypass' in environment 'xxx'. Error Code: 'UserMissingRequiredPermission'"}}

[Pstork1]

The only requirement should be that you are a Global Admin in the Tenant and that the Oauth permissions were created when you setup the app.  I think you should go back and try again, but don't skip the "Almost There..." dialog.

[Neville]

Just to clarify... The Admin account has completed the consent dialog, and verified the connection to the SPO-list on Admin profile.  We are seeking now only to bypass consent for the rest of the members of the tenancy.

[Neville]

...adding @iAm_ManCat to this thead as he seems very knowledgable in this area of consent-bypass.

we have successfully executed these commands about a year ago, but it was in "default" environment and the platform appears to have changed siginificantly since then

[Pstork1]

The only two requirements that should be in play then are that the user running the PowerShell command is a global Admin for the tenant and has a PowerApps P2 license.  I would double check to make sure that you are logged in through PowerApps with credentials that have those requirements fulfilled. I know you said you already checked that, but those are the only requirements for that command.

[Neville · Accepted solution]

DON'T USE WINDOWS SERVER!!!

I had overlooked that little admonition in my notes from a year ago.  So on my local local Windows10Enterprise x64 box I opened PowerShell ISE as admin, installed the PowerApps modules, and all subsequent commands succeeded.  That's 24-hours I wish I could have back...

[iAm_ManCat]

Using Windows server might be to do with your SSO for that server, or the version of PowerShell that it's running, glad you managed to figure it out! 

I've had this issue before when trying to run some commands locally (as it would then SSO as my non-admin user, which does not have global admin rights), so would always do it on my local machine with an elevated PowerShell ISE running under my admin creds.

Cheers,

ManCat

[Pstork1]

Yes, all these PowerShell commands should be run from a client workstation and not a server.

[Neville]

@iAm_ManCat : that was precisely my fear! that SSO would require the local-machine-admin be SharePoint-Online-Admin too ( I've learned in the past, as we all probably have, that SSO highjacks even "incognito" browser sessions) 

So I retreated to a remote-desktop-session on a remote-Windows-Server-box where I knew I could operate exclusively as SharePoint-Online-Admin and simultaneous local-admin and not worry about an overlap of session tokens.

Only out of frustration did I finally execute on my local-machine. Even with my local-daily-user-account I only authenticated as the SharePoint-Online-account when prompted by executing the "Add-PowerAppsAccount" command. And it all worked!

So I learned these interesting lessons: TL:DR : The account running the admin-elevated PowerShell-session locally does NOT need to be the same as the PowerApps-admin account executing the commands in the cloud. (plus, as stated earlier, never use Windows Server for this)