In order for Configuration Manager to read and manage the configurations in your tenant, you must provide a way for Configuration Manager to authenticate into each tenant installed on the platform.
Before starting the onboarding process, we recommend taking a moment to determine which authentication method you intend to utilize. You can decide:
- to enable the user account authentication option, which will be accompanied by the creation of a service principal,
- or to proceed with a service principal only, and, if you wish to, enable the user account authentication option later.
If you use Service Principal authentication, you will see a limited set of configurations. If you use User Account authentication, you will have access to the full list of supported configurations.
Access the list of supported configuration article to see which configurations are available for each authentication method.
Authentication methods
By default, Configuration Manager will create a service principal in the tenant you are installing. This service principal assists in tenant authentication and is also used to manage configurations compatible with a service principal. For more information on this, see our guide on Service Principal authentication.
In addition to a service principal, Configuration Manager you can set up a user account for tenant authentication. In this case, in addition to the service principal, you can choose to enable user authentication via delegated authentication.
User Account Authentication
User account authentication is a method that allows you to use an existing user account within the tenant for Configuration Manager's authentication process. This could be any user that already exists in the tenant, such as your user account, your admin account, or an account specifically created for Configuration Manager.
You can enable User Account authentication by going into CoreView and creating the CoreView Management Service Account.
The process involves signing in as the chosen user, whereupon Configuration Manager caches the sign-in as a refresh token. Moving forward, Configuration Manager uses this refresh token to authenticate into the tenant.
Pros
- High security: This user can have MFA and other Conditional Access policies applied, enhancing security.
- Choice of any user account: Any Azure AD user in the tenant can be utilized with this option
- Customizable roles and permissions: The chosen user's roles and permissions can be tailored, offering flexibility in controlling Configuration Manager's access level. This includes utilizing PIM to provide time-based role activation of higher privileges when necessary.
You can opt for a Global Administrator role to ensure access to all configurations. However, if you prefer not to use a Global Administrator, you can choose a user with lower-level permissions for delegated authentication. Here you can find the guide on how to add roles to CoreView Management Service Account. Configuration Manager will then authenticate as this user, meaning it will only have the permissions granted to that user account. For instance, if your user account lacks the permission to create or manage Exchange Online policies or SharePoint policies, Configuration Manager will be unable to perform these actions as well. This approach allows you to precisely tailor Configuration Manager's access level through the chosen user account.
Cons
- Refresh token lifecycle: refresh tokens can become invalidated if security policies or sign-in policies within the tenant change (e.g., re-enrollment in MFA or periodic MFA verification requirements).
- Potential access issues: when the refresh token is invalidated, Configuration Manager loses the ability to authenticate, leading to disruptions in backup and syncing operations until a new sign-in generates a fresh refresh token.
- Management overhead: for clients managing multiple tenants, the need to re-authenticate the Sync when tenant policies change can be burdensome, especially if refresh tokens frequently invalidate across several tenants.
As authentication depends on a refresh token, a key issue with delegated authentication is its sensitivity to security policy changes in your tenant. For instance, if there's a re-enrollment in MFA or a need for periodic MFA renewal, the refresh token gets invalidated. This means Configuration Manager can't authenticate, stopping backups and Syncs until you sign in again for a new token. Managing this for a large number of tenants can become a hassle if even a few require frequent re-authentication.
It is recommended to review the current sign-in policies, including token expiration policies, in the tenants you are installing to ensure that delegated authentication makes sense.
In summary, delegated authentication offers a secure and customizable way for Configuration Manager to access and manage tenant configurations, with the trade-off being the potential need for re-authentication due to refresh token invalidation.