Chapter 6: Authentication — MFA, SSO & Active Directory
Learning Objectives
Configure multi-factor authentication (MFA) for Cohesity cluster access
Implement single sign-on (SSO) using SAML and OIDC identity providers
Integrate Cohesity with Active Directory and LDAP for centralized authentication
Design authentication policies that enforce organizational security standards
Pre-Quiz — Test Your Current Knowledge
1. Which MFA method does Cohesity recommend as the primary authentication factor?
Email verification codes
SMS text messages
Authenticator app (TOTP)
Hardware security keys
2. What SSO protocol does Cohesity support for web UI login?
OAuth 2.0 only
SAML 2.0
OIDC only
Kerberos tokens
3. What is the maximum allowed clock skew between Active Directory and a Cohesity cluster for Kerberos authentication?
1 minute
10 minutes
5 minutes
15 minutes
4. Can MFA be disabled for Active Directory users in Cohesity?
Yes, through the MFA tab in Access Management
Yes, but only by the built-in admin account
No, disabling MFA for AD users is not supported
Yes, if the AD domain policy allows it
5. Which RBAC mapping method uses SAML attributes to automatically assign roles in Cohesity?
Default role assignment
Individual user-based mapping
Group-based mapping
Certificate-based mapping
6.1 Multi-Factor Authentication
Authentication is the gatekeeper of every security architecture. Before a user can protect data, restore backups, or manage policies on a Cohesity cluster, the system must first verify identity through multiple independent factors.
Multi-factor authentication (MFA) requires users to present two or more independent pieces of evidence before gaining access. Even if an attacker steals a password, they cannot authenticate without the additional factor. Cohesity supports MFA natively, requiring no additional hardware or internet connectivity for its primary method.
Enabling MFA is a straightforward process performed through the management UI:
Navigate to Settings > Access Management and select the MFA tab.
Turn on the MFA toggle.
Select one or both authentication methods (Authenticator App and/or Email).
Click Enable.
After MFA is enabled at the cluster level, individual users complete setup during their next login by scanning a QR code or manually entering a security key into their authenticator app.
Supported MFA Methods
Method
How It Works
Requirements
Recommended?
Authenticator App (TOTP)
User enters a six-digit, time-based one-time password generated by a TOTP app
TOTP app installed (Okta Verify, Google Authenticator, Microsoft Authenticator, or Duo Mobile)
Yes — primary method
Email Verification
User enters a code sent to their registered email address
SMTP server configured and active on the cluster; email address configured per user
As backup only
TOTP (Time-based One-Time Password) generates a new numeric code every 30 seconds based on a shared secret and the current time. The code is valid for approximately five minutes on Cohesity. The cluster does not need internet connectivity when using TOTP.
Interactive: TOTP Code Lifecycle
Simulated authenticator code (refreshes every 30 seconds)
------
30s remaining
sequenceDiagram
participant U as User
participant App as Authenticator App
participant C as Cohesity Cluster
U->>C: Enter username & password
C->>C: Validate credentials
C-->>U: Prompt for MFA code
U->>App: Open authenticator app
App->>App: Generate 6-digit TOTP code (shared secret + current time)
App-->>U: Display code (valid 30s)
U->>C: Enter TOTP code
C->>C: Generate expected TOTP code (same shared secret + current time)
C->>C: Compare codes (5-min window)
C-->>U: Access granted
Real-World Analogy: TOTP works like a combination lock where the combination changes every 30 seconds. Both you and the lock know the pattern for generating combinations, so even without communicating, you always arrive at the same code at the same time. An attacker who intercepts one code finds it useless seconds later.
Enforcing MFA: All Users vs. Privileged Accounts
Local and AD Users: Administrators can enable MFA for all users or specific local users. MFA is enabled by default for Active Directory users and disabling MFA for AD users is not supported.
Support User Accounts: MFA for support users is configured separately via Settings > Access Management > Support. The administrator must click Unlock and enter the support user password first.
Multi-Tenant Organizations: MFA can be enabled at the organization level, allowing each tenant to enforce their own MFA policies.
Flex Appliance Enforcement: MFA extends across Web UI, shell CLI, and NetBackup interfaces. Administrators can set a grace period of up to 90 days. Once enforcement is activated, it becomes permanent and cannot be reversed.
MFA Recovery and Emergency Access
When users lose access to their authenticator device, administrators with super administrator or security administrator privileges can reset that user's MFA credentials. The user re-enrolls on next login.
Best practices for recovery planning:
Enable both MFA methods (TOTP and email) so users have a fallback.
Ensure at least two administrators have super administrator or security administrator privileges.
Secure the built-in admin account with a strong password stored in a sealed envelope or vault as a break-glass access path.
Key Points — Multi-Factor Authentication
Cohesity MFA uses open-standard TOTP and email verification with no extra hardware or internet required.
TOTP is the recommended primary method; email is backup only (vulnerable to interception).
MFA is mandatory for AD users by default and cannot be disabled for them.
On Flex Appliances, MFA enforcement is permanent once activated (grace period up to 90 days).
Always enable both methods to prevent lockouts; secure the built-in admin account as a break-glass path.
6.2 Single Sign-On Configuration
Single sign-on (SSO) allows users to authenticate once with a central identity provider (IdP) and then access multiple applications — including Cohesity — without re-entering credentials. SSO reduces password fatigue, centralizes authentication policy enforcement, and simplifies user provisioning and deprovisioning.
SAML 2.0 Integration
SAML 2.0 (Security Assertion Markup Language) is an XML-based open standard for exchanging authentication and authorization data between an identity provider and a service provider. SAML is Cohesity's primary SSO protocol, supporting both UI and API-based authentication.
sequenceDiagram
participant U as User Browser
participant C as Cohesity Cluster (Service Provider)
participant IdP as Identity Provider (Okta / Azure AD / AD FS)
U->>C: Access Cohesity login page
C->>C: Detect SSO domain
C-->>U: Redirect to IdP with SAML request
U->>IdP: Follow redirect
IdP->>IdP: Authenticate user (credentials + MFA)
IdP-->>U: Return signed SAML assertion
U->>C: POST SAML assertion
C->>C: Validate signature & extract user attributes
C->>C: Map groups to RBAC roles
C-->>U: Grant access with assigned role
To configure SAML SSO, navigate to Settings > Access Management > Single Sign-On > Configure SSO and provide:
Field
Purpose
SSO Domain
Unique identifier (typically company domain) that routes users to the correct IdP
SSO Provider
Selected provider from the dropdown list
Single Sign-on URL
The authentication endpoint provided by your IdP
Provider Issuer ID
The identity assertion issuer identifier
X.509 Certificate
Public certificate downloaded from the IdP (must be in .pem format)
Cohesity supports signed authentication requests using RSA-SHA256 and SHA256 digest algorithms. SAML assertions can be both signed and encrypted for maximum security.
OIDC Configuration
OpenID Connect (OIDC) is a modern authentication layer built on OAuth 2.0 that uses lightweight JSON Web Tokens (JWTs). However, Cohesity supports OIDC only for API-based authentication, not for UI login. If users need to sign in through the Cohesity web interface, SAML is required.
Cohesity supports 11+ identity providers. The three most common configurations:
Okta (SAML 2.0)
In Okta, create a SAML 2.0 App Integration.
Set the SSO URL to https://<cluster_fqdn>/idps/authenticate.
Map SAML attributes: Email to user.email, Login to user.login.
For group-based RBAC, enter "groups" in the group attribute name field and apply filters (e.g., "Starts with cohesity_").
Retrieve the IdP SSO URL, Issuer, and download the certificate in .pem format.
Microsoft Entra ID (Azure AD) — SAML
Create a Non-gallery Enterprise Application in Azure AD.
Set Entity ID and Reply URL to the Cohesity authentication endpoint.
Add custom claims and group claims (nested groups are not supported; sAMAccountName requires Azure AD Connect Sync 1.2.70.0+).
Download the SAML Signing Certificate in PEM format.
AD FS
Add a Claims-aware Relying Party Trust with the Cohesity authentication URL.
Create three claim rules: LDAP-to-claims mapping, email claim transformation, and a custom group rule.
Export the Token-Signing Certificate as Base-64 encoded X.509 (.pem).
Note: Cohesity does not support Sign Auth Requests for AD FS.
RBAC with SSO
RBAC Method
Description
Default Role
All SSO users receive the same pre-selected default role
Individual User-Based
Roles are assigned per user within Cohesity
Group-Based
Cohesity reads the "Groups" SAML attribute and matches it to SSO groups; user inherits the group's role
Users must have explicit IdP entries — missing entries result in authentication rejection. Access can be scoped to all clusters or limited to specific ones.
Key Points — Single Sign-On
Cohesity supports SSO via SAML 2.0 (UI + API) and OIDC (API only).
SAML configuration requires: SSO domain, provider URL, issuer ID, and X.509 certificate in .pem format.
Signed and encrypted SAML assertions provide the highest security level.
Group-based RBAC mapping through SAML attributes automates role assignment aligned with organizational structure.
Cohesity integrates with 11+ IdPs including Okta, Azure AD (Entra ID), and AD FS.
6.3 Active Directory & LDAP Integration
While SSO handles web-based authentication flows, many organizations need Cohesity to participate directly in their Active Directory (AD) domain — particularly for SMB file services, delegated administration, and environments where AD is the authoritative identity source.
Real-World Analogy: Joining a Cohesity cluster to Active Directory is like adding a new employee to the company directory. Once registered, the cluster can verify anyone's badge (Kerberos ticket) against the central registry, and existing group memberships automatically determine what each person can access.
Prerequisites for Joining AD
Requirement
Details
Network Connectivity
Network path from Cohesity cluster to domain controllers
Account Permissions
Domain Administrator privileges (or permissions to join Computer Objects)
Preferred Domain Controllers
At least 1 DC (2 strongly recommended); without preferred DCs, DNS round-robin can cause intermittent failures
DNS Configuration
A record for each machine account FQDN on the DNS server
Clock Synchronization
Kerberos allows no more than 5-minute clock skew
Configuration Steps
Navigate to Settings > Access Management > Active Directory tab.
Enter the AD domain name.
Provide at least one machine account to identify the cluster on the domain.
(Optional) Select a mapped provider (LDAP or NIS) for UID/GID mapping.
(Optional) Specify the organizational unit.
(Optional) Enable trusted domain discovery.
Supply domain join credentials and complete the join process (~5 minutes).
flowchart TD
subgraph Prerequisites
DNS["DNS A Record\nfor machine account"]
NTP["Clock Sync\n(less than 5 min skew)"]
DC["Preferred Domain\nControllers (2+)"]
Creds["Domain Admin\nCredentials"]
end
Prerequisites --> Join["Join Cohesity Cluster\nto AD Domain"]
Join --> Machine["Machine Account\nCreated in AD"]
Machine --> Ready["Cluster Ready for\nAD Authentication"]
subgraph Login["AD User Login Flow"]
direction LR
UserLogin["User selects\nAD domain"] --> Kerberos["Kerberos ticket\nvalidated against DC"]
Kerberos --> GroupLookup["Group membership\nresolved"]
GroupLookup --> RBAC["RBAC role\nassigned"]
end
Ready --> Login
style Join fill:#3498db,color:#fff
style Ready fill:#2ecc71,color:#fff
style Machine fill:#9b59b6,color:#fff
Interactive: Kerberos Authentication Handshake
1
User enters AD credentials on Cohesity login page
2
Cluster forwards authentication request to preferred Domain Controller
3
DC validates credentials and issues Kerberos TGT (Ticket Granting Ticket)
4
Cluster requests service ticket using TGT
5
DC resolves group memberships for the user
6
Cohesity maps AD groups to RBAC roles and grants access
LDAP Authentication Configuration
LDAP (Lightweight Directory Access Protocol) is a vendor-neutral protocol for directory services. Cohesity supports LDAP as either a standalone directory source or as a mapped provider alongside AD.
Parameter
Description
Name
Descriptive name for the LDAP provider
Server
IP addresses or FQDNs of the LDAP server
Domain Name
Domain name used when querying via DNS
Port
Listening port (default: 389)
Base DN
Base Distinguished Name for LDAP queries
Authentication Type
Authentication method (e.g., Simple with Bind DN and password)
Important limitations:
Cohesity does not support LDAP authentication for users logging in to the Cohesity Dashboard (web UI).
LDAP providers are primarily used for NFS exports for Unix users belonging to more than 16 groups.
Only administrators or users with the "Manage AD and LDAP" role can add/modify LDAP providers.
Trusted Domain Support
When trusted domain discovery is enabled during AD join, Cohesity detects trust relationships. Administrators can selectively exclude certain trusted domains afterward.
For SMB shares with multiple AD domains, only Kerberos authentication is supported (NTLM is disabled). Client machines must be joined to the same domain as the cluster.
Service Account Requirements
Domain Join Account: Needs permissions to create Computer Objects in the target OU. Domain Admin credentials are simplest, but delegated least-privilege accounts also work.
Machine Account: Created during join to represent the cluster in AD. Must retain Read membership permissions across users and groups.
Built-in Admin Account: Persists after AD integration. Cohesity recommends a complex password stored securely as a break-glass access path.
RBAC with Active Directory
Role
Access Level
Cluster Administrator
Full cluster management
Backup Operator
Data management tasks without cluster configuration authority
Backup Viewer
Read-only access
Custom Roles
Configurable based on organizational security policies
Key Points — Active Directory & LDAP
AD integration requires DNS A records, preferred DCs (at least 2), and clock sync within 5 minutes.
Machine accounts must have Read membership permissions across all users and groups.
LDAP supplements AD for NFS/Unix access but does NOT support Cohesity Dashboard login.
For multi-domain SMB shares, only Kerberos is supported (no NTLM).
The built-in admin account persists after AD join — secure it as a break-glass path.
6.4 Authentication Policy Design
Configuring authentication mechanisms is only half the battle. Effective security requires well-designed policies governing password strength, session management, and audit logging.
Password Policies and Complexity Requirements
Policy Element
Recommendation
Minimum Length
12+ characters
Complexity
Mix of uppercase, lowercase, numbers, and special characters
Rotation
Per organizational policy (NIST recommends against forced periodic rotation unless compromise is suspected)
Built-in Admin Account
Unique, highly complex password stored in a secure vault
Support Account
Enable MFA; set a strong password separate from the admin account
For AD-integrated environments, the domain's Group Policy Objects (GPOs) enforce password policies centrally across all domain-joined systems, including Cohesity.