Centrify Deployment and Support Guide

— ny_wk

Centrify (now part of Delinea Server Suite) joins Linux and UNIX servers to Active Directory so administrators sign in with their domain accounts instead of scattered local logins. This Centrify deployment and support guide walks through installing the agent, joining a server to AD, mapping access groups, converting users, and troubleshooting the join end to end.

Centralizing Linux authentication on Active Directory removes the headache of managing /etc/passwd and /etc/shadow on hundreds of hosts, gives you one place to disable a leaver, and lets security teams enforce consistent access policy. The trade-off is a handful of moving parts - DNS, Kerberos, computer objects, and group mapping - that all have to line up. The steps below cover the full rollout.

The problem: local accounts do not scale

On a fleet of Linux servers without a directory bridge, every box has its own copy of every user. Onboarding means touching dozens of /etc/passwd files; offboarding is even riskier because a forgotten local account is a standing door. UIDs drift between hosts, sudo rules are duplicated, and audits are painful.

An Active Directory bridge such as Centrify DirectControl (the agent package is CentrifyDC) solves this by making each Linux host a first-class AD member. Users authenticate with their domain credentials over Kerberos, group membership in AD decides who can log in, and a user receives the same UID on every joined server, which keeps file ownership consistent across NFS and migrations.

A note on versions: Centrify is now Delinea

The product described here is the classic CentrifyDC 5.x agent. Centrify rebranded to Delinea, and the modern product is the Delinea Server Suite; the commands (adjoin, adinfo, adquery, adflush) are unchanged, so this guide stays accurate for current installs. The free Centrify Express tier has been discontinued. If you are building net-new and want a no-license option, the open-source equivalent is SSSD driven by realmd (realm join), which ships with RHEL/Rocky/Alma and Ubuntu. The concepts - join a computer object, allow groups, map UIDs - carry over directly.

High-level rollout plan

Stage the deployment rather than flipping every server at once. A phased plan keeps a clean rollback path at every step.

1. Secure AD privileges. The join account needs rights to create or write the computer object. Until that is granted, have the AD team pre-create each computer object from a request form.
2. Pilot the join. Join a couple of dozen representative servers first so teams can watch how login behaves before a mass rollout.
3. Convert admins to AD auth. Move users from local to domain authentication one at a time during the pilot, then in bulk once it is proven.
4. Clean up local accounts. Once AD logins are stable with no need to revert, remove the now-redundant local accounts. Centrify needs no local-to-AD mapping, so /etc/passwd stays lean.

Step 1: Install the CentrifyDC agent on Linux

The same RPM works across Red Hat Enterprise Linux 5 and 6 (and the modern Delinea package across current RHEL releases). There are three install paths; pick whichever fits your tooling.

Option A: Install with YUM (recommended for fleets)

Publish the RPM in an internal repo or Satellite channel, entitle the host, then install. First confirm the host sees the channel:

1. List repositories and look for the Centrify channel:
   yum repolist
   You should see an entry such as centrify-5-x86_64.
2. Confirm the package is visible:
   yum list CentrifyDC
   Expect a line like CentrifyDC.x86_64 5.1.0-497 centrify-5-x86_64.
3. Install it:
   yum install CentrifyDC

On modern systems the equivalent is dnf install CentrifyDC. If the host is not entitled to the channel, the package will not appear - fix the repo entitlement before going further.

Option B: Manual RPM install

When no repo is available, copy the RPM to the server and install it directly. Use scp or sftp to drop the file in a temp directory, then:

1. cd /tmp
2. rpm -ivh centrifydc-5.1.0-rhelX-x86_64.rpm

The -ivh flags mean install, verbose, and show a progress hash. Match the package to your RHEL major version.

Option C: Centralized push

If you run a configuration/automation platform (Ansible, a CMDB-driven build tool, or an enterprise server-automation suite), wrap Option A or B in a play or job so installs are identical and auditable across the pilot group.

Step 2: Plan Active Directory groups and roles

Do not invent a parallel set of UNIX groups. Reuse the AD groups your access model already defines so one membership change governs both Windows and Linux access. Map each server to the support role that owns it, for example:

Decide which roles need login on each host before you join - the join configuration references these group names. Application and DBA access can be layered on per server later.

Step 3: Join the server to Active Directory

Prerequisites

Two things must be true before adjoin will succeed:

• The computer object exists. Until the join account has create rights, the AD team pre-creates the object and grants the dedicated join account (for example sa_automation) permission to it.
• Forward and reverse DNS resolve correctly. Centrify needs the host to resolve into the AD DNS domain. If the resolver is ambiguous, make the AD FQDN the first entry in /etc/hosts:
  172.22.124.250 host01.ad.example.net host01.example.net host01

Important: with auto-zone the agent assigns a new UID, and it is the same on every host you log into. Plan for this - it is central to the home-directory permission steps later.

Configure the agent before joining

All agent settings live in /etc/centrifydc/centrifydc.conf. Edit it with your usual editor:

1. Protect existing local accounts. Add every current local user to /etc/centrifydc/user.ignore, one per line. When the agent starts it sits in front of authentication; any user in user.ignore is skipped by Centrify so local logins keep working. This is what makes the join non-disruptive.
2. Enable auto-schema allow groups. In centrifydc.conf uncomment:
   auto.schema.allow.groups: file:/etc/centrifydc/auto_user_groups.allow
   then create the file and list the AD groups whose users should get a UNIX profile:
   touch /etc/centrifydc/auto_user_groups.allow
3. Enable auto-schema groups. Uncomment:
   auto.schema.groups: file:/etc/centrifydc/auto_groups.allow
   then touch /etc/centrifydc/auto_groups.allow and add the AD groups that should resolve as UNIX groups.
4. Restrict who may log in. Uncomment:
   pam.allow.groups: file:/etc/centrifydc/groups.allow
   then touch /etc/centrifydc/groups.allow and add only the AD groups that need shell access to this server, one per line. This is your login allow-list.

Use lowercase group names consistently in these files. The rol-linux_wheel group is for privilege escalation only and should not go in groups.allow.

Run the join

With the computer object pre-created, run the join against the join account:

1. adjoin -u sa_automation@ad.example.net -p '<password>' -V -w ad.example.net
   Here -u is the join user, -V is verbose, and -w targets the workstation/domain. A few warnings (for example a missing subnet-to-site mapping) are normal; watch for hard errors.
2. Verify connectivity to AD:
   adinfo --test

For repeatable joins, wrap these configuration and adjoin steps in a script or automation job so every host is identical.

Step 4: Convert users from local to AD authentication

After the join, local logins still work because everyone is in user.ignore. Converting a user means moving them off that list and making sure their files are owned by the AD UID.

When the AD username matches the local username

This is the only case that needs care, because the names collide. Steps:

1. Remove the user from /etc/centrifydc/user.ignore.
2. Reload and flush the agent cache so it picks up the change:
   adreload
adflush -f
adquery group (caches the groups you defined as UNIX groups)
3. Look up the user's AD UID (this fails while they are still in user.ignore):
   adquery user --uid <username>
4. Re-own the home directory - including hidden dotfiles - to the AD UID. For example:
   chown -R 536928450:536928450 /home/jdoe
chown 536928450:536928450 /home/jdoe/.bashrc

If your team has the helper scripts centrify_convert_to_ad.sh and centrify_convert_to_local.sh, run them with the username and tee the output, because a large home directory can overflow the screen buffer:

1. centrify_convert_to_ad.sh <username> | tee /var/log/convert_jdoe.log
2. If the user hits problems, roll back: centrify_convert_to_local.sh <username> | tee /var/log/revert_jdoe.log

When the AD username differs from the local username

There is no conflict, so the user can log in with their AD name immediately. On first login Centrify creates a fresh home directory owned by the AD UID. The user simply copies files from the old local home into the new one, fixes permissions to match the AD UID, and once satisfied the old local account and directory can be removed.

Clean up local accounts

When AD logins are proven and there is no reason to revert, delete the local account with userdel. Centrify keeps no local-to-AD mapping, so removing the entry from /etc/passwd and /etc/shadow is safe and keeps the host tidy. Test userdel on a non-critical account first.

Step 5: Configure sudo and the wheel group

Existing sudoers rules keep working after the join as long as the AD username equals the old local username. If the names differ, update /etc/sudoers (and any local group memberships) to reference the new identity.

The wheel group restricts who may switch to root - a common hardening requirement. Create an AD group such as rol-linux_wheel and require membership for su and sudo. In /etc/pam.d/su:

auth required pam_wheel.so use_uid group=rol-linux_wheel

And in /etc/sudoers (edit with visudo):

%rol-linux_wheel ALL=(ALL) NOPASSWD: ALL

Login access is still granted by the AD role groups in groups.allow; the wheel group only governs escalation, so do not add it to groups.allow.

Verification and Centrify troubleshooting

Three commands tell you almost everything about a join's health. Run them after any join or when logins misbehave.

adinfo - join status at a glance

Plain adinfo shows the domain, the DC you are bound to, the zone, and the agent mode:

• Joined to domain and Current DC confirm the bind.
• CentrifyDC mode: connected is what you want; disconnected means the agent cannot reach AD and is serving cached credentials.
• Licensed Features: Enabled confirms licensing.

Add --test to probe each DC's ports - LDAP 389, SMB 445, Kerberos 88, and kpasswd 464. A kpasswd 464/tcp - timeout on one DC while others pass usually points to a firewall rule, not a broken join.

adcheck - deep diagnostics

Run against the domain to validate DNS, time sync, and global-catalog reachability:

/usr/share/centrifydc/bin/adcheck -V ad.example.net

It reports host OS sanity, DNS server response times, SRV record discovery, DC functional levels, and a summary of passes, warnings, and serious issues. Read the summary line carefully: a serious issue must be fixed before joining, while warnings (for example "this machine's subnet is not known by AD" or a global-catalog port 3268 timeout to a remote DC) should be reviewed but rarely block a join.

adquery - user and group lookups

Use adquery to confirm AD is returning the identity data you expect:

• Dump a user: adquery user -j <user>
• Dump a group: adquery group -j <group>
• Get a UID or GID: adquery user --uid <user> / adquery group --gid <group>
• List a user's groups: adquery user --groups <user>
• List a group's members: adquery group --members <group>
• Help: adquery --help

Common pitfalls

• Skipping user.ignore. Join a host without listing local accounts and you can lock everyone out the moment the agent starts. Populate it first.
• Editing the wrong file. The configuration file is /etc/centrifydc/centrifydc.conf - changes to any other path are ignored.
• Forgetting hidden files in chown. Always use chown -R on the home directory and re-own dotfiles, or the user logs in to a broken shell environment.
• Clock skew. Kerberos rejects authentication if the host clock drifts more than five minutes from the DC. Keep NTP/chrony running.
• DNS pointing away from AD. If the host cannot resolve the AD domain's SRV records, the join fails. Fix the resolver or pin the AD FQDN in /etc/hosts.
• Stale cache after changes. After editing allow files or converting a user, run adreload and adflush -f so the agent sees the change.

Key Takeaways

• Centrify (now Delinea Server Suite) bridges Linux to Active Directory so users authenticate with one domain identity and a consistent UID across every host.
• Roll out in phases - install the CentrifyDC agent, pilot the join, convert users individually, then remove local accounts - to keep a clean rollback at every step.
• Protect existing local logins by listing them in user.ignore, and control access with the allow-group files in /etc/centrifydc/centrifydc.conf.
• Verify with adinfo --test, adcheck, and adquery; treat a serious adcheck issue as a blocker and warnings as review items.
• Centrify Express is discontinued and the agent is now Delinea; for a free, built-in alternative on modern Linux use SSSD with realm join.

Frequently Asked Questions

Will joining a server to Active Directory break existing local logins?

No, as long as you add every local account to /etc/centrifydc/user.ignore before the agent starts. Centrify sits in front of authentication, and any user it is told to ignore continues to authenticate locally. You then convert users to AD one at a time on your own schedule.

Why does Centrify give my user a new UID?

With auto-zone, the agent derives a stable UID from the AD object rather than reusing the local one, and that UID is identical on every joined server. That consistency is the point - it prevents ownership mismatches across NFS and migrations - but it means you must re-own the user's home directory (including dotfiles) to the new UID during conversion.

What is the difference between Centrify and SSSD/realmd?

Both join Linux to Active Directory. Centrify/Delinea is a commercial suite with centralized zone management, richer reporting, and supported legacy-UNIX coverage. SSSD with realmd is the free, open-source bridge bundled with modern RHEL and Ubuntu. For new deployments without legacy UNIX, SSSD is often enough; large estates needing central policy and audit often choose Delinea.

How do I check whether my server is properly joined?

Run adinfo and confirm it shows your domain, a current DC, and CentrifyDC mode: connected. Then run adinfo --test to confirm LDAP, SMB, and Kerberos ports respond, and adquery user --uid <you> to confirm AD is returning your identity.

For more Linux and system administration walkthroughs, subscribe on YouTube @explorenystream.