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 Active Directory.

Attribute assigned to the AD appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. by Okta — This is the name Okta uses to call native AD attributes when Active Directory 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. For details, see The Okta User Profile

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 the AD app by Okta

Native

Okta attribute

Required by Okta?

Mapping Direction

AD to Okta

Mapping Direction Okta to AD Note
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 Only used 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 domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https). 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  
description description description 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  
facsimileTelephoneNumber facsimileTelephoneNumber facsimileTelephoneNumber 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. When doing so, 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  
physicalDeliveryOfficeName deliveryOffice deliveryOffice 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 mastered 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. When doing so, 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 mangerDN in AD, use the managerDn mapping. In this case the manager can be in different domain than the user.

The system treats previously imported usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control. 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 OUAn acronym of Organizational Unit. Organizational units are Active Directory containers into which you can place users, groups, computers, and other organizational units. It is the smallest scope or unit to which you can assign Group Policy settings or delegate administrative authority. selection during the next full import.

Top