12.1 Directory Integration: LDAP Mapping, RADIUS MFA & SAML 2.0 SSO

12.1 Directory Integration: LDAP Mapping, RADIUS MFA & SAML 2.0 SSO

Quick Answer: The CyberArk Digital Vault connects to Active Directory via LDAPS over TCP port 636 (or TCP 3269 for Global Catalog), requiring the domain's issuing CA certificate in the Vault's local Trusted Root store. Administrators define Directory Mapping rules that link AD security groups to Vault authorizations, user templates, and Safe access dynamically without static Vault accounts. Secondary authentication challenges are integrated via RADIUS over UDP port 1812/1645 in DBParm.ini, while federated SAML 2.0 SSO redirects users to external Identity Providers (Entra ID, Okta), relying on LDAP directory mappings to resolve the SAML NameID into authorized Vault identities.

---

Active Directory Integration Architecture & LDAPS Configuration

CyberArk integrates with Microsoft Active Directory (AD) and LDAP-compliant directories to centralize identity management, enforce enterprise password policies, and leverage existing directory groups.

Protocol and Cryptographic Requirements

The Digital Vault initiates outbound connections to Active Directory domain controllers:

• Protocol & Ports: Integration requires LDAP over SSL/TLS (LDAPS) on TCP port 636 for standard Domain Controller queries, or TCP port 3269 for Global Catalog queries across multi-domain forests. Cleartext LDAP over TCP port 389 is insecure and rejected in hardened environments.
• Certificate Validation: The Vault validates the SSL/TLS certificate presented by the Domain Controller. The issuing Root and Intermediate CA certificates must be imported into the Local Computer \ Trusted Root Certification Authorities certificate store on the Vault host.

High Availability & The Bind Account

To eliminate single points of failure, CyberArk supports configuring multiple Domain Controllers in Password Vault Web Access (PVWA):

• Host Priority: Administrators define primary and backup Domain Controllers by FQDN or static IPv4 address.
• Automatic Failover: If the primary Domain Controller is unresponsive, the Vault automatically diverts subsequent search and authentication requests to the secondary directory host.
• The Bind User: The Vault requires a dedicated domain service account (the Bind Account) with read-only permissions across user and group Organizational Units (OUs). This account should have a complex, non-expiring password (or be managed by CPM) and requires standard Domain Users rights rather than domain administrative privileges.

---

Directory Mapping Rules & Dynamic Provisioning

CyberArk avoids synchronizing the entire Active Directory tree into the Vault database. Instead, it uses an on-demand, transparent provisioning model driven by Directory Mapping Rules.

Directory Map Components

A Directory Map evaluates incoming directory attributes against defined search criteria to determine how a user is represented inside the Vault:

1. LDAP Query / Group Filter: Evaluates directory group memberships or OU paths (e.g., memberOf=CN=PAM_Admins,OU=Groups,DC=corp,DC=local).
2. Vault User Template: Defines Vault attributes applied to matching users:
   • User Type: Defines the license type (typically EPVUser for standard administrators).
   • Authorized Interfaces: Controls accessible client interfaces, including PVWA Web, PrivateArk Client GUI, and PACLI.
   • Default Location: The organizational container in the Vault directory hierarchy where the user object is placed.
   • Internal Groups: Built-in Vault groups (e.g., Vault Admins, Auditors) to which matching users are automatically added.

Rule Precedence & Safe Access via AD Groups

• Evaluation Order: The Vault evaluates Directory Mapping rules sequentially from top to bottom. The first matching rule is applied, and evaluation stops immediately. Subsequent rules are ignored. Specific administrative mappings must reside at the top, with broad catch-all maps at the bottom.
• Safe Authorizations: Best practice mandates adding the Active Directory security group directly as a Safe member in PVWA. When a domain user logs in for the first time, CyberArk provisions an external user reference object in the Vault database. Because the user belongs to the AD security group, the Vault automatically calculates effective permissions and grants instant access to authorized Safes.

---

Multi-Factor Authentication: RADIUS Integration

CyberArk natively supports the Remote Authentication Dial-In User Service (RADIUS) protocol to deliver secondary authentication challenges (RSA SecurID, Duo Security, Okta Verify).

RADIUS Configuration in DBParm.ini

RADIUS integration is configured at the Vault level by modifying DBParm.ini in C:\Program Files (x86)\PrivateArk\Server\Conf\:

[RADIUS]
RadiusServersInfo=10.10.1.50;1812;VaultPrimary;secretKey123;1;10.10.1.51;1812;VaultPrimary;secretKey123;2
RadiusTimeout=15

• RadiusServersInfo: Semicolon-delimited string specifying the RADIUS server IP address, UDP port (1812 or legacy 1645), client host identifier, shared secret, and priority order.
• RadiusTimeout: Seconds the Vault waits for a challenge-response packet before failing over to the secondary server.

Authentication Workflow

1. The user provides their directory credentials at the PVWA portal.
2. PVWA prompts for the RADIUS passcode (or triggers an out-of-band push notification).
3. The Vault formats an Access-Request UDP packet and forwards it over UDP 1812 to the RADIUS server.
4. Upon receiving an Access-Accept response, the Vault issues an encrypted session token.

---

Federated Single Sign-On: SAML 2.0 Integration

SAML 2.0 enables web-based Single Sign-On (SSO) by delegating authentication to an Identity Provider (IdP) such as Microsoft Entra ID, Okta, PingIdentity, or ADFS.

SP-Initiated Flow & PVWA Configuration

In the standard Service Provider (SP)-Initiated flow, the user accesses the PVWA URL. PVWA generates an encrypted SAML AuthnRequest and redirects the browser to the IdP. The IdP authenticates the user, generates a signed SAML assertion, and redirects the browser back to the PVWA Assertion Consumer Service (ACS) endpoint (/PasswordVault/api/auth/saml/logon).

SAML is configured in PVWA under Administration \ Configuration Options \ Options \ Authentication Methods \ saml:

• IdentityProviderLoginURL: The SSO URL of the external IdP.
• IdentityProviderCertificate: Public X.509 certificate used by PVWA to validate assertion signatures.
• Issuer / EntityID: The unique URI identifying the PVWA instance to the IdP.
• NameID Claim: Attribute containing the user's primary logon identifier (e.g., sAMAccountName or userPrincipalName).

SAML and LDAP Co-Dependence

SAML authentication requires underlying Active Directory integration:

• The SAML assertion confirms only that the user authenticated successfully at the IdP.
• When PVWA receives the assertion, it extracts the NameID attribute.
• The Vault must resolve this NameID against an existing Directory Mapping rule configured via LDAPS to calculate group memberships and Safe authorizations. Without LDAP directory mapping, login fails.

---

Enterprise Authentication Protocols Comparison Matrix