Problèmes connus concernant les types d'utilisateurs personnalisés de Universal Directory

Voici les problèmes connus pour les types d'utilisateurs personnalisés de Universal Directory :

Les nouveaux utilisateurs importés sont restreints au type d'utilisateur Okta par défaut.
Le type d'utilisateur (nom de variable userType) est l'un des 31 attributs du schéma Okta de base. L'attribut User type n'est pas lié à la fonctionnalité des types d'utilisateurs personnalisés.
Vous ne pouvez pas avoir deux types d'utilisateurs différents utilisant le même nom d'attribut, mais avec des types de données différents. Les types de données doivent correspondre.
Seul l'ensemble de mappage du type d'utilisateur Okta par défaut sur les pages de connexion des applications est mis à jour pendant les importations et approvisionnements sortants. Si vous utilisez un type d'utilisateur personnalisé, le nom d'utilisateur associé à l'application n'est pas mis à jour.
Contrairement aux mappages de propriétés, les mappages d'assertions SAML ne tiennent pas compte des types. Okta utilise le type d'utilisateur par défaut pour tous les mappages d'assertions SAML.
- Okta valide chaque assertion SAML pour garantir que seuls les administrateurs autorisés peuvent modifier les attributs sensibles. Cela n'inclut pas les types utilisateur autres que ceux par défaut dont les propriétés sensibles peuvent différer du type par défaut.
- Les propriétés utilisées dans une assertion qui n'existent que pour les utilisateurs de type autre que le type par défaut ne verront pas cette vérification appliquée.
- Les propriétés sensibles dans le type par défaut, mais qui ne le sont pas dans certains types autres que celui par défaut, seront toujours traitées comme sensibles.
- Lors de la validation du nom d'utilisateur SAML EL, Okta ne prend en compte que la façon dont les propriétés sont définies dans le type d'utilisateur par défaut, même si les types personnalisés peuvent définir les propriétés différemment.
Les règles d'appartenance à un groupe ne valident la règle que par rapport au type par défaut. Cela se produit lorsque vous utilisez les conditions prédéfinies dans l'interface utilisateur ou lorsque vous utilisez le langage d'expression Okta Expression. Dans tous les cas, une expression n'est pas valide pour le type par défaut. Par exemple, si elle fait référence à une propriété qui n'existe que dans un type d'utilisateur personnalisé, la règle ne peut pas être enregistrée ou prévisualisée. Ceci s'applique même si l'utilisateur prévisualisé est du type personnalisé. Si la règle fait référence à une propriété qui n'existe que pour le type par défaut et non pour le type personnalisé, alors lorsqu'elle est évaluée pour un utilisateur personnalisé (pour la prévisualisation ou pour déterminer les appartenances à un groupe), l'expression traitera la propriété comme ayant une valeur nulle.
Les règles de groupe ne sont pas exécutées pour les types d'utilisateurs autres que ceux par défaut.
Les affectations d'applications de groupe sont validées par rapport au Type d'utilisateur par défaut. Une attribution d'Applications de groupe impliquant un attribut qui n'est pas cohérent entre plusieurs types d'utilisateurs sera validée par rapport au Type d'utilisateur par défaut.
Les utilisateurs importés depuis Active Directory qui correspondent partiellement aux utilisateurs Okta de type personnalisé existants peuvent uniquement utiliser le nom principal de l'utilisateur (UPN) comme format de nom d'utilisateur Okta. Lorsqu'un administrateur sélectionne un format de nom d'utilisateur Okta différent comme l'e-mail, SAMaccountName ou d'autres propriétés appuser personnalisées, le mappage de propriétés Active Directory pour le champ de connexion devrait être modifié, mais actuellement, il ne met à jour que le mappage pour le type d'utilisateur Okta par défaut.
La page des paramètres Active Directory vous permet de configurer la connexion Okta pendant le flux d'importation et le userName Active Directory pendant le flux d'approvisionnement sortant pour l'utilisateur. Dans les deux cas, ces mappages depuis l'UI ne sont actuellement mis à jour que pour le type d'utilisateur Okta par défaut.
La page des paramètres LDAP vous permet de configurer la connexion Okta pendant le flux d'importation et le userName Active Directory pendant le flux d'approvisionnement sortant pour l'utilisateur. Dans les deux cas, ces mappages depuis l'UI ne sont actuellement mis à jour que pour le type d'utilisateur Okta par défaut.
Dans l'UI de la page des paramètres d'approvisionnement LDAP, la section « Mappages d'attributs Okta » ne définit que le mappage entre LDAP et le profil utilisateur Okta par défaut. En d'autres termes, si n'importe lequel des mappages d'attributs abordés dans cette section est mis à jour, celle-ci ne sera efficace que sur le mappage entre le profil utilisateur de l'application et le profil utilisateur Okta par défaut. Si vous avez besoin de modifier le mappage entre le profil utilisateur de l'application et un profil utilisateur Okta personnalisé, vous devez effectuer les modifications dans le Profile Editor.
Les paramètres d'approvisionnement effectuent également une validation si le RDN est un attribut valide et cette vérification se fait uniquement par rapport au Type d'utilisateur par défaut.
De même que pour l'importation Active Directory, si l'administrateur modifie le « format de nom d'utilisateur Okta » sur la page des paramètres d'importation LDAP, cette modification ne s'applique qu'au mappage depuis LDAP vers le type d'utilisateur Okta par défaut.
En utilisant la fonctionnalité Fournisseurs d'identité, pour les règles de routage des fournisseurs d'identité (IdP) ou pour la fédération entrante, les propriétés utilisateur seront uniquement interprétées par rapport au type d'utilisateur par défaut. En d'autres termes, le système détermine si des propriétés utilisateur existent, si elles contiennent des données sensibles, etc., en fonction uniquement du type d'utilisateur par défaut. Pour éviter tout comportement involontaire, veillez à ce que toutes les propriétés utilisées dans les politiques de fournisseurs d'identité (IdP) sont configurées de la même manière dans tous les types d'utilisateurs.
Pour la fédération entrante :
- Les utilisateurs JIT sont créés avec le type par défaut.
- Lors de la configuration d'une Correspondance d'utilisateur pour la fédération entrante, la configuration répertorie ou valide uniquement les propriétés dans le type par défaut, mais la correspondance sera tentée à l'aide du Type d'utilisateur réel.
- Les mappages sont configurés automatiquement à partir de l'utilisateur du fournisseur d'identité (IdP) ou de l'utilisateur Application vers le type par défaut, mais pas vers les types personnalisés. Ainsi, à moins que les mappages soient créés manuellement, rien ne sera mappé pour ces utilisateurs.
Si Okta détecte de nouveaux modèles d'application pour Office 365 ou SharePoint, les instances existantes de l'application sont mises à jour. Ces mises à jour automatiques ne sont actuellement effectuées que pour les instances d'applications associées au Type d'utilisateur par défaut. Si un Type d'utilisateur autre que celui par défaut est affecté à O365 ou SharePoint, les modifications apportées aux modèles de ces applications ne seront pas appliquées à ces instances d'applications.