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

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

Typically we 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 our 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.

AccessMode:
SecurityGroup=wmq\wmq

AccessMode:
RemoveMQMAccess=true|false

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. We 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 we 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.

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

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. We 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.

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.