| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MCAUSER and PUTAUT |
« View previous topic :: View next topic » |
| Author |
Message
|
| MonkeyDoo |
 Posted: Wed Jun 04, 2014 10:59 am Post subject: MCAUSER and PUTAUT |
 |
|
Novice
Joined: 05 Aug 2013
Posts: 17
|
So, specifying PUTAUT(ONLYMCA) gives the distributed behavior for sure for PUTAUT(DEF)?
And PUTAUT(ALTMCA) for distributed PUTAUT(CTX)?
Where on z for the first two options, there is more going on depending on RESLEVEL?
What network ID would it be checking?
I'm assuming 0 ID is no IDs are checked and the msg is just slammed on the queue; 1 ID is the ID running the listener (CHIN); 2 IDs is CHIN and network ID (what is this?). |
|
| Back to top |
|
 |
| hughson |
| Posted: Thu Jun 05, 2014 5:43 am Post subject: Re: MCAUSER and PUTAUT |
|
|
Padawan
Joined: 09 May 2013
Posts: 1916
Location: Bay of Plenty, New Zealand
|
| MonkeyDoo wrote: |
So, specifying PUTAUT(ONLYMCA) gives the distributed behavior for sure for PUTAUT(DEF)?
And PUTAUT(ALTMCA) for distributed PUTAUT(CTX)?
Where on z for the first two options, there is more going on depending on RESLEVEL? |
That is correct.
| MonkeyDoo wrote: |
| What network ID would it be checking? |
The network ID is described here: "Client MQI requests" as CHL. In short if you are using TCP/IP the only flowed network ID is the SSL certificate ID. It was mainly used for SNA, which I'm assuming you're not using.
| MonkeyDoo wrote: |
| I'm assuming 0 ID is no IDs are checked and the msg is just slammed on the queue; 1 ID is the ID running the listener (CHIN); 2 IDs is CHIN and network ID (what is this?). |
You are correct about zero IDs checked. But when you have only one ID checked, then it depends on your PUTAUT value. The table on the same page referenced above shows what is checked for one or two user ID checking.
There's also a very similar page for "Receiving channel using TCP/IP" if your question was not about clients.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| MonkeyDoo |
| Posted: Fri Jun 06, 2014 7:23 am Post subject: |
|
|
Novice
Joined: 05 Aug 2013
Posts: 17
|
Thx Morag,
What is best practice?
For client channels, we use SSL and currently use an exit that maps the client cert to a z ID but this requires the Cert be known to RACF. Once we get to a version of MQ that has CHLAUTH rules, I intend to switch to those and not use the exit.
For receiver channels (we also use SSL), do folks mostly use the permission granted to the CHIN ID?
What makes most sense to me, is to restrict messages from being administrative changes over these channels. I don't want changes to objects done this way. |
|
| Back to top |
|
|
| hughson |
| Posted: Fri Jun 06, 2014 8:27 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1916
Location: Bay of Plenty, New Zealand
|
Avoiding using the CHIN ID, in the same way that you should avoid using the mqm user ID for inbound channels.
Provide a user ID with only the authorities needed and use that.
Choice of 1 user ID checking or 2 user ID checking will likely be a decision your RACF guys have already made. Make sure you have at least 1 for CHINIT connections. If you're using TCP/IP, using 2 doesn't buy you so much as it would for SNA. So my opinion would be to go for 1 check, but that's only my opinion.
If you make use of RACFs Certificate Name Filtering (CNF) then 2 checks becomes more useful.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
