Universal Directory custom user types known issues

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

  • Newly imported 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 can't have two different user types with the same attribute name but different data types. The data types must match.

  • Only the default Okta user type mapping set on an application sign-in page are updated during imports and outbound provisioning. If you use a custom user type, the username associated with the application isn't updated.

  • If Self-Service Registration is enabled in an org, all users in the org have their login IDs forcibly mapped to match their email addresses. Forced mapping applies to all User Types in that org.
  • Unlike property mappings, SAML assertion mappings aren't type-aware. Okta uses the default user type for all SAML assertion mappings.

    • Okta validates each SAML assertion to ensure that only authorized admins can edit sensitive attributes. This doesn't include non-default user types whose sensitive properties may differ from the default type.

    • Properties used in an assertion that only exists for non-default-type users won't have this check applied.

    • Properties that are sensitive in the default type, but aren't sensitive in some non-default types, are always treated as sensitive.
    • When validating the SAML username EL, Okta only considers how the properties are defined in the default user type, even though custom types may define the properties differently.
  • Group membership rules are only validated against the default type. This happens when you use the preset conditions in the user interface or when using the Okta Expression Langauge. In either case, an expression is invalid for the default type. For example, if it refers to a property that exists solely in a custom user type, then the rule can't be saved or previewed. This applies 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 during evaluation for a custom user (for previewing or for determining group memberships), the expression treats the property as having a value of null.

    Group Rules aren't executed for non-default user types.

  • Group App assignments are validated against the default User Type. A Group App assignment involving an attribute that isn't consistent across multiple user types is 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 Active Directory property mapping for the login field is expected to change, but it currently only updates the mapping for the default Okta user type.

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

  • The LDAP settings page allows you to set the Okta login during the import flow and the Active DirectoryuserName during the outbound provisioning flow for the user. In both cases, those mappings from this user interface are 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 change 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.

  • Similar to Active Directory import, if the admin changes the 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 Provider feature for IdP routing rules or inbound federation, user properties are interpreted based only on the default user type. This means that the system determines whether user properties exist, whether they contain sensitive data, and so on, based only on the default user type. To avoid unintended behavior, configure any properties used in IdP policies the same way in all user types.
  • For inbound federation:
    • JIT users are created with the default type.
    • When configuring a User Match for inbound federation, only properties in the default type are listed or validated, but matching is 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. Therefore, unless mappings are manually created nothing is mapped for those users.
  • If Okta detects new app templates for either Office 365 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 to Office 365 or Sharepoint, changes to the templates for those apps aren't applied to those app instances.