Universal Directoryのカスタム・ユーザー・タイプに関する既知の問題

Universal Directoryのカスタム・ユーザー・タイプには以下のような既知の問題があります。

インポートした新規ユーザーは、デフォルトのOktaユーザー・タイプに限定されます。
ユーザー・タイプ（変数名userType）は、Oktaベース・スキーマの31個ある属性の1つです。ユーザー・タイプ属性はカスタム・ユーザー・タイプの機能とは無関係です。
属性名は同じでデータ型が異なるという2種類のユーザー・タイプを作成することはできません。データ型は一致している必要があります。
組織でセルフサービス登録が有効化されている場合、組織の全ユーザーのログインIDは、強制的に各自のメール・アドレスと一致するようにマッピングされます。その組織のすべてのユーザー・タイプが、強制マッピングの対象になります。
プロパティーのマッピングとは異なり、SAMLアサーションのマッピングでは型は認識されません。このようなケースでは、Oktaのデフォルトのユーザー・タイプが使用されます。
- 認可された管理者のみが機密性の高い属性を使用してSAMLアサーションを編集できるようにする検証処理では、デフォルト以外のユーザー・タイプ（機密性の高いプロパティーが、デフォルトのタイプとは異なる場合がある）は考慮されません。
- デフォルト以外のタイプのユーザーにしか存在しないアサーションで使用されるプロパティーには、このチェックは適用されません。
- 機密性の高い属性 - デフォルトのタイプでは機密性が高くても、デフォルト以外の一部のタイプでそれが当てはまらないプロパティーは、必ず機密性が高いものとして扱われます。
- SAMLユーザー名のELを検証する際にプロパティーの定義方法が考慮されるのは、デフォルトのユーザー・タイプのみです。カスタム・タイプではプロパティーの定義方法が異なっているとしても、考慮はされません。
グループ・メンバーシップ・ルールによって検証されるのは、デフォルト・タイプのルールのみです。これは「基本条件」UIと「Okta式言語」オプションのどちらを使用しても同じです。いずれの場合でも、たとえば式がカスタムのユーザー・タイプにのみ存在するプロパティーを参照しているために、デフォルトのタイプには効果がない場合、（プレビュー対象のユーザーがカスタム型であっても）ルールは保存もプレビューもできません。デフォルト・タイプにのみ存在し、カスタムのタイプには存在しないプロパティーを参照するルールの場合、カスタム・ユーザーに対して（プレビューまたはグループ・メンバーシップを判断するために）ルールが評価されると、その式はプロパティーがnullの値を持つものとして扱います。

グループ・ルールはデフォルト以外のユーザー・タイプに対しては実行されません。

グループ・アプリの割り当ては、デフォルトのユーザー・タイプと照合して検証されます。複数のユーザー・タイプ間で一貫性のない属性を含むグループ・アプリの割り当ては、デフォルトのユーザー・タイプと照合して検証されます。
Active Directoryからインポートしたユーザーで、カスタム・タイプの既存のOktaユーザーと部分的に一致するユーザーについては、Oktaユーザー名フォーマットのユーザー・プリンシパル名（UPN）だけを使用できます。メール、sAMAccountName、その他のカスタムappuserプロパティーのような別のOktaユーザー名フォーマットを選択した場合、「login」フィールドのADプロパティーのマッピングが変更されることになっていますが、現時点では、デフォルトのOktaユーザー・タイプのマッピングのみが更新されます。

ADの設定ページでは、インポートのフローでOktaログインを、ユーザーのアウトバウンドのプロビジョニング・フローでADユーザー名を設定できます。どちらの場合も、現状このUIからのマッピングはデフォルトのOktaユーザー・タイプに対してのみ更新されます。

LDAPの設定ページでは、インポートのフローでOktaログインを、ユーザーのアウトバウンドのプロビジョニング・フローでADユーザー名を設定できます。どちらの場合も、現状このUIからのマッピングはデフォルトのOktaユーザー・タイプに対してのみ更新されます。

LDAPのプロビジョニング設定ページのUIである[Okta属性マッピング]セクションで定義されるのは、LDAPとデフォルトのOktaユーザー・プロファイルとの間のマッピングのみです。つまり、このセクションの属性マッピングのいずれかが更新された場合、その変更はアプリのユーザー・プロファイルとデフォルトのOktaユーザー・プロファイルとの間のマッピングにしか反映されません。アプリのユーザー・プロファイルとカスタムのOktaユーザー・プロファイルとの間のマッピングを変更する場合は、プロファイル・エディターを使用する必要があります。

RDNが有効な属性の場合はプロビジョニング設定でも検証が行われます。またそのチェックはデフォルトのユーザー・タイプに対してのみ行われます。

Oktaユーザー名のフォーマット - Active Directoryのインポートの場合と同様に、管理者がLDAPインポート設定ページで「Oktaユーザー名のフォーマット」を変更した場合、その変更はLDAPからデフォルトのOktaユーザー・タイプへのマッピングに対してのみ適用されます。
IdPのルーティング・ルールまたはインバウンド・フェデレーションのいずれかでIDプロバイダーの機能を使用する場合、Oktaユーザー・プロパティーは、デフォルトのユーザー・タイプのみに基づいて解釈されます（プロパティーが存在するかどうか、機密性の高いデータが含まれるかどうかなど）。意図しない動作を起こさないように防ぐには、IdPポリシーで使用されるすべてのプロパティーを、どのユーザー・タイプでも必ず同じように構成します。
インバウンド・フェデレーションの場合
- JITユーザーはデフォルト・タイプで作成されます。
- インバウンド・フェデレーション用のユーザー一致を設定する場合、構成ではデフォルト・タイプのプロパティーのみが一覧で表示または検証されますが、一致の試行は実際のユーザー・タイプを使用して行われます。
- マッピングは、IdPユーザーまたはアプリ・ユーザーからデフォルト・タイプに対しては自動的に設定されますが、カスタム・タイプに対しては設定されません。したがって手動でマッピングを作成しない限り、カスタム・タイプのユーザーには何もマッピングされません。
OktaがOffice 365またはSharePointの新しいアプリ・テンプレートを検出すると、アプリの既存のインスタンスが更新されます。この自動更新は、現状ではデフォルトのユーザー・タイプに関連付けられたアプリ・インスタンスに対してのみ実行されます。デフォルト以外のユーザー・タイプにOffice 365またはSharePointが割り当てられている場合、それらのアプリのテンプレートに対する変更は、対応するアプリのインスタンスには適用されません。