Identity Integration After a 30-Day Acquisition Cutover
Helio Systems acquires a 300-person analytics firm. The parent has 2,400 employees and 180 contractors using Okta and Microsoft 365; the acquired firm uses on-premises Active Directory and a line-of-business application that only supports LDAP simple bind to a single directory. The deal requires a 30-day cutover to the parent identity provider for email and SSO. The acquired firm has 12 domain admins, shared local admin passwords, and no MFA on VPN. Contractors at the parent must use phishing-resistant MFA, and privileged access must be time-bound. The acquired firm’s application vendor says LDAP over TLS and a service account are the only supported integration; a rewrite is 9 months away.
1. What identity integration pattern should you choose for the 30-day cutover, and why?
Read the worked answer
I would not attempt a full directory merge in 30 days. A safer pattern is to keep the acquired firm’s Active Directory as an authoritative source for its users but federate authentication to the parent Okta tenant, or use a controlled migration wave for email and SSO while preserving a separate tenant boundary temporarily. A full migration risks UPN collisions, duplicate accounts, broken distribution lists, and loss of access during the cutover. Federation lets the parent enforce MFA and conditional access without flattening every legacy object immediately. I would migrate high-risk privileged accounts first, then standard users in waves, with rollback tested. The decision should be driven by the 30-day constraint and the need to preserve auditability, not by a desire for a single clean directory on day one.
2. How should privileged access and contractor access be secured during the transition?
Read the worked answer
I would inventory the 12 domain admins and remove standing domain-admin rights wherever possible, replacing them with time-bound elevation through a privileged access management workflow. Shared local admin passwords must be rotated immediately and moved into a vault with checkout and logging. For contractors, I would enforce the parent’s phishing-resistant MFA requirement at the federation layer, use conditional access based on device compliance and location, and set account expiry dates. VPN access should require MFA before the cutover, not after, because the acquired firm currently has none. I would create two break-glass accounts stored offline, excluded from normal workflows, with alerting on use. The goal is to reduce standing privilege while the directory boundaries are still being sorted out.
3. How can the legacy LDAP simple-bind application be integrated without weakening the parent’s identity controls?
Read the worked answer
I would avoid giving the application direct broad LDAP access to the parent directory. Instead, place a directory proxy or virtual directory in front of the legacy application, expose only the required attributes and user subset, enforce LDAP over TLS, and restrict network access to the application hosts. The service account should be vaulted, rotated, and monitored for anomalous bind patterns. If simple bind is unavoidable, I would require a long random credential, limit source IPs, and alert on failed and unusual successful binds. The application remains an exception with a documented nine-month rewrite plan and a compensating control of network isolation plus attribute minimisation. This preserves functionality without allowing a weak legacy protocol to become a path into the parent’s full directory.