18.12. エントリーのアクセス権利の確認 (Get Effective Rights)

ユーザーが特定のエントリー内の属性に対して持っているアクセス権を見つけることは、管理者がアクセス権限を見つけて制御するのための便利な方法を提供します。
Get effective rights は、ディレクトリー検索を拡張して、ユーザーが特定のエントリーに対してどのようなアクセス権 (読み取り、検索、書き込みと自己書き込み、追加、削除など) を持っているかを表示する方法です。
Directory Server では、通常のユーザーは、表示できるエントリーに対する権限を確認して、他の人による個人エントリーへのアクセスを確認することができます。Directory Manager は、あるユーザーが別のユーザーに属する権限を確認できます。
エントリーの実効権限を確認することが便利な状況は 2 つあります。
  • 管理者は、ディレクトリーに対するアクセス制御手順をより適切に整理するために、get effective rights コマンドを使用できます。あるグループのユーザーが閲覧または編集できる内容を、別のグループと比較して制限する必要があることがよくあります。たとえば、QA Managers グループのメンバーには、manager や salary などの属性を検索および読み取る権利がありますが、HR Group メンバーのみが変更または削除する権限を持ちます。ユーザーまたはグループの実効権限を確認する方法は、適切なアクセス制御が有効であることを確認する方法です。
  • ユーザーは、get effective rights コマンドを実行して、個人エントリーで表示または変更できる属性を確認することができます。たとえば、ユーザーは homePostalAddress や cn などの属性にアクセスできますが、manager 属性および salary 属性への読み取りアクセスしかできません。
getEffectiveRights 検索には、エンティティーが 3 つあります。1 つ目は、getEffectiveRights 検索操作の実行時に認証済みエントリーである requester です。2 つ目は、権限の評価に使用される サブジェクト で、GER 制御の 承認 DN として定義されます。3 つ目は、要求の検索ベース、検索フィルター、属性リストで定義される ターゲット です。

18.12.1. Get Effective Rights 検索表示される権限

コマンドラインでの get effective rights の検索時に、要求側がターゲットエントリーに対して必要とする権限が表示されます。
任意のエントリーに指定できるアクセス権には、2 種類があります。1 つ目は上位の権利で、エントリー自体に対する権利 です。つまり、ユーザー A がユーザー B のエントリー全体に対して実行できる操作の種類を意味します。第 2 レベルのアクセス権はより詳細で、ユーザー A が ある属性に対してどのような権利 を有しているかを示しています。この場合、ユーザー A は同じエントリーで異なる属性のアクセスパーミッションがある可能性があります。ユーザーに許可されるアクセス制御は、そのエントリーに対する 有効な 権限です。
以下に例を示します。 
entryLevelRights: vadn
attributeLevelRights: givenName:rscWO, sn:rscW, objectClass:rsc, uid:rsc, cn:rscW
表18.2「エントリーの権限」および 表18.3「属性権」は、エントリーおよび属性へのアクセス権限をそれぞれ表示し、get effective rights 検索で返されます。

表18.2 エントリーの権限

パーミッション 説明
a エントリーを追加します。
d このエントリーを削除します。
n DN の名前を変更します。
v エントリーを表示します。

表18.3 属性権

パーミッション 説明
r 読み取り。
s 検索。
w 書き込み (mod-add)。
o 抹消 (mod-del)。削除に類似しています。
c 比較。
W 自己書き込み。
O 自己削除。

18.12.3. GER 検索の例

GER 検索を実行する方法は複数あります。返される情報のタイプや、検索されるエントリーおよび属性のタイプによって異なります。

18.12.3.1. アクセス権限の確認に関する一般的な例

効果的な権利検索のための一般的なシナリオとして、一般ユーザーが自身の個人的なエントリーにどのような変更を加えることができるかを判断することがあります。
たとえば、Ted Morris は、エントリーに対する権限を確認します。-D と -E オプションの両方により、そのエントリーは要求元として付与されます。-b オプションには、個人エントリーを確認するため、その DN も含まれます。

例18.36 個人の権利の確認 (ユーザー A からユーザー A)

# 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=*)"

 dn: uid=tmorris,ou=People,dc=example,dc=com
 givenName: Ted
 sn: Morris
 ou: IT
 ou: People
 l: Santa Clara
 manager: uid=jsmith,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: v
 attributeLevelRights: givenName:rsc, sn:rsc, ou:rsc, l:rsc, manager:rsc, roomNumber:rscwo, mail:rscwo, facsimileTelephoneNumber:rscwo, objectClass:rsc, uid:rsc, cn:rsc, userPassword:wo
Ted Morris は、たとえば、管理職であったり、IT や人事など、他のユーザーのエントリーを編集しなければならない部署で働いていたりします。この場合、例18.37「別のユーザーの権限を個人的に確認 (ユーザー A からユーザー B へ)」のように、Ted (-D) が Dave Miller のエントリー (-b) に対する自分の権利 (-E) を確認しているように、他のユーザーのエントリーに対して自分がどのような権利を持っているかを確認したい場合があります。

例18.37 別のユーザーの権限を個人的に確認 (ユーザー A からユーザー B へ)

# ldapsearch -p 389 -h server.example.com -D "uid=tmorris,ou=people,dc=example,dc=com" -W -b "uid=dmiller,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=*)"

dn: uid=dmiller,ou=People,dc=example,dc=com
...
entryLevelRights: vad
attributeLevelRights: givenName:rscwo, sn:rscwo, ou:rscwo, l:rscwo, manager:rsc, roomNumber:rscwo, mail:rscwo, facsimileTelephoneNumber:rscwo, objectClass:rscwo, uid:rscwo, cn:rscwo, userPassword:rswo
すべての属性について、Ted Morris は、Dave Miller のエントリーへのパーミッションを読み取り、検索、比較、修正、および削除するパーミッションがあります。これらの結果は、Ted Morris が自分のエントリーへのアクセスをチェックしたときに返されたものとは異なります。Ted Morris は個人的に、これらの属性のほとんどに対して読み取り、検索、比較の権利しか持っていなかったからです。
Directory Manager には、あるユーザーが別のユーザーのエントリーに対する権限をチェックする機能があります。例18.38「Directory Manager での別のユーザーに対する (User A からユーザー B に対する) 権利の確認」では、Directory Manager が、マネージャーである Jane Smith (-E) が部下である Ted Morris (-b) に対して持っている権限をチェックしています。

例18.38 Directory Manager での別のユーザーに対する (User A からユーザー B に対する) 権利の確認

# ldapsearch -p 389 -h server.example.com -D "cn=Directory Manager" -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=jsmith,ou=people,dc=example,dc=com' "(objectClass=*)"

dn: uid=tmorris,ou=People,dc=example,dc=com
...
entryLevelRights: vadn
attributeLevelRights: givenName:rscwo, sn:rscwo, ou:rscwo, l:rscwo, manager:rscwo, roomNumber:rscwo, mail:rscwo, facsimileTelephoneNumber:rscwo, objectClass:rscwo, uid:rscwo, cn:rscwo, userPassword:rscwo
管理者のみが、異なるユーザーがエントリーにある実効権限を取得することができます。Ted Morris が Dave Miller のエントリーを判定しようとすると、アクセスエラーが不十分になります。 
# ldapsearch -p 389 -h server.example.com -D "uid=dmiller,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=*)"

ldap_search: Insufficient access
ldap_search: additional info: get-effective-rights: requester has no g permission on the entry
ただし、一般ユーザーは get effective rights 検索を実行して、別のユーザーが個人エントリーに対して持っている権利を確認することができます。例18.39「個人のエントリーに対する他ユーザーの権利の確認」では、Ted Morris は、Dave Miller が Ted Morris のエントリーに対してどのような権利を持っているかを確認します。

例18.39 個人のエントリーに対する他ユーザーの権利の確認

# ldapsearch -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=dmiller,ou=people,dc=example,dc=com' "(objectClass=*)"

dn: uid=tmorris,ou=people,dc=example,dc=com
...
entryLevelRights: v
attributeLevelRights: givenName:rsc, sn:rsc, ou:rsc, l:rsc,manager:rsc, roomNumber:rsc, mail:rsc, facsimileTelephoneNumber:rsc, objectClass:rsc, uid:rsc, cn:rsc, userPassword:none
この場合、Dave Miller は、エントリーの DN を閲覧する権利と、ou、givenName、l、およびその他の属性を読み取り、検索し、比較する権利を有しており、userPassword 属性については権利を有していません。

18.12.3.2. Non-Existent 属性の Get Effective Rights 検索の例

デフォルトでは、値を持たないエントリーの属性には情報は提供されません。たとえば、userPassword の値が削除された場合、上記のエントリーで将来的に有効な権利を検索しても、自己書き込みおよび自己削除の権利が許可されていても、userPassword に対する有効な権利は返されません。
get effective rights 検索でアスタリスク (*) を使用すると、エントリーに設定されていない属性も含めて、そのエントリーで利用可能なすべての属性が返されます。

例18.40 Non-Existent 属性の有効な権限を返す

# ldapsearch -D "cn=Directory Manager" -W -b "uid=scarter,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" "*"  

dn: uid=scarter,ou=People,dc=example,dc=com
givenName: Sam
telephoneNumber: +1 408 555 4798
sn: Carter
ou: Accounting
ou: People
l: Sunnyvale
manager: uid=dmiller,ou=People,dc=example,dc=com
roomNumber: 4612
mail: scarter@example.com
facsimileTelephoneNumber: +1 408 555 9700
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: scarter
cn: Sam Carter
userPassword: {SSHA}Xd9Jt8g1UsHC8enNDrEmxj3iJPKQLItlDYdD9A==
entryLevelRights: vadn
attributeLevelRights: objectClass:rscwo, aci:rscwo, sn:rscwo, cn:rscwo, description:rscwo, seeAlso:rscwo, telephoneNumber:rscwo, userPassword:rscwo, destinationIndicator:rscwo, facsimileTelephoneNumber:rscwo, internationaliSDNNumber:rscwo, l:rscwo, ou:rscwo, physicalDeliveryOfficeName:rscwo, postOfficeBox:rscwo, postalAddress:rscwo, postalCode:rscwo, preferredDeliveryMethod:rscwo, registeredAddress:rscwo, st:rscwo, street:rscwo, teletexTerminalIdentifier:rscwo, telexNumber:rscwo, title:rscwo, x121Address:rscwo, audio:rscwo, businessCategory:rscwo, carLicense:rscwo, departmentNumber:rscwo, displayName:rscwo, employeeType:rscwo, employeeNumber:rscwo, givenName:rscwo, homePhone:rscwo, homePostalAddress:rscwo, initials:rscwo, jpegPhoto:rscwo, labeledUri:rscwo, manager:rscwo, mobile:rscwo, pager:rscwo, photo:rscwo, preferredLanguage:rscwo, mail:rscwo, o:rscwo, roomNumber:rscwo, secretary:rscwo, uid:rscwo,x500UniqueIdentifier:rscwo, userCertificate:rscwo, userSMIMECertificate:rscwo, userPKCS12:rscwo
secretary など、エントリーに使用できる属性はすべて、その属性が存在しない場合でも表示されます。

18.12.3.3. 特定の属性またはオブジェクトクラスの Get Effective Rights 検索の例

属性関連の GER 検索を追加で取り込むと、特定の属性への権限を検索し、属性セットを検索し、エントリーに設定したオブジェクトクラスのいずれかで使用できる属性をすべて表示することができます。
「Get Effective Rights 検索の形式」のフォーマット例に記載されているオプションの 1 つは attributeList です。特定属性のみの実効権限を返すには、search コマンドの最後に、属性をスペースで区切って指定します。

例18.41 特定の属性に対する get effective rights の結果

# ldapsearch -D "cn=Directory Manager" -W -b "uid=scarter,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" cn mail initials  

dn: uid=scarter,ou=People,dc=example,dc=com
cn: Sam Carter
mail: scarter@example.com
entryLevelRights: vadn
attributeLevelRights: cn:rscwo, mail:rscwo, initials:rscwo
例18.41「特定の属性に対する get effective rights の結果」の initials 属性のように、attributeList に存在しない属性を指定することで、アスタリスクを使用してすべての属性をリストアップするのと同様に、利用可能な権利を確認することができます。
Directory Manager は、特定のオブジェクトクラスで利用可能なすべての属性の権限をリスト表示することもできます。このオプションの形式は attribute@objectClass です。これにより、2 つのエントリーが返されます。1 つ目は指定された GER サブジェクトのエントリー、2 つ目はオブジェクトクラスのテンプレートエントリーです。

例18.42 オブジェクトクラス内の属性に対する get effective rights 結果

# ldapsearch -D "cn=Directory Manager" -W -b "uid=scarter,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" uidNumber@posixAccount   
...
dn: cn=template_posixaccount_objectclass,uid=scarter,ou=people,dc=example,dc=com
uidnumber: (template_attribute)
entryLevelRights: v
attributeLevelRights: uidNumber:rsc
注記
検索形式 attribute@objectClass は、要求元 (-D) が Directory Manager の場合のみ利用できます。
特定の属性の代わりにアスタリスク (*) を使用すると、指定された GER サブジェクトのすべての属性 (present と non-existent) と、オブジェクトクラステンプレートの属性の全リストが返されます。

例18.43 オブジェクトクラスのすべての属性に対する get effective rights 結果

# ldapsearch -D "cn=Directory Manager" -W -b "uid=scarter,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" *@posixaccount   
...
dn: cn=template_posixaccount_objectclass,uid=scarter,ou=people,dc=example,dc=com 
objectClass: posixaccount 
objectClass: top 
homeDirectory: (template_attribute) 
gidNumber: (template_attribute) 
uidNumber: (template_attribute) 
uid: (template_attribute) 
cn: (template_attribute) 
entryLevelRights: v 
attributeLevelRights: cn:rsc, uid:rsc, uidNumber:rsc, gidNumber:rsc, homeDirectory:rsc, objectClass:rsc, userPassword:none, loginShell:rsc, gecos:rsc, description:rsc, aci:rsc

18.12.3.4. 存在しないエントリーの get effective rights 検索の例

管理者は、既存のアクセス制御ルールに基づいて、特定のユーザー (jsmith) が存在しないユーザーにどのような権限を確認したい場合があります。存在しないエントリーをチェックする場合、サーバーはそのサブツリー内にテンプレートエントリーを生成します。たとえば、テンプレートエントリー cn=joe new user,cn=accounts,ou=people,dc=example,dc=com を確認するには、サーバーは cn=template,cn=accounts,ou=people,dc=example,dc=com を作成します。
存在しないエントリーをチェックする場合、get effective rights 検索は、指定したオブジェクトクラスを使用して、(存在しない) エントリーのすべての属性を持つテンプレートエントリーを生成することができます。person のオブジェクトクラス (@person) を持つ cn=joe new user,cn=accounts,ou=people,dc=example,dc=com の場合、サーバーは cn=template_person_objectclass,cn=accounts,ou=people,dc=example,dc=com を生成します。
サーバーがテンプレートエントリーを作成すると、オブジェクトクラス定義の最初の MUST 属性を使用して RDN 属性を作成します (または、MUST 属性がない場合は MAY を使用します)。しかし、これは誤った RDN 値になる可能性があり、その結果、与えられたサブツリーに対して確立された ACI に違反または回避することになります。この場合は、使用する RDN 値をオブジェクトクラスを渡すことで指定できます。これには @objectclass:rdn_attribute の形式があります。
たとえば、RDN として、uidNumber の存在しない Posix エントリーについて scarter の権限を確認するには、次のコマンドを実行します。 
# ldapsearch -D "cn=Directory Manager" -W -b "ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" @posixaccount:uidnumber

dn: uidNumber=template_posixaccount_objectclass,ou=people,dc=example,dc=com
entryLevelRights: v
attributeLevelRights: description:rsc, gecos:rsc, loginShell:rsc, userPassword
 :rsc, objectClass:rsc, homeDirectory:rsc, gidNumber:rsc, uidNumber:rsc, uid:
 rsc, cn:rsc

18.12.3.5. 操作属性の get effective rights 検索の例

操作属性は、get effective rights 検索など、通常の ldapsearch で返されません。操作属性の情報を返すには、プラス記号 (+) を使用します。これにより、エントリーで使用できる操作属性のみが返されます。

例18.44 操作属性に対する get effective rights の結果

# ldapsearch -D "cn=Directory Manager" -W -x -b "uid=scarter,ou=people,dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" "+"  

dn: uid=scarter,ou=People,dc=example,dc=com
entryLevelRights: vadn
attributeLevelRights: nsICQStatusText:rscwo, passwordGraceUserTime:rscwo, pwdGraceUserTime:rscwo, nsYIMStatusText:rscwo, modifyTimestamp:rscwo, passwordExpWarned:rscwo, pwdExpirationWarned:rscwo, entrydn:rscwo, aci:rscwo, nsSizeLimit:rscwo, nsAccountLock:rscwo, passwordExpirationTime:rscwo, entryid:rscwo, nsSchemaCSN:rscwo, nsRole:rscwo, retryCountResetTime:rscwo, ldapSchemas:rscwo, nsAIMStatusText:rscwo, copiedFrom:rscwo, nsICQStatusGraphic:rscwo, nsUniqueId:rscwo, creatorsName:rscwo, passwordRetryCount:rscwo, dncomp:rscwo, nsTimeLimit:rscwo, passwordHistory:rscwo, pwdHistory:rscwo, nscpEntryDN:rscwo, subschemaSubentry:rscwo, nsYIMStatusGraphic:rscwo, hasSubordinates:rscwo, pwdpolicysubentry:rscwo, nsAIMStatusGraphic:rscwo, nsRoleDN:rscwo, createTimestamp:rscwo, accountUnlockTime:rscwo, copyingFrom:rscwo, nsLookThroughLimit:rscwo, nsds5ReplConflict:rscwo, modifiersName:rscwo, parentid:rscwo, passwordAllowChangeTime:rscwo, nsBackendSuffix:rscwo, nsIdleTimeout:rscwo, ldapSyntaxes:rscwo, numSubordinates:rscwo

18.12.3.6. get effective rights 結果とアクセスコントロールルールの例

get effective 権限は、get effective rights サブジェクトエントリーに対して有効な ACL に応じて返されます。
たとえば、この ACL が設定され、この例の目的でのみ ACL が設定されます。 
dn: dc=example,dc=com
objectClass: top
objectClass: domain
dc: example
aci: (target=ldap:///ou=Accounting,dc=example,dc=com)(targetattr="*")(version
 3.0; acl "test acl"; allow (read,search,compare) (userdn = "ldap:///anyone") ;)

dn: ou=Accounting,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Accounting
ACL には dc=example,dc=com サブツリーが含まれていないため、get effective rights 検索では、ユーザーに dc=example,dc=com エントリーに対する権限がないことが表示されます。

例18.45 ACL を設定しない (Directory Manager) Get Effective Rights の結果

# ldapsearch -D "cn=Directory Manager" -W -b "dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" "*@person"

dn: cn=template_person_objectclass,uid=scarter,ou=people,dc=example,dc=com
objectClass: person
objectClass: top
cn: (template_attribute)
sn: (template_attribute)
description: (template_attribute)
seeAlso: (template_attribute)
telephoneNumber: (template_attribute)
userPassword: (template_attribute)
entryLevelRights: none
attributeLevelRights: sn:none, cn:none, objectClass:none, description:none, seeAlso:none, telephoneNumber:none, userPassword:none, aci:none
Directory Manager ではなく通常のユーザーが同じコマンドを実行しようとすると、結果は単に空白になります。

例18.46 ACL を設定しない (通常ユーザー) Get Effective Rights の結果

# ldapsearch -D "uid=scarter,ou=people,dc=example,dc=com" -W -b "dc=example,dc=com" -E '!1.3.6.1.4.1.42.2.27.9.5.2=:dn:uid=scarter,ou=people,dc=example,dc=com' "(objectclass=*)" "*@person"

18.12.4. Get Effective Rights 戻りコード

Get Effective Rights 検索とエラーに重大度が設定されていない場合は、通常のエントリー情報が返されますが、entryLevelRights および attributeLevelRights の権限の代わりに、エラーコードが返されます。このコードにより、クエリーされたエントリーの設定に関する情報を取得できます。表18.4「返された結果コード」 は、エラーコードと、リレーが可能な潜在的な設定情報を要約します。

表18.4 返された結果コード

コード 説明
0 正常に完了しました。
1 操作エラー。
12 重要な拡張機能は利用できません。重大度式が true に設定され、クエリー対象のエントリーに有効な権限がない場合は、このエラーが返されます。
16 そのような属性はありません。アクセス権のために特定の属性をクエリーしましたが、その属性がスキーマに存在しない場合は、このエラーが返されます。
17 未定義の属性タイプ。
21 無効な属性構文。
50 権限が不十分。
52 利用できません。
53 不本意なパフォーマンス。
80 その他。