Active Directory attribute mappings to Okta properties
The following table shows how Okta properties are mapped to corresponding Active Directory (AD) attributes.
Native Active Directory attribute: This is the name of the attribute in AD.
Attribute assigned to the AD app by Okta: This is the name Okta uses to call native AD attributes when AD is set up as an app within Okta. This value appears in the app user profile.
Native Okta attribute: This is the native Okta attribute name.
Required by Okta: Okta requires certain base attributes in an Okta user profile. Yes indicates the attribute is required by Okta. See Profile types.
Mapping Direction AD to Okta: Indicates whether there is a corresponding Okta property for the AD attribute.
Mapping Direction Okta to AD: Indicates whether there is a corresponding AD attribute for the Okta property.
|
Native Active Directory attribute |
Attribute assigned to AD by Okta |
Native Okta attribute |
Required by Okta |
Mapping: AD to Okta |
Mapping: Okta to AD | Notes |
|---|---|---|---|---|---|---|
| distinguishedName | dn | dn | Yes | Yes | Yes | |
| givenName | firstName | firstName | Yes | Yes | Yes | |
| Yes | Yes | Yes | ||||
| objectGUID | externalId | externalId | Yes | Yes | Yes | |
| objectSid | objectSid | objectSid | Yes | Yes | Yes | |
| primaryGroupID | primaryGroupID | primaryGroupID | Yes | Yes | Yes | |
| userPrincipalName* | userName | userName, email, login | Yes | No | Yes |
Used only if email is not set. Available as one of the choices for the Okta username preference, along with email, UPN, and sAMAccountName. If selected, the Okta username is generated by combining the sAMAccountName with the AD domain name (naming context) to form an email-like value. |
| sn | lastName | lastName | Yes | Yes | Yes | |
| sAMAccountName | sAMAccountName | substringBefore(user.login, \"@\") | No | No | Yes | |
| c | countryCode | countryCode | No | Yes | Yes | |
| cn | cn | user.firstName + \" \" + user.lastName | No | No | Yes | |
| co | co | co | No | Yes | Yes | |
| countryCode | adCountryCode | countryCode | No | Yes | Yes | |
| department | department | department | No | Yes | Yes | |
| departmentNumber | departmentNumber | departmentNumber | No | Yes | Yes | |
| displayName | displayName | displayName | No | Yes | Yes | |
| division | division | division | No | Yes | Yes | |
| employeeID | employeeID | employeeID | No | Yes | Yes | |
| employeeNumber | employeeNumber | employeeNumber | No | Yes | Yes | |
| generationQualifier | honorificPrefix | honorificPrefix | No | Yes | Yes | |
| l | city | city | No | Yes | Yes | |
| managerDN | managerDN | managerDN | No |
If you have manager value coming from Workday or any other app into Okta and that value can be represented as mangerDN in AD, use the managerDn mapping. In this case the manager can be in different domain than the user. |
||
| managerUPN | managerUpn | managerUpn | No | Yes | Yes |
If you have manager value coming from Workday or any other application into Okta and that value can be represented as managerUPN in AD, use the managerUpn mapping. In this case, the manager must be in same domain as the user. |
| middleName | middleName | middleName | No | Yes | Yes | |
| mobile | mobilePhone | mobilePhone | No | Yes | Yes | |
| personalTitle | honorificSuffix | honorificSuffix | No | Yes | Yes | |
| postalCode | postalCode | zipCode | No | Yes | Yes | |
| preferredLanguage | preferredLanguage | preferredLanguage | No | Yes | Yes | |
| st | state | state | No | Yes | Yes | |
| streetAddress | streetAddress | streetAddress | No | Yes | Yes | |
| telephoneNumber | telephoneNumber | telephoneNumber | No | Yes | Yes | |
| title | title | title | No | Yes | Yes |
-
Note that AD app user profile schema requires first and last name unlike the Okta user profile, which is optional. So you can create an Okta sourced user without first or last name but you can't import an AD user into Okta without first and last name today.
- If any AD attribute that is required by Okta is missing in a user's profile, the user is ignored. The exception is the Okta email attribute which is required. If the AD user object's email attribute is not populated, it will be populated by the userPrincipalName value.
- If the isCriticalSystemObject attribute is set to true, the user is omitted. This setting is mostly for internal accounts used by the system, but also includes various built-in accounts like Administrator.
- If a custom attribute is marked as required in Profile Editor (that is, Attribute required is selected in the Add Attribute dialog), and no corresponding field exists in the user's AD profile, the user is deprovisioned during the next import or, if JIT is enabled, the next time the user logs in.
- Mapping the managerUPN or the managerDN incorrectly could result in the manager value failing to update the user object in AD.
- If you have manager value coming from Workday or any other application into Okta and that value can be represented as managerUPN in AD, use the managerUpn mapping. In this case, the manager must be in same domain as the user.
- If you have manager value coming from Workday or any other app into Okta and that value can be represented as managerDN in AD, use the managerDn mapping. In this case the manager can be in different domain than the user.
The system treats previously imported users as deleted if any of the following conditions are met:
-
The userAccountControl attribute indicates that the user has been deactivated. (Detected by incremental import or JIT sign in.)
-
The user no longer exists in the directory. (Only detected by a full import.)
If this occurs, the corresponding Okta user (if any) is deactivated. Users are also deactivated if the user goes out of OU selection during the next full import.