Power Platform Community Forum Thread Details

Service Principal and permissions

Hi!

EDIT: It seems like performing an environment reset causes my service principal to loose permissions. Then any subsequent delete + create of the environment (using the same domain name) does not add the permissions. Creating a new environment with a new name works (an application user is added with sysadmin role), but executing a reset results in permissions being lost. Why is that, and is there a way around this?

The goal I am trying to achieve is to have a reset/newly created environment that can be used for automatic testing of Dynamics 365 CE solutions via Azure pipelines (to make sure the solutions are working in an 'empty' environment that is (close to) the latest version). I also want to be able to login to the environment GUI afterwards, see the environment in my list of environments, et cetera. Since our organization uses MFA I have access to a service principal that I can use for all the automated tasks. I have tried both by using powershell functions from the Microsoft.PowerApps.Administration.PowerShell and Microsoft.PowerApps.PowerShell libraries and by using the DevOps extension Power Platform Build Tools. But for some reason I can't get the permissions to work and was wondering if anyone has any suggestions on how to solve this?

It seems to be a bit random as well. At first creating an environment using the Power Platform Build Tools (Power Platform Create Environment) seemed to add my application user to the environment, which meant that I afterwards could add my own personal user as a system administrator to the environment, and thus login to the environment using a web browser. But then I executed a reset (not using Power Platform Build Tools, since that only works with non-MFA users, and not for service principals) and got a permission error, and since then no subsequent attempt has worked. Neither resetting, e.g. by using the following code:

$resetRequest = [PSCustomObject]@{
FriendlyName = "$friendlyName"
DomainName = "$domainName"
Purpose = "Nightly builds/regression testing"
BaseLanguageCode = $baseLanguage
Currency = [PSCustomObject]@{
Code = "SEK"
Name = "Svensk krona"
Symbol = "kr"
}
SecurityGroupId = $null
Templates = @('D365_CustomerService')
}

Reset-PowerAppEnvironment -EnvironmentName $TargetInstanceIdToReset -ResetRequestDefinition $resetRequest -WaitUntilFinished $true

...nor using Power Platform Delete Environment followed by Power Platform Create Environment lets my service principal user perform any data operations afterwards. Creating, deleting and resetting works, i.e. no error messages are displayed and the environment is in fact created, removed and reset when executing these functions, which means that the service principal at least has those administrative permissions, but whenever I try to fetch a record, e.g. from the role entity (to get the System Administrator role GUID) I get an error message, stating the following:

"The user with id <Id> has not been assigned any roles. They need a role with the prvReadRole privilege."

I tried the function Set-AdminPowerAppEnvironmentRoleAssignment, but that only works for environments without a Dataverse database, which is a requirement in this case.

I am not a global admin in our tenant, so there are limitations as to what I can check/update regarding the service principal configuration. Any help on how to resolve this would be appreciated.

Thanks in advance!

Best regards,

Henrik Svensson

Categories:

Power Platform Build Tools

Hi!

I did not find a solution to this. I've been wasting a lot of time on this issue.

The work-around I went with is to have an extra environment that serves as a template that I just copy from, using the "Power Platform Copy Environment" task (as part of the DevOps extension Power Platform Build Tools). In that case the permissions are not lost.

In my case I have an environment called "Regression Test Template", and in the nightly build pipeline I start by copying from this environment to my (existing) target environment "Regression Test". And then succeeding steps will import my solution and execute the unit tests in that target environment.

It takes more time than performing a reset, but at least I found one nice side-effect of using the copy method: It seems I don't have to wait for (or manually trigger) a synchronization of the users in the target environment, which I always had to do after resetting an environment.

Quick Links

Leaderboard > Power Apps - Power Apps Pro Dev & ISV