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® WebSphere® 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 IBM WebSphere 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>
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.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 WebSphere 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 WebSphere MQ server. Instead, create a Domain mqm global
group on the domain controller, and make the users that run IBM WebSphere MQ members of the Domain
mqm group; see Figure 2
. When you install IBM WebSphere MQ as a
domain installation, the Prepare IBM WebSphere 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. You 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 WebSphere 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 WebSphere 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.