This article outlines how to tailor service principal permissions to read-only scopes.
Configuration Manager uses a service principal to read and write changes to supported configurations. Users can use a custom service principal to tailor the access and permissions of the service principal, including restricting access to certain areas of the tenant, or granting read-only permission where writing changes is not desired.
Read this article if you want your custom service principal to operate with strict read-only permissions.
Please, note that using a custom service principal with read-only scopes represents the most restrictive form of read-only access.
Approaches to implementing read-only Sync
There are two options to implementing a read-only Sync.
Option 1: install the tenant as “backup only”.
This means that the Sync will only perform a backup operation and will not attempt to write any changes to the tenant.
Option 2: install the tenant with read-only access.
This process consists of two components:
- If you're utilizing a user account, ensure you install with delegated authentication and choose a user who possesses both the global reader and reports reader roles, or any roles that correspond to the tenant areas you wish Configuration Manager to access.
- A service principal is always required. To enable read-only access, you must install using a custom service principal that has been assigned read-only scopes for the specific resources you want Configuration Manager to access.
It's important to recognize that some configurations require management through a user account. Microsoft mandates that certain configurations utilize delegated authentication via a user account. Therefore, regardless of how restrictively you set the service principal's permissions, if the user account has write access, it will still be capable of making changes to those configurations. Thus, for delegated authentication, both a Global Reader role for the user account and a custom service principal with read-only scopes are necessary to maintain a secure read-only environment.
Understanding scopes
When creating a custom service principal in the portal, you'll encounter the option to assign specific scopes, which define the permissions granted. These scopes fall into two categories:
Delegated scopes
These permissions allow the service principal to act on behalf of a specified user. For example, if user@coreview.com is your delegated authentication user, the actions occur via this user's agency.
Application scopes
These define what the application itself can perform independently, without user account references. Ensure both types of scopes are diligently configured in the portal.
Most scopes are typically set to readwrite by default (with exceptions such as the audit log, which is inherently read-only). If you were to use these readwrite scopes, the service principal would be permitted to both read configurations and implement changes. To enforce read-only access, you can simply substitute read.all for readwrite.all, thereby restricting permissions to read-only.
Setting up read-only scopes
To achieve a read-only configuration, modify the scopes to read.all instead of readwrite.all.
- Find the default scopes Configuration Manager utilizes here: Application scopes
- Read the instruction on how you can set up a custom service principal in the Azure portal.
Example setup for Microsoft Graph
For example, if you wish to modify permissions for Microsoft Graph you will:
Step 1: select Microsoft Graph
Step 2: add permissions:
You'll see options for both delegated and application permissions.
- Choose the appropriate permissions for your needs.
- Specifically look for and select options like
accessreview.read.allinstead ofaccessreview.readwrite.all.
Replicate for Application permissions:
After selecting the delegated permissions, repeat the same for application permissions.
By opting for read.all scopes, you ensure the service principal is limited to reading configuration data. It will not have the capability to write changes.