There is a special, predefined user named admin that can perform any administrative action. You cannot grant or revoke any permissions to
admin. You must assign a password for
admin immediately after installation. For more information about changing the
admin password, see
When You First Start tibemsadmin.
There is also a special group named $admin for system administrator users. When a user becomes a member of this group, that user receives the same permissions as the
admin user. You cannot grant or revoke administrator permissions from any user that is a member of the
$admin group. You should only assign the overall system administrator(s) to the
$admin group.
You grant and revoke administrator permissions to users using the grant and
revoke commands in
tibemsadmin, or by means of the Java o
r .NET admin API. You can either grant global administrator permissions or permissions on specific destinations. See
Global Administrator Permissions for a complete list of global administrator permissions. See
Destination-Level Permissions for a description of administrator permissions for destinations.
The admin user or all users in the
$admin group can grant or revoke any administrator permission to any user. All other users must be granted the
change-admin-acl permission and the
view-user and/or the
view-group permissions before they can grant or revoke administrator permissions to other users.
If a user has the change-admin-acl permission, that user can only grant or revoke permissions that have been granted to the user. For example, if user
BOB is not part of the
$admin group and he has only been granted the
change-admin-acl and
view-user permissions,
BOB cannot grant any administrator permissions except the
view-user or
change-admin-acl permissions to other users.
For example, an administrator has been granted the view permission on the
foo.* destination. This administrator has not been granted the global
view-destination permission. The administrator is only able to view destinations that match the
foo.* parent destination. If this administrator is granted the global
view-acl permission, the administrator is only able to view the access control list for destinations that match the
foo.* parent. Any access control lists for other destinations are not displayed when the administrator performs the
showacl topic or
showacl queue commands.
If the administrative user attempts to execute a command without permission, the user may either receive an error or simply see no output. For example, if the administrator issues the showacl queue bar.foo command, the administrator receives a “Not authorized to execute command” error because the administrator is not authorized to view any destination except those that match
foo.*.
Table 46 describes the global administrator permissions.
Global permissions are stored in the acl.conf file, along with all other permissions. Global permissions in this file have the following syntax:
For example, if a user named BOB is granted the
view-user global administration permission and the group
sys-admins is granted the
change-acl permission, the following entries are added to the
acl.conf file:
Table 47 describes the destination-level administration permissions.
Administration permissions for a destination are stored alongside all other permissions for the destination in the acl.conf file. For example, if user
BOB has publish and subscribe permissions on topic
foo, and then
BOB is granted view permission, the acl listing would look like the following:
The user name of the manager is mgr, the user names of the other system administrators are
admin1,
admin2, and
admin3. The following commands illustrate the grants necessary for creating the example administration structure.
For example, admin1 can perform any action on any user in the
sales group, and can view any users in the
manufacturing or
finance groups. However,
admin1 is not able to grant permissions, change passwords, delete users from, or perform any other administrative action on users of the
manufacturing or
finance groups. The
mgr user is able to perform any action on any user, regardless of their protection permission because
mgr is a member of the
$admin group.