Description
While Veritas Alta SaaS Protection is a fully managed SaaS offering, deploying Veritas Alta SaaS Protection into your own Azure subscription requires the customer to complete a set of steps within Azure. Steps 1-9 below is an overview of the process. If at any time there are questions or if you would like assistance, please contact your Veritas technical contact.
- Create a dedicated Azure subscription for Veritas Alta SaaS Protection.
- Create an 'Veritas Alta SaaS Protection' user in your default Azure Active Directory.
- Assign the created 'Veritas Alta SaaS Protection user to have the required access to the new Azure subscription. This user does not require an O365 license or be mail-enabled.
- Create the Azure Active Directory 'Veritas Alta SaaS Protection COPS' application, to permit the Veritas Alta SaaS Protection provisioning system access to the new Azure subscription.
- Create the Azure Active Directory 'Veritas Alta SaaS Protection Directory Provider' application to allow Veritas Alta SaaS Protection to sync your organization's Azure Active Directory.
- Disable MFA for the user account.
- Remove restrictions on user login to Azure.
- Whitelist COPS IP addresses.
- Disable any conditional policy.
Required Information Checklist
At the end of this process, there will be a section to enter the information below that you will send to your Veritas technical contact.
- The 'Veritas Alta SaaS Protection' user's 'SMTP address' and temporary 'password'.
- The 'Application ID' for the 'Veritas Alta SaaS Protection COPS' Azure Active Directory application.
- Optionally, the 'Application ID' and generated 'key' for the created 'Veritas Alta SaaS Protection Directory Provider' Azure Active Directory application.
Creating a dedicated Azure subscription for Veritas Alta SaaS Protection
Create a new dedicated Azure subscription for the exclusive use of Veritas Alta SaaS Protection. Care should be taken to ensure that only required users have access to this subscription, to prevent accidental deletion or modification of Veritas Alta SaaS Protection's underlying Azure resources.
Log in to the Azure portal, select the 'All Services' blade, then 'Subscriptions', then click the 'Add' action, and follow the normal steps to create a subscription.
Create an 'Veritas Alta SaaS Protection' user in your default Azure Active Directory
Log in to the Azure portal using a Global admin account to create an 'Veritas Alta SaaS Protection' user in your organization's default Azure Active directory. Veritas will use this account to manage your deployment.
- Select the proper directory by referencing the top-right user widget. If the default directory is not selected, click top-right user widget, select 'Switch directory', and select the default directory.
- Select the Azure Active Directory blade, then click 'Users', 'All Users', and the 'New user' action.
- User name: Veritas Alta SaaS Protection@<your_azure_ad_domain>
- Name: Veritas Alta SaaS Protection
- Create a password
- Click the 'Create' button
- Veritas will change the password during the provisioning process, and this user will be enrolled in Veritas Alta SaaS Protection's password management system, and have the password updated every 60 days.
- Take note of the 'User name' and temporary 'Password' as this will be sent to your Veritas technical contact.
Assign the 'Veritas Alta SaaS Protection' user to have the required access to the new Azure subscription
Grant the newly created 'Veritas Alta SaaS Protection' user to have Owner permissions to the new Azure subscription. The Veritas Alta SaaS Protection provisioning system will connect and manage the Azure subscription through that user.
- Select the 'All Services' blade, then 'Subscriptions', and then click the newly created Veritas Alta SaaS Protection subscription, followed by the 'Access Control (IAM)' blade.
- Click the 'Add' button.
- Select the 'Add role assignment'.
- Select the 'Role' to be 'Owner'
- Type 'Veritas Alta SaaS Protection@' in the 'Select' text field. The Veritas Alta SaaS Protection user should be returned.
- Click the user, and it is added to the bottom list of 'Selected members'.
- Click the 'Save' button.
Create the Azure Active Directory 'Veritas Alta SaaS Protection COPS' application
Access to the Windows Azure Service Management API must be granted for the Veritas Alta SaaS Protection Customer Operations System (COPS) to manage the subscription in an automated manner. Create an Azure Active Directory native application as follows:
- Select the 'Azure Active Directory blade', then click 'App registrations', followed by 'New registration'.
Configure the application as follows:
- Name: Veritas Alta SaaS Protection COPS
- Support Account Types: Accounts in this organizational directory only
- Redirect URI (Optional):
- Select Public client (mobile & desktop)
- Enter URL as: https://localhost
- Click the 'Register' button.
The application blade will be automatically opened once the application is created.
- Take note of the 'Application (client) ID' for 'Veritas Alta SaaS Protection COPS' as this will also be provided to your Veritas technical contact.
- Click 'API Permissions'
On the 'API Permissions' blade, select 'Add a permission.'
Select the 'APIs my organization uses' tab, then type 'Windows' in the search field. Click the 'Windows Azure Service Management API' entry.
- Check the 'user_impersonation Access Azure Service Management as organization users (preview)' option.
- Click 'Add Permission.'
- Click the 'Grant Permissions' button
- Click 'Yes' when prompted.
The COPS account does not collect plain text passwords from the M365 tenant. The account credentials are securely held in the COPs system and the obfuscated password provided is rolled periodically by the system.
This setting is not about the Identity Provider (Azure AD)’s security feature. It is about the client application’s design flow and the environment the application is used in. Changing the type does not cause Azure AD to provide any more or less security protection for the application than the other setting. It only changes what Azure AD expects from the client application during authentication. A confidential client is expected to provide a secret (or assertion) when authenticating to Azure AD while a public client does not have to provide this parameter. Access the Learn more link to see more.
Configure Veritas Alta SaaS Protection to sync your organization's Azure Active Directory
- Link-based stubbing. (Used for stubbing files on non-Windows file shares such as CIFS).
- End-user Portal. (Allows end user Browse and Search functionality based on user permissions)
- Custodian based searching in the Veritas Alta SaaS Protection Discovery application.
If none of the above apply to your deployment, it is possible to skip directory synchronization, in which case Veritas can provision your tenant without any action on your part. If your requirements change, Veritas can enable the directory synchronization functionality at that time.
To enable directory synchronization, please follow these steps on How to Enable Directory Synchronization.
User Name
|
SMTP Address
|
Temporary Password
|
Veritas Alta SaaS Protection
|
|
|
Name
|
Application ID
|
Veritas Alta SaaS Protection COPS
|
|
Name
|
Application ID
|
Veritas Alta SaaS Protection Directory Provider
|
|
App Service and App Service plan - 1 Per StorSite
The sizes we currently use are:
S1,S2,S3
P1v2,P2v2,P3v2
P0v3,P1v3,P2v3,P3v3
P1mv3,P2mv3,P3mv3,P4mv3.P5mv3
SQL Server - 1 Per StorSite
SQL databases - 1 for the Hub and 1 per Stor
The sizes we use are:
S0,S1,S2,S3,S4,S5,S7,S9,S12,vCore
Storage Account - 2 per Stor
Per ASP Connector VM’s (sizing dependent- minimum 1)
Public IP address - 1
Virtual machine - 1
The sizes we currently use are:
DS1_V2,DS2_V2,DS3_V2,DS4_V2,DS5_V2,D4S_V3
E2S_V3,E4S_V3,E8S_V3,E16S_V3,E32S_V3,E48S_V3,E64S_V3
F2S_V2,F4S_V2,F8S_V2,F16S_V2,F32S_V2,F48S_V2,F64S_V2
E4_2AS_V4,E8DS_V4,E8AS_V4
Network Interface -1
Network security group - 1
Storage account -1
Disk - (sizing dependent- minimum 3)
Virtual network
For Search we require some additional resources
Virtual network - 1 Per StorSite
Per search cluster node (sizing dependent- minimum 1)
Public IP address - 1
Virtual machine - 1
The sizes we currently use are:
DS1_V2,DS2_V2,DS3_V2,DS4_V2,DS5_V2,D4S_V3
E2S_V3,E4S_V3,E8S_V3,E16S_V3,E32S_V3,E48S_V3,E64S_V3
F2S_V2,F4S_V2,F8S_V2,F16S_V2,F32S_V2,F48S_V2,F64S_V2
E4-2AS_V4,E8DS_V4,E8AS_V4
Network Interface -1
Network security group - 1
Storage account -1
Disk - (sizing dependent- minimum 3)
Recovery Services vault - 1
App Service and App Service plan - 1 Per StorSite
The sizes we currently use are:
S1,S2,S3
P1v2,P2v2,P3v2
P0v3,P1v3,P2v3,P3v3
P1mv3,P2mv3,P3mv3,P4mv3.P5mv3
SQL Server - 1 Per StorSite
SQL databases - 1 for the Hub and 1 per Stor
The sizes we use are:
S0,S1,S2,S3,S4,S5,S7,S9,S12,vCore
Storage Account - 2 per Stor
Per ASP Connector VM’s (sizing dependent- minimum 1)
Public IP address - 1
Virtual machine - 1
The sizes we currently use are:
DS1_V2,DS2_V2,DS3_V2,DS4_V2,DS5_V2,D4S_V3
E2S_V3,E4S_V3,E8S_V3,E16S_V3,E32S_V3,E48S_V3,E64S_V3
F2S_V2,F4S_V2,F8S_V2,F16S_V2,F32S_V2,F48S_V2,F64S_V2
E4_2AS_V4,E8DS_V4,E8AS_V4
Network Interface -1
Network security group - 1
Storage account -1
Disk - (sizing dependent- minimum 3)
Virtual network
For Search we require some additional resources
Virtual network - 1 Per StorSite
Per search cluster node (sizing dependent- minimum 1)
Public IP address - 1
Virtual machine - 1
The sizes we currently use are:
DS1_V2,DS2_V2,DS3_V2,DS4_V2,DS5_V2,D4S_V3
E2S_V3,E4S_V3,E8S_V3,E16S_V3,E32S_V3,E48S_V3,E64S_V3
F2S_V2,F4S_V2,F8S_V2,F16S_V2,F32S_V2,F48S_V2,F64S_V2
E4-2AS_V4,E8DS_V4,E8AS_V4
Network Interface -1
Network security group - 1
Storage account -1
Disk - (sizing dependent- minimum 3)
Recovery Services vault - 1