Secure unshared queue manager data and log directories and files on Windows
This topic describes how we can secure an alternative location for queue manager data
and log files, both by using the local mqm group and an alternative security group.
Typically we do not set up an alternative 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. It
secures the directories with the local mqm group, and configures a user ID for the
IBM MQ service to access the directories.
Two examples demonstrate how to configure access control for IBM MQ. The examples show how to create a queue manager with its
data and logs in directories that are not on the data and log paths created by the installation. In
the first example, Reading and writing data and log files authorized by the local mqm group, you permit access to the queue and log directories
by authorizing by the local mqm group. The second example, Reading and writing data and log files authorized by an alternative local security group, differs in that access to the directories is authorized by an alternative
security group. When the directories are accessed by a queue manager running on only one server,
securing the data and log files with the alternative security group gives you the choice of securing
different queue managers with different local groups or principals. When the directories are
accessed by a queue manager running on different servers, such as with a multi-instance queue
manager, securing the data and log files with the alternate security group is the only choice; see
Securing shared queue manager data and log directories and files on Windows.
Configure the security permissions of queue manager data and log files is not a common task on
Windows. When you install IBM MQ for Windows, you either specify directories for queue manager data
and logs, or accept the default directories. The installation program automatically secures these
directories with the local mqm group, giving it full control permission. The
installation process makes sure the user ID that runs queue managers is a member of the local
mqm group. We can modify the other access permissions on the directories to meet
your access requirements.
If you move the data and log files directory to new locations, we must configure the security of
the new locations. We might change the location of the directories if you back up a queue manager
and restore it onto a different computer, or if we change the queue manager to be a multi-instance
queue manager. We have a choice of two ways of securing the queue manager data and log directories
in their new location. We can secure the directories by restricting access to the local
mqm group, or we can restrict access to any security group of our choosing.
It takes the least number of steps to secure the directories using the local mqm
group. Set the permissions on the data and log directories to allow the local mqm
group full control. A typical approach is to copy the existing set of permissions, removing
inheritance from the parent. We can then remove or restrict the permissions of other principals.
We can also secure queue manager data and log files using an alternative security group. The
process of securing the queue manager data and log files with the alternative security group has a
number of steps that refer to Figure 1. The local group,
wmq, is an example of an alternative security group.
Figure 1. Securing queue manager data and logs using an alternative local security group,
wmq
Either create separate directories for the queue manager data and logs, a common directory, or a
common parent directory.
Copy the existing set of inherited permissions for the directories, or parent directory, and
modify them according to your needs.
Secure the directories that are to contain the queue manager and logs by giving the alternative
group, wmq, full control permission to the directories.
Give all user IDs that run queue manager processes the credentials of the alternative security
group or principal:
If you define a user as the alternative security principal, the user must be same user as the
queue manager is going to run under. The user must be a member of the local mqm
group.
If you define a local group as the alternative security group, add the user that the queue
manager is going to run under to the alternative group. The user must also be a member of the local
mqm group.