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

Okta Universal Directoryカスタムユーザータイプに関する既知の問題があります。

• インポートされる新規ユーザーは、デフォルトのOktaユーザータイプに限定されます。
• ユーザータイプ（変数名userType）はOktaベーススキーマの31個の属性のうちの1つです。ユーザータイプ属性はカスタムユーザータイプの機能とは無関係です。
• 同じ属性名を使用するが異なるデータタイプを持つ2つの異なるユーザータイプを持つことはできません。データタイプは一致しなければなりません。

• アプリケーションのサインインページに設定されているデフォルトのOktaユーザータイプマッピングのみが、インポートおよびアウトバウンドプロビジョニング中に更新されます。

• orgでセルフサービス登録が有効化されている場合、org内のすべてのユーザーがログインIDをメールアドレスと一致するよう強制的にマップされます。強制マッピングはorg内のすべてのユーザータイプに適用されます。
• プロパティマッピングと異なり、SAMLアサーションマッピングはタイプを認識しません。Oktaはそのようなすべてのケースでデフォルトのユーザータイプを使用します。
  • 許可された管理者のみが機密の属性を使用してSAMLアサーションを編集できることを検証する際に、デフォルト以外のユーザータイプは考慮されません（機密のプロパティはデフォルトタイプによって異なります）。
  • アサーションで使用されデフォルト以外のユーザータイプに対してのみ存在するプロパティには、このチェックは適用されません。
  • 機密の属性 ― デフォルトタイプでは機密扱いであるが、一部のデフォルト以外のタイプでは非機密扱いのプロパティが、常に機密に扱われます。
  • SAMLユーザー名ELを検証するときに、たとえカスタムタイプではプロパティが別の方法で定義されたとしても、Oktaはデフォルトユーザータイプでのプロパティの定義方法のみを考慮します。
• グループメンバーシップルールはデフォルトタイプに対してのみルールを検証します。これは、「基本条件」UIまたは「Okta Expression Language」オプションを使用する場合に当てはまります。どちらの場合も、（カスタムユーザータイプのみに存在するプロパティを参照しているなどの理由で）式がデフォルトタイプで有効でない場合、（たとえプレビューされるユーザーがカスタムタイプであっても）ルールは保存もプレビューもされません。ルールがカスタムタイプではなくデフォルトタイプのみに存在するプロパティを参照している場合、（グループメンバーシップのプレビューや決定のために）カスタムユーザー向けにルールを評価する際に、式はそのプロパティがnull値を持つものとして扱います。

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

• グループアプリの割り当ては、デフォルトのユーザータイプに対して検証されます。複数のユーザータイプ間で整合しない属性を含むグループアプリの割り当ては、デフォルトのユーザータイプに対して検証されます。
• Active Directoryからインポートされ、既存のカスタムタイプのOktaユーザーと部分一致するユーザーは、Oktaユーザー名の形式としてユーザープリンシパル名（UPN）のみを使用できます。管理者がメール、sAMAccountName、その他のカスタムアプリユーザープロパティなど別のOktaユーザー名の形式を選択すると、［Login（ログイン）］フィールドのADプロパティマッピングが変更されるはずですが、現行ではデフォルトのOktaユーザータイプに対してのみマッピングを更新します。

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

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

LDAPプロビジョニング設定ページのUIで、［Okta Attribute Mappings（Okta属性マッピング）］セクションではLDAPとデフォルトのOktaユーザープロファイルとの間のマッピングのみを定義します。言い換えると、このセクションで何らかの属性マッピングがアップデートされた場合、アプリユーザープロファイルとデフォルトのOktaユーザープロファイル間のマッピングのみに反映されます。アプリユーザープロファイルとカスタムOktaユーザープロファイル間のマッピングに変更を加える必要がある場合、Profile Editorで変更を行う必要があります。

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

• Oktaユーザー名の形式―Active Directoryインポートと同様、管理者がLDAPインポート設定ページで「Oktaユーザー名の形式」を変更した場合、その変更はLDAPからデフォルトのOktaユーザータイプへのマッピングに対してのみ適用されます。
• IDプロバイダー機能を使用する場合、IdPルーティングルールまたはインバウンドフェデレーションのいずれかに対して、デフォルトユーザータイプのみに基づいて（存在するかどうか、機密データを含むかどうかなどを判断するために）Oktaユーザープロパティが解釈されます。意図しない動作を回避するために、IdPポリシーで使用されるプロパティがすべてのユーザータイプで同じ方法で設定されているか確認してください。
• インバウンドフェデレーション向け：
  • JITユーザーがデフォルトタイプで作成されます。
  • インバウンドフェデレーションでユーザー一致を設定する場合、設定ではデフォルトタイプでのプロパティのみを一覧表示または検証しますが、実際のユーザータイプを使用してマッチングが試行されます。
  • マッピングはIdPユーザーまたはアプリユーザーからデフォルトタイプへ自動設定されますが、カスタムタイプへのマッピングは設定されません。つまり手作業でマッピングが作成されない限り、これらのユーザーに対しては何もマップされません。
• OktaがO365またはSharepointで新しいアプリテンプレートを検出すると、アプリの既存インスタンスがアップデートされます。これらの自動アップデートは、現行ではデフォルトユーザータイプと関連付けられたアプリのインスタンスに対してのみ実行されます。デフォルト以外のユーザータイプがO365またはSharepointに割り当てられている場合、これらのアプリでテンプレートに加えられた変更はアプリのインスタンスに適用されません。