Before starting the installation process, we recommend taking a moment to determine which authentication method you intend to utilize.
Each method has pros and cons, which must be evaluated to choose the right method that aligns with the security requirements and security posture of your organization.
It is important to have this architected ahead of time for each tenant you intend to install onto Simeon.
Overview
In order for Simeon to read and manage the configurations in your tenant, you must provide a way for Simeon to authenticate into each tenant installed on the platform.
Choosing the correct authentication method is essential, as:
- it will shape your workflow with Simeon;
- is crucial for adhering to your company's security and compliance guidelines.
For example, if you're a Managed Service Provider (MSP), it will also influence how you interact with your customers to align their tenants. For enterprises, this choice carries significant security implications.
Authentication methods
By default, Simeon 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, Simeon requires a user account for tenant authentication. You can choose between two user authentication methods: Delegated Authentication and a Service Account. Both solutions have their pros and cons, described here.
Delegated Authentication
Delegated authentication is a method that allows you to use an existing user account within the tenant for Simeon'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 Simeon.
The process involves signing in as the chosen user, whereupon Simeon caches the sign-in as a refresh token. Moving forward, Simeon uses this refresh token to authenticate into the tenant.
Simeon recommends delegated authentication for all production tenants as you have control over how the user account is configured.
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 Simeon'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 account for delegated authentication 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. Simeon 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, Simeon will be unable to perform these actions as well. This approach allows you to precisely tailor Simeon'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, Simeon 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 Simeon 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 Simeon to access and manage tenant configurations, with the trade-off being the potential need for re-authentication due to refresh token invalidation.
Use Service Account
The service account is an Entra ID user account that Simeon creates in the tenant during the installation process. The service account user will be named simeon@tenantdomain.com. Simeon will generate a random 128-character password for this user, which is encrypted and stored in your Azure DevOps organization.
Pros
- Direct authentication: Simeon directly signs in as the service account user to authenticate into the tenant, bypassing the need for a refresh token. This direct sign-in method simplifies the authentication process and reduces potential access issues related to token invalidation.
- Stable access: Once configured, changes in tenant security policies, such as MFA re-enrollment, do not affect the service account, ensuring uninterrupted access and functionality for Simeon.
-
Non-Interactive: the service account is non-interactive, meaning only Simeon has access to and can use this account, enhancing security by limiting access.
Cons
- Fixed permissions: the service account is created with Global Administrator permissions, giving you no control over its permission levels.
- Limited accessibility: this kind of account is non-interactive; you cannot sign in to the tenant as the service account user or change this user's properties.
- Exclusion from MFA: since the account is non-interactive and you won't have login credentials, you cannot apply Multi-Factor Authentication (MFA) to the service account. This requires setting exclusions to MFA policies specifically for this account.
In summary, using a service account with Simeon simplifies the authentication process by eliminating refresh tokens and ensures stable and consistent access to the tenant. However, it requires accepting a predefined level of access permissions and making specific security policy exclusions, which might not align with every organization's security posture. We recommend using a service account for your baseline tenant or any non-production tenants.