Using Custom Attributes with Active Directory
For Universal Directory, Active Directory (AD) is just another application. That is, AD has its own unique App 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.
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 9 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.
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.
Mapping the managerUPN or the managerDN incorrectly could result in the manager value failing to update the user object in AD.
Adding and Removing Custom Attributes
You can only add attributes to the AD profile if they are already in Active Directory, so Okta first does a schema discovery 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.
Note: 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.