Configure read-only Sync

This article outlines how to tailor read-only access to your tenant.  

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.

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. This option is recommended as it prevents any changes to the tenant without changing user account permissions or the service principal scopes. 

Option 2: install the tenant with read-only access.

This option is best for customers with strict security protocols that prevent write access to your tenant. Installing a tenant with read-only access 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.

  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.

   
• A service principal is always required. To enable read-only access, you need to select the read-only service principal option. To use the read-only service principal, access the tenant installation page, and select the “Use Simeon’s service principal (read-only)” option: 

• The read-only option installs Simeon's default service principal, but with read-only scopes. Find the read-only scopes Configuration Manager utilizes here: Read-only scopes

Remove default service principal

Before reinstalling the tenant to use the read-only service principal, remove the default service principal by following these steps:

1. Sign into the tenant at https://portal.azure.com/
2. Navigate to App Registrations > Simeon Cloud Sync
3. On the left, select the Overview tab > Delete at the top 

Revoke admin consent for unused scopes

If you'd prefer not to remove the service principal, you can revoke admin consent for unused scopes:

1. Sign into the tenant at https://portal.azure.com/
2. Navigate to App Registrations > Simeon Cloud Sync
3. On the left, select the API permissions tab > scroll down to “Other permissions granted for tenant”

4. Select the three dots > revoke admin consent

Custom service principal

Configuration Manager provides the option to customize a service principal with only the scopes and permissions needed for each tenant. To configure some areas of the tenant to be read-only, you can apply read-only scopes via a custom service principal. 

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.