よくあるご質問

属性同期の設定項目について、さらに詳しい情報はありますか？

この設定は、Directory Sync がテナントレジストリを更新するために、ユーザーおよびグループの SCIM REST API 呼び出しを生成する際に使用されます。したがって、この設定はこれらのAPIへの入力と類似しているため、このAPIのドキュメントを参照すれば理解の一助となるでしょう。 https://docs.verify.ibm.com/verify/reference/createuser /v2.0/Groups例えば、およびの /v2.0/Users POST、PATCH、PUT操作を参照してください。

@realmどちらを使うべきか、 urn:ietf:params:scim:schemas:extension:ibm:2.0:User.realm と unqualifiedUserName 、それとも単に userName とか？

urn:ietf:params:scim:schemas:extension:ibm:2.0:User.realm および unqualifiedUserName は無視され、サンプル設定ファイルから削除されます。 @realmとを userName 組み合わせて使用してください。 "verify-realm"たとえば、属性 userPrincipalName の値が testuser@adomain.comuserName で、Verify レルムがである場合、以下の例に従ってを設定してください userName 。

{
  "ldap": "userPrincipalName",
  "tweaks": {
    "append": "@verify-realm"
  }
  "new-attr":{
    "scim":{"userName":"{{value}}"}
  },
  "mod-attr":{
    "scim":{
      "add":{"op":"add","path":"userName","value":"{{value}}"},
      "remove":{"op":"remove","path":"userName"},
      "replace":{"op":"replace","path":"userName","value":"{{value}}"}
    }
  }
}

その結果、前述の例の値に対しては、が userName に "testuser@adomain.com@verify-realm" 設定されます。

注：同じオンプレミスレジストリに対してBridgeエージェント IBM® Verify も使用している場合、「set on userName 」の指定 @realm は、そのBridgeエージェントに関連付けられているIDソースと一致している必要があります。

Active Directory を使用する場合、設定 "ldap-base-dn" の粒度が十分ではありません。他にどのような解決策がありますか？

"msDs-parentdistname"Active Directory 特定のDNグループと照合できる操作属性を提供します。この属性を設定 "ldap-search-filter" 文字列に追加することで、ユーザーおよびグループの照合をディレクトリ内の特定の領域に限定することができます。 "msDs-parentdistname" は、一致したDNのすべての子要素に対して成立 true する。この一致はサブツリーの一致ではなく、1レベルの一致です。例えば、以下のとおりです。

"ldap-base-dn": "DC=adomain,DC=com",
"ldap-search-filter":"(|(&(objectClass=user)(msDs-parentdistname=CN=SyncUsers,DC=adomain,DC=com))(&(objectClass=group)(msDs-
parentdistname=CN=SyncGroups,DC=adomain,DC=com))"

DC=comDC=adomainCN=SyncGroupsCN=testgroupDC=comDC=adomainCN=SyncUserscn=testuserこのフィルターは、、、、、のようなユーザーと、、、、のようなグループにのみ一致します。

同期対象のユーザーは、グループへの所属だけで特定できますか？

はい、ただし、グループの所属を条件 "ldap-search-filter" として使用してはいけません。 Active Directory にユーザーエントリが最初に作成された時点では、そのグループメンバーシップは設定されていません。これは作成ステップの後に追加されます。 "ldap-search-filter"したがって、ユーザー作成イベントは、. で使用された場合、無視され、失われてしまいます。解決策は、設定項目 "user-sync-filter" を使用することです。「cloud-bridge」JSONオブジェクトを参照してください。 memberOfこの構成項目は、単に.に限定されるものではありません。他のユーザー属性も同様の方法で使用できます。

SaaS 内の Verify 属性は upn 必須ですか？

UPN（ユーザープリンシパル名）属性は、 Active Directory （AD）との統合において技術的には必須ではありませんが、使用することが推奨されます。 IBM VerifyAzure ADや特定の SAML、あるいはOIDCサービスプロバイダーなどのアプリケーションや連携機能で、UPN属性が明示的に必要とされる場合は、これをカスタム属性として設定できます。これは、ユースケースにUPNに依存するSSOアサーションや属性マッピングが含まれる場合にのみ必要となります。特に、次のような場合です：

UPN に基づいてリダイレクトを行うカスタムログインページを使用する
複数のドメインまたはレルムのサポート
SSOシナリオの実装

ブリッジインスタンス（ユーザー、管理者、グループ）を分離することは推奨されますか？

いいえ、この分離方法は、 IBM のベストプラクティスでは推奨されていません。 IBM Verify Bridge for Directory Sync 単一のインスタンスでユーザーとグループの両方を管理できるように設計されています。標準的な導入モデルでは、ディレクトリソースごとに1つのDirectory Syncブリッジを設置し、高可用性を確保するためにスタンバイ用の冗長インスタンスを用意します。また、機能（ユーザー、グループ）ごとに分割することも、複雑さが増し、同期の問題を引き起こす可能性があるため、推奨されません。

IBM Verify にはなぜ 2 つの username 属性（preferred_username と username）があるのでしょうか？また、その違いは何ですか？

IBM Verify 2つの異なるユーザー名関連の属性を使用しています。

userName これは、認証やシステム操作に使用される主要な識別子です。これはシステム内におけるユーザーの一意の識別子として機能し、レルム内で一意である必要があります。これは、認証処理、ユーザー検索、およびシステム操作に使用されます。これは多くの場合、 Active Directory から (UPN) に userPrincipalName マッピングされ、システムの機能にとって極めて重要です。
preferred_username これは、主に表示用に使用される代替ユーザー名です。これは主にユーザーインターフェースでの表示を目的としており、より親しみやすい表示名を提供します。ユーザープロフィールやUI要素に表示することができます。これは認証やシステム検索には使用されず、変更しても中核となる認証機能には影響しません。

パスワード認証用のBridgeエージェントと組み合わせて使用する場合、Directory Syncでは「フェデレーションユーザー」と「通常ユーザー」のどちらを作成するのが適切ですか？

「フェデレーションユーザー」が正しい選択肢です。フェデレーションユーザーは IBM Verify 、SSO機能をサポートしています。彼らは、オンプレミスのレジストリをID情報の信頼できる情報源として維持しています。これらは外部IDソース（オンプレミスのBridgeエージェント）に対して認証を行い、その属性はオンプレミスのレジストリから同期されます。