Implementing Okta in various environments
Implementing Okta in Various Environments
This domain tests whether you can place Okta correctly among existing directories, identity providers, and network boundaries. Expect scenarios involving Active Directory, LDAP, multiple Okta orgs, on-premises apps, and sandbox-to-production promotion.
Core rules and concepts
- Okta Universal Directory is the central profile store. Each attribute has one profile master; source priority determines which value wins when multiple sources write.
- The AD and LDAP agents handle import, matching, password sync (AD only), and group push. Agents should be redundant and placed close to the directory.
- Use group rules for dynamic membership, but avoid circular dependencies with app assignments.
- Org2Org links separate Okta tenants; Access Gateway publishes internal apps without inbound firewall holes.
- Run changes in a preview or sandbox org, then promote configuration; do not test new agents directly in production.
Worked example
A company masters employee attributes in AD but contractors in Okta. It needs both groups to access Salesforce. Set AD as master for employee attributes such as department and manager; keep Okta as master for contractor fields. Match imported AD users by objectGUID or sAMAccountName, not email, to survive address changes. Build a group rule for contractors and assign the Salesforce app to both groups. Verify in preview that an AD user's department change overwrites Okta, while a contractor's Okta-managed title persists.
Traps
Do not enable password sync before confirming agent permissions and AD password policy. Profile mastering conflicts look like random overwrites. Deleting a source does not always deprovision the Okta user; check lifecycle and deactivation rules. Group push is one-way and does not replace directory import.