Group and role management
This chapter discusses the way groups and roles are managed in the directory server. The groups/roles are the easiest means of segregating users with like profiles/privileges. For example, if you want to give a common permission to a set of 100 users then it would be difficult if you try manipulating access on an individual basis. On the other hand if you create a group with these 100 users as its members and assign the permissions you want to the group, things would be much more easier. On same lines you can create a role and have that role assigned to these 100 users. You can set the permissions at the role level and achieve the same thing as you do by using a group.
There is a very thin boundary between a role and a group. There is just a conceptual difference between the two. Even the objectclass used to define a a nd a Role are same. The Role is just a different view of a Group and vise-versa. You say a group of engineers. Now it is also possible to create a Role with the name engineer. Whoever conforms to this Role possesses the attributes assigned to the Role. In other words, whoever is assigned the role of system administrator possesses the privileges assigned to the role system administrator. It is as like saying whoever belongs to the group of system administrators would be carrying the attributes defined for the role system administrators.
12.1 Groups
A group is a list, a collection of names. A groups can be used in attributes as like aclentry, ibm-fliterAclEntry, and entryowner to implement access control or in application-specific uses such as a mailing list (Refer Chapter 14, “Access control” on page 395, for further information on aclentry, ibm-filterAclEntry and entryowner attributes). Groups can be defined as either static, dynamic, or nested.
12.1.1 Static groups
A static group defines each member individually using the structural objectclass groupOfNames, groupOfUniqueNames, accessGroup, or accessRole, or by using the auxiliary objectclass ibm-staticgroup. The objectclass groupOfNames has its member attribute as a required attribute. The objectclass groupOfUniqueNames has its uniqueMember attribute as a required attribute. The objectclasses accessGroup, accessRole and ibm-staticgroup have their attribute member as an optional one and hence can be empty/null (with no members) while creating the group. Note that attributes member and uniqueMember attributes are multivalued.
A typical group entry is:
dn: cn=Dev.Staff,ou=Austin,c=US
objectclass: accessGroup
cn: Dev.Staff
member: cn=John Doe,o=IBM,c=US
member: cn=Jane Smith,o=IBM,c=US
member: cn=James Smith,o=IBM,c=US
Each group object contains a multivalued attribute consisting of member DNs.
Upon deletion of an access group, the access group is also deleted from all ACLs to which it has been applied.
Let us see how a static group is created. There are two ways of doing the same.
Using Web Administration Tool
Using the Web Administration Tool:
1. Connect to the desired server using the Web Administration Tool.
2. If you have not done so already, expand the Directory management category in the navigation area.
3. Click Add an entry.
4. Select one of the Structural object classes from the list box. You may select any of the four objectclasses: groupOfNames, groupOfUniqueNames, accessGroup, or accessRole. You also have an option to select any other objectclass in this step and go to the next page.
5. If you have already specified one of the above four groups as your objectclass then you may skip this step, else you can select the auxiliary class ibm-staticGroup and press Next.
6. In the Relative DN field, enter the relative distinguished name (RDN) of the group that you are creating, for example, cn=staticgroup.
7. In the Parent DN field, enter the distinguished name of the tree entry you selected, for example, o=IBM, c=US. You can also click Browse to select the Parent DN from the list. You can also expand the selection to view other choices lower in the subtree. Specify your choice and click Select to specify the Parent DN that you want. The Parent DN defaults to the entry selected in the tree.
 
Note: If you started this task from the Manage entries panel, this field is prefilled for you. You selected the Parent DN before clicking Add to start the process of creating a group.
8. Now you would need to specify the member, if member is a mandatory field (depends upon the objectclass you have chosen for your static group). If you do not want to add members at this stage you may skip the step (this is possible only in case the member/uniquemember attribute is optional).
9. The group is created at this point and you can view it as any other normal entry.
The above procedure shows that creating a group is as like creating a normal entry. The only point to remember is that you need to use the objectclasses as applicable for groups, those mentioned above.
Through the command line
Here is the procedure of creating a static group using an LDIF file.
Assuming that we have an ldif file, test.ldif with the following entries:
dn: cn=staticGroup 1,o=ibm,c=us
objectclass: accessGroup
objectclass: top
cn: staticGroup 1
The following command would add the group for you:
C:> ldapadd -D <admin DN> -w <admin PW> -i test.ldif
adding new entry cn=staticGroup 1,o=ibm,c=us
You can verify that the group actually exists or not, by browsing through the Web Administration tool or by firing a search as like:
E:>ldapsearch -D <admin DN> -w <admin PW> -b "cn=staticgroup 1,o=ibm,c=us" objectclass=*
cn=staticGroup 1,o=ibm,c=us
objectclass=accessGroup
objectclass=top
cn=staticGroup 1
Now let us see the procedure for adding/removing a member to/from a group.
Using the Web Administration Tool
To use this:
1. If you have not done so already, expand the Directory management category in the navigation area, then click Manage entries.
2. You can expand the various subtrees and select the entry (group) that you want to work on. Click Edit attributes from the right-side tool bar.
3. At the Required attributes tab enter the values for the required attributes.
4. Search for the member attribute. Depending upon the objectclass, chosen for the group, it may be in the tab of Required attributes or in the tab of Optional attributes.
5. To add members to the group:
a. Click either Multiple values which is by the Member attribute field on the Required attributes tab, or click Members by the Member attribute field on the Members tab.
b. In the Member field, enter the DN of the entry you want to add.
c. Click Update/Add (depends upon the panel your in to add the member).
d. Click OK.
6. To remove members from the group:
a. Either click Multiple values by the Members attribute field on either the Required attributes or the Other attributes tabs.
b. Select the entry you want to remove.
c. Click Remove.
d. Click OK.
Refer to Figure 12-1 on page 305 for the screenshot of the panel where you would be adding/removing members to/from a group.
Figure 12-1 Add or remove members
Through command line
This syntax is not much different than the ldapmodify syntax you use to modify an entry.
Adding a member
Assuming the fact that we have an ldif file, test.ldif, with the following contents:
dn: cn=staticGroup 1,o=ibm,c=us
changetype: modify
add: member
member: cn=member4,o=ibm,c=us
Here is the command you need to execute:
E:>ldapmodify -D cn=root -w secret -f test.ldif
modifying entry cn=staticGroup 1,o=ibm,c=us
Here is the verification that the member actually got added:
E:>ldapsearch -D cn=root -w secret -b "cn=staticgroup 1,o=ibm,c=us" objectclass=* ibm-allmembers
cn=staticGroup 1,o=ibm,c=us
ibm-allmembers=CN=USER1,O=IBM,C=US
ibm-allmembers=CN=MEMBER4,O=IBM,C=US
Do not worry much about the attribute used to fetch the members of the group. You will be seeing more details on the same, shortly.
Removing a member
Assuming the fact that we have an ldif file, test.ldif, with the following contents:
dn: cn=staticGroup 1,o=ibm,c=us
changetype: modify
add: member
member: cn=member4,o=ibm,c=us
Here is the command you need to execute:
E:>ldapmodify -D cn=root -w secret -f test.ldif
modifying entry cn=staticGroup 1,o=ibm,c=us
Here is the procedure you need to use to verify that the member actually got removed:
E:>ldapsearch -D cn=root -w secret -b "cn=staticgroup 1,o=ibm,c=us" objectclass=* ibm-allmembers
cn=staticGroup 1,o=ibm,c=us
ibm-allmembers=CN=USER1,O=IBM,C=US
12.1.2 Dynamic groups
A dynamic group defines its members differently than a static group. Instead of listing them individually, the dynamic group defines its members using an LDAP search. The dynamic group uses the structural objectclass groupOfURLs (or auxiliary objectclass ibm-dynamicGroup) and the attribute, memberURL to define the search using a simplified LDAP URL syntax.
ldap:///<base DN of search>? ?<scope of search>?<searchfilter>
 
Note: From the LDAP URL that is shown above it is clear, that the host name must not be present in the syntax. The remaining parameters are just like normal ldap URL syntax. Each parameter field must be separated by a ?, even if no parameter is specified. Normally, a list of attributes to return would be included between the base DN and scope of the search. This parameter is also not used by the server when determining dynamic membership, and so may be omitted, however, the separator ? must still be present.
Where:
•base DN of search
This is the point from which the search begins in the directory. It can be the suffix or root of the directory such as ou=Austin. This parameter is required.
•scope of search
Specifies the extent of the search. The default scope is base.
 – base - Returns information only about the base DN specified in the URL.
 – one - Returns information about entries one level below the base DN specified in the URL. It does not include the base entry.
 – sub - Returns information about entries at all levels below and includes the base DN.
•searchfilter
This is the filter that you want to apply to the entries within the scope of the search. See the ldapsearch filter option in Chapter 10 for information about the syntax of the searchfilter. The default is objectclass=*.
The search for dynamic members is always internal to the server, so unlike a full ldap URL, a host name and port number is never specified, and the protocol is always ldap (never ldaps). The memberURL attribute may contain any kind of URL, but the server only uses memberURLs beginning with ldap:/// to determine dynamic membership.
Examples
A single entry in which the scope defaults to base and the filter defaults to objectclass=*:
ldap:///cn=John Doe, cn=Employees, o=Acme, c=US
All entries that are 1-level below cn=Employees, and the filter defaults to objectclass=*:
ldap:///cn=Employees, o=Acme, c=US??one
All entries that are under o=Acme,c=us with the objectclass=person:
ldap:///o=Acme, c=US??sub?objectclass=person
Depending on the object classes you use to define user entries, those entries might not contain attributes which are appropriate for determining group membership. You can use the auxiliary object class, ibm-dynamicMember, to extend your user entries to include the ibm-group attribute. This attribute allows you to add arbitrary values to your user entries to serve as targets for the filters of your dynamic groups. For example, the members of this dynamic group are entries directly under the cn=users,ou=Austin entry that have an ibm-group attribute of GROUP1:
dn: cn=GROUP1,ou=Austin
objectclass: groupOfURLs
cn: GROUP1
memberURL: ldap:///cn=users,ou=Austin??one?(ibm-group=GROUP1)
Here is an example member of cn=GROUP1,ou=Austin:
dn: cn=Group 1 member, cn=users, ou=austin
objectclass: person
objectclass: ibm-dynamicMember
sn: member
userpassword: memberpassword
ibm-group: GROUP1
Now let us see the procedure for adding/removing a member to/from a group.
Using the Web Administration Tool
The procedure for adding a dynamic group through the Web Administration tool is as like the procedure for static groups, except for the fact that:
•You need to use the structural object class groupOfUrls or either of the auxiliary classes ibm-dynamicGroup or ibm-dynamicMember for creating the dynamic group.
•You need to mention the LDAP URL for the dynamic members against the memberURL attribute, in case the objectclass, chosen for the group is either groupOfUrls or ibm-dynamicGroup.
•In case you have selected ibm-dynamicMember as your auxiliary objectclass, you need to use the attribute ibm-group as explained earlier.
•Both the memberURL and the ibm-group are multivalued optional attributes.
Refer to Figure 12-2 on page 309 for a screenshot of the panel listing the users of a dynamic group, based on the LDAP URL you have specified. Please note that a similar output is expected to verify that the dynamic group creation was successful.
Figure 12-2 Members evaluated against an LDAP URL
Now let us see the similar procedure via command line.
Using the command line
Assuming that we have an ldif file named test.ldif as like:
cn=dynamicgroup 1,o=ibm,c=us
objectclass=groupOfURLs
objectclass=top
cn=dynamicgroup 1
memberurl=ldap:///o=ibm,c=us??one?cn=user*
Execute the following command to add the group:
E:>ldapadd -D cn=root -w secret -f test.ldif
adding new entry cn=dynamicgroup 1,o=ibm,c=us
Let us see what are the members, that the group contains:
E:>ldapsearch -D cn=root -w secret -b "cn=dynamicgroup 1,o=ibm,c=us" objectclass=* ibm-allmembers
cn=dynamicgroup 1,o=ibm,c=us
ibm-allmembers=CN=USER1,O=IBM,C=US
ibm-allmembers=CN=USER3,O=IBM,C=US
ibm-allmembers=CN=USER4,O=IBM,C=US
Deleting or removing members is very much like normal entries. You would just need to modify the relevant attributes that hold the URL to the group members. You can do this either through the Web Administration Tool or through the command line.
12.1.3 Nested groups
The nesting of groups enables the creation of hierarchical relationships that can be used to define inherited group membership. A nested group is defined as a child group entry whose DN is referenced by an attribute contained within a parent group entry. A parent group is created by extending one of the structural group object classes (groupOfNames, groupOfUniqueNames, accessGroup, accessRole, or groupOfURLs) with the addition of the ibm-nestedGroup auxiliary object class. After nested group extension, zero or more ibm-memberGroup attributes may be added, with their values set to the DNs of nested child groups. For example:
dn: cn=Group 2, cn=Groups, o=IBM, c=US
objectclass: groupOfNames
objectclass: ibm-nestedGroup
objectclass: top
cn: Group 2
description: Group composed of static, and nested members.
member: cn=Person 2.1, cn=Dept 2, cn=Employees, o=IBM, c=US
member: cn=Person 2.2, cn=Dept 2, cn=Employees, o=IBM, c=US
ibm-memberGroup: cn=Group 8, cn=Nested Static, cn=Groups, o=IBM, c=US
 
 
Note: The introduction of cycles into the nested group hierarchy is not allowed. If it is determined that a nested group operation results in a cyclical reference, either directly or through inheritance, it is considered a constraint violation and therefore, the update to the entry fails.
Now let us see the procedure for adding/removing a member to/from a group.
Using the Web Administration Tool
The procedure for adding a dynamic group through the Web Administration tool remains the same as the static group, except for the fact that:
•You need to have one structural objectclass as like the one for static groups / dynamic groups.
•You need to have one auxiliary objectclass, which happens to be ibm-nestedGroup.
•The rules for mentioning the static members/dynamic members remain the same as explained earlier.
•The nested group needs to be mentioned against the ibm-memberGroup attribute, which happens to be a multi-valued, optional attribute.
Refer Figure 12-3 for a screenshot of the panel listing the users of a nested group, based on the static members and the member group(s) that you have specified. Please note that a similar output is expected to verify that the nested group creation was successful.
Figure 12-3 Member listing of a nested group
The procedure on the command line can be derived on the lines of command line procedures for static and dynamic groups, it is just a matter of using the right objectclass, while defining the group.
12.1.4 Hybrid groups
Any of the structural group object classes, mentioned in the earlier sections, can be extended such that group membership is described by a combination of static, dynamic, and nested member types.
For example:
dn: cn=Group 10, cn=Groups, o=IBM, c=US
objectclass: groupOfURLs
objectclass: ibm-nestedGroup
objectclass: ibm-staticGroup
objectclass: top
cn: Group 10
description: Group composed of static, dynamic, and nested members.
memberURL: ldap:///cn=Austin, cn=Employees, o=IBM, c=US??one?objectClass=person
ibm-memberGroup: cn=Group 9, cn=Nested Dynamic, cn=Groups, o=IBM, c=US
member: cn=Person 10.1, cn=Dept 2, cn=Employees, o=IBM, c=US
member: cn=Person 10.2, cn=Dept 2, cn=Employees, o=IBM, c=US
The methods to create such a group are just the combination of what we have seen in case of static groups, dynamic groups and nested groups as three separate cases.
12.1.5 Determining group membership
Two operational attributes can be used to query aggregate group membership. For a given group entry, the ibm-allMembers 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 ibm-allGroups operational attribute enumerates the aggregate set of groups, including ancestor groups, to which that user has membership.
A requester may only receive a subset of the total data requested, depending on how the ACLs have been set on the data. Anyone can request the ibm-allMembers and ibm-allGroups 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 ibm-allMembers or ibm-allGroups attribute must have access to the member or uniquemember 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 memberURL attribute values in order to see dynamic members. Let us take some examples. First let us see a hierarchy tree, which is going to be used in our examples.
Figure 12-4 Hierarchy of groups and members
Hierarchy examples
For this example as shown in Figure 12-4, m1 and m2 are in the member attribute of g2. The ACLs for g2 allows user1 to read the member attribute, but user2 does not have access to the member attribute. The entry LDIF for the g2 entry is as follows:
dn: cn=g2,cn=groups,o=ibm,c=us
objectclass: accessGroup
cn: g2
member: cn=m1,cn=users,o=ibm,c=us
member: cn=m2,cn=users,o=ibm,c=us
aclentry: access-id:cn=user1,cn=users,o=ibm,c=us:normal:rsc
aclentry: access-id:cn=user2,cn=users,o=ibm,c=us:normal:rsc:at.member:deny:rsc
The g4 entry uses the default aclentry, which allows both user1 and user2 to read its member attribute. The LDIF for the g4 entry is as follows:
dn: cn=g4,cn=groups,o=ibm,c=us
objectclass: accessGroup
cn: g4
member: cn=m5, cn=users,o=ibm,c=us
The g5 entry is a dynamic group, which gets its two members from the memberURL attribute. The LDIF for the g5 entry is as follows:
dn: cn=g5, cn=groups,o=ibm,c=us
objectclass: container
objectclass: ibm-dynamicGroup
cn: g5
memberURL: ldap:///cn=users,o=ibm,c=us??sub?(|(cn=m3)(cn=m4))
The entries m3 and m4 are members of group g5 because they match the memberURL attribute. The ACL for the m3 entry allows both user1 and user2 to search for it. The ACL for the m4 entries does not allow user2 to search for it. The LDIF for m4 is as follows:
dn: cn=m4, cn=users,o=ibm,c=us
objectclass:person
cn: m4
sn: four
aclentry: access-id:cn=user1,cn=users,o=ibm,c=us:normal:rsc
aclentry: access-id:cn=user2,cn=users,o=ibm,c=us
Example 1
User1 does a search to get all the members of group g1. User1 has access to all members, so they are all returned.
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
Example 2
User2 does a search to get all the members of group g1. User2 does not have access to members m1 or m2 because they do not have access to the member attribute for group g2. User2 has access to the member attribute for g4 and therefore has access to member m5. User2 can perform the search in the group g5 memberURL for entry m3, so that members are listed, but cannot perform the search for m4.
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
Example 3
User2 does a search to see if m3 is a member of group g1. User2 has access to do this search, so the search shows that m3 is a member of group g1.
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
Example 4
User2 does a search to see if m1 is a member of group g1. User2 does not have access to the member attribute, so the search does not show that m1 is a member of group g1.
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
Checking group membership using the Web Administration Tool
To check:
1. Connect to the relevant server through Web Administration Tool.
2. If you have not done so already, expand the Directory management category in the navigation area.
3. Click Manage entries.
4. Select a user from the directory tree and click the Edit attributes icon that appears at the right side of the main panel.
5. Click the Memberships tab.
6. That will show you all the groups to which this user/entry belongs to and also a lot of additional stuff as is explained further.
Refer to Figure 12-5 for the panel which shows the group memberships of a user.
Figure 12-5 Change group membership
To modify the memberships for the user, the Change memberships panel (as shown in Figure 12-5 on page 315) displays the Available groups to which the user can be added, as well as the entry’s Static Group Memberships.
1. Select a group from Available groups and click Add to make the entry a member of the selected group.
2. Select a group from Static Group Memberships and click Remove in case you need to remove the entry from the selected group.
3. Click OK to save your changes or click Cancel to return to the previous panel without saving your changes.
12.1.6 Group object classes
In this section we discuss group object classes.
ibm-dynamicGroup
This auxiliary class allows the optional memberURL attribute. Use it with a structural class such as groupOfNames to create a hybrid group with both static and dynamic members.
ibm-dynamicMember
This auxiliary class allows the optional ibm-group attribute. Use it as a filter attribute for dynamic groups.
ibm-nestedGroup
This auxiliary class allows the optional ibm-memberGroup attribute. Use it with a structural class such as groupOfNames to enable sub-groups to be nested within the parent group.
ibm-staticGroup
This auxiliary class allows the optional member attribute. Use it with a structural class such as groupOfURLs to create a hybrid group with both static and dynamic members.
 
Note: The ibm-staticGroup is the only class for which member is optional, all other classes taking member require at least 1 member.
12.1.7 Group attribute types
In this section we discuss group attribute types.
ibm-allGroups
Shows all groups to which an entry belongs. An entry can be a member directly by the member, uniqueMember, or memberURL attributes, or indirectly by the ibm-memberGroup attribute. This Read-only operational attribute is not allowed in a search filter.
ibm-allMembers
Shows all members of a group. An entry can be a member directly by the member, uniqueMember, or memberURL attributes, or indirectly by the ibm-memberGroup attribute. This Read-only operational attribute is not allowed in a search filter.
ibm-group
This is an attribute taken by the auxiliary class ibm-dynamicMember. Use it to define arbitrary values to control membership of the entry in dynamic groups. For example, add the value “Bowling Team” to include the entry in any memberURL that has the filter “ibm-group=Bowling Team”.
ibm-memberGroup
This is an attribute taken by the auxiliary class ibm-nestedGroup. It identifies sub-groups of a parent group entry. Members of all such sub-groups are considered members of the parent group when processing ACLs or the ibm-allMembers and ibm-allGroups operational attributes. The sub-group entries themselves are not members. Nested membership is recursive.
12.2 Roles
Role-based authorization is a conceptual complement to the group-based authorization, and is useful in some cases. As a member of a role, you have the authority to do what is needed for the role in order to accomplish a job. Unlike a group, a role comes with an implicit set of permissions. There is not any built-in assumption about what permissions are gained (or lost) by being a member of a group.
Roles are similar to groups in that they are represented in the directory by an object. Additionally, roles contain a group of DNs. Roles which are to be used in access control must have an objectclass of AccessRole. The Accessrole objectclass is a subclass of the GroupOfNames objectclass.
For example, if there is a collection of DNs such as ‘sys admin’, your first reaction may be to think of them as the ‘sys admin group’ (since groups and users are the most familiar types of privilege attributes). However, since there are a set of permissions that you would expect to receive as a member of ‘sys admin’ the collection of DNs may be more accurately defined as the ‘sys admin role’.
12.3 Summary
Now let us go through what we have covered in this chapter:
•We have seen that the directory management becomes much easier by means of groups and roles.
•We have seen the different types of groups:
 – Static groups
 – Dynamic groups
 – Nested groups
 – Hybrid groups
•We have seen how we can determine whether a given user is a member of a specific group and vice-versa.
•We have seen the objectclasses and attributes pertaining to groups.
•We have seen a set of examples to explain the concept and implementation of groups and roles.
 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset