Active Directory attribute mappings to Okta properties
The following table shows how Okta properties are mapped to corresponding Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. (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
to the AD app by Okta
|Required by Okta?||
AD to Okta
|Mapping Direction Okta to AD||Note|
|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.
|cn||cn||user.firstName + \" \" + user.lastName||No||No||Yes|
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.
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.
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
isCriticalSystemObjectattribute 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 users as deleted if any of the following conditions are met:
userAccountControlattribute 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