Secure shared queue manager data and log directories and files on Windows

This topic describes how you can secure a shared location for queue manager data and log files using a global alternative security group. You can share the location between different instances of a queue manager running on different servers.

Typically you do not set up a shared location for queue manager data and log files. When you install IBM® MQ for Windows, the installation program creates a home directory of your choosing for any queue managers that are created on that server. It secures the directories with the local mqm group, and configures a user ID for the IBM MQ service to access the directories.

When you secure a shared folder with a security group, a user that is permitted to access the folder must have the credentials of the group. Suppose that a folder on a remote file server is secured with the local mqm group on a server called mars . Make the user that runs queue manager processes a member of the local mqm group on mars . The user has the credentials that match the credentials of the folder on the remote file server. Using those credentials, the queue manager is able to access its data and logs files in the folder. The user that runs queue manager processes on a different server is a member of a different local mqm group which does not have matching credentials. When the queue manager runs on a different server to mars , it cannot access the data and log files it created when it ran on mars . Even if you make the user a domain user, it has different credentials, because it must acquire the credentials from the local mqm group on mars , and it cannot do that from a different server.

Providing the queue manager with a global alternative security group solves the problem; see Figure 1. Secure a remote folder with a global group. Pass the name of the global group to the queue manager when you create it on mars . Pass the global group name as the alternative security group using the -a[r] parameter on the crtmqm command. If you transfer the queue manager to run on a different server, the name of the security group is transferred with it. The name is transferred in the AccessMode stanza in the qm.ini file as a SecurityGroup ; for example: 

AccessMode:
SecurityGroup=wmq\wmq
The AccessMode stanza in the qm.ini also includes the RemoveMQMAccess ; for example: 

AccessMode:
RemoveMQMAccess=<true\false>
If this attribute is specified with value true, and an access group has also been given, the local mqm group is not granted access to the queue manager data files.
Figure 1. Securing queue manager data and logs using an alternative global security group (1)
Simplified diagram of securing a folder using a global group wmq

For the user ID that queue manager processes are to run with to have the matching credentials of the global security group, the user ID must also have global scope. You cannot make a local group or principal a member of a global group. In Figure 1, the users that run the queue manager processes are shown as domain users.

If you are deploying many IBM MQ servers, the grouping of users in Figure 1 is not convenient. You would need to repeat the process of adding users to local groups for every IBM MQ server. Instead, create a Domain mqm global group on the domain controller, and make the users that run IBM MQ members of the Domain mqm group; see Figure 2. When you install IBM MQ as a domain installation, the Prepare IBM MQ wizard automatically makes the Domain mqm group a member of the local mqm group. The same users are in both the global groups Domain mqm and wmq.

Tip: The same users can run IBM MQ on different servers, but on an individual server you must have different users to run IBM MQ as a service, and run interactively. You must also have different users for every installation on a server. Typically, therefore Domain mqm contains a number of users.
Figure 2. Securing queue manager data and logs using an alternative global security group (2)
Securing a folder using a global group wmq and making the domain users that run IBM MQ a member of Domain mqm

The organization in Figure 2 is unnecessarily complicated as it stands. The arrangement has two global groups with identical members. You might simplify the organization, and define only one global group; see Figure 3.

Figure 3. Securing queue manager data and logs using an alternative global security group (3)
Securing a folder using a global group wmq and making the domain users that run IBM MQ a member of Domain mqm

Alternatively, you might need a finer degree of access control, with different queue managers restricted to being able to access different folders; see Figure 4. In Figure 4, two groups of domain users are defined, in separate global groups to secure different queue manager log and data files. Two different local mqm groups are shown, which must be on different IBM MQ servers. In this example, the queue managers are partitioned into two sets, with different users allocated to the two sets. The two sets might be test and production queue managers. The alternate security groups are called wmq1 and wmq2. You must manually add the global groups wmq1 and wmq2 to the correct queue managers according to whether they are in the test or production department. The configuration cannot take advantage that the installation of IBM MQ propagates Domain mqm to the local mqm group as in Figure 3, because there are two groups of users.

Figure 4. Securing queue manager data and logs using an alternative global security principal (4)
Securing a folder using global group wmq1 and wmq2, and making the domain users that run IBM MQ members of each group

An alternative way to partition two departments would be to place them in two windows domains. In that case, you could return to using the simpler model shown in Figure 3.