Service Account vs Service Principal
Muhammad Arslan Khan
PUCIT | Power Platform | Dynamics 365 | ASP.NET MVC | ASP.NET Core | Dynamics 365 Plugins | SQL | JavaScript
Power Automate allows to automate workflows. While creating a flow, we need to decide how to authenticate and authorize it to access the data sources and actions it needs. Using personal accounts for Power Automate Cloud flows can create challenges when the account owner leaves the organization or loses access?
Service Account
Service account are normal accounts with a username and password, just like any other user in an organization.
They can be granted different roles and licenses based on the needs of the flow (e.g., Dataverse or SharePoint access).
Since these are user-based, if the service account's credentials expire or the account is deactivated, the automation tied to the account may fail.
Each flow tied to a service account consumes a license.
Can be assigned different roles and licenses for various flows.
Simple to set up by creating a regular user account and assigning necessary licenses and roles.
?
Service Principal
Service Principal represents an Azure AD application and is associated with app registrations.
Service Principals authenticate using a client secret (or certificates),
Since service principals are not tied to specific individuals, they ensure workflows continue running even if a user leaves or a user account is deactivated.
It uses client credentials (such as a client secret or certificate) instead of passwords, which is more secure and scalable.
With Service Principals, you don’t need to worry about license expiration for individual users affecting your flows. Instead, you manage everything centrally through the Azure App registration.
Needs explicit role and permission assignment via Azure AD for each service and API it needs to access.
More complex to configure, requiring Azure AD app registration and permission setup for each resource.
?
Setup Service Principal for Dataverse connector in Power Automate
To use service principal as connection reference in power automate following steps need to be followed
1)Register an app on Azure Portal
2)Create Secrets
3)ApI Permission
4)Add app in power platform admin center as application user
5)Inside flow create connection reference using (client secrets, client id , tenant id)
?
1)Register an App on Azure Portal
Search for App registrations->Click on New Registration
?
?
Give Name of app and select account type
?
Note down Client ID and Tenant ID this will be used for power automate connection reference
?
2) Create Secrets (Certificates)
Create secrete by click on Add a certificate or secret option OR
Manage->Certificates and Secrets
?
?
?
To define a secrets click on New client secret option->Name of secret and expires time
?
Secret is created note down value of secret this will also used in power automate connection reference creation
?
领英推荐
3) Now Give API ?Permissions to app (which resource app will be accessed)
Go to API permission section ->Add a permission->Dynamics CRM
?
?
?
4) App is registered, and API permission granted successfully
Now add this app in environment as application user
Go to Power platform admin center -> Go to environment-> Settings
?
Under settings click on Application users
?
?
Click on New app user-> Search app that is created above and add this app
?
?
Give Security role to this app
?
?
We have Registered and add app successfully
Now create a power automate flow to test service principal
I have created simple flow which will create a record in a table
First create record using credentials (normal as user name and password) the owner of record will be flow owner(person who created flow)
?
Now test Service account
Create new connection reference
?
?
?Enter Client ID ,Client Secret and tenant ID that we have created during app registration
?
?
Save and run flow again
The owner of record is now Service Principal not a regular user
Power Platform & Azure Architect - Changing the world one app at a time! Note: I'm happy as an independent! Dear recruiters: I'm open for contracts, not FTE roles! Want to connect? Write a note! Otherwise, follow me :-)
1 个月No, you don’t need to add the user_impersonation permission. Permissions for Dataverse are EXCLUSIVELY handled by security roles. You can read about it in my blog post from a while ago https://www.m365princess.com/blogs/2022-07-25-why-your-service-principal-doesnt-need-a-dynamics-user_impersonation-scope/