| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Help on ChannelAUTH and MO71 |
« View previous topic :: View next topic » |
| Author |
Message
|
| cicsprog |
 Posted: Tue Jul 12, 2016 9:22 am Post subject: Help on ChannelAUTH and MO71 |
 |
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
I find the Channel Auth parameters very confusing on how to implement. Maybe someone can help my little brain with them.
Requirement: Have MQ Admins that want to use MO71 but their Windows userids are not valid in RACF. Want to configure ChannelAuth so that we only change the behavior for a certain SVRCONN channel and not any others.
Any suggestions would be appreciated. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Jul 12, 2016 11:13 am Post subject: Re: Help on ChannelAUTH and MO71 |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| cicsprog wrote: |
I find the Channel Auth parameters very confusing on how to implement. Maybe someone can help my little brain with them.
Requirement: Have MQ Admins that want to use MO71 but their Windows userids are not valid in RACF. Want to configure ChannelAuth so that we only change the behavior for a certain SVRCONN channel and not any others.
Any suggestions would be appreciated. |
So you set up your chlauth records to be valid only for that channel.
Depending on whether or not the users need priviledged access you will need to create a block record. Otherwise create a user map entry for each user you need mapped.
You can see and learn more on the topic by reading Morag's entries on the matter in Developerworks....
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Tue Jul 12, 2016 3:31 pm Post subject: Re: Help on ChannelAUTH and MO71 |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| cicsprog wrote: |
| Requirement: Have MQ Admins that want to use MO71 but their Windows userids are not valid in RACF. Want to configure ChannelAuth so that we only change the behavior for a certain SVRCONN channel and not any others. |
I suspect what you want to do is map those MQ Admins onto a RACF user ID when they connect. I'm assuming that you already have the RACF user ID you want them to be mapped to that has been set up with the appropriate authorities for what they need to do - if not, shout, and we can cover that too.
The below choices also assume that you have a back-stop rule, which locks down everything and then you open up what you need (bit like a firewall). Read CHLAUTH - the back-stop rule for more on the back-stop rule. Of course, having a backstop rule will affect your other channels, so if you're happy with their security already, you might not want one of these. You could choose to put in a back-stop rule only for your MQ Admin channel, so that anyone trying to use that channel who isn't mapped to an appropriate RACF user id by one of the positive rules you put in place, falls through to your channel specific back-stop rule. That would look like this:-
| Code: |
| SET CHLAUTH(channel-name) TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) DESCR('Back-stop rule for this channel') |
You have a few choices about how you do this mapping. It comes downs to how strong a level of security you want on the mapping - i.e how hard a hacker has to try to be able to pretend to be one of your MQ Admins.
- Map MQ Admins by their known Windows userid and their known IP address
Even though the Windows userids are not known to RACF, they can be used (simply as a string match) in a CHLAUTH rule. In other words, if you see a client present this user id, don't use it, but map it into this other user id. Since it's very easy to make a user id on a client machine, it's best if this is combined with the known IP address where the MQ Admins machine lives. Of course IP addresses are also spoofable, so even combining the two, this is considered the weakest choice. Here's the CHLAUTH rule to use.
| Code: |
| SET CHLAUTH(channel-name) TYPE(USERMAP) CLNTUSER('windows-user-id') ADDRESS('ip-address') USERSRC(MAP) MCAUSER(RACF-user-id) |
As above, but make them prove who they are with a password
If you have IBM MQ for z/OS V8 or above, you can use a password to improve your authentication of these MQ admins. You can mandate that they provide a user id and password, and MO71 can be set up to do that, and then still map them to a different RACF user id for all their authorisations if you wish, so that they can't do anything if they log on with that RACF user id and password, it is just used as a gatekeeper. In the commands below, the default IDPWOS object has CHCKCLNT and CHCKLOCL as OPTIONAL which shouldn't then affect any other application, and we bump it up to REQUIRED for your specific channel. If you have it REQUIRED on the AUTHINFO object that's not a problem with this channel, but it can't be NONE.
| Code: |
ALTER QMGR CONNAUTH(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
REFRESH SECURITY TYPE(CONNAUTH)
SET CHLAUTH(channel-name) TYPE(USERMAP) CLNTUSER('windows-user-id') ADDRESS('ip-address') USERSRC(MAP) MCAUSER(RACF-user-id) CHCKCLNT(REQUIRED) |
Map MQAdmins by their digital certificate details
The strongest level of authentication is to use SSL/TLS and digital certificates. Here's the CHLAUTH rule you would use.
| Code: |
| SET CHLAUTH(channel-name) TYPE(SSLPEERMAP) SSLPEER('subjects-dn-from-mq-admin-client-cert') USERSRC(MAP) MCAUSER(RACF-user-id) |
I have written a few blog posts about security access to queue managers by admins in the past, although most are concerned about the privileged vs non-privileged question that crops up on distributed. Helpfully we don't have that problem on z/OS! In case you're interested, some of it still applies to z/OS, here's a few links:
As I look back on them, they are all very distributed based, shame on me! Your question tempts me to write a z/OS slanted equivalent blog post.
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
|
|
|
|
