Unable to Search Active Directory-Sourced Users in Okta by Null user.locale Value

When Okta imports a user from Active Directory (AD) as a profile source without a mapping for the user.locale attribute, Okta defaults the value to en_US. Although the attribute displays as empty on the Admin Console and returns as null in the Okta LDAP Interface (LDAPi) and the Okta API, Okta does not evaluate the attribute as null. To resolve this, map an existing or custom AD attribute to the user.locale attribute using the Okta Expression Language (OEL).

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Active Directory (AD)
• user.locale
• Okta Expression Language (OEL)

Okta automatically defaults the user.locale attribute for an AD-sourced user to en_US if no data is imported or entered. The user profile page, the Okta LDAPi, and the Okta API all show the attribute as empty or null. An OEL conditional expression for user.locale in a downstream profile mapping does not evaluate as true.

The user profile page displays an empty locale attribute for the user.

An OEL conditional expression that evaluates whether the user attribute is null or empty confirms that the value is not null.

How is the user.locale attribute mapped for Active Directory-sourced users?

The Okta user attribute user.locale value is a concatenation of the ISO 639-1 two-letter language code, an underscore, and the ISO 3166-1 two-letter country code. For example, en_US specifies the language English and country US.

Active Directory does not contain a locale attribute, but other attributes exist that provide the necessary information to create an OEL expression in the attribute mapping of user.locale.

Populate part of the user.locale attribute by mapping the co attribute and logically inferring the remaining portion.

Map a custom, populated Active Directory attribute directly to the user.locale attribute.