The setmqaut command and authorization requirements:
The setmqaut command is used to grant and revoke
authorizations to user IDs and MQ objects.
We use the WebSphere® MQ connector in a job to perform these
tasks:
·
To establish a connection to a queue manager,
·
To read messages from source queues so that they
can later be processed by other stages in the job, and
·
To take data that is produced by the stages in
the job and write it as messages to the target queues.
To enable the connector to access the specified queue
manager and queue objects, we must grant certain authorizations to the user ID
under whose credentials the connector runs. If the user ID does not have the
necessary authorizations to the objects, the connector reports MQ error code
2035 (MQRC_NOT_AUTHORIZED).
After we grant authorizations, the authorization service
that is associated with the queue manager inspects the list of authorizations
that we grant to the user ID to determine whether the user ID is authorized to
perform a particular operation on a particular MQ object.
Two factors determine
the IDs to which we grant authorizations:
Whether the connector runs in Server mode or in Client mode
and whether the connector is running in a job or is invoked at design time, for
example to test the connector. The mode in which the connector runs also
determines the objects for which we set authorizations. In general, we must
grant authorizations for the queue manager, queue, and namelist objects that
the connector accesses.
Depending on the mode in which the connector runs, we use
the setmqaut command to grant one or more of the
Following
authorizations to each MQ object:
altusr – To specify an alternate user ID to use for opening
queues
browse – To browse messages on queues
connect – To connect to queue managers
dlt – To automatically delete the dynamic reply queue when
closing it
dsp – To create dynamic queues that are based on a model
queue
get – To get messages from queues
inq – To inquire about the attributes of MQ objects
put – To put messages on queues
setall – To set identity context fields and origin context
fields on messages
setid – To set the identity context fields on messages
After we use the setmqaut command to grant authorizations to
MQ objects, issue the REFRESH SECURITY command to refresh the security cache
for the queue manager. For example, the refresh the security settings for the
queue manager QMNAME, we issue the following command:
runmqsc QMNAME
When the MQSC editor
opens, issue the following MQ command:
REFRESH SECURITY
The following response message should display to confirm
that the security cache was refreshed:
AMQ8560: WebSphere MQ security cache refreshed
Few examples are listed below on how
to grant permissions while configuring authorization:
1. This example shows
a command that specifies that the object on which authorizations are being
given is the queue orange.queue on queue manager saturn.queue.manager. If the
queue does not exist, the command fails.
setmqaut -m
saturn.queue.manager -n orange.queue -t queue
-g tango +inq +alladm
The authorizations are given to a user group called tango,
and the associated authorization list specifies that the user group can:
·
Issue MQINQ calls
·
Perform all administration operations on that
object
2. In this example,
the authorization list specifies that a user group called foxy:
·
Cannot issue any MQI calls to the specified
queue
·
Can perform all administration operations on the
specified queue
If the queue does not exist, the command fails.
setmqaut -m
saturn.queue.manager -n orange.queue -t queue
-g foxy -allmqi +alladm
3. This example gives
user1 full access to all queues with names beginning a.b. on queue manager
qmgr1. The profile is persistent and applies to any object with a name that
matches the profile.
setmqaut -m qmgr1 -n a.b.* -t q -p user1 +all
4. This example
deletes the specified profile.
setmqaut -m qmgr1 -n a.b.* -t q -p user1 -remove
setmqaut -m qmgr1 -n More Detail and Examples ........................................
MCA channels
The channels that connect queue managers to one another are known as MCA channels because they use a message channel agent. An inbound MCA channel can be a receiver, requestor, or cluster receiver. If you have looked closely at the system administration manual, you may have noticed that tools like runmqsc and WMQ Explorer can use one queue manager as a proxy to administer another queue manager using MCA channels. This means that, in the default configuration, any queue manager can be administered by any adjacent queue manager.
Clearly, if you wish to restrict administrative access, you need to consider MCA channels. Here is a script of setmqaut commands that block administrative access over MCA channels. These would be applied to all non-default channels on the queue manager. (Your default channels should have been set to MCAUSER('nobody') a long time ago, but that's a topic for another article.)
# Allow MCAUSER to connect. Needs +set and +setall per IBM docs. setmqaut -m QMGR -g mqmmca -t qmgr -all +connect +inq +set +setall # Grant MCAUSER default policy of "allow all" to all queues. Channels # put messages so no need for get, browse, etc. Also needs +setall. setmqaut -m QMGR -g mqmmca -n '**' -t queue -all +put +setall # Now deny access to administrative queues setmqaut -m QMGR -g mqmmca -n SYSTEM.ADMIN.COMMAND.QUEUE -t queue -all +none setmqaut -m QMGR -g mqmmca -n SYSTEM.DEFAULT.INITIATION.QUEUE -t queue -all +none # Restrict access to any additional initiation queues as well.
This, of course, is the bare minimum and restricts only administrative access. Adjacent queue managers can still put messages to SYSTEM.* queues and any application queues, but this is probably good enough for a network of trusted queue managers.
MQI channels
Once the connections from other queue managers are locked down to your satisfaction, you need to consider the MQI channels. These are represented by SVRCONN definitions. Hopefully, your SYSTEM.DEF.SVRCONN and SYSTEM.AUTO.SVRCONN already have MCAUSER('nobody') set and are not actively used. If this is not the case, these channels will need to receive the updates described here. Whatever you do, don't leave these channels without an MCAUSER set.
We should also pause a moment and consider SYSTEM.ADMIN.SVRCONN. If the WebSphere MQ administration team uses a desktop client to access the queue managers, the configurations proposed here will break that access. But in the absence of authentication, leaving the channel unsecured opens up administrative privileges to anyone. There are two options here: either implement authentication in a limited fashion just for the administration team, or require administrators to log onto the server to make configuration changes. To simplify this discussion, we will assume the latter case. After all, you would not be considering this option if you were prepared to move forward with SSL and/or exits in the first place.
After the changes are applied, SYSTEM.ADMIN.SVRCONN will still be available and desktop tools, such as WebSphere MQ Explorer will still work, up to a point. Users will be able to browse, get or put messages, inquire on any object, and even set objects (enabling triggering, for example), but they will not be able to create or delete objects or control channels.
# Allow MCAUSER to connect to QMgr setmqaut -m QMGR -g mqmmqi -t qmgr -all +connect +allmqi +dsp # Allow inquire/display of non-queue objects # Some of these object types are new for v6 setmqaut -m QMGR -g mqmmqi -n '**' -t namelist -all +dsp +inq setmqaut -m QMGR -g mqmmqi -n '**' -t process -all +dsp +inq setmqaut -m QMGR -g mqmmqi -n '**' -t authinfo -all +dsp +inq setmqaut -m QMGR -g mqmmqi -n '**' -t channel -all +dsp setmqaut -m QMGR -g mqmmqi -n '**' -t service -all +dsp setmqaut -m QMGR -g mqmmqi -n '**' -t listener -all +dsp setmqaut -m QMGR -g mqmmqi -n '**' -t clntconn -all +dsp # Default allow-all to all queues setmqaut -m QMGR -g mqmmqi -n '**' -t queue -all +allmqi +dsp # This gets us back to almost full admin but positions us to set # additional restrictions. # Restrict access to SYSTEM.** queues. Browsing and display of these # queues is reasonable but not PUT, SET, ALTUSR, etc. setmqaut -m QMGR -g mqmmqi -n 'SYSTEM.**' -t queue -all +inq +browse +dsp # Allow limited access to command queue. setmqaut -m QMGR -g mqmmqi -n 'SYSTEM.ADMIN.COMMAND.QUEUE' -t queue -all +inq +put +dsp # Allow access to SYSTEM.MQEXPLORER.REPLY.QUEUE if it exists. setmqaut -m QMGR -g mqmmqi -n 'SYSTEM.MQEXPLORER.REPLY.QUEUE' -t queue -all +inq +dsp +put # Allow access to SYSTEM.DEFAULT.MODEL.QUEUE. setmqaut -m QMGR -g mqmmqi -n 'SYSTEM.DEFAULT.MODEL.QUEUE' -t queue -all +allmqi +dsp # Restrict access to DLQ. This assumes SYSTEM DLQ is used. If not, # you might want to script this to inquire on the QMgr DLQ property # and set that. setmqaut -m QMGR -g mqmmqi -n 'SYSTEM.DEAD.LETTER.QUEUE' -t queue -all +put +inq +browse +dsp
Some things to be aware of:
- The setmqaut commands shown above will enable users to do almost anything that they could before, except for administrative commands and update-type commands on SYSTEM.* queues. Be aware, though, that only users in the mqm group are allowed to inquire on SYSTEM.AUTH.DATA.QUEUE. This is not a problem for most applications, but it causes saveqmgr (the MS03 SupportPac) to fail when run remotely.
- Concerning the script commands, wildcarded parameters should always be quoted. If not, the shell will attempt to expand them using file names in the current directory. If no filenames match, the command is passed in and works as intended. If only one file name matches, the file name is substituted for the queue name, and the setmqaut command is executed but fails silently. If two or more file names match, the setmqaut command will fail outright. This can be a devil to debug because the authorization script may work one day and fail the next, and nothing in the script itself has changed.
- In each of the setmqaut commands listed above, the permissions always start with -all because successive commands are cumulative. Running setmqaut once with +dsp and once with +inq results in an effective permission of +dsp +inq. Starting with -all insures that the permissions listed are the only ones in force after the command line is executed. The only other way to insure that unwanted permissions do not creep in is to dump them and compare them to your script. The -all saves that extra step.
Comments