Prerequisites

Before deploying Omada Identity Cloud Private, ensure the following requirements are in place in your Azure tenant and environment.

note

For prerequisites required during deployment, including system requirements, detailed network configuration, and certificate preparation – see Prerequisites in the deployment guide.

Azure tenant requirements

Identity

Microsoft Entra ID (Azure AD) Premium P1 is required to support:

• Service Principals used by deployment automation.
• Managed identities used by Azure resources.

The deployment process requires sufficient permissions to create and manage Azure resources. At a minimum, the executing identity (user or service principal) must have:

• Permissions to deploy and manage resources in the target subscription or resource groups.
• Permissions to assign roles and manage access control (RBAC).
• Permissions to create and manage Service Principals and managed identities.

The executing identity must also have the following Azure roles assigned at subscription scope:

Role	Purpose
Contributor (or Owner)	Create and manage Azure resources in the target subscription
User Access Administrator (or Owner)	Assign roles and manage RBAC for deployed resources

note

For details on Azure built-in roles and their permissions, see Azure built-in roles – Azure RBAC.

Subscription and quotas

The Azure subscription must have sufficient quotas for the resource types listed below. The values provided are indicative minimums based on a medium-profile deployment (see Infrastructure sizing).

note

These quotas should be treated as initial guidance to avoid environment provisioning issues. Exact vCPU requirements are dependent on the sizing profile.

To review and request quota increases in your subscription, see Quotas – Microsoft Azure.

Compute

Quota	Minimum recommended
Standard DSv5 Family vCPUs	100
Standard Bsv2 Family vCPUs	10
Total Regional vCPUs	140
Virtual Machine Scale Sets	2,500
Virtual Machines	25,000
Premium Storage Managed Disks	50,000
Standard SSD Storage Disks	50,000
Standard Storage Managed Disks	50,000

Networking

Quota	Minimum recommended
Public IP Addresses	40
Public IPv4 Addresses – Standard	40
Load Balancers	1,000
Standard SKU Load Balancers	1,000
Virtual Networks	1,000
Network Security Groups	5,000
Network Interfaces	65,536

warning

Azure allows one Network Watcher per region by default. If your subscription already has a Network Watcher deployed in the target region, this quota will be at capacity. Verify availability before deployment.

Azure Kubernetes Service

Quota	Minimum recommended
Managed Clusters	10

Storage

Quota	Minimum recommended
Storage Accounts	250

Networking and DNS

The deployment requires network configuration within your Azure environment to enable communication between platform components and external access to application endpoints. Virtual network (VNet) and subnet configurations must be in place to support the deployed resources.

DNS configuration is required to expose application endpoints and enable name resolution:

• DNS records for public endpoints exposed by the platform.
• Internal name resolution for service-to-service communication (if applicable).

Network security configuration, including firewall rules, NSGs, and routing, must be defined according to your security requirements.

Certificates and SMTP

TLS certificates are required to secure external endpoints. You must provide valid certificates and corresponding private keys for use by platform components.

If email functionality is required, an SMTP server must be available.

You are responsible for:

• Providing and managing TLS certificates.
• Ensuring secure storage and handling of private keys.
• Configuring and maintaining SMTP connectivity (if applicable).

Optional / policy-driven requirements

Some organizations may require additional policies:

• Microsoft Defender for Cloud
• Extended log retention
• Geo-redundant storage or cross-region backup
• Private endpoints for all data services
• Customer-managed encryption keys (CMK) in Key Vault

Configuration

Configuration is managed through Terraform variables, Ansible variables, and supporting configuration files. You are responsible for reviewing and adapting these values to match your Azure environment, naming standards, and operational requirements.

Customization

Custom code, including custom assemblies (DLLs), custom JavaScript, and custom connectivity packages, is not directly supported by the Cloud Private deployment automation or Omada support scope.

If customization is required, users must create and maintain their own deployment scripts for installing customizations and performing updates.

Terraform configuration

Key configuration elements include:

• Variable definitions: Environment-specific values defined in variable files (for example, variables.auto.tfvars.json).
• Shared configuration: Common settings such as resource SKUs, network settings, and default values defined in shared configuration files (for example, shared-config.tf).
• Environment-specific overrides: Configuration values can be adjusted per Terraform workspace to support different environments (for example, development, QA, or production).

Environment parameters

Each environment is defined by a unique workspace and associated configuration values. Key aspects include:

• Workspace selection: The Terraform workspace determines which set of resources is deployed and which configuration overrides apply.
• Environment-specific values: Parameters such as resource names, scaling, and service configurations may vary between environments.
• Region configuration: The Azure region must be selected based on service availability, capacity, and organizational requirements.
• Environment isolation: Each workspace represents a separate deployment scope.

Naming conventions

Resource naming follows a consistent structure across deployed resources, typically including:

• Environment identifier (for example, dev, QA, prod).
• Workspace or deployment prefix.
• Resource type or functional role.

You may adapt naming conventions to align with internal standards and governance requirements.

note

Currently, certain naming constraints are still enforced by the provided scripts. These constraints are being actively reviewed and are expected to be relaxed in future releases.

---

tip

For deployment instructions, see the Deployment guide.