<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
An Updated AD Attribute is Not Being Pushed to an Application that has Provisioning and Update User Attributes Enabled in Okta
Lifecycle Management
Okta Classic Engine
Directories
Overview

Okta is not pushing an updated Active Directory (AD) attribute value to a downstream application (for example, Office 365 or ServiceNow). 

Applies To
  • Active Directory Sourced Users
  • Active Directory (AD)
  • Mappings
  • Universal Directory
  • Okta Classic Engine
Cause

The application attribute mapping is set to use the default expression:

hasDirectoryUser()?findDirectoryUser


This expression can successfully create attribute values when Okta provisions a new user object in the downstream application. However, updates to the AD user object will not trigger an application profile update task when this expression is in use.

Solution

Replace the default attribute mapping expression with a strategy that maps from Active Directory > Okta and Okta > Application by performing the following steps:

  1. If there is currently no Okta attribute that corresponds to the AD attribute (for example, ProxyAddresses, ManagerID), create a matching custom attribute in Okta (please refer to the Add Custom Attributes to a user profile for details).
  2. Map the Active Directory attribute to the corresponding Okta attribute (please refer to View existing application attribute mapping for additional details).
  3. Map the Okta attribute to the Application attribute.

 

If the solution presented above is not practical in some situations, always syncing at least one attribute from AD to the Okta profile for each user ensures that the remaining attributes are also evaluated. In Active Directory, the "whenChanged" attribute indicates when the user was last updated. For example, let's say that we update an extension attribute in AD. This, in consequence, will update "whenChanged" with the date/time of when the extension attribute has been changed. On the next import, we will have two attribute updates on the user's AD profile: an extension attribute and "whenChanged". This update to the user's application profile will not trigger automatic updates. If we map "whenChanged" to an Okta attribute, the update to the Okta profile will also evaluate the other attributes from the AD user's profile. "whenChanged" is great for this role, as it will always update when there is a change made to the user in AD. 

Related References

Loading
An Updated AD Attribute is Not Being Pushed to an Application that has Provisioning and Update User Attributes Enabled in Okta