Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

9.7. アクセス制御の設計

ディレクトリークライアントのアイデンティティーを確立するために使用する認証スキームを決定した後、そのスキームを使用してディレクトリーに含まれる情報を保護する方法を決定します。アクセス制御では、特定のクライアントが特定の情報にアクセスでき、その他のクライアントはアクセスできないように指定できます。
アクセス制御は、1 つ以上のアクセス制御リスト (ACL) を使用して定義されます。ディレクトリーの ACL は、指定されたエントリーとその属性へのパーミッション (読み取り、書き込み、検索、比較など) を許可または拒否する一連の 1 つ以上の アクセス制御情報 (ACI) ステートメントで設定されます。
ACL を使用すると、ディレクトリーツリーの任意のレベルでパーミッションを設定できます。
  • ディレクトリー全体。
  • ディレクトリーの特定のサブツリー。
  • ディレクトリーの特定のエントリー。
  • エントリー属性の特定セット。
  • 指定の LDAP 検索フィルターと一致するエントリー。
さらに、特定のユーザー、特定のグループに所属するすべてのユーザー、またはディレクトリーのすべてのユーザーにパーミッションを設定できます。最後に、アクセスは IP アドレス (IPv4、IPv6) や DNS 名などのネットワークの場所に定義できます。

9.7.1. ACI 形式
リンクのコピー

セキュリティーポリシーを設計する場合は、ACI がディレクトリーでどのように表されているかを理解しておくと便利です。また、ディレクトリーに設定できる権限を理解しておくと便利です。このセクションでは、ACI メカニズムの概要を簡単に説明します。ACI 形式の完全な説明は『Red Hat Directory Server Administration Guide』を参照してください。
ディレクトリー ACI は、一般的な形式 target permission bind_rule を使用します。
ACI 変数を以下に定義します。
  • targetACI が対象とするエントリー (通常はサブツリー)、対象とする属性、またはその両方を指定します。ターゲットは ACI が適用されるディレクトリー要素を識別します。ACI はエントリーを 1 つだけターゲットにできますが、複数の属性をターゲットにできます。さらに、ターゲットには LDAP 検索フィルターを含めることができます。パーミッションは、共通の属性値を含む、広範囲に散在するエントリーにパーミッションを設定することができます。
  • パーミッション.この ACI によって設定される実際のパーミッションを特定します。permission 変数は、ACI が指定されたターゲットへの特定タイプのディレクトリーアクセス (読み取りや検索など) を許可または拒否していることを示します。
  • bind ruleパーミッションが適用されるバインド DN またはネットワークの場所を特定します。バインドルールは LDAP フィルターを指定する場合もあり、そのフィルターがバインドクライアントアプリケーションに対して true であると評価された場合、ACI はクライアントアプリケーションに適用されます。
そのため、ACI は For the directory object target, allow or deny permission if bind_rule is true と表すことができます。
permission および bind_rule はペアとして設定され、ターゲットごとに複数の permission-bind_rule ペアを設定できます。複数のアクセス制御を任意のターゲットに効果的に設定できます。以下に例を示します。 
target (permission bind_rule)(permission bind_rule)...
Copy to Clipboard Toggle word wrap
Babs Jensen としてバインドするユーザーが誰でも Babs Jensen の電話番号へ書き込みできるパーミッションを設定できます。このパーミッションのバインドルールは、if you bind as Babs Jensenの部分です。ターゲットは Babs Jensen の電話番号で、パーミッションが 書き込みアクセスです。

9.7.1.1. ターゲット
リンクのコピー

ディレクトリーに作成されたすべての ACI のターゲットとなるエントリーを決定します。ディレクトリー分岐点エントリーをターゲットにすると、その分岐点とそのすべての子エントリーがパーミッションの範囲に含まれます。ターゲットエントリーが ACI に明示的に定義されていない場合、ACI は ACI ステートメントが含まれるディレクトリーエントリーに対してターゲットとなります。targetattr パラメーターを設定して、1 つ以上の属性をターゲットにします。targetattr パラメーターが設定されていない場合、ターゲットになる属性はありません。詳細は、『Red Hat Directory Server Administration Guide』の該当セクションを参照してください。
各 ACI に対し、1 つのエントリーのみ、または 1 つの LDAP 検索フィルターに一致するエントリーのみをターゲットにすることができます。
エントリーをターゲットにすることに加えて、エントリーの属性をターゲットにすることができます。これは属性値のサブセットにのみパーミッションが適用されます。ターゲットとなる属性に明示的に命名するか、ACI によってターゲットにされていない属性に明示的に命名することによる属性のターゲットセット。ターゲットで属性を除外すると、オブジェクトクラス構造によって許可されるいくつかの属性を除くすべての属性にパーミッションが設定されます。
詳細は、『Red Hat Directory Server Administration Guide』の該当セクションを参照してください。

9.7.1.2. パーミッション
リンクのコピー

パーミッションは、アクセスを許可または拒否できます。一般的には、パーミッションを拒否しないようにします (「アクセスの許可または不許可」 に記載の理由により)。パーミッションは、ディレクトリーサービスに対して実行される操作のいずれかです。
Expand
パーミッション 説明
Read ディレクトリーデータを読み取ることができるかどうかを示します。
Write ディレクトリーデータを変更または作成できるかどうかを示します。このパーミッションは、ディレクトリーデータの削除を許可しますが、エントリー自体は削除できません。エントリー全体を削除するには、ユーザーに delete パーミッションが必要です。
Search
ディレクトリーデータを検索できるかどうかを示します。これは、検索操作の一部として返される場合にディレクトリーデータを表示できる点で、read パーミッションとは異なります。
たとえば、共通名の検索と、人の部屋番号の読み取りが許可された場合は、共通名の検索の一部として部屋番号を返すことができますが、部屋番号自体は検索の対象として使用できません。この組み合わせを使用して、ディレクトリーを検索してどの部屋に誰がいるかを検索できないようにします。
Compare 比較操作でデータを使用できるかどうかを示します。compare パーミッションは検索可能であることを意味しますが、検索の結果として実際のディレクトリー情報は返されません。代わりに、比較した値と一致するかどうかを示す簡単なブール値が返されます。これは、ディレクトリー認証中に userPassword 属性値を照合するために使用されます。
Self-write グループ管理にのみ使用されます。このパーミッションにより、ユーザーはグループに自身を追加したり、グループから削除したりできます。
追加 子エントリーを作成できるかどうかを示します。このパーミッションにより、ユーザーはターゲットとなるエントリーの下に子エントリーを作成できます。
削除 エントリーを削除できるかどうかを示します。このパーミッションにより、ユーザーはターゲットとなるエントリーを削除できます。
Proxy ユーザーがディレクトリーマネージャー以外の他の DN を使用して、この DN の権限でディレクトリーにアクセスできることを示します。

9.7.1.3. バインドルール
リンクのコピー

バインドルールは通常、パーミッションの対象となるバインド DN を示します。また、時刻や IP アドレスなどのバインド属性を指定することもできます。
バインドルールは、ACI がユーザー自身のエントリーにのみ適用されることを簡単に表現します。これにより、ユーザーは別のユーザーのエントリーを更新するリスクを負わずに、独自のエントリーを更新できます。
バインドルールは、ACI が特定の状況に適用可能なことを示します。
  • バインド操作が特定の IP アドレス (IPv4 または I Pv6) または DNS ホスト名から送信される場合のみ。これは、特定のマシンまたはネットワークドメインからすべてのディレクトリー更新を強制的に実行するためによく使用されます。
  • ユーザーが匿名でバインドする場合。匿名バインドのパーミッションを設定すると、ディレクトリーにバインドするすべてのユーザーにもパーミッションが適用されます。
  • ディレクトリーに正常にバインドされるユーザーの場合。これにより、匿名アクセスを阻止する一方で、一般的なアクセスが可能になります。
  • クライアントがエントリーの直接の親としてバインドされている場合のみ。
  • ユーザーがバインドしたエントリーが特定の LDAP 検索条件を満たしている場合のみ。
Directory Server は、これらの種類のアクセスをより簡単に表現するためにキーワードをいくつか提供します。
  • Parentバインド DN が直接の親エントリーである場合、バインドルールは true になります。これは、ディレクトリー分岐点がその直接の子エントリーを管理できるようにする特定のパーミッションを付与できることを意味します。
  • Selfバインド DN がアクセスを要求するエントリーと同じである場合、バインドルールは true になります。個人が独自のエントリーを更新できるように特定のパーミッションを付与できます。
  • Allディレクトリーに正常にバインドされたユーザーは、バインドルールは true になります。
  • Anyonebind ルールは、すべてのユーザーで true になります。このキーワードは、匿名アクセスを許可または拒否するために使用されます。

9.7.2. パーミッションの設定
リンクのコピー

デフォルトでは、Directory Manager を除くすべてのユーザーには、いかなる種類のアクセス権も与えられていません。そのため、ユーザーがディレクトリーにアクセスできるように、一部の ACI をディレクトリーに設定する必要があります。
ディレクトリーに ACI を設定する方法は『Red Hat Directory Server Administration Guide』を参照してください。

9.7.2.1. 優先度ルール
リンクのコピー

ユーザーがディレクトリーエントリーへの何らかのアクセスを試みると、Directory Server はディレクトリーに設定されているアクセス制御を調べます。アクセスを決定するため、Directory Server は 優先度ルール を適用します。このルールは、競合する 2 つのパーミッションが存在する場合に、アクセスを拒否するパーミッションが、アクセスを許可するパーミッションよりも常に優先されることを示しています。
たとえば、書き込みパーミッションがディレクトリーの root レベルで拒否され、そのパーミッションがディレクトリーにアクセスするすべてのユーザーに適用される場合、書き込みアクセスを許可する他のパーミッションに関係なく、ユーザーにはそのディレクトリーへ書き込みできません。特定ユーザーのディレクトリーへの書き込みパーミッションを許可するには、元の書き込み拒否の範囲を設定して、そのユーザーが含まれないようにする必要があります。次に、対象のユーザーに書き込み許可パーミッションが必要です。

9.7.2.2. アクセスの許可または不許可
リンクのコピー

ディレクトリーツリーへのアクセスは明示的に許可または拒否することができますが、ディレクトリーへのアクセスを明示的に拒否する場合は注意してください。優先度ルールにより、ディレクトリーがアクセスを明示的に禁止するルールを見つけると、アクセスを付与する可能性のある競合するパーミッションに関係なく、ディレクトリーへのアクセスが禁止されます。
ユーザーまたはクライアントアプリケーションの可能な限り小さなサブセットのみが含まれるように、アクセスルールのスコープを制限します。たとえば、パーミッションを設定して、ユーザーがディレクトリーエントリーの任意の属性に書き込むことができますが、Directory Administrators グループのメンバー以外のすべてのユーザーが uid 属性に書き込む権限を拒否します。または、以下の方法で書き込みアクセスを許可する 2 つのアクセス制御ルールを作成します。
  • uid 属性以外のすべての属性への書き込み権限を許可するルールを 1 つ作成します。このルールはすべてのユーザーに適用される必要があります。
  • uid 属性への書き込み権限を許可するルールを 1 つ作成します。このルールは、Directory Administrators グループのメンバーにのみ適用する必要があります。
許可特権のみを提供すると、明示的な拒否特権を設定する必要がなくなります。

9.7.2.3. アクセスを拒否する場合
リンクのコピー

明示的な拒否権限を設定する必要はほとんどありませんが、便利な状況がいくつかあります。
  • 複雑な ACL が分散している大きなディレクトリーツリーがある。
    セキュリティー上の理由から、特定のユーザー、グループ、または物理的な場所へのアクセスを突然拒否しなければならない場合があります。時間をかけて既存の ACL を注意深く調べて、許可パーミッションを適切に制限する方法を理解するのではなく、分析を行う時間ができるまで、明示的な拒否特権を一時的に設定します。ACL がこのように複雑になった場合、長期的には、拒否 ACI は管理オーバーヘッドを増やすだけです。できるだけ早く ACL を作り直して、明示的な拒否特権を回避し、アクセス制御スキーム全体を簡素化します。
  • アクセス制御は、曜日または 1 日の時間を基にする必要があります。
    たとえば、すべての書き込みアクティビティーは日曜日の午後 11 時から拒否できます。(2300) to Monday at 1:00 a.m.(0100).管理の観点からは、すべての allow-for-write ACI のディレクトリーを検索し、この期間でスコープを制限するよりも、このタイプの時間ベースのアクセスを明示的に制限する ACI を管理する方が簡単かもしれません。
  • ディレクトリー管理者権限を複数のユーザーに委譲する場合は、特権を制限する必要があります。
    個人またはユーザーのグループに、ツリーの一部を変更を許可せずに、ディレクトリーツリーの一部の管理を許可するには、明示的な拒否特権を使用します。
    たとえば、メール管理者が共通名属性への書き込みアクセスを許可しないようにするには、共通名属性への書き込みアクセスを明示的に拒否する ACI を設定します。

9.7.2.4. アクセス制御ルールの配置場所
リンクのコピー

アクセス制御ルールは、ディレクトリー内の任意のエントリーに配置できます。多くの場合、管理者は、オブジェクトクラス domainComponent、country、organization、organizationalUnit、inetOrgPerson、または group を使用して、エントリーにアクセス制御ルールを配置します。
ACL 管理を簡素化するために、ルールを可能な限りグループに編成します。ルールは通常、ターゲットエントリーとそのエントリーのすべての子に適用されます。したがって、アクセス制御ルールは、個々のリーフ (個人など) のエントリーに分散させるのではなく、ディレクトリーのルートポイントまたはディレクトリーブランチポイントに配置するのが最適です。

9.7.2.5. フィルターされたアクセス制御ルールの使用
リンクのコピー

Directory Server ACI モデルのより強力な機能の 1 つは、LDAP 検索フィルターを使用してアクセス制御を設定する機能です。LDAP 検索フィルターを使用して、定義された基準セットに一致するディレクトリーエントリーへのアクセスを設定します。
たとえば、Marketing に設定された organizationalUnit 属性が含まれるエントリーの読み取りアクセスを許可します。
フィルターされたアクセス制御ルールにより、事前定義のアクセスレベルが許可されます。ディレクトリーに自宅の住所と電話番号情報が含まれるとします。この情報を公開したい人もいれば、非公開にしたい人もいます。これに対処する方法はいくつかあります。
  • publishHomeContactInfo という属性をすべてのユーザーのディレクトリーエントリーに作成します。
  • homePhone 属性が true （有効）に設定されているエントリーに対してのみ、homePostalAddress 属性および publishHomeContactInfo 属性への読み取りアクセスを許可するアクセス制御ルールを設定します。LDAP 検索フィルターを使用して、このルールのターゲットを表します。
  • ディレクトリーユーザーが、独自の publishHomeContactInfo 属性の値を true または false に変更できるようにします。これにより、ディレクトリーユーザーは、この情報が公開されているかどうかを判断できます。
LDAP 検索フィルターの使用および ACI での LDAP 検索フィルターの使用に関する詳細は、『Red Hat Directory Server Administration Guide』を参照してください。

9.7.3. ACI の表示: Get Effective Rights
リンクのコピー

きめ細かいアクセス制御を付与するため、または効率的なエントリー管理のために、エントリーに設定されたアクセス制御を表示する必要がある場合があります。Get effective rights は拡張された ldapsearch で、エントリー内の各属性に設定されたアクセス制御パーミッションを返し、LDAP クライアントがサーバーのアクセス制御設定によってユーザーが実行できる操作を決定できるようにします。
アクセス制御情報は、エントリーに対する権限と属性に対する権限の 2 つのアクセスグループに分けられます。エントリーに対する権限とは、その特定のエントリーに限定された、変更または削除などの権限を意味します。属性に対する権限とは、ディレクトリー全体のその属性のすべてのインスタンスへのアクセス権を意味します。
この種の詳細なアクセス制御は、次のような状況で必要になる場合があります。
  • 管理者は、get effective rights コマンドを使用して、特定のグループまたはユーザーのエントリーへのアクセスを許可し、他のユーザーを制限するなど、細かなアクセス制御を行うことができます。たとえば、QA Managers グループのメンバーには、title や salary などの属性を検索および読み取る権限がありますが、HR Group メンバーのみが変更または削除する権限を持ちます。
  • ユーザーは、有効な権限を取得するオプションを使用して、個人エントリーで表示または変更できる属性を決定できます。たとえば、ユーザーは homePostalAddress および cn などの属性にアクセスできますが、title および salary への読み取りアクセスのみが許可されます。
-E スイッチを使用して実行される ldapsearch は、通常の検索結果の一部として、特定のエントリーのアクセス制御を返します。次の検索は、ユーザー Ted Morris が個人エントリーに対して持っている権限を示しています。 
ldapsearch -x -p 389 -h server.example.com -D "uid=tmorris,ou=people,dc=example,dc=com" -W -b "uid=tmorris,ou=people,dc=example,dc=com" -E !1.3.6.1.4.1.42.2.27.9.5.2:dn:uid=tmorris,ou=people,dc=example,dc=com "(objectClass=*)"

version: 1
dn: uid=tmorris,ou=People,dc=example,dc=com
givenName: Ted
sn: Morris
ou: Accounting
ou: People
l: Santa Clara
manager: uid=dmiller,ou=People,dc=example,dc=com
roomNumber: 4117
mail: tmorris@example.com
facsimileTelephoneNumber: +1 408 555 5409
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: tmorris
cn: Ted Morris
userPassword: {SSHA}bz0uCmHZM5b357zwrCUCJs1IOHtMD6yqPyhxBA==
entryLevelRights: vadn
attributeLevelRights: givenName:rsc, sn:rsc, ou:rsc, l:rscow, manager:rsc, roomNumber:rscwo, mail:rscwo, facsimileTelephoneNumber:rscwo, objectClass:rsc, uid:rsc, cn:rsc, userPassword:wo
Copy to Clipboard Toggle word wrap
この例では、entryLevelRights の結果が示すように、Ted Morris には自分のエントリーの DN を追加、表示、削除、または名前変更する権限があります。lの結果に示されるように、場所の読み取り、検索、比較、自己変更、または自己削除を行えますが、パスワードに対する自己書き込みおよび自己削除の権限のみになります。attributeLevelRights
デフォルトでは、値を持たない、またはエントリー内に存在しないエントリー内の属性に対して有効な権限情報は返されません。たとえば、userPassword の値が削除されると、自己書き込みおよび自己削除の権限が許可されていても、将来的に上記のエントリーで有効な権限を検索しても、userPassword の有効な権限は返されません。同様に、street 属性に読み取り、比較、および検索の権限が追加されると、street: rsc は attributeLevelRights の結果に表示されます。
存在しない属性や操作属性など、通常は検索結果に含まれない属性の権限を返すことができます。アスタリスク(*)を使用すると、存在しない属性を含む、エントリーの可能なすべての属性の権限が返されます。 
ldapsearch -x -E !1.3.6.1.4.1.42.2.27.9.5.2:dn:uid=scarter,ou=people,dc=example,dc=com "(objectclass=*)" "*"
Copy to Clipboard Toggle word wrap
プラス記号(+)を使用すると、エントリーの操作属性が返されます。これは通常 ldapsearch アスタリスク(*)では返されません。以下に例を示します。 
ldapsearch -x -E !1.3.6.1.4.1.42.2.27.9.5.2:dn:uid=scarter,ou=people,dc=example,dc=com "(objectclass=*)" "+"
Copy to Clipboard Toggle word wrap
アスタリスク(*)とプラス記号(+)を一緒に使用して、エントリーのすべての属性を返すことができます。

9.7.4. ACI の使用: いくつかのヒントとコツ
リンクのコピー

セキュリティーポリシーを実装する際には、このヒントに留意してください。これらは、ディレクトリーセキュリティーモデルを管理する管理上の負担を軽減し、ディレクトリーのパフォーマンス特性を改善するのに役立ちます。
  • ディレクトリー内の ACI の数を最小限に抑えます。
    Directory Server は 50,000 を超える ACI を評価できますが、多数の ACI ステートメントを管理するのは困難です。ACI の数が多いと、人間の管理者が特定のクライアントが使用できるディレクトリーオブジェクトをすぐに判断することが難しくなります。
    Directory Server は、マクロを使用してディレクトリー内の ACI の数を最小限に抑えます。マクロは、ACI の DN または DN の一部を表すために使用されるプレースホルダーです。マクロを使用して、ACI のターゲット部分、バインドルール部分、またはその両方で DN を表現することができます。マクロ ACI の詳細は、『Red Hat Directory Server Administration Guide』の Managing Access Control の章を参照してください。
  • アクセス許可の許可と拒否のバランスを取ります。
    デフォルトのルールでは、特にアクセスを許可されていないユーザーへのアクセスは拒否されますが、1 つの ACI を使用してツリーのルートに近いアクセスを許可し、少数の拒否を許可することで、ACI の数を減らす方がよい場合があります。リーフエントリーに近い ACI。このシナリオでは、リーフエントリーの近くで複数の許可 ACI を使用することを回避できます。
  • 特定の ACI で最小の属性セットを特定します。
    オブジェクトの属性のサブセットへのアクセスを許可または拒否する場合、最小のリストが、許可される属性のセットであるか、拒否される属性のセットであるかを決定します。次に、最小のリストのみを管理する必要があるように ACI を表現します。
    たとえば、person オブジェクトクラスには多数の属性が含まれます。ユーザーがこれらの属性の 1 つまたは 2 つだけを更新できるようにするには、それらのいくつかの属性のみに書き込みアクセスを許可するように ACI を記述します。ただし、1 つまたは 2 つの属性を除くすべての属性をユーザーが更新できるようにするには、いくつかの名前付き属性を除くすべての属性に対して書き込みアクセスを許可するように ACI を作成します。
  • LDAP 検索フィルターの使用には注意が必要です。
    検索フィルターは、アクセスを管理しているオブジェクトに直接名前を付けません。したがって、それらを使用すると、予期しない結果が生じる可能性があります。これは、ディレクトリーがより複雑になるにつれて特に当てはまります。ACI で検索フィルターを使用する前に、同じフィルターを使用して ldapsearch 操作を実行し、変更の結果がディレクトリーにとって何を意味するかを明確にします。
  • ディレクトリーツリーの異なる部分で ACI を複製しないでください。
    ACI の重複を防ぎます。たとえば、commonName 属性および givenName 属性へのグループの書き込みアクセスを許可する ACI と、同じグループの書き込みアクセスを許可する別の ACI がディレクトリールートポイントにある場合は、1 つの制御のみがグループに書き込みアクセスを付与するように ACI を再起動することを検討してください。commonName
    ディレクトリーが複雑になるにつれて、誤って ACI が重複するリスクが急速に高まります。ACI の重複を避けることで、セキュリティー管理が容易になり、ディレクトリーに含まれる ACI の総数が減る可能性があります。
  • ACI に名前を付けます。
    ACI の命名は任意ですが、各 ACI に短くて意味のある名前を付けることは、セキュリティーモデルの管理に役立ちます。
  • ディレクトリー内で ACI をできるだけ密接にグループ化します。
    ACI の配置をディレクトリールートポイントと主要なディレクトリーブランチポイントに制限するようにしてください。ACI をグループ化すると、ディレクトリー内の ACI の総数を最小限に抑えるだけでなく、ACI の合計リストを管理するのにも役立ちます。
  • バインド DN が cn=Joe と等しくない場合に書き込みを拒否する など、二重否定を使用しないでください。
    この構文はサーバーには完全に受け入れられますが、人間の管理者にとっては混乱を招きます。

9.7.5. ルート DN への ACI の適用 (Directory Manager)
リンクのコピー

通常のアクセス制御ルールは、Directory Manager ユーザーには適用されません。Directory Manager は、通常のユーザーデータベースではなく dse.ldif ファイルで定義されているため、ACI ターゲットにはそのユーザーが含まれません。
また、メンテナンスの観点からも理にかなっています。Directory Manager では、メンテナンスタスクを実行し、インシデントへの対応に高いレベルのアクセスが必要です。
それでも、Directory Manager ユーザーの権限により、ある程度のアクセス制御は、root ユーザーとして、承認されていないアクセスや攻撃を阻止することを推奨します。
RootDN アクセス制御プラグインは、Directory Manager ユーザーに固有の特定のアクセス制御ルールを設定します。
  • 8 a.m. から 5 p.m.までのような時間的な範囲での時間ベースのアクセス制御(0800 - 1700)。
  • 曜日のアクセス制御により、アクセスは明示的に定義された日数でのみ許可されます。
  • 指定した IP アドレス、ドメイン、またはサブネットのみが明示的に許可または拒否される IP アドレスルールです。
  • ホストアクセスルール。指定されたホスト名、ドメイン名、またはサブドメインのみが明示的に許可または拒否されます。
他のアクセス制御ルールと同様、deny ルールは allow ルールよりも優先されます。
重要
Directory Manager が常に適切なレベルのアクセスを許可されていることを確認してください。Directory Manager は、オフタイム (ユーザーの負荷が少ない時) や障害対応のためにメンテナンス作業を行う必要があります。その場合、時間や曜日ベースのアクセス制御ルールを厳しく設定すると、Directory Manager がディレクトリーを適切に管理できなくなる可能性があります。
ルート DN アクセス制御ルールはデフォルトで無効になっています。RootDN アクセスコントロールプラグインを有効にする必要があります。その後、適切なアクセスコントロールルールを設定できます。
注記
Directory Manager には 1 つのアクセス制御ルールがあり、プラグインエントリーには、ディレクトリー全体のすべてのアクセスに適用されます。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat