Red Hat Training

A Red Hat training course is available for Red Hat Directory Server

4.3.3. ロールとグループの使い分け

ロールとグループは同じ目標を達成することができます。管理されたロールは、静的グループができることをすべて行うことができ、フィルタリングされたロールは、動的グループのようにメンバーをフィルタリングして識別することができます。ロールとグループの両方に、メリットとデメリットがあります。ロールとグループのどちらを使用するか (または混在させるか) は、クライアントのニーズとサーバーのリソースのバランスによって決まります。
ロールはクライアント側の複雑さを軽減することができ、それがロールの主な利点です。ロールの場合、クライアントアプリケーションは、エントリーの nsRole 操作属性を検索して、ロールのメンバーシップを確認することができます。この多値属性は、エントリーが属するすべてのロールを識別します。クライアントアプリケーションの観点からは、メンバーシップを確認する方法は統一されており、サーバー側で実行されます。
しかし、このようなクライアントにとっての使い勝手の良さは、サーバーの複雑化という代償を伴います。 サーバーがクライアントアプリケーションに対して機能するため、Directory Server ではロールの評価がグループを評価するよりもリソース集約されます。
グループは、サーバーにとっては簡単ですが、効果的に使用するには、よりスマートで複雑なクライアントが必要です。たとえば、ダイナミックグループは、アプリケーションの観点から見ると、グループメンバーのリストを提供するサーバーからのサポートを提供しません。代わりに、アプリケーションはグループ定義を取得してから、フィルタを実行します。グループメンバーシップは、適切なプラグインが設定されている場合にのみ、ユーザーエントリーに反映されます。結局のところ、グループのメンバーシップを決定する方法は一様ではなく、予測もできません。
注記
グループメンバーシップの管理をバランスよく行うことができるものとして、MemberOf プラグインがあります。memberOf を使用することで、クライアントにとっての使いやすさと、サーバーの計算効率の良さのバランスがとれます。
MemberOf プラグインは、ユーザーがグループに追加されるたびに、ユーザーエントリに memberOf 属性を動的に作成します。クライアントは、グループエントリーを 1 回検索することで、そのグループのすべてのメンバーのリストを取得できます。ユーザーエントリーを 1 回検索することで、そのユーザーが属するすべてのグループの完全なリストを取得できます。
サーバーには、メンバーシップが変更されたときにのみメンテナンスのオーバーヘッドが発生します。指定されたメンバー (グループ) 属性と memberOf (ユーザー) 属性の両方がデータベースに格納されているため、検索に必要な余分な処理がなく、クライアントからの検索を非常に効率的に行うことができます。