134 lines
8.2 KiB
HTML
134 lines
8.2 KiB
HTML
|
<?xml version="1.0" encoding="utf-8"?>
|
||
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
||
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
|
||
|
<head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
<meta name="dc.language" scheme="rfc1766" content="en-us" />
|
||
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
<!-- US Government Users Restricted Rights -->
|
||
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
<meta name="dc.date" scheme="iso8601" content="2005-09-06" />
|
||
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
<meta name="security" content="public" />
|
||
|
<meta name="Robots" content="index,follow"/>
|
||
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
<title>Directory Server (LDAP) - Determining group membership</title>
|
||
|
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
|
||
|
<link rel="stylesheet" type="text/css" href="ic.css" />
|
||
|
</head>
|
||
|
<body>
|
||
|
<a id="Top_Of_Page" name="Top_Of_Page"></a><!-- Java sync-link -->
|
||
|
<script language = "Javascript" src = "../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
||
|
|
||
|
<a name="rzahydetgpmem"></a>
|
||
|
<h4 id="rzahydetgpmem">Determining group membership</h4>
|
||
|
<p>Two operational attributes can be used to query aggregate group membership.
|
||
|
For a given group entry, the <span class="bold">ibm-allMembers</span> operational
|
||
|
attribute enumerates the aggregate set of group membership, including static,
|
||
|
dynamic, and nested members, as described by the nested group hierarchy. For
|
||
|
a given user entry, the <span class="bold">ibm-allGroups</span> operational
|
||
|
attribute enumerates the aggregate set of groups, including ancestor groups,
|
||
|
to which that user has membership.</p>
|
||
|
<p>A requester can only receive a subset of the total data requested, depending
|
||
|
on how the ACLs have been set on the data. Anyone can request the <span class="bold">ibm-allMembers</span> and <span class="bold">ibm-allGroups</span> operational
|
||
|
attributes, but the data set returned only contains data for the LDAP entries
|
||
|
and attributes that the requester has access rights to. The user requesting
|
||
|
the <span class="bold">ibm-allMembers</span> or <span class="bold">ibm-allGroups</span> attribute must have access to the <span class="bold">member</span> or <span class="bold">uniquemember</span> attribute values
|
||
|
for the group and nested groups in order to see static members, and must be
|
||
|
able to perform the searches specified in the <span class="bold">memberURL</span> attribute values in order to see dynamic members. For examples:</p>
|
||
|
<p><span class="bold">Hierarchy examples</span></p>
|
||
|
<div class="mmobj">
|
||
|
<img src="rzahy502.gif" alt="Example of a nested group hierarchy" /></div>
|
||
|
<p>For this example, <span class="bold">m1</span> and <span class="bold">m2</span> are in the member attribute of <span class="bold">g2</span>.
|
||
|
The ACL for <span class="bold">g2</span> allows <span class="bold">user1</span> to read the member attribute, but <span class="bold">user
|
||
|
2</span> does not have access to the member attribute. The entry LDIF for the <span class="bold">g2</span> entry is as follows:</p>
|
||
|
<pre class="xmp">dn: cn=<span class="bold">g2</span>,cn=groups,o=ibm,c=us
|
||
|
objectclass: accessGroup
|
||
|
cn: g2
|
||
|
member: cn=<span class="bold">m1</span>,cn=users,o=ibm,c=us
|
||
|
member: cn=<span class="bold">m2</span>,cn=users,o=ibm,c=us
|
||
|
aclentry: access-id:cn=<span class="bold">user1</span>,cn=users,o=ibm,c=us:normal:rsc
|
||
|
aclentry: access-id:<span class="bold">cn=user2</span>,cn=users,o=ibm,c=us:normal:rsc:at.member:deny:rsc
|
||
|
</pre><p class="indatacontent">The <span class="bold">g4</span> entry uses the default aclentry,
|
||
|
which allows both <span class="bold">user1</span> and <span class="bold">user2</span> to read its member attribute. The LDIF for the <span class="bold">g4</span> entry is as follows:</p>
|
||
|
<pre class="xmp">dn: cn=<span class="bold">g4</span>, cn=groups,o=ibm,c=us
|
||
|
objectclass: accessGroup
|
||
|
cn: g4
|
||
|
member: cn=<span class="bold">m5</span>, cn=users,o=ibm,c=us</pre>
|
||
|
<p>The <span class="bold">g5 </span>entry is a dynamic group, which
|
||
|
gets its two members from the memberURL attribute. The LDIF for the <span class="bold">g5</span> entry is as follows:</p>
|
||
|
<pre class="xmp">dn: cn=<span class="bold">g5</span>, cn=groups,o=ibm,c=us
|
||
|
objectclass: container
|
||
|
objectclass: ibm-dynamicGroup
|
||
|
cn: g5
|
||
|
memberURL: ldap:///cn=users,o=ibm,c=us??sub?(|(cn=<span class="bold">m3</span>)(cn=<span class="bold">m4</span>))</pre>
|
||
|
<p>The entries <span class="bold">m3</span> and <span class="bold">m4</span> are members of group <span class="bold">g5</span> because they
|
||
|
match the <span class="bold">memberURL</span> The ACL for the <span class="bold">m3</span> entry allows both <span class="bold">user1</span> and <span class="bold">user2</span> to search for it. The ACL for the <span class="bold">m4</span> entries doesn't allow <span class="bold">user2</span> to search
|
||
|
for it. The LDIF for <span class="bold">m4</span> is as follows:</p>
|
||
|
<pre class="xmp">dn: cn=<span class="bold">m4</span>, cn=users,o=ibm,c=us
|
||
|
objectclass:person
|
||
|
cn: m4
|
||
|
sn: four
|
||
|
aclentry: access-id:cn=<span class="bold">user1</span>,cn=users,o=ibm,c=us:normal:rsc
|
||
|
aclentry: access-id:cn=<span class="bold">user2</span>,cn=users,o=ibm,c=us</pre>
|
||
|
<dl>
|
||
|
<dt class="bold">Example 1:</dt>
|
||
|
<dd>User 1 does a search to get all the members of group <span class="bold">g1</span>. User 1 has access to all members, so they are all returned.
|
||
|
<pre class="xmp">ldapsearch -D cn=user1,cn=users,o=ibm,c=us -w user1pwd -s base -b cn=g1,
|
||
|
cn=groups,o=ibm,c=us objectclass=* ibm-allmembers
|
||
|
|
||
|
|
||
|
cn=g1,cn=groups,o=ibm,c=us
|
||
|
ibm-allmembers: CN=M1,CN=USERS,O=IBM,C=US
|
||
|
ibm-allmembers: CN=M2,CN=USERS,O=IBM,C=US
|
||
|
ibm-allmembers: CN=M3,CN=USERS,O=IBM,C=US
|
||
|
ibm-allmembers: CN=M4,CN=USERS,O=IBM,C=US
|
||
|
ibm-allmembers: CN=M5,CN=USERS,O=IBM,C=US</pre>
|
||
|
</dd>
|
||
|
<dt class="bold">Example 2:</dt>
|
||
|
<dd>User 2 does a search to get all the members of group <span class="bold">g1</span>. User 2 does not have access to members<span class="bold"> m1</span> or <span class="bold">m2</span> because they do not have access
|
||
|
to the member attribute for group <span class="bold">g2</span>. User
|
||
|
2 has access to the member attribute for <span class="bold">g4</span> and
|
||
|
therefore has access to member <span class="bold">m5</span>. User 2
|
||
|
can perform the search in the group <span class="bold">g5</span> memberURL
|
||
|
for entry <span class="bold">m3</span>, so that member are listed, but
|
||
|
cannot perform the search for <span class="bold">m4</span>.
|
||
|
<pre class="xmp">ldapsearch -D cn=user2,cn=users,o=ibm,c=us -w user2pwd -s base -b cn=g1,
|
||
|
cn=groups,o=ibm,c=us objectclass=* ibm-allmembers
|
||
|
|
||
|
|
||
|
cn=g1,cn=groups,o=ibm,c=us
|
||
|
ibm-allmembers: CN=M3,CN=USERS,O=IBM,C=US
|
||
|
ibm-allmembers: CN=M5,CN=USERS,O=IBM,C=US</pre>
|
||
|
</dd>
|
||
|
<dt class="bold">Example 3:</dt>
|
||
|
<dd>User 2 does a search to see if <span class="bold">m3</span> is
|
||
|
a member of group <span class="bold">g1</span>. User 2 has access to
|
||
|
do this search, so the search shows that <span class="bold">m3</span> is
|
||
|
a member of group <span class="bold">g1</span>.
|
||
|
<pre class="xmp">ldapsearch -D cn=user2,cn=users,o=ibm,c=us -w user2pwd -s base -b cn=m3,
|
||
|
cn=users,o=ibm,c=us objectclass=* ibm-allgroups
|
||
|
|
||
|
|
||
|
cn=m3,cn=users,o=ibm,c=us
|
||
|
ibm-allgroups: CN=G1,CN=GROUPS,O=IBM,C=US</pre>
|
||
|
</dd>
|
||
|
<dt class="bold">Example 4:</dt>
|
||
|
<dd>User 2 does a search to see if <span class="bold">m1</span> is
|
||
|
a member of group <span class="bold">g1</span>. User 2 does not have
|
||
|
access to the member attribute, so the search does not show that <span class="bold">m1</span> is a member of group <span class="bold">g1</span>.
|
||
|
<pre class="xmp">ldapsearch -D cn=user2,cn=users,o=ibm,c=us -w user2pwd -s base -b
|
||
|
cn=m1,cn=users,o=ibm,c=us objectclass=* ibm-allgroups
|
||
|
|
||
|
|
||
|
cn=m1,cn=users,o=ibm,c=us
|
||
|
</pre>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
|
||
|
</body>
|
||
|
</html>
|