Principals and groups

Principals can belong to groups. By granting resource access to groups rather than to individuals, you can reduce the amount of administration required. Access Control Lists (ACLs) are based on both groups and user IDs.

For example, you might define a group consisting of users who want to run a particular application. Other users can be given access to all the resources they require by adding their user ID to the appropriate group.

This process of defining and managing groups is described for particular platforms:
A principal can belong to more than one group (its group set). It has the aggregate of all the authorities granted to each group in its group set. These authorities are cached, so any changes you make to the group membership of the principal are not recognized until the queue manager is restarted, unless you issue the MQSC command REFRESH SECURITY (or its PCF equivalent).
UNIX and Linux systems
From Version 8.0, access control lists (ACLs) are based on both user IDs and groups and you can use either for authorization by setting the SecurityPolicy attribute to the appropriate value as described in Installable services and Configuring authorization service stanzas on UNIX and Linux.

From Version 8.0, you can use the user-based model for authorization, and this allows you to use both users and groups. However, when you specify a user in the setmqaut command, the new permissions apply to that user alone, and not any groups to which that user belongs. For more information, see User-based permissions on Unix and Linux.

When you use the group-based model for authorization, the primary group to which the user ID belongs is included in the ACL. The individual user ID is not included and authority is granted to all members of that group. Because of this, be aware that you can inadvertently change the authority of a principal by changing the authority of another principal in the same group.

All users are nominally assigned to the default user group nobody and by default, no authorizations are given to this group. You can change the authorization in the nobody group to grant access to IBM® MQ resources to users without specific authorizations.

Do not define a user ID with the value UNKNOWN. The value UNKNOWN is used when a user ID is too long, so arbitrary user IDs would use the access authorities of UNKNOWN.

User IDs can contain up to 12 characters and group names up to 12 characters.

Windows systems
ACLs are based on both user IDs and groups. Checks are the same as for UNIX systems. You can have different users on different domains with the same user ID. IBM MQ permits user IDs to be qualified by a domain name so that these users can be given different levels of access.
The group name can optionally include a domain name, specified in the following formats: 

GroupName@domain domain_name\group_name
Global groups are checked by the OAM in two cases only:
  1. The queue manager security stanza includes the setting: GroupModel=GlobalGroups. See Security.
  2. The queue manager is using an alternative security access group. See crtmqm .

User IDs can contain up to 20 characters, domain names up to 15 characters, and group names up to 64 characters.

The OAM first checks the local security database, then the database of the primary domain, and finally the database of any trusted domains. The first user ID encountered is used by the OAM for checking. Each of these user IDs might have different group memberships on a particular computer.

Some control commands (for example, crtmqm) change authorities on IBM MQ objects using the object authority manager (OAM). The OAM searches the security databases in the order given in the preceding paragraph to determine the authority rights for a particular user ID. As a result, the authority determined by the OAM might override the fact that a user ID is a member of the local mqm group. For example, if you issue the crtmqm command from a user ID authenticated by a domain controller that has membership of the local mqm group through a global group, the command fails if the system has a local user with the same name who is not in the local mqm group.

For more information about setting the SecurityPolicy attribute on Windows, see Installable services and Configuring authorization service stanzas on Windows.