We're a 200-person shop with a mix of on-prem AD, Azure AD, and AWS/GCP cloud apps. Our current setup is a patchwork of scripts and manual provisioning that's breaking down.
We need to replace it. Okta is the obvious name, but I'm skeptical of "obvious." I need to know if it actually works in a complex hybrid environment, not just in a sales demo.
Key requirements we have:
* Real, reliable synchronization between on-prem AD and the cloud directory. Not just one-way.
* Seamless SSO for both SaaS apps *and* legacy on-prem web apps (through a reverse proxy or similar).
* Automated deprovisioning that actually works across all connected systems.
* Transparent pricing without gotchas for hybrid features.
If you run a similar setup, tell me:
* What breaks first with Okta in a hybrid scenario?
* Is the Universal Directory actually universal, or do we end up with sync gaps?
* How much ongoing maintenance does the AD integration require?
* Any hidden costs for the hybrid connectors or required on-prem servers?
Just the facts.
Trust but verify.
We went with Okta a year ago with a similar setup. The main thing that broke for us was the AD agent. It's this Java service you run on-prem, and it can be fussy with firewalls or if your AD schema is non-standard. When it hangs, your sync just stops.
The Universal Directory does work, but you have to be meticulous with your mapping rules. We had a few gaps where custom attributes from on-prem just wouldn't flow to some cloud apps. It took support tickets to sort out.
Ongoing maintenance is maybe an hour a week checking the dashboard and agent health. The hidden cost wasn't the connector itself, but needing a dedicated Windows server (or two for HA) just to run it reliably. That's extra infra and patching.
How do you handle your on-prem app SSO? We're using the Okta Access Gateway and it's been okay, but I've heard others use a different reverse proxy.
Yeah, the Java-based AD agent is a known weak link. We moved away from it entirely and use Okta's SCIM APIs with a small custom service that pulls from AD via LDAP. It's more code to manage, but it doesn't randomly hang. The agent was a black box we couldn't debug.
For on-prem app SSO, we skipped the Access Gateway. We run an OIDC-capable reverse proxy (like Pomerium or OAuth2 Proxy) in front of the legacy apps. It talks to Okta as the identity provider. One less vendor-specific component to worry about, and we can deploy it in k8s alongside the apps.
The hidden server cost for the agent is real. If you're already running a Windows fleet, maybe it's fine. But if you're not, it's an architectural tax.
Automate everything. Twice.
Oh the agent. We hit the same exact issue. The "hour a week" to check on it became more like a few hours when it would fail silently mid-sync. We had to set up aggressive external monitoring just for that Java service.
Agree on the mapping rules! It feels like you're configuring it twice - once in AD, once in Okta. We still have one HR system that gets custom attributes through a scheduled CSV export because the flow just wouldn't stick.
We also skipped the Access Gateway. Using a simple OIDC proxy (we picked Traefik with the forward auth plugin) for our on-prem legacy intranet apps. One less vendor piece, and we already knew the proxy. Does the Gateway add anything you actually need?
Let's build better workflows.
The AD agent is absolutely the first point of failure. It's a resource hog that fails open, so sync just stops without clear alarms. We had to wrap it with a custom watchdog script that pokes the health endpoint and restarts the service.
On "universal," you'll find gaps with multi-valued AD attributes or any custom objectClass. The sync is universal for standard user fields, but the moment you need to push a department code or custom ID to a SaaS app like Salesforce, you're writing a transform in the provisioning rules. It's another layer of mapping logic to maintain.
For hidden costs, budget for the Windows Server CALs and the operational overhead of maintaining that VM. The agent itself is "free," but the server it demands is not. You also might need to scale up your AD schema admins' involvement, as every sync quirk requires digging into ADSIedit to validate source data.
Extract, transform, trust