| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| zOS Disallow Remote Default to CHIN Userid |
« View previous topic :: View next topic » |
| Author |
Message
|
| Buzz |
 Posted: Wed Aug 04, 2010 6:34 am Post subject: zOS Disallow Remote Default to CHIN Userid |
 |
|
Newbie
Joined: 04 Aug 2010
Posts: 4
|
I am new to this forum and have a question... My background is stronger in RACF than it is in MQSeries.
We get the CSQX632I message with text "SSL Cert has no associated userid" and "channel initiator user ID used".
From what I've read, the solution to this is to set up Certificate Name Filtering in RACF which is nicely written in the RACF SAG.
My question is: In addition to RACF's Certificate Name Filtering, can WebSphere MQ be configured NOT to default to the CHIN userid? I would like to set it up so that such a request would fail and therefore prompt me to define/adjust my RACF CNF profiles. I also think this would be a good secuirty practice of denying-by-default.
Any advice would be greatly appreciated. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Aug 04, 2010 8:58 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
Moved to Mainframe and CICS forum.
_________________
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 |
|
|
| bruce2359 |
| Posted: Wed Aug 04, 2010 9:16 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| Buzz |
| Posted: Wed Aug 04, 2010 9:31 am Post subject: |
|
|
Newbie
Joined: 04 Aug 2010
Posts: 4
|
| Quote: |
| are you asking if WMQ can be configured so as not to use the chin address space id as default? I don't believe so |
Yes, this is exactly what I'm asking. From a security standpoint, I don't know why you would ever want to associate an unknown remote connection to an existing valid userid. Isn't that like saying "Hey, I'm not really sure who you are but you can use my key to get into my house."
Of course as I said before, I am more of a security tech and maybe don't understand WMQ well enough. Perhaps there is a reason why this is done?? I was hoping that it could be disabled thru WMQ and not just fixed with the RACF CNF profiles.[/quote] |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 04, 2010 9:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Perhaps there is a reason why this is done?? |
Every address space, including started tasks must have some kind of identity. WMQ presumes that this identity will be the address space id.
It's been quite some time since I RACF'd for a living. I'm not sure if there is UACC(NONE) possible for the cert issue you are facing.
Perhaps it's time for a PMR.
_________________
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 |
|
|
| Vitor |
| Posted: Wed Aug 04, 2010 9:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Buzz wrote: |
| Isn't that like saying "Hey, I'm not really sure who you are but you can use my key to get into my house." |
No it's like saying "I know you're the guy who delivers our mail & I'm happy to let you open the mailbox to put the deliveries in".
The CHIN id is performing a known role within the WMQ software. It has a high level of authority for the same reason the equivalent role in a distributed system is performed using the mqm id. It's also not an unknown remote connection; it's your end of 1-n pre-configured connections.
| Buzz wrote: |
| Perhaps there is a reason why this is done?? |
Yes - it's to allow one controlled user id to do the work rather than having a free for all inside the queue manager.
| Buzz wrote: |
| I was hoping that it could be disabled thru WMQ and not just fixed with the RACF CNF profiles. |
It can't & I'm not sure the ability to do it would make the security any tighter. But my RACF is on a level with your WMQ so you may know some method I'm unfamiliar with.
Bear in mind WMQ & RACF are both IBM products. If there was a better way I'd hope someone at Hursley would have thought of it. But given that they havn't if you' have please fill out a product enhancement form (or get your MQ admin to do it). Seriously. Nothing I like better than a good idea, especially a good idea to improve z/OS security. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Buzz |
| Posted: Wed Aug 04, 2010 10:05 am Post subject: |
|
|
Newbie
Joined: 04 Aug 2010
Posts: 4
|
Thanks much for the replies!
Regarding:
| Quote: |
| It's also not an unknown remote connection; it's your end of 1-n pre-configured connections. |
So does this mean that a true unknown connection would not default to the CHIN userid? And that it would never make a connection because I would not have defined it to my system (in both WMQ and RACF)?
So you're saying I would have had to pre-configure the remote channel? If this is the case then I would know something about this connection like perhaps the expected certificate content which I can then use to set up the RACF CNF and map to an appropriate userid. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 04, 2010 10:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
This is where channel attribute MCA userid leaps into the spotlight. If specified, it will be checked against RACF.
_________________
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 |
|
|
| Vitor |
| Posted: Wed Aug 04, 2010 12:28 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Buzz wrote: |
| So does this mean that a true unknown connection would not default to the CHIN userid? And that it would never make a connection because I would not have defined it to my system (in both WMQ and RACF)? |
You can't just say "Hey, I've got a queue manager, wouldn't it be great to connect to this other queue manager & send some messages". You need a connection pre-defined on the target queue manager, or the queue manager needs to be configured to say "I'll take messages from any queue manager who sends them". An unknown queue manager trying to connect without pre-configuration your end will fail, and anyone just posting data at the port won't get anywhere because WMQ expects a propriaty format. SSL adds an extra layer to this by making the pre-configured connection check the credentials of the sending end.
(Application connections to a queue manager are a different kettle of fish & need a different view of security)
| Buzz wrote: |
| So you're saying I would have had to pre-configure the remote channel? |
SSL or no it has to be paired with the one your end. Whoever administers the WMQ at that end would have had to set it up in collaboration with the administrator your end.
| Buzz wrote: |
| If this is the case then I would know something about this connection like perhaps the expected certificate content which I can then use to set up the RACF CNF and map to an appropriate userid. |
If you're using SSL to add an additional layer of security to this then at a minimum WMQ will check the credentials. If as a result of this CNF thing you plan to have the connection not use the CHIN id make sure this appropriate userid you map to has the permissions it needs to do the work that will be required of it. Which will probably be very similar to the level of authority the CHIN id has.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Buzz |
| Posted: Thu Aug 05, 2010 4:14 am Post subject: |
|
|
Newbie
Joined: 04 Aug 2010
Posts: 4
|
Well I can't tell you how much I appreciate your help. I think my next move will be to set up a meeting with my WMQ support person and discuss this issue. This thread will be beneficial.
I'm not just the "RACF guy". I am also on a team with our auditing group and our goal is to come up with guidelines for "best practices" security. I still don't like the idea of the default to the CHIN userid but I now see that I should be able to avoid the default by setting up proper RACF definitions when the connection is established. Good security sez that one person/entity can have more than one userid but one userid should not be used by more that one person/entity. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Aug 05, 2010 6:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Good security sez that one person/entity can have more than one userid but one userid should not be used by more that one person/entity. |
Agreed.
It's easier for an individual running an individual application. Does person x have privilege to execute app y with the intent to update object z?
With servers (daemons, for the midrange folks), the server (in this case WMQ) needs an identity of its own (the address space id). In daemon/server fashion, it attempts to do end-user work using the identity of the end-user.
Prior to API calls like MQCONN, MQOPEN, etc., an identity is sent to SAF. It is usually the end-users username (USERID), but can be an alternate user id - if this privilege has been granted.
Briefly (refer to the System Setup Guide), for channels, things are a bit different. The sender channel end MCA executes with address space id, AND, if specified, the MCAUser() identity. At the receiving end, the receiver MCA executes with address space id, and MCAUser (if specified), AND, if CTX is specified, the userid from the message.
Broadly stated: under which authority does the app execute, under which authority does the message get put to the queue (xmit or other), under which authority is the message sent down the channel, and under which authority is the message put to the destination queue?
This all gets a bit complex when the message leaves one security domain, and arrives on another.
_________________
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 |
|
|
|
|
|
| |
|
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
|
|
|
|
