Centrify alternatives, and how we untangle Server Suite zones
The usual Centrify alternatives are connecting Server Suite to the Delinea Platform, joining Linux natively to Active Directory with SSSD, Entra ID sign-in on Azure and Arc-enabled Linux, or BeyondTrust AD Bridge. Cohash exports your zones, UID and GID maps and dzdo rights, picks a target per server group, then moves servers in tested waves.
- 01Zone export and analysis
- 02ID rationalization
- 03Target per server group
- 04Rights rebuild
- 05Pilot and waves
The story
Told without the client's name or anything that could identify them.
A financial services firm's Unix and Windows engineering team had Centrify zones designed long before anyone on the team arrived. Child zones nobody could explain, UID and GID overrides that broke file ownership whenever a server moved, and dzdo roles that had grown one ticket at a time were all still in use. Cloud-built Linux hosts didn't fit the domain-joined model, and the Server Suite session audit fed SOX evidence. We exported zones, roles, dzdo rights and ID profiles, agreed one UID and GID per person and group, and chose a target per server group: Server Suite connected in place to the Delinea Platform, or native directory join with sudo rules as code. Servers moved in waves by application owner, with login, elevation, cron jobs and service accounts tested in a pilot first.
why it was urgentIn August 2026 Delinea published guidance for Server Suite customers moving to the Delinea Platform, with deployments connected in place. Its newer Platform Agent doesn't join an Active Directory domain, but it is still in private preview and isn't offered in FedRAMP tenants. Delinea hasn't published a product-wide end-of-life date for Server Suite, only support end dates per release.
- openSomeone designed the zone hierarchy a decade ago. Nobody can tell you now what the child zones are for.
- recurringZones don't agree on UID and GID overrides, so file ownership breaks whenever a server moves.
- blockeddzdo role definitions grew one ticket at a time and nobody reviews them.
- openCloud-built Linux hosts don't fit the domain-joined zone model at all.
The estate, before and after
Before: tangled Centrify zones on every server
Servers joined Active Directory through Centrify zones with per-zone UID and GID overrides and dzdo roles. Cloud-built Linux hosts fell outside the model and were managed separately.
After: one ID map and elevation rules as code
Each server group follows a model we decided up front. It's either Server Suite connected to the Delinea Platform, or a native directory join with sudo rules. One UID and GID per identity keeps file ownership stable. Elevation policies live in version control.
How we run it, phase by phase.
5 phases take you from Centrify / Delinea Server Suite zones to Delinea Platform server PAM or native directory join. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Zone export and analysis
We export zones, computer roles, role assignments, dzdo command rights, PAM access rules and UID and GID profiles. Then we go looking for duplicate IDs, orphaned roles and servers that don't exist any more but are still listed.
- phase 02
ID rationalization
Agree one UID and GID per person and group, and map where overrides exist. Plan file ownership fixes on NFS shares and local disks before any server changes model.
- phase 03
Target per server group
We decide group by group. Keeping Server Suite and connecting it to the Delinea Platform is one option. Cloud-first Windows and Linux hosts can go to the Platform Agent once you can get it, and anything else can join natively with standard sudo rules.
- phase 04
Rights rebuild
We rewrite dzdo rights as platform elevation policies or sudo rules kept as code, and turn on MFA for elevation wherever the target supports it. Rights that went unused during the review period don't make the trip.
- phase 05
Pilot and waves
Move a pilot group, test login, elevation, cron jobs and service accounts, then migrate by application owner. Remove the old agent only after each wave signs off.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
One UID and GID per person and group
Before a single server changed model, we mapped every conflicting override and fixed ownership on NFS shares and local disks. Now a move doesn't cost anyone access to their files or jobs.
- result 02
Elevation rights are code that gets reviewed
We rewrote dzdo rights as platform elevation policies or sudo rules, kept in version control. Elevation needs MFA where the target supports it. Rights nobody used during the review period were dropped.
- result 03
Each server group has a decided target
Each group's target is written down: connected Server Suite, native directory join or a later Platform Agent move. Where the plan relied on a preview feature, there's a fallback.
- result 04
Session audit evidence kept flowing
The replacement model kept turning out session records for auditors from the first wave on, so there was no gap in SOX or PCI evidence.
- result 05
Service accounts were found before they failed
In each wave we listed and tested the zone-mapped AD accounts applications use, and the cron jobs, before the old agent came off.
Risks we plan for
-
File ownership breaks
A changed UID means a user locked out of their own files and jobs that fail. We fix ID mapping first, before touching agents.
-
Service accounts in zones
Applications often run as zone-mapped AD accounts. Each one is found and tested, or a batch job fails on its first night.
-
Preview features in the plan
The Platform Agent is private preview today. A design that depends on it needs a fallback and a check with Delinea before the date is fixed.
-
Auditors expect session records
Server Suite is often where the SOX or PCI session audit evidence comes from. Whatever replaces it has to keep producing that evidence from day one.
Where AI helps, and where it needs guardrails
Delinea's August 2026 guidance lets Server Suite audit run on the platform, where Iris AI summaries flag risky moments in recordings. We check those summaries against recordings your team has already been through. When an AI agent runs commands on servers, we give it its own identity and least-privilege elevation rules instead of someone's dzdo role. We record its sessions the way we'd record any admin's.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- document01
An export of zones, roles and UIDs and GIDs, with the conflicts flagged
yours to keep - inventory02
An ID mapping plan, plus the file ownership fixes you'll need on each share
yours to keep - design03
Target model decision per server group
yours to keep - report04
Elevation policies or sudo rules kept in version control, so every change gets a review
yours to keep - tests05
A wave plan that tests login, elevation and jobs for each application before it moves
yours to keep
Platforms and services on this move
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Rules
- The JavaScript snippets Auth0 used to run at login. Someone would write one to add a role to the token or block a sign-in, and each one ran after the last.in context →
- 02PAM
- PAM is privileged access management: the vault for admin and service account passwords, which also rotates them and checks who's asking.in context →
- 03Wave
- One batch of workloads moved together. Large migrations run as a series of these, so each one can be planned, cut over and reviewed on its own.in context →
- 04MFA
- Multi-factor authentication. On top of the password you prove it's you a second way, usually with an app prompt or a security key.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01What are the main alternatives to Centrify?
Four come up. Connect Server Suite to the Delinea Platform and keep enforcement where it is. Join Linux directly to Active Directory with SSSD and realmd. Use Entra ID sign-in on Azure VMs and Arc-enabled servers. Or move to BeyondTrust AD Bridge, which also brings Active Directory login and Group Policy to Unix and Linux. Choose per server group, since cloud hosts and old Unix boxes rarely want the same answer.
02What happens to UIDs if we leave Centrify for SSSD?
They can change, and that's where file ownership breaks. By default SSSD generates UIDs and GIDs from each user's AD SID and ignores any uidNumber and gidNumber held in AD. If AD already holds the IDs you want, join with automatic ID mapping turned off, then check a test user with getent passwd before any wave starts.
03Does Entra ID replace dzdo on Linux?
Only roughly. Someone with the Virtual Machine Administrator Login role can run sudo with no further prompt, and someone with the User Login role can't run sudo at all. If your auditors expect command-by-command rights like dzdo gives you, work out how you'll cover that gap before you commit.
04Is Server Suite being retired?
We found no product-wide end-of-life date as of 6 November 2026, only support end dates per release. But Delinea is steering customers to the Delinea Platform, so get the support commitment from your account team in writing before you plan a long stay.
05How long does a zone cleanup take?
That depends on how many zones you have, how many UID overrides exist, and how many applications run under zone-mapped accounts. We'll know by the end of the first phase, from the export and the ID analysis.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyMoving Auth0 Rules and Hooks to Actions before Auth0 switches them off
Moving Auth0 Rules and Hooks to Actions before Hooks stop on 30 April 2027 and Rules on 31 January 2028, with token claims checked before and after each change.
read the case studye70d6e4a - 01Book a 30-minute working sessionsenior engineer
- 02Talk to an engineer about your setupreply within 24 hours
- 03See how similar projects wentcase studies
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it