Two-Forest AD Integration with a 5-Minute Deprovisioning SLA
A 4,800-employee manufacturer runs two Active Directory forests: CORP with 3,600 users and PLANT with 1,200 users, joined by a two-way forest trust. Okta is already the IdP for 14 OIN applications, and Workday is the authoritative source for job title, department, and manager. The company wants AD credentials to remain authoritative for Windows desktop sign-in, while Okta owns MFA and application access. One Okta AD agent runs on a single server in CORP. PLANT users can sign in to Okta, but password changes made in PLANT do not flow, and 90 days after go-live 37 users have duplicate Okta profiles with stale department values. Security requires that disabling a user in AD blocks application access within 5 minutes. The current design uses delegated authentication, and the team cannot explain why a disabled PLANT user still accessed an OIN app 40 minutes later.
1. Recommend the AD integration mode, agent placement, and profile mastering priorities. Justify each choice against the 5-minute deprovisioning requirement.
Read the worked answer
Use password sync rather than delegated authentication. Delegated authentication only validates a password against AD at sign-in; it gives Okta no reliable user-status signal, so an AD disable does not immediately become an Okta deactivation. Password sync gives Okta a credential to validate and lets Okta enforce MFA and app policy independently of the AD agent's availability.
Place at least one AD agent in each forest/domain, sized for redundancy, with service accounts that can read the required OUs. A single CORP agent explains why PLANT password changes do not flow and creates a single point of failure.
Set mastering deliberately: Workday masters department, manager, and job title; AD masters the login credential and enabled/disabled status; Okta masters Okta-only attributes. Do not let AD overwrite department just because AD is the credential source.
For the 5-minute SLA, do not promise it from the AD agent alone. Okta AD imports are scheduled, not event-driven. Set the incremental import as low as the agent supports, then add a compensating control: an event-driven workflow that calls the Okta API when AD emits a disable event, or an application session lifetime of 5 minutes or less. Validate with a test user in PLANT and check the System Log for the deactivation event timestamp.
2. Explain why the 37 duplicate profiles and stale department values exist, and what matching and mastering rules you would change.
Read the worked answer
The duplicates are almost certainly a matching failure, not a UI problem. The same person is being imported from both forests with different samAccountName or UPN values. If Okta matches on username or email, the PLANT record looks like a new user. The stale department values come from multiple masters writing the same attribute without a clear priority.
Change the AD integration matching rule to a truly immutable attribute, preferably employeeNumber, and make it required for both forests. Do not use email or display name as the join key. Before changing the rule, export the 37 affected pairs, identify the authoritative record, and link or merge duplicates rather than deleting blindly. Preserve the Okta user ID that applications already reference.
For mastering, set Workday as the priority source for department, manager, and title. Set AD as the priority source for password and status. If PLANT has no employeeNumber today, add it to the HR feed before re-running the import. Then run a full import and verify that a department change in Workday wins over an AD value, while a password change in PLANT still flows to Okta.
3. Design the MFA rollout for PLANT users, many of whom share Windows workstations and do not have company-issued phones.
Read the worked answer
Separate the authenticator enrollment policy from the application sign-on policy. In the enrollment policy, offer Okta Verify and FIDO2/WebAuthn security keys, and use a phased grace period so users are not locked out on day one. Do not enable SMS as the primary factor for shared-workstation users; it is weak and creates helpdesk load.
For shared Windows workstations, do not assign one security key to a whole station. A shared key destroys user attribution and lets one person act as another. Issue individual FIDO2 keys to users who cannot use a personal phone, and require them to remove and reinsert the key at each shift. If the plant has smart cards or PIV badges, evaluate certificate-based authentication as an alternative. For users with BYOD phones, allow Okta Verify with a clear acceptable-use policy.
Pilot with one PLANT shift and one CORP group. Exclude service accounts, kiosk accounts, and test accounts from the MFA requirement. Monitor enrollment failures in the System Log, and give the helpdesk a documented reset procedure. Only after the pilot should the app sign-on policy require MFA for the PLANT group.