Using Custom Attributes with Active Directory
For Universal DirectoryUniversal Directory enables you to store an unlimited amount of users and attributes from applications and sources like AD or HR systems. Any type of attributes are supported including linked-objects, sensitive attributes, and pre-defines lists. All of it accessible by all apps in our OIN catalog, over LDAP or via API., 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) is just another application. That is, AD has its own unique 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. User Profile within Okta. You can view user profiles for directories in Directory > Profile Editor.
Profile Editor gives admins complete control over the AD app profile for a user. Admins can add and remove attributes from the profile, customize attribute mappings, and perform data transformations within the inbound or outbound flows.
- Navigate to Directory > Profile Editor.
- Click Profile in the Actions column for the directory you want to update.
- Click Add Attribute.
- In the Pick Schema Attributes window, select the attributes you want to add.
- To remove a custom attribute, find it in the Profile window and then click X to delete it.
You can only add attributes to the AD profile if they are already in Active Directory, so Okta first does a schema discoveryAbility to import additional attributes to Okta step to populate the attribute picker. For Okta to discover the attribute, it must be added to an object within the User object hierarchy in AD. That is, the attribute has to be added to either the user object, a parent object, or an auxiliary object in order to be discovered during this process.
Executing schema discovery takes a few seconds. When finished you are provided with a list of the attributes that Okta is permitted to discover in AD.
Back-linked attributes, such as memberOf are computed attributes and are not actually stored in your Active Directory database. As a result, Okta will not see changes to the user object and perform an import operation when these changes occur. It is recommended not to use computed attributes as mapped attributes into Okta, especially if you require changes in downstream systems as a result of a change in the attribute. This may lead to inconsistent data between your on-premises Active Directory and Universal Directory. More information is available from https://msdn.microsoft.com/en-us/library/cc223384.aspx
For information on the default attribute mappings, refer to Active Directory attribute mapping.
There is a distinction between base and custom attributes. For AD, only 10 attributes are considered base. This means that for Okta, a minimum AD profile contains only 10 attributes. Every attribute outside of the 10-field base profile is considered custom. Some of these custom attributes were previously part of the static profile, but now with UD, you can remove them.
|Display Name||Variable Name||Data Type|
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 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). 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.
Mapping the managerUPN or the managerDN incorrectly could result in the manager value failing to update the user object in AD.