| Author |
Message
|
| zhanghz |
 Posted: Fri Jan 23, 2009 2:10 am Post subject: |
 |
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
| PeterPotkay wrote: |
...
Put a bogus ID in the MCAUSER of the RCVR channel and watch the SNDR retry. |
I did a test. I altered my zOS RCVR MCAUSER to TTTT which does not exist. I stopped it, also stopped Windows SDR channel. Restarted both, channel is running.. |
|
| Back to top |
|
 |
| masteringmq |
| Posted: Fri Jan 23, 2009 2:17 am Post subject: |
|
|
Master
Joined: 20 Oct 2008
Posts: 200
|
| Ok. Does the messages get put to the destination queue?. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 23, 2009 10:24 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| zhanghz wrote: |
| PeterPotkay wrote: |
...
Put a bogus ID in the MCAUSER of the RCVR channel and watch the SNDR retry. |
I did a test. I altered my zOS RCVR MCAUSER to TTTT which does not exist. I stopped it, also stopped Windows SDR channel. Restarted both, channel is running.. |
RACF MQ Security is not enabled for your z/OS QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jan 23, 2009 12:04 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| RACF MQ Security is not enabled for your z/OS QM. |
To elaborate a bit: On z/OS, there a fleet of RACF security switches that must be set appropriately; and there must be the appropriate RACF facility classes enables and rules created.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| zhanghz |
| Posted: Sat Jan 24, 2009 10:33 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
gosh, is it because RACF security is not enabled? I just checked, the RACF indeed is not enabled for the qmgr, which is our own test z/OS qmgr..
I have been having this wrong idea for months! I thought that MCAUSER was only in action when there was a MQOPEN call and MQPUT or MQGET call, and that channel connections did not require a valid MCAUSER id. I even told this to someone from application side! Man!
I will create a RCVR on another QMGR with all RACF things on and test again after chinese new year.
Thanks for pointing out this misconception of mine.. How many other things are there that I have wrong?  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jan 24, 2009 10:50 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
MCAuser is a channel attribute that can provide a userid under which the Message Channel Agent will do its business.
A sender MCA needs to MQCONNect to its queue manager and MQOPEN the transmission queue; a receiver side MCA needs to MQCONNect to its queue manager and MQOPEN destination queues and Dead Letter Queue.
If MCAuser is not specified (left blank), the MCA will take on the identity of who/what started it. This is generally believed to be too much authority for a channel agent.
Many shops specify CTX in the receiver channel so that the MCA attempts to MQOPEN the destination queue using the userid in the MQMD - the userid that created the message in the first place.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jan 24, 2009 1:57 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| bruce2359 wrote: |
Many shops specify CTX in the receiver channel so that the MCA attempts to MQOPEN the destination queue using the userid in the MQMD - the userid that created the message in the first place. |
Which is a bad idea. The assumtion is that every ID presented is a valid one. The receiving MQ Admin spends all his time trying to keep the valid list of IDs properly authorized, and is powerless in preventing the sending system from sending any ID it wants, including ones with MQ Administrator level access.
An incoming channel with a blank MCAUSER means you accept the fact the the channel can be used for remote MQ Administration. The only way to have a blank MCAUSER is to also have an Exit on the channel that rejects connections coming in as mqm, MUSER_MQADMIN, and any other IDs that you have in groups with MQ Admin rights.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Sun Jan 25, 2009 3:12 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zhanghz wrote: |
| ...Thanks for pointing out this misconception of mine.. How many other things are there that I have wrong? |
Don't worry too much - every time I learn something more about WMQ, the more I learn that I know so little about it!
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| masteringmq |
| Posted: Sun Jan 25, 2009 5:54 pm Post subject: |
|
|
Master
Joined: 20 Oct 2008
Posts: 200
|
We are using PUTAUT(CTX) which means that the message userid will be used for authorization. The OAM applied on the QM will grab the message userid and check to see if the userid has the permission to put messages into the queue and so on. Yes, there is a need to create the userid at both sender and receiver end.
| Quote: |
| The assumtion is that every ID presented is a valid one |
But we can use SSL cert for authentication. Also we can apply the OAM on the QM. Besides that a security program can be created to listen to a particular port for request. Firewall can be configured to prevent un-authorized connection to QM. So this are things that makes it safe to use PUTAUT(CTX).
Therefore It all depends on the business and base on the business the architecture is built. Some would choose PUTAUT(CTX) and others PUTAUT(DEF).
Last edited by masteringmq on Sun Jan 25, 2009 9:34 pm; edited 4 times in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Jan 25, 2009 7:22 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| masteringmq wrote: |
But we can use SSL cert for authentication. Also we can apply the OAM on the QM. Besides that a security program can be created to listen to a particular port for request. So this are things that makes it safe to use PUTAUT(CTX).
|
The only thing SSL does is authenticate the remote connection. If I have a valid SSL cert to connect to your QM, because I am a valid customer, the fact that you have SSL enabled your channel does nothing to prevent me from sending messages with mqm in the header and sending messages to your command queue.
If an incoming channel has a blank MCAUSER, and/or uses PUTAUT(CTX), you are saying you accept the fact that your QM can be administered remotely, even if by "trusted" connections over SSL protected channels.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| masteringmq |
| Posted: Sun Jan 25, 2009 9:44 pm Post subject: |
|
|
Master
Joined: 20 Oct 2008
Posts: 200
|
| From a userid point of view there can be two userid serving two different region. For example one userid represents the eastern region and the other userid represents the western region. So I can be sending messages that represents the eastern region using the userid that represents the eastern region. As for messages comming from the western region I can be using the userid that represents the western region. Two userid with different naming convention and serving different countries but from the same customer in a single location. The same sender channel will be used by the customer located in a single location. The difference is the userid represents different region. Therefore in this context there is no need to create two different sender channel with different userid specified in MCAUSER attribute and PUTAUT(DEF). |
|
| Back to top |
|
|
| sumit |
| Posted: Mon Jan 26, 2009 2:19 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
Lots of important info in this thread.
widnewbie,
Have you got solution of your problem?
_________________
Regards
Sumit |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jan 26, 2009 3:39 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
| masteringmq wrote: |
| From a userid point of view there can be two userid serving two different region. For example one userid represents the eastern region and the other userid represents the western region. So I can be sending messages that represents the eastern region using the userid that represents the eastern region. As for messages comming from the western region I can be using the userid that represents the western region. Two userid with different naming convention and serving different countries but from the same customer in a single location. The same sender channel will be used by the customer located in a single location. The difference is the userid represents different region. Therefore in this context there is no need to create two different sender channel with different userid specified in MCAUSER attribute and PUTAUT(DEF). |
One of the valid reasons for having 2 channels here is that in case of communication problems you can force shutdown one and restart it without affecting the other. So when all the western clients lock their channel with the max allowed instances, you just force shutdown the western channel and restart it. No one in the eastern region is affected....
This is why good practice says use separate channels and mcauser on them. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jan 26, 2009 5:17 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| masteringmq wrote: |
| From a userid point of view there can be two userid serving two different region. For example one userid represents the eastern region and the other userid represents the western region. So I can be sending messages that represents the eastern region using the userid that represents the eastern region. As for messages comming from the western region I can be using the userid that represents the western region. Two userid with different naming convention and serving different countries but from the same customer in a single location. The same sender channel will be used by the customer located in a single location. The difference is the userid represents different region. Therefore in this context there is no need to create two different sender channel with different userid specified in MCAUSER attribute and PUTAUT(DEF). |
We're not saying you can't technically do this. Obviously it works. You've just accepted the fact that anybody from the western region or eastern region can send PCF commands to your SYSTEM.ADMIN.COMMAND.QUEUE and have their way with your QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| masteringmq |
| Posted: Mon Jan 26, 2009 5:34 am Post subject: |
|
|
Master
Joined: 20 Oct 2008
Posts: 200
|
Actually our customer is our company itself. I believe I learn something valuable today which I can bring forward to the solution architect at my working place  |
|
| Back to top |
|
|
|
|
