Delegation of Administrative Rights in Tivoli Directory Server 6.1 Using Administrative Roles

Delegate administrative tasks with lot more granularity and flexibility

For better delegation of administrative rights, a "server administrative roles" feature has been added in the 6.1 release of IBM® Tivoli® Directory Server (TDS). This article takes a look at each administrative role in details and presents use cases to show how the role can be used in the real-life scenarios.

Share:

Chandrajit G. Joshi (chanjosh@in.ibm.com), Staff Software Engineer, Tivoli Directory Server Development, IBM

Chandrajit JoshiChandrajit G. Joshi is a part of the Tivoli Directory Server Development team at IBM India Software Lab, Pune. He has experience of more than nine years in the IT industry, mainly on the System Managed Storage products, batch processing and middleware products, and operating system. His current interests include high availability, fault tolerant and self healing systems, autonomic computing, operating systems and automated storage management.



Romil J. Shah (rshah@in.ibm.com), System Software Engineer, Tivoli Directory Server Development, IBM

Romil ShahRomil J. Shah is a part of Tivoli Directory Server development team at IBM India Software Lab, Pune for the past two years. He has four years of experience in the IT industry, mainly in embedded real-time operating system, device drivers, storage, middleware products, and operating systems. His areas of interest are distributed computing, RTOS, and autonomic computing.



19 September 2007

Introduction

In Tivoli Directory Server (TDS), the directory administrator, also known as root administrator (cn=root), is the most powerful user. This user can carry out all the administrative tasks related to a TDS instance, which include

  • Configuration of a server instance
  • Schema management
  • Directory database management
  • Replication setup & management
  • Server log files management

The security scheme of TDS 6.0 allows directory administrators to delegate some of their administrative tasks to "local administrative group members". These are the user accounts defined by the directory administrator in the server configuration file. This delegation of authority covers a wide spectrum of tasks, in the sense that it encompasses tasks related to multiple server components or tasks related to wide range of server functionalities. However, this security scheme does not give the directory administrators flexibility in delegating the admin rights. Hence, there was a need to implement a scheme whereby directory administrators can delegate the tasks at a more granular level, with more flexibility. This granularity and flexibility has been achieved by the addition of "server administrative roles" feature in TDS 6.1.

This feature enables directory administrators to assign administrative roles to the local administrative group members, which defines the administrative tasks a member can carry out. The one or more administrative roles that a local administrative group member can have are:

  • Audit Administrator
  • Directory Data Administrator
  • No Administrator
  • Password Administrator
  • Replication Administrator
  • Schema Administrator
  • Server Configuration Group Member and
  • Server Start and Stop Administrator

The article first lists the administrative and non-administrative rights associated with each of the administrative roles. It then discusses the possible hierarchies amongst different administrative roles, and then describes various special cases for different roles. Finally, it presents use cases that might be useful for the customers in using this feature in real life.

Some acronyms used throughout this article are given below.

  • TDS: Tivoli Directory Server
  • LAGM: Local Administrative Group Member
  • GAGM: Global Administrative Group Member
  • ExOp: Extended Operation

Introduction to the administrative roles

This section gives administrative and non-administrative rights associated with each of the administrative roles. Here, administrative rights mean the rights associated with a user that enable addition, modification, and deletion of user accounts apart from the user's own account, and addition, modification, and deletion of the configuration settings. Non-administrative rights essentially mean rights to read through the user accounts and read the configuration settings. However, this does not include the ability to read the user credentials if the account is not the user's own.

Audit Administrator: This role enables a LAGM to gain unrestricted access to the:

  • Audit log, Admin Audit log, and all other server logs
  • Audit log settings (cn=Audit, cn=Log Management, cn=Configuration)
  • Admin Audit log settings (cn=Admin Audit, cn=Log Management, cn=Configuration)
  • Default log management settings (cn=Default, cn=Log Management, cn=Configuration)
  • Read access to the audit encoded data in the cn=Monitor search. For example, ibm-auditEncodedDN, the number of Audit log messages or Audit failed messages.

By virtue of this access, the audit administrator is able to issue dynamic updates ("readconfig" ExOp) for the above mentioned log settings and "clearlog", "getlogsize" , and "readlog" ExOps for the server logs. Members having this role will have the following non-administrative access permissions.

  • Modify access to the ibm-slapdAdminPW attribute in their own configuration entries
  • Read access to all the entries in the configuration file except credentials of root administrator and other administrative group members
  • Read access to schema backend
  • Access to entries in RDBM backend through normal ACL evaluation

Directory Data Administrator: This role enables a LAGM to gain unrestricted access to the entries in the RDBM backend. However, for setting the password attribute of RDBM entries, the Directory Data Administrator still must follow the usual password policy rules that are in effect. Other administrative access permissions enabled by this role are:

  • Add, modify and delete access to Master DN and replication supplier entries in the configuration file of a consumer replica, only in conjunction with Schema Administrator and Server Configuration Group Member roles
  • Complete access to cn=Replication, cn=Configuration entry in the configuration file
  • Can issue "readconfig" ExOp for only cn=Replication, cn=Configuration and ibm-slapdAdminPW attribute in their own configuration entries
  • Can issue following ExOps: "Enable/Disable Tracing Dynamically", "cascrepl", "controlqueue", "controlrepl" "controlreplerr", "quiesce", "Kill Connection" (Except connection of root administrator), "evaluategroups", "repltopology", "Unique Attributes", "acctstatus", "locateEntry", "resumerole", & "Get Attribute Types"
  • Read access to the audit encoded data in the cn=Monitor search

Non-administrative access permissions that these members have are:

  • Modify access to the ibm-slapdAdminPW attribute in their own configuration entries.
  • Read access to all the entries in the configuration file except credentials of root administrator and other administrative group members.
  • Can issue "getlogsize" and "readlog" ExOps for all the TDS logs except Audit and Admin Audit logs.
  • Read access to schema backend.

No Administrator: This role provides a way for the directory administrator to take away the administrative privileges of an administrative group member. Members having this role will not have administrative privileges.

The non-administrative access permissions associated with this role are:

  • Modify access to the ibm-slapdAdminPW attribute within their own configuration entries
  • Read access to configuration file
  • Can issue "readconfig" ExOp for only ibm-slapdAdminPW attribute in their own configuration entries
  • Read access to schema backend
  • Access to entries in RDBM backend through normal ACL evaluation

Password Administrator: A LAGM with this role is authorized to change passwords and unlock accounts of users in the RDBM backend. However, password administrators are not allowed to access the GAGM accounts, in the sense that they cannot change the password or unlock the accounts of GAGMs. For changing the password, they need not follow the password policy constraints that are usually in effect. These members can issue "acctstatus" ExOp for all the users in the RDBM backend, except GAGMs.

This authority does not allow access permissions to the user accounts defined in the server configuration file. When the LAGMs having this role change their own passwords, the usual administration password policy rules apply to the new password.

Non-administrative access permissions associated with this role are:

  • Modify access to the ibm-slapdAdminPW attribute in their own configuration entries
  • Read access to all the entries in the configuration file except credentials of root administrator and other administrative group members
  • Can issue "readconfig" ExOp for only ibm-slapdAdminPW attribute in their own configuration entries
  • Can issue "getlogsize" and "readlog" ExOps for all the TDS logs except Audit and Admin Audit logs
  • Read access to schema backend.
  • Access to all the other attributes of entries in RDBM backend through the usual ACL evaluation

Replication Administrator: This role enables LAGMs to manage replication topology objects. And it enables unrestricted access to all the replication topology objects that reside in the RDBM backend of the master instance of TDS. However, it does not enable them to setup the replication topology completely, in the sense that they will not have authority to add the Master Server DN entry and replication supplier entries in the consumer replica's configuration file. To do this, they will need the help of other administrators who have access to add it (like the Directory Administrator or LAGMs having Directory Data Administrator, Schema Administrator and Server Configuration Group Member roles).

Other administrative rights associated with this role are:

  • Complete access to cn=Replication, cn=Configuration entry in the configuration file
  • Can issue "readconfig" ExOp for only cn=Replication, cn=Configuration and ibm-slapdAdminPW attribute in their own configuration entries
  • Can issue following ExOps: "cascrepl", "controlqueue", "controlrepl", "controlreplerr", "quiesce", "repltopology"
  • Complete access to all the replication topology objects in the RDBM backend. The determination of replication objects is done based on the presence of following objectclasses in the RDBM entry: ibm-replicationContext, ibm-replicaGroup, ibm-replicaSubentry, ibm-replicationAgreement, ibm-replicationCredentials, ibm-replicationCredentialsSimple, ibm-replicationCredentialsKerberos, ibm-replicationCredentialsExternal, ibm-replicationWeeklySchedule, ibm-replicationDailySchedule, and ibm-replicationFilter. They also have complete access to "cn=Replication, cn=Localhost" and "cn=Replication, cn=IBMpolicies" container objects, because the replication credentials, schedule and filter entries are stored under these containers

Non-administrative access permissions associated with this role are:

  • Modify access to the ibm-slapdAdminPW attribute in their own configuration entries
  • Read access to all the entries in the configuration file except credentials of root administrator and other administrative group members
  • Can issue "getlogsize" and "readlog" ExOps for all the TDS logs except Audit and Admin Audit logs
  • Read access to schema backend
  • Access to all other entries in RDBM backend through normal ACL evaluation

Schema Administrator: This role enables LAGMs to have the following administrative rights

  • Complete access to schema backend
  • Add, modify and delete access to Master Server DN and replication supplier entries in the configuration file of a consumer replica, only in conjunction with Directory Data Administrator and Server Configuration Group Member roles
  • Can issue "Get Attribute Types" ExOp, where they can request for all the attributes except encryptable and encrypted attributes

Non-administrative access permissions associated with this role are:

  • Modify access to the ibm-slapdAdminPW attribute in their own configuration entries
  • Read access to all the entries in the configuration file except credentials of root administrator and other administrative group members
  • Can issue "readconfig" ExOp only for ibm-slapdAdminPW attribute in their own configuration entries
  • Can issue "getlogsize", "readlog" ExOps for all the server logs except Audit and Admin Audit logs
  • Access to entries in RDBM backend through the usual ACL evaluation

Server Configuration Group Member: The administrative rights associated with this role are:

  • Add, modify and delete access to all the entries in the configuration file except the following: 1) ibm-slapdAdminDN, ibm-slapdAdminPW and ibm-slapdAdminGroupEnabled attributes under cn=Configuration entry, 2) Entries under cn=AdminGroup, cn=Configuration entry, 3) cn=Audit, cn=Log Management, cn=Configuration entry, 4) cn=Admin Audit, cn=Log Management, cn=Configuration entry, 5) Kerberos and Digest-MD5 root administrator bind attributes under cn=Kerberos, cn=Configuration or cn=Digest, cn=Configuration entries
  • Add, modify and delete access to Master Server DN and replication supplier entries in the configuration file of a consumer replica, only in conjunction with Directory Data Administrator and Schema Administrator roles
  • Can issue "readconfig" ExOp for entire configuration file
  • Can issue "getlogsize", and "readlog" ExOps for all the TDS logs. Can also issue "clearlog" ExOp for all the logs except Audit and Admin Audit logs
  • Read access to the audit encoded data in the cn=Monitor search

Non-administrative access permissions associated with this role are:

  • Modify access to ibm-slapdAdminPW attribute within their own configuration entries
  • Read access to all the entries in the configuration file except credentials of root administrator and other administrative group members
  • Read access to schema backend
  • Access to entries in RDBM backend through the usual ACL evaluation

Server Start/Stop Administrator: This role enables LAGMs to start and stop the server and the admin daemon. Hence, it also enables this administrator to issue the ExOps related to starting and stopping the server instance and the admin daemon. The non-administrative access permissions associated with this role are:

  • Modify access to the ibm-slapdAdminPW attribute within their own configuration entry
  • Read access to all the entries in the configuration file except credentials of root administrator and other administrative group members
  • Read access to the schema backend
  • Access to entries in RDBM backend through the usual ACL evaluation

Overlaps of administrative rights amongst various administrative roles

The following table gives cross-references of various administrative rights and the administrative roles, which is helpful in determining the overlaps of the administrative rights amongst various administrative roles:

Table 1: Cross references of admin rights and admin roles
Admin rights and access permissionsAudit AdminDirData AdminNo AdminPassword AdminReplication AdminSchema AdminServer Config Group MemberStart and Stop Admin
Audit and admin audit logsYes
Other server log filesYesYes
Configuration settings of audit and admin audit logsYes
Default configuration settings of logsYesYes
Entries in RDBM backendYes
Master server DN entry in the configuration fileNote 1Note 1Note 1
"cn=Replication, cn=Configuration" entryYesYes
Password setting and account unlocking operation as per password policy rulesYes
Password setting and account unlocking operation without following password policy rulesYes**
Replication topology objects in RDBM backendYesYes
Server schemaYes
"readconfig" ExOp for entire configuration FileYes
All the replication related ExOpsYesYes
Audit encoded data in "cn=Monitor" searchYesYesYes
"Account Status" ExOpYesYes
"Get Attribute Type" ExOpYesYes
ExOps related to starting and stopping server instance and admin daemonYes

Note1 - A LAGM has access to add, modify, and delete the master DN entry only if the member has all Directory Data Administrator, Schema Administrator and Server Configuration Group Member roles

** The Password Admin can change the password and unlock the accounts in the RDBM backend, except the GAGMs

For the details about the cross-references of various ExOps and the different administrative roles, please refer to the IBM Tivoli Directory Server Administration Guide V6.1.


Assignment of administrative roles

The administrative roles can be assigned to the LAGMs using the new ibm-slapdAdminRole attribute. This is a MUST attribute in the objectclass ibm-slapdAdminGroupMember and is multi-valued. Hence, multiple roles can be assigned to a member using multiple instances of this attribute. The list of allowable role values associated with various administrative roles is given below.

  • Audit Administrator: AuditAdmin
  • Directory Data Administrator: DirDataAdmin
  • No Administrator: NoAdmin
  • Password Administrator: PasswordAdmin
  • Replication Administrator: ReplicationAdmin
  • Schema Administrator: SchemaAdmin
  • Server Configuration Group Member: ServerConfigGroupMember
  • Server Start and Stop Administrator: ServerStartStopAdmin

The following example shows how roles can be assigned.

bash> idsldapadd -p <port> -D <adminDN> -w <adminPW>
dn: cn=lagm1, cn=AdminGroup, cn=Configuration
cn: lagm1
ibm-slapdAdminDN: cn=lagm1
ibm-slapdAdminPW: lagm1
ibm-slapdAdminRole: AuditAdmin
ibm-slapdAdminRole: DirDataAdmin
ibm-slapdAdminRole: SchemaAdmin
ibm-slapdAdminRole: ServerStartStopAdmin
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdAdminGroupMember

Special cases

This section covers special cases while assigning, deleting, or modifying the administrative roles. It also covers cases where administrative roles are denied administrative rights.

Default administrative roles: While assigning a role to a LAGM, the attribute ibm-slapdAdminRole should be set to the role value associated with that role. Because it is a MUST attribute, clients should specify it while adding LAGMs. However, if it is not specified, then the server internally sets it to the default role values. The default role values are such that the resultant LAGM is equivalent to the LAGM of TDS 6.0. This serves as backward compatibility for 6.0 clients. Hence, the 6.0 Web Administration tool can add LAGM entries in TDS 6.1 even when there is no way in it to specify the administrative roles. The default roles are:

  • Directory Data Administrator
  • Password Administrator
  • Schema Administrator
  • Server Configuration Group Member
  • Server Start and Stop Administrator

Special cases with no administrator role:
1. The No Administrator role is a way for the directory administrators to revoke all the administrative rights associated with a LAGM. If multiple roles are assigned to a LAGM and one of those is No Administrator, then the effective roles associated with that LAGM will be No Administrator. This means that all other roles will be ignored. The following examples show LAGM entries having effective role as No Administrator:

dn: cn=lagm2, cn=AdminGroup, cn=Configuration
cn: lagm2
ibm-slapdAdminDN: cn=lagm2
ibm-slapdAdminPW: lagm2
ibm-slapdAdminRole: AuditAdmin
ibm-slapdAdminRole: DirDataAdmin
ibm-slapdAdminRole: NoAdmin
ibm-slapdAdminRole: SchemaAdmin
ibm-slapdAdminRole: ServerStartStopAdmin
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdAdminGroupMember

dn: cn=lagm3, cn=AdminGroup, cn=Configuration
cn: lagm3
ibm-slapdAdminDN: cn=lagm3
ibm-slapdAdminPW: lagm3
ibm-slapdAdminRole: NoAdmin
objectclass: top
objectclass: ibm-slapdConfigEntry
objectclass: ibm-slapdAdminGroupMember

2. If a user issues a command to delete all the instances of ibm-slapdAdminRole attribute associated with a LAGM, the server does not delete them completely, for two reasons:

  • Because it is a MUST attribute, deleting all the instances of it creates a schema violation.
  • When all the instances of this attribute are to be removed, it implicitly means that the directory administrator wants to revoke all the admin rights of this LAGM. This can be achieved by keeping one instance of the attribute set to No Administrator role.


Hence, the resultant entry is a LAGM having only one instance of the ibm-slapdAdminRole attribute that is set to the NoAdmin role value.

Special case with Password Administrator role: The Password Administrator role enables LAGMs to change the userpassword attribute and unlock the user accounts in the RDBM backend. However, this authority does not include permissions to access attributes in the GAGM accounts. This restriction has been introduced so that a LAGM having a Password Administrator role will not be able to gain the unrestricted access to all the entries in RDBM backend by changing the password of a GAGM.

Special cases with Replication Administrator, Server Configuration Group Member, and Directory Data Administrator roles:
1. Though by definition the Replication Administrator roles enables LAGMs to have complete access to replication topology objects, it does not enable them to set up the replication topology completely. It only enables them to manage the replication objects when the replication is set up, in the sense that they can access all the replication objects in the RDBM backend of the master instance; however a LAGM having Replication Administrator role, in the replica instance, is not able to add Master Server DN entry in the configuration file of replica instance. This restriction has been introduced for the reason that since the Master DN has complete access to directory database and schema, a LAGM having Replication Administrator role can create a dummy Master Server DN entry in the configuration file and can gain complete access to the directory database and schema. This is a violation of the directory security model.

2. Though the Server Configuration Group Member role enables LAGMs to have unrestricted access to most of the entries in the configuration file, it does not include access permissions for the Master Server DN entry. This restriction has been introduced for the same reason as mentioned above for the Replication Administrator role. In order to have the access permissions to the Master Server DN entry, a LAGM needs to have all of DirDataAdmin, SchemaAdmin and ServerConfigGroupMember roles.

3. The Directory Data Administrator role enables LAGMs to have unrestricted access to all the entries in the RDBM backend. This role is also the superset of the Replication Administrator role. However, it does not enable them to add a Master Server DN entry in the configuration file of a replica server instance. This restriction has been introduced because Master DN has complete access to directory database and schema, a LAGM having Directory Data Administrator role can create a dummy Master Server DN entry in the configuration file and can gain complete access to the directory schema. This is a violation of the directory security model.

4. Though there are overlaps amongst the various administrative rights of different administrative group members, the hierarchy of rights exists only in the case of Directory Data Administrator and Replication Administrator. The Directory Data Administrator role enables the LAGM to have unrestricted access to the entries in the RDBM backend, including replication of topology objects in the RDBM backend as well. Hence, a LAGM having the Directory Data Administrator role will be able to do all the administrative tasks that a member having Replication Administrator role is able to do. In other words, the Directory Data Administrator role implicitly has the Replication Administrator role.


Use cases

This section covers some real-life scenarios that show how and to whom different administrative roles can be assigned. In each of these scenarios, the objective of this feature, that is delegation of administrative rights by the directory administrator, has been underlined. Note that delegation being the primary objective of the feature, need for assigning more than one role to a single user arises when the directory administrator does not want to add too many people in the local administrative group. That is when fewer people are assigned multiple roles by the directory administrator.

Help Desk users need to reset passwords of regular users

The Password Administrator role can be assigned to Help Desk personnel. In the events of account deactivation because of password expiry or too many unsuccessful login attempts, the account holders can contact the Help Desk and can get their accounts activated. The figure below depicts this scenario:

Figure 1: Use case for Password Administrator role
Use case for Password Administrator role

Server needs to be restarted as soon as possible after a crash

Multiple LAGMs can be assigned Server Start and Stop Administrator role. So, in the event of unplanned outage of the server, any of these members can restart the server. An example of this might be the directory administrator permitting data center operators or Help Desk staff to restart the directory servers in case of failures. This will improve overall availability of the server.

Directory Administrator wants to get away from the tasks related to business continuity plan

Every organization has some business continuity plans. As per these plans, backup of critical data has to be kept at the standby locations for disaster recovery. In these scenarios, the directory administrator can create two LAGM accounts.

  • One with Replication Administrator role
  • The other with Directory Data Administrator, Schema Administrator and Server Configuration Group Member roles


The first LAGM can then set up replication, and the second LAGM can help the first by configuring the Master DN entry in the consumer replica's configuration file. All subsequent activities related to the management of replication can then be handled by the first LAGM. Note that the second LAGM will then be able to perform all the tasks related to the RDBM backend and server schema and most of the tasks related to server configuration.

Figure 2: Use case for setting up replication
Use case for setting up replication

Avoid possible misuse of a LAGM account when the member goes for a long vacation

In the event of a LAGM going for a long vacation, the Directory Administrator can temporarily revoke all the administrative rights associated with this LAGM account by adding an instance of the ibm-slapdAdminRole attribute set to the NoAdmin role value to prevent possible misuse of this account by anyone else.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Tivoli (service management) on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Tivoli
ArticleID=252397
ArticleTitle=Delegation of Administrative Rights in Tivoli Directory Server 6.1 Using Administrative Roles
publish-date=09192007