Centrify in the Enterprise: Architecture, Deployment, and Hardening Guide

Overview

Centrify is an enterprise identity and privileged access platform used to centralize authentication, enforce least privilege, and control access to servers, workstations, cloud resources, and applications. Enterprises adopt it to reduce standing privilege, integrate with Active Directory and cloud identity providers, and provide auditable access for administrators, developers, and third parties.

In practice, Centrify is commonly used for:

• Privileged Access Management (PAM) for vaulting, session control, and elevation
• Identity federation and single sign-on across SaaS and internal apps
• Server Suite / Privilege Elevation for Linux and UNIX integrated with AD
• MFA enforcement for high-risk or privileged workflows

Architecture

A typical Centrify deployment includes:

• Centrify Cloud Service / Delinea tenant for policy, identity, MFA, and privileged access workflows
• Directory integration with Microsoft Active Directory or LDAP
• Centrify Connector deployed on Windows Server to broker communication from internal resources to the cloud service
• Centrify Agent on Linux/UNIX servers for AD join, authentication, and privilege elevation
• Vaulting and session services for credential checkout and monitored access

Deployment models

• Cloud-managed: preferred for rapid rollout and lower operational overhead
• Hybrid: cloud control plane with on-prem connectors and agents
• On-prem legacy: used in regulated environments with strict residency constraints

Data flow

1. User authenticates with AD or federated IdP.
2. Centrify evaluates policy, device posture, and MFA requirements.
3. Connector proxies requests to internal targets without inbound firewall exposure.
4. Agent on target host enforces authentication and privilege rules.
5. Events are logged to Centrify audit trails and optionally forwarded to SIEM.

Implementation Guide

1. Prepare prerequisites

• Active Directory service account with delegated join rights
• Outbound HTTPS from connectors to the Centrify tenant
• NTP synchronization across AD, connectors, and Linux hosts
• DNS resolution for tenant and domain controllers

2. Install Linux agent and join AD

On RHEL or compatible systems:

sudo rpm -ivh centrifydc-5.8.1-rhel7.x86_64.rpm
sudo /usr/share/centrifydc/bin/adcheck
sudo /usr/sbin/adjoin -w EXAMPLE.COM -u svc_centrify_join -z Default-Zone linux-app-01.example.com
sudo /usr/sbin/adinfo
sudo systemctl restart centrifydc

Expected validation:

adinfo | egrep 'Joined to domain|Zone|Licensed Features'
getent passwd 'EXAMPLE\\jdoe'

3. Configure privilege elevation

Edit /etc/centrifydc/user.ignore only if you must exclude local break-glass accounts. Centrify privilege rules are usually policy-driven from the tenant or AD zone. Example sudo role mapping in zone policy:

{
  "role": "Linux-Operations",
  "members": ["EXAMPLE\\linux-admins"],
  "commands": ["/usr/bin/systemctl", "/usr/bin/journalctl", "/bin/su"],
  "runAs": "root",
  "mfaRequired": true
}

4. Deploy connector on Windows Server

Install the Centrify Connector, register it to the tenant, and verify outbound connectivity on TCP 443. Confirm service health in Windows:

Get-Service *Centrify*
Test-NetConnection tenant.example.my.centrify.net -Port 443

5. Enable auditing and SIEM forwarding

Forward syslog or API-based audit exports to Splunk, Microsoft Sentinel, or QRadar. On Linux, ensure audit-relevant logs are retained:

sudo grep centrify /var/log/messages
sudo journalctl -u centrifydc --since '1 hour ago'

Code Examples

Example 1: Linux domain join automation

#!/usr/bin/env bash
set -euo pipefail
DOMAIN="EXAMPLE.COM"
ZONE="Default-Zone"
USER="svc_centrify_join"
rpm -q centrifydc || rpm -ivh centrifydc-5.8.1-rhel7.x86_64.rpm
/usr/sbin/adjoin -w "$DOMAIN" -u "$USER" -z "$ZONE" "$(hostname -f)"
/usr/sbin/adinfo
systemctl enable centrifydc && systemctl restart centrifydc

Example 2: Connector deployment values

tenant: corp-prod.my.centrify.net
proxy:
  enabled: true
  httpsProxy: http://proxy01.example.com:8080
logging:
  level: info
  forwardToSiem: true
ha:
  minimumConnectors: 2

Example 3: Audit event retrieval via API

import requests
tenant = "https://corp-prod.my.centrify.net"
token = "eyJhbGciOi..."
resp = requests.get(f"{tenant}/Security/Reports/AuditTrail", headers={"Authorization": f"Bearer {token}"}, timeout=30)
resp.raise_for_status()
for event in resp.json().get("Result", [])[:5]:
    print(event.get("EventType"), event.get("Message"), event.get("When"))

Security Hardening

• Enforce MFA for all privileged roles and credential checkout workflows.
• Use least privilege roles scoped by system, command set, and time window.
• Deploy at least two connectors per region for high availability.
• Restrict connector hosts with outbound-only rules and hardened admin access.
• Enable TLS 1.2+, rotate service account credentials, and store secrets in a vault.
• Forward audit logs to a SIEM and alert on failed joins, repeated MFA denial, and privilege escalation outside change windows.
• Maintain break-glass accounts offline, monitored, and excluded from daily use.

Comparison

Troubleshooting

1. Domain join fails

Log sample:

May 14 10:22:31 linux-app-01 centrifydc[2145]: ERROR adclient.krb5: KRB5KDC_ERR_PREAUTH_FAILED during adjoin for user svc_centrify_join@EXAMPLE.COM
May 14 10:22:31 linux-app-01 centrifydc[2145]: Join to domain EXAMPLE.COM failed: authentication error

Fix:

• Verify service account password and Kerberos time sync
• Run chronyc sources and kinit svc_centrify_join@EXAMPLE.COM

2. User cannot resolve AD identity on Linux

Log sample:

Jun 02 08:11:09 db-01 centrifydc[1887]: NSS lookup failed for EXAMPLE\\jdoe: zone assignment not found
Jun 02 08:11:09 db-01 centrifydc[1887]: adclient: user not mapped to any role in zone Default-Zone

Fix:

• Confirm host is in the correct zone with adinfo -z
• Add the user or group to the zone role and refresh policy

3. Connector cannot reach tenant

Log sample:

2025-06-02 12:44:18,901 ERROR ConnectorService HttpClient - Connection failed to https://corp-prod.my.centrify.net:443/api/login, reason=PKIX path building failed
2025-06-02 12:44:18,903 WARN ConnectorService Retry scheduled in 30 seconds

Fix:

• Import the required root and intermediate CA certificates
• Inspect TLS interception on outbound proxies and retest with Test-NetConnection

Best Practices

Do

• Map roles to AD groups, not individual users
• Require MFA for elevation and vault checkout
• Segment connectors by region or trust boundary
• Test policies in a pilot zone before production rollout

Don't

• Don't grant broad root access when command-scoped elevation is sufficient
• Don't place a single connector in a critical region
• Don't rely only on tenant logs; always export to SIEM
• Don't skip time synchronization; Kerberos failures are common and disruptive