Universal Directory custom user types known issues

These are the known issues for custom Universal Directory user types:

  • Imported new users are restricted to the default Okta user type.
  • User type (variable name userType) is one of the 31 attributes in the Okta Base schema. The User type attribute is unrelated to the custom user types feature.
  • You cannot have two different user types using the same attribute name but with different data types. The data types must match.

  • Only the default Okta user type mapping set on application sign in pages is updated during imports and outbound provisioning.

  • Unlike property mappings, SAML assertion mappings are not type aware. Okta uses the default user type in all such cases.
    • Validation to ensure only authorized admins can edit SAML assertions using sensitive attributes does not account for non-default user types (whose sensitive properties may differ from the default type).
    • Properties used in an assertion that only exist for non-default-type users will not have this check applied.
    • Sensitive attributes —Properties that are sensitive in the default type, but are not sensitive in some non-default types, will always be treated as sensitive.
    • When validating the SAML username EL, Okta considers only how the properties are defined in the default user type, even though custom types may define the properties differently.
  • Group Membership rules validate the rule only against the default type. This is the case whether you use the preset conditions in the UI or the "Okta Expression language" option. In either case, if the expression is not valid for the default type, for example because it references a property that exists only in a custom user type, then the rule can be neither saved nor previewed (even if the user being previewed is of the custom type). If the rule references a property that exists only for the default type and not the custom type, then when it is evaluated for a custom user (for previewing or for determining group memberships) the expression will treat the property as having a value of null.

    • Group Rules are not executed for non-default user types.

  • Group App assignments are validated against the default User Type. A Group App assignment involving a attribute that is not consistent across multiple User Types will be validated against the default User Type.
  • Users imported from Active Directory which partial match with existing custom type Okta users can only use User Principal Name (UPN) as Okta username format. When an admin selects a different Okta username format such as email, sAMAccountName, or other custom appuser properties, the AD property mapping for "login" field is supposed to be changed, but it currently only updates the mapping for the default Okta user type.

    • The AD settings page allows you to set the Okta login during import flow and AD userName during outbound provisioning flow for the user. In both cases, currently those mappings from this UI would be updated only for the default Okta user type.

  • The LDAP settings page allows you to set the Okta login during import flow and AD userName during outbound provisioning flow for the user. In both cases, currently those mappings from this UI would be updated only for the default Okta user type.

    • In the LDAP provisioning settings page UI, the section "Okta Attribute Mappings" defines only the mapping between LDAP and the default Okta user profile. In other words, if any of the attribute mappings in this section is updated, it's only reflected in the mapping between the app user profile and the default Okta user profile. If you need to make changes to the mapping between the app user profile and a custom Okta user profile, you need to make such changes in the Profile Editor.

    Provisioning settings also do validation if RDN is a valid attribute and that check happens only against the default User Type.

  • Okta username format— Similar to Active Directory import, if the admin changes "Okta username format" on the LDAP import settings page, the change only applies to the mapping from LDAP to the default Okta user type.
  • When using the Identity Providers feature, either for IdP Routing Rules or inbound federation, Okta user properties will be interpreted (to determine whether they exist, whether they contain sensitive data, and so on) based only on the default user type. To avoid unintended behavior, be sure that any properties used in IdP policies are configured the same way in all user types.
  • For inbound federation:
    • JIT users are created with the default type.
    • When setting up a User Match for inbound federation, the configuration only lists or validates properties in the default type, but matching will be attempted using the actual User Type.
    • Mappings are set up automatically from the IdP user or App user to the default type but not any custom types, so unless mappings are manually created nothing will be mapped for those users.
  • If Okta detects new app templates for either O365 or Sharepoint, existing instances of the app are updated. These automatic updates are currently performed only for app instances associated with the default User Type. If a non-default User Type is assigned O365 or Sharepoint, changes to the templates for those apps will not be applied to those app instances.