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

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

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

  • グループアプリの割り当ては、デフォルトのユーザータイプに対して検証されます。複数のユーザータイプ間で整合しない属性を含むグループアプリの割り当ては、デフォルトのユーザータイプに対して検証されます。
  • Active Directoryからインポートされ、既存のカスタムタイプのOktaユーザーと部分一致するユーザーは、Oktaユーザー名形式としてユーザー プリンシパル名(UPN)のみを使用できます。管理者が電子メール、SamAccountName、その他のカスタム アプリ ユーザープロパティなど別のOktaユーザー名形式を選択すると、[ログイン]フィールドの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ユーザータイプへのマッピングに対してのみ適用されます。
  • IDプロバイダー機能を使用する場合、IdPルーティング ルールまたはインバウンド フェデレーションのいずれかに対して、デフォルト ユーザータイプのみに基づいて(存在するかどうか、機密データを含むかどうかなどを判断するために)Oktaユーザープロパティが解釈されます。意図しない動作を回避するために、IdPポリシーで使用されるプロパティがすべてのユーザータイプで同じ方法で設定されているか確認してください。
  • インバウンド フェデレーション向け:
    • JITユーザーがデフォルトタイプで作成されます。
    • インバウンド フェデレーションでユーザー一致を設定する場合、設定ではデフォルトタイプでのプロパティのみを一覧表示または検証しますが、実際のユーザータイプを使用してマッチングが試行されます。
    • マッピングはIdPユーザーまたはアプリユーザーからデフォルトタイプへ自動設定されますが、カスタムタイプへのマッピングは設定されません。つまり手作業でマッピングが作成されない限り、これらのユーザーに対しては何もマップされません。
  • OktaがO365またはSharepointで新しいアプリ テンプレートを検出すると、アプリの既存インスタンスがアップデートされます。これらの自動アップデートは、現行ではデフォルト ユーザータイプと関連付けられたアプリのインスタンスに対してのみ実行されます。デフォルト以外のユーザータイプがO365またはSharepointに割り当てられている場合、これらのアプリでテンプレートに加えられた変更はアプリのインスタンスに適用されません。