Entra ID Requirements and Considerations

Before you register an Entra ID source on Cohesity DataProtect as a Service, ensure the following requirements are met:

  1. Register an application with Azure Entra ID and create a service principal. For information, see the Azure documentation.

  2. Create an application secret key for setting up authentication for the service principal. For information, see the Azure documentation.

  3. Assign the custom role to the Azure Entra ID application created in step 1.

    The application ID and application secret key are required when you register the Azure source with the Cohesity cluster.

  4. The ports listed in the Azure section in the Firewall Port topic are open to allow communication between the Cohesity SaaS Connector(s) and Azure environment.

Required Permissions

The following permissions are required in the tenant’s Entra ID:

  • Directory.ReadWrite.All

  • Application.ReadWrite.All

  • AdministrativeUnit.ReadWrite.All

  • AppRoleAssignment.ReadWrite.All

  • RoleManagement.ReadWrite.Directory

  • Device.ReadWrite.All

  • Group.ReadWrite.All

  • OrgContact.Read.All

  • User.ReadWrite.All

Supported Object Types

Cohesity supports the protection of the following Microsoft Entra ID Object types:

  • User

  • Group

  • Devices

  • Administrative Unit

  • Application

  • ServicePrincipal

  • AppRoleAssignment

  • OrgContact

Entra ID Considerations

Before you register your Azure sources as a data source with Cohesity DataProtect as a Service, ensure that you have understood the considerations.

  • Application and Service Principal Deletion Behavior

    In Microsoft Entra ID, deleting an Application object automatically deletes its associated Service Principal (SP) object. To recover both, you must explicitly select both the Application and the SP object for recovery in the Cohesity interface.

  • Service Principal ID History

    • Application objects support the appId-based extension attribute, which tracks ID history.

    • Service Principal objects do not support this attribute. If an SP object is permanently deleted, it will be recreated during recovery with a new ID, but its ID history will not be maintained.

    • After recovery, correlating the restored SP object with the original is not possible.

    • Running recovery for the same SP object again will fail with the following error:

      "The associated AppId <appId> has a valid ServicePrincipal already created in Azure, so we cannot create another SP."

  • Limited Backup Support for Certain Application Properties

    Some properties of Application objects cannot be backed up, including web/homePageUrl and info/logoUrl.

  • Password Management for User Objects

    • If a User object is permanently deleted, the password is reset when the object is recreated during recovery.

    • For objects that are not permanently deleted and only require property recovery, the new password will not be applied.

  • Recovery Status Reporting

    • Cohesity does not display partial status for recovery operations. If any objects from the recovery list are successfully restored, the operation status will display as "Success."

    • If no objects are successfully restored, the operation status will display as "Failure."

    • The pulse logs capture up to 100 recovery failures for detailed troubleshooting.

  • No Rollback for Canceled or Failed Restores

    • If a restore operation is canceled or encounters a failure mid-operation, already restored objects will not be rolled back. For example:

      • Selecting 100 objects for recovery, and canceling the operation after 50 objects are restored, will not roll back those 50 objects.

      • If the network connection is lost during recovery, the operation will fail, but any objects restored before the failure will remain.

  • Multi-Tenant Application Scenarios

    Consider a multi-tenant application scenario:

    • Application App1 is created under Tenant A as a multi-tenant application.

    • Tenant B creates a Service Principal SP1 for App1.

    • If App1 is permanently deleted in Tenant A and then recreated, restoring SP1 in Tenant B will fail. This is because the recreated App1 will have a new appId, which cannot be found by the original SP1.

  • Running Multiple Browsing Sessions Impacts Backup and Recovery

    The platform does not close browsing sessions automatically. Running browsing sessions consumes resources. Hence, having multiple browsing sessions running will impact the backup and recovery performance. Ensure to close the browsing session by clicking the Tear Down button after the recovery is complete.