To begin onboarding with ContraForce, the first step is to sign the Microsoft Customer Agreement (MCA). This agreement grants ContraForce consent to deploy the necessary security infrastructure to connect your environment to the ContraForce Portal.
What is the purpose of the Microsoft Customer Agreement?
The primary purpose of using the Microsoft Customer Agreement is the simplified billing of the associated Azure resources deployed by ContraForce during onboarding. By signing the MCA, ContraForce can manage the billing of all deployed resources in a streamlined predictable manner.
What is the purpose of Global Admin?
From the customer side, a Global Admin is needed to sign the agreement. Once signed, the agreement will grant ContraForce the Global Admin role. This is shown in the screenshot below. ContraForce only requires the Global Admin role to assign the Owner role to a newly created Subscription. Once the primary ContraForce subscription is created, the Global Admin role is removed from your authorized partner relationships.
Onboarding Consent Flow
After the MCA is signed, there are two main groups of API permissions that are granted. The first is the ContraForce API and the second is the ContraForce Portal. Both of these are set up as app registrations within Microsoft Entra ID.
In the sections below, every permission needed by ContraForce is listed and explained. The ContraForce Portal permission set builds upon the permissions that are granted within the ContraForce API as the ContraForce API is a component of the ContraForce Portal.
ContraForce API Permissions
Log Analytics
API / Permission Name |
Description |
ContraForce Usage |
---|---|---|
Data.Read |
Read Log Analytics data as user |
Log Analytics data retrieval and processing |
Microsoft Graph
API / Permission Name |
Description |
ContraForce Usage |
---|---|---|
Group.ReadWrite.All |
Read and write all groups |
Security Group creation during deployment |
Directory.Read.All |
Read directory data |
ContraForce service principles fetching, resource deployment |
User.Read.All |
Read all users' full profiles |
User assignment in Incident Case management |
AppRoleAssignment.ReadWrite.All |
Manage app permission grants and app role assignments |
Security Group subscription assignment, service principle and user subscription assignment |
ContraForce Portal Permissions
ContraForce API
API / Permission Name |
Description |
ContraForce Usage |
---|---|---|
Api.Access |
API Access |
Enables API usage |
Microsoft Graph
API / Permission Name |
Description |
ContraForce Usage |
---|---|---|
Directory.Read.All |
Read directory data |
RBAC |
|
View users' email address |
Integration between Azure AD user profile and ContraForce portal |
offline_access |
Maintain access to data you have given it access to |
App token refreshing |
openid |
Sign users in |
Portal Authentication |
profile |
View users' basic profile |
Integration between Azure AD user profile and ContraForce portal |
User.Read |
Sign in and read user profile |
Integration between Azure AD user profile and ContraForce portal |
User.Read.All |
Read all users' full profiles |
Integration between Azure AD user profile and ContraForce portal |
Note that all permission types are delegated.
Delegated permissions are used by apps that have a signed-in user present. For these apps, either the user or an administrator consents to the permissions that the app requests. The app is delegated with the permission to act as a signed-in user when it makes calls to the target resource.
Some delegated permissions can be consented to by non-administrators. But some high-privileged permissions require administrator consent. To learn which administrator roles can consent to delegated permissions, see Administrator role permissions in Azure Active Directory (Azure AD).
If you have any further questions about the Microsoft Customer Agreement or onboarding with ContraForce, please let us know! We are more than happy to answer any additional questions.