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 About 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
mail email email 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.