When an Okta user is imported from Active Directory (AD) as its profile source, if no mapping is set for the Okta user attribute locale (user.locale), the attribute will display as empty on the Admin dashboard and return as null in the Okta LDAP Interface (LDAPi) and the Okta API. However, for these AD-sourced users, the Okta attribute will not be evaluated as null, even when Okta shows no value for the attribute.

• Active Directory
• user.locale
• en_US
• Okta Expression Language (OEL)

Okta automatically defaults the locale attribute for an AD-sourced user to en_US if no data was imported or entered. The user profile page, the Okta LDAPi, and the Okta API will all show the attribute as empty or null.

This can be shown by using the Okta Expression Language (OEL). An OEL conditional expression for locale in a downstream profile mapping will not be evaluated as true.

An example user with no entry for locale:

An OEL conditional expression to evaluate whether the user attribute is null or empty:

The Okta user attribute locale must conform to the commonly accepted standard of language and country, outlined in the ISO 639-1 (Alpha-2) code standard for language abbreviations and the ISO 3166-1 (Alpha-2) code standard for country abbreviations and connected by an underscore. Example: en_US

In AD, there is no locale attribute, though attributes do exist that can provide the necessary information to create an OEL expression in the attribute mapping of user.locale.

For example, the co attribute could be used to populate part of the user.locale attribute. The other piece of the attribute could be logically inferred:

Likewise, a custom AD attribute may be used: