Okta’s AD/LDAP integration doesn’t just push users to Okta; it actively pulls changes from Active Directory, making AD the single source of truth.
Let’s see this in action. Imagine you have an Active Directory user, johndoe, who is already synced to Okta.
First, check AD:
Get-ADUser jdoe -Properties sAMAccountName,givenName,sn,mail,userPrincipalName,description
This might show:
sAMAccountName : jdoe
givenName : John
sn : Doe
mail : john.doe@example.com
userPrincipalName : jdoe@example.local
description : Marketing Department
Now, in Okta, if you look up jdoe, you’ll see a matching user profile with these attributes populated.
If you were to change jdoe’s description in AD to Sales Department:
Set-ADUser jdoe -Description "Sales Department"
And then trigger an Okta AD agent import (or wait for the scheduled import), the jdoe user in Okta would automatically update its "Description" field. No manual creation or update needed in Okta.
Okta’s AD/LDAP integration works by installing an agent on a server that can communicate with your Active Directory domain controllers. This agent periodically queries AD for changes (new users, modified attributes, deleted users) and then communicates those changes to the Okta service. The core mechanism is an "import" process where the agent reads from AD and an "export" process where Okta can push certain attributes back to AD (though for user provisioning, AD is typically the source of truth).
The agent uses standard LDAP protocols to query Active Directory. It’s configured with credentials and an LDAP base DN to know where to start looking for users and groups. The import process is highly configurable. You define which Organizational Units (OUs) to scan, what attributes to map from AD to Okta, and what rules to apply for user provisioning and deprovisioning. For example, you can set up a rule to only import users whose description attribute contains "Okta Enabled".
The real power comes from the bi-directional potential, even if AD is usually the source of truth for core user data. Okta can provision new users to AD, update certain attributes (like password changes initiated in Okta), and deactivate/delete users in AD based on Okta policies. This is managed through "Provisioning" settings within the AD/LDAP application in Okta. You’ll see options like "Create Users," "Update User Attributes," and "Deactivate Users." When enabled, Okta’s agent will translate these actions into AD LDAP operations. For instance, deactivating a user in Okta might result in the agent setting the userAccountControl attribute in AD to ACCOUNTDISABLE (value 2).
The "Sync Users from Active Directory" feature primarily refers to the import process, where Okta acts as a consumer of AD data. The agent is configured with a schedule to poll AD for changes. During an import, the agent compares the current state of AD with the state it last saw. It identifies:
- New Users: Users present in AD but not in Okta.
- Modified Users: Users present in both AD and Okta, where attributes have changed.
- Unchanged Users: Users present in both without modifications.
- Deleted Users: Users that were in Okta (and previously in AD) but are no longer found in the configured AD OUs.
The agent then sends a delta of these changes to Okta. Okta processes these changes based on your application’s configuration, creating, updating, or marking users for deactivation.
The most surprising thing about this integration is how granularly you can control the import process, especially with regards to filtering and attribute transformations. It’s not just a simple dump; you can define complex LDAP filters that go beyond just OUs. For example, you can import only users where the extensionAttribute1 is set to IMPORT_TO_OKTA and userAccountControl does not have the ACCOUNTDISABLE bit set. This allows for a phased rollout or selective syncing of specific user populations without modifying AD group memberships.
When configuring attribute mappings, you don’t just map mail to email. You can also apply transformations. For instance, if your AD givenName is "John" and sn is "Doe", but you want the Okta displayName to be "Doe, John", you can configure a transformation like "{sn}, {givenName}". This means Okta is intelligently constructing attributes based on AD data, not just mirroring it.
The key to reliable syncing is ensuring the Okta AD agent has consistent network access to your domain controllers and that the service account it runs under has sufficient read permissions across the OUs you’ve configured for import. If the agent can’t reach AD, or if permissions are too restrictive, imports will fail, and Okta will not reflect the latest state of your directory.
Once users are imported and managed by Okta, the next logical step is to integrate them into applications.