Chapter 6: Identity, Access Management, and Multi-Tenancy

Authentication answers "are you who you claim to be?" Cohesity supports four paths: local users, AD/LDAP, SAML SSO, and API keys, with optional MFA layered on top. Most enterprise designs use AD or SAML for humans, local accounts for break-glass, and API keys for automation.

1.1 Local Users vs. AD/LDAP

A local user is an account whose password is stored directly in Cohesity. Local accounts provide a recovery path when the corporate IdP is unavailable — you do not want a domain controller outage to lock you out of your backup system. Best practice: keep one or two named break-glass admins with strong passwords, MFA, and tight audit.

Active Directory and LDAP handle daily authentication. Assign roles to AD groups (e.g., cohesity-operators) rather than to individuals. Hybrid Azure AD with AAD Connect typically uses sAMAccountName to keep on-prem and cloud names aligned.

1.2 SAML SSO with Modern Identity Providers

For organizations standardized on cloud IdPs — Microsoft Entra ID, Okta, Ping, JumpCloud, OneLogin, Duo SSO, RSA SecurID, ADSelfService Plus, IBM Security Verify, CyberArk, Thales SafeNet — Cohesity speaks SAML 2.0. SAML establishes a trust triangle: Identity Provider (IdP) authenticates and issues a signed assertion; Service Provider (Cohesity SP) consumes it; the user presents credentials to the IdP and is redirected to the SP.

Authentication can be IdP-initiated (start at IdP portal, click Cohesity tile) or SP-initiated (click "Sign in with SSO" on Cohesity login). When Cohesity receives a SAML assertion it performs four validations: signature verification, temporal validity (NotBefore / NotOnOrAfter), recipient validation against ACS URL, and identity-attribute extraction.

1.3 SAML Configuration Fields

Cohesity needs to know two URLs about itself, which you give to the IdP:

• Self-managed cluster: https://<cluster_fqdn>/idps/authenticate
• Helios: https://helios.cohesity.com/v2/mcm/idp/authenticate

The Identifier (Entity ID) and Reply URL (ACS URL) must equal that endpoint exactly. A mismatch produces "Subject confirmation validation failed" — the most common SAML failure.

Pitfall #1 — Login attribute beats Email. If both are present, Cohesity uses Login for role mapping and ignores Email entirely.

Pitfall #2 — Nested AD groups are not supported. Azure AD and Okta will not expand sub-groups into the SAML assertion. Assign the leaf group(s) the user actually belongs to directly to the Cohesity application.

Pitfall #3 — AD FS does not support signed auth requests. Okta (RSA-SHA256 + SHA256) and Azure AD do; AD FS does not.

1.4 MFA and API Keys

MFA is best enforced at the IdP — Azure Conditional Access, Okta MFA, Duo SSO. Cohesity also supports MFA for local users via TOTP. Compliance-driven deployments combine MFA with quorum approval for destructive operations.

API keys authenticate automation. An API key inherits exactly the privileges of the issuing user — no separate per-key permission set. Least-privilege automation: dedicated service-account user with a narrowly-scoped custom role, key issued from that account.

Authorization answers "what may you do?" Cohesity's model has three primitives: principals (users/groups), roles (privilege sets), and access scopes (resource boundaries). They combine multiplicatively — an identity has a role, and that role applies only to resources within the assigned scope.

2.1 Built-in Roles

Hierarchy (rough): Viewer < Operator < Self-Service < DR Admin / Data Security < Admin / Super Admin.

2.2 Custom Roles and Granular Privileges

Architects designing for least privilege almost always create custom roles via Settings > Access Management > Roles > Add Custom Role. Access Management privileges are pre-selected by default — uncheck them for non-admin roles to prevent privilege escalation.

2.3 Access Scopes — The Layer That Makes Least-Privilege Real

Roles tell Cohesity what; access scopes tell Cohesity where:

Multiple scopes combine ("Operator on VMware AND NAS in Region us-east"). Auto Assign brings newly-added matching resources into scope automatically.

2.4 Auditing Role Assignments

All role assignments and authentication events are logged and exportable via Syslog or REST API to a SIEM. Review quarterly: identify Super Admin equivalents, dormant service accounts, and drifted AD groups. A user with both individual and group role assignments inherits the union of both — useful for exceptions, but a privilege-creep risk.

Multi-tenancy runs independent workloads on shared infrastructure with strict isolation. Cohesity's primitive is the Organization (Org), surrounded by Storage Domains (View Boxes), Views, VLANs, and quotas.

3.1 The Apartment Building Analogy

A Cohesity cluster is an apartment building. Each Organization is a unit with its own door and keys. Helios is the building manager. View Boxes are the plumbing risers — multiple units may share a riser (shared View Box: lower cost) or have dedicated risers (dedicated View Box: stronger isolation). VLANs are the building's intercom wiring. Quotas are per-unit utility metering.

3.2 Organizations as the Isolation Primitive

Critical principle: Organizations remain logically isolated regardless of Storage Domain sharing settings. Even with shared View Boxes, a tenant admin sees only their own Org's Storage Domains, Views, sources, Protection Groups, jobs, and reports.

Hierarchical Organizations let a parent Org contain child Orgs — common for MSPs with reseller-managed customers under direct ones.

3.3 View Box Isolation — Shared vs. Dedicated

The Storage Domain is the unit of storage policy — encryption keys, dedup scope, compression are configured per View Box. View Box separation enforces cryptographic and deduplication boundaries.

3.4 Resource Hierarchy and Quotas

Organization → Storage Domain → View. Quotas are hard — writes exceeding a quota are rejected, not just alerted. Silver tenants exceeding their 50 TB allocation get write failures, not surprise bills.

3.5 Network Isolation — VLAN per Organization

Application-layer isolation alone does not satisfy regulated tenants. VLAN-per-Organization extends isolation to the network layer: Tenant A on VLAN 100, Tenant B on VLAN 200. The cluster supports multiple VIPs across VLANs so each tenant gets a DNS-resolvable management endpoint reachable only from their network.

4.1 MSP/CSP Deployment Patterns

1. Shared cluster, multiple Organizations — Most common; relies on RBAC + Access Scopes + (optional) dedicated View Boxes + VLANs. SMB/mid-market MSPs.
2. Dedicated cluster per tenant — Often a Cloud Edition per tenant. For largest or most regulated tenants. Loses scale economies.

Hybrid: shared for Bronze/Silver, dedicated for Gold. Helios unifies the fleet view.

4.2 Self-Service Portals via Helios

The Self-Service role lets tenant admins create Protection Groups, modify Policies within MSP-imposed bounds, run on-demand backups, and recover — without ticketing the MSP.

4.3 Chargeback and Usage Metering

• FETB (Front-end TB) protected per Organization
• Back-end consumed capacity (post dedup/compression) per Storage Domain
• Protection Groups, Views, recoveries as activity metrics
• Egress for cross-cluster replication or cloud archive

Pricing is typically base $/TB FETB by tier (Bronze/Silver/Gold) plus add-ons for replication, DataLock, DataHawk. Helios reports export to billing via API.

4.4 Twelve-Step Tenant Onboarding (Acme Corp Worked Example)