| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| RACF and Administrative SVRCONN channels |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Wed Mar 10, 2010 6:44 pm Post subject: RACF and Administrative SVRCONN channels |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
All my incoming channels (SVRCONN, RQSTR, RCVR, CLUSRCVR) are tagged with an ID in the MCAUSER. The PUTAUT value is set to ONLYMCA. This ID does not have any administrative access (no access to the command queue). So, I think I can say no one can admin my z/OS QM from an MQ Client connection or from another QM.
I want to allow an MQ Client admin access. Me and my MO71 is that MQ Client.
Option A is to tag my MO71 SVRCONN channel with my TSO ID in the MCAUSER, PUTAUT = ONLYMCA, and then restrict access to that channel via SSL or a Security Exit so only I can use it.
My question to you is Option B feasible if I don't implement SSL or an Exit right this moment.
Option B.
I leave the MCAUSER blank on my MO71 SVRCONN channel.
I set PUTAUT = Default.
My RESLEVEL has a UACC of NONE.
I assume that this means 2 IDs will be checked on this connection - the ID of the "channel", which is really the CHIN ID, and my network ID flowing from my desktop.
My CHIN ID has access to the command queue. But remember, every other channel is tagged with an MCAUSER and PUTAUT=ONLYMCA, so I don't think this is a concern.
If I get the MVS guys to define my network ID in RACF, and then grant it access to the command queue plus any other queues I need, does this mean that this channel, while "wide open", will only allow my ID administrative access? I do realize others may try to connect to it, but since their IDs will be checked, and their IDs don't have access, they will fail.
The risk is that they know my ID has access, and they could spoof it? A secure SSL Cert or a password-using Exit eliminates that. But since mqm and MUSR_MQADMIN and a blank ID have no power to a z/OS QM (unlike non z/OS MQ), it’s a little safer.
If Option A is not feasible now (for stupid political reasons we don't need to get into), I want to know if Option B is realistic, or a complete waste of time, assuming I need an administrative SVRCONN channel now.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Wed Mar 10, 2010 11:26 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2602
Location: The Netherlands (Amsterdam)
|
You need to restrict access from any other place then your workstation, so you need to limit acess to the channel via SSL and Exit like BlockIP.
wether you set MCAUSER Blank or not is in this case less relevant as you want Admin access through that channel...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Mar 11, 2010 12:35 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
I also added the security exit to channels i dont want to be used. In the beginning i used that "ONLYMCA" and a non defined MCA user too, but this allows the channel to start, and the user trying to connect is blocked on access to queues or when he tries to issue commands.
Now i also use a security exit that blocks the channel to start on these channels. may not be a real difference, but somehow looks more secure to me.
For the administation access, i also prefer the SSL and exit combination. Things may work based on lan userid being defined in racf, but - remember, everybody using a fat client being alowed to create a local userid may use this to fake your userid......
_________________
Regards, Butcher |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 11, 2010 6:39 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| Mr Butcher wrote: |
I also added the security exit to channels i dont want to be used. In the beginning i used that "ONLYMCA" and a non defined MCA user too, but this allows the channel to start, and the user trying to connect is blocked on access to queues or when he tries to issue commands.
Now i also use a security exit that blocks the channel to start on these channels. may not be a real difference, but somehow looks more secure to me.
For the administation access, i also prefer the SSL and exit combination. Things may work based on lan userid being defined in racf, but - remember, everybody using a fat client being alowed to create a local userid may use this to fake your userid...... |
Shouldn't it be enough using the lan id as CN and an appropriate list of OUs in the SSLPeer when using SSL?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Mar 11, 2010 7:19 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2602
Location: The Netherlands (Amsterdam)
|
| fjb_saper wrote: |
| Mr Butcher wrote: |
I also added the security exit to channels i dont want to be used. In the beginning i used that "ONLYMCA" and a non defined MCA user too, but this allows the channel to start, and the user trying to connect is blocked on access to queues or when he tries to issue commands.
Now i also use a security exit that blocks the channel to start on these channels. may not be a real difference, but somehow looks more secure to me.
For the administation access, i also prefer the SSL and exit combination. Things may work based on lan userid being defined in racf, but - remember, everybody using a fat client being alowed to create a local userid may use this to fake your userid...... |
Shouldn't it be enough using the lan id as CN and an appropriate list of OUs in the SSLPeer when using SSL?
|
without an additional exit (like BlockIP2) and only SSL, please explain 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 11, 2010 1:31 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Well setting SSL on the channel you can force the connecting party to present a certificate. However this is not enough as anybody having a cert signed by the CA in your qmgr's certstore is eligible.
In order to restrict this you can use the Distinguished Name (DN) to restrict the allowed values in SSL PEER. This means that the party trying to connect will have to present a certificate having the specific SSLPEER values you are requesting. These values should be unique by CA provider.
So as a client you can present your cert with dn='CN="yourname", OU="IT", OU="MQ", OU="MQADMINISTRATOR", O="MYCORP", L="MyCity", C="US" '. On the server the SSLPEER value for the channel can be:
'OU="MQADMINISTRATOR", OU="MQ", OU="IT", O="MYCORP"'
This way only people presenting a cert from your corporation in the org units of IT, MQ, MQADMINISTRATOR can connect.
This works well with self signed certs. If you add an internal CA authority, you may want to remove all non used CA authorities from the certstore.
As well make sure you maintain the CRL (Certificate Revocation List) as it will allow you to invalidate an individual cert that otherwise has the right DN.
There is an interesting link to a developerworks article about that on http://t-rob.net
Have fun.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Mar 11, 2010 2:22 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2602
Location: The Netherlands (Amsterdam)
|
Oh sorry, I think I misunderstood you.
I thought you implied there was a relation between the supplied certificate CN value and the 'authority' assign to the channel based on this CN value...
I know you can restrict who can access the channel by the SSLPEER value, but not what they have access to, as that is tied to the MCAUSER value, which you can not leave blank as we all know by now... (do we really?)
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 11, 2010 2:49 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
A few comments:
About RESLEVEL: Once successful check of the connection profile, the same user ID is checked against the profile ssid.RESLEVEL in the MQADMIN class. This sets the level of resource checking for all subsequent API calls on that connection that are affected by resource security, meaning access to queues, processes, and so on.
MCA user IDs require access to the ssid.CHIN profile. I'm guessing that this is already in place, or your channels would not start.
Presuming that you had only one channel, securing that channel to only one laptop/desktop would seem enough; but I gather that there will be other less secured channels.
Any less secured channel(s) (or a local application) will allow others with any admin tool (including home-grown) access to the SYSTEM.COMMAND.INPUT queue and SYSTEM.COMMAND.REPLY.MODEL. I'd suggest ensuring that RACF rules keep strays out of both queues.
Make sure that there are no aliases of the command input queue.
Make sure that there are no NO security switches enabled, such that security checks are bypassed.
Make sure that ssid.ALTERNATE.USER.* UACC NONE.
Make sure that apps cannot change context fields.
If RESLEVEL results in two checks, PUTAUT(CTX) will cause the MCA userid AND the MQMD userid in the to be a tested for auth to the command queue.
What am I forgetting...?
_________________
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: Thu Mar 11, 2010 3:06 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| Michael Dag wrote: |
| I know you can restrict who can access the channel by the SSLPEER value, but not what they have access to, as that is tied to the MCAUSER value, which you can not leave blank as we all know by now... (do we really?) |
If the channel is an MQ Admin channel, and SSL limits the use of that channel to a particular MQ Admin, I don't there is any harm in leaving MCAUSER blank. Unless this particular MQ Admin should have less than 100% access.
But back to my original question, rephrased...
On Windows / Unix, the super MQ Admin IDs are well known, and a blank Client ID defaults to super user. But on z/OS, I was wondering with my Option B what would RACF do when presented with a blank client ID. Does it shrug its shoulders and say "Eh, what the heck. No ID, no problem, come on in." Or does it have a better default behaviour than Windows / UNIX and maybe it doesn't accept the connection at all?
I do realize that if they happen to deduce my TSO ID and can send that ID from the client then they are in if that channel doesn't have SSL (correctly set up) or an Exit that checks ID and password.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 11, 2010 10:00 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I was wondering with my Option B what would RACF do when presented with a blank client ID. |
The default is to flow the logged in userid on the client. I suppose you could flow blanks. With UACC(NONE) for the command input queue, access would be denied.
| Quote: |
| Does it shrug its shoulders and say "Eh, what the heck. No ID, no problem, come on in." Or does it have a better default behaviour than Windows / UNIX and maybe it doesn't accept the connection at all? |
z behaves better generally; but this is a client issue. There is room for improvement with the client and security. Perhaps some future release...
As usual, access control is based on the userid used by the svrconn process. MCAUSER in the MQCD is the source of this id for MQI calls from the client app.
By default, the userid of the logged in user will be flowed to the server, and become the MCAUSER id. This is a significant exposure because client software is widely distributed. This where SSL helps quite a bit.
Here are the possibilities (and this is not all that different from midrange qmgrs):
1) you can install a security exit on the server, and authenticate the flowed userid.
2) you can install a security exit on the client, and flow a userid and pwd.
3) you can install security exits on both client and server; and client security exit can flow userid/pwd, and server security exit can authenticate this id, and set MCAUSER to that id or some other id.
4) you can have no security exits on both ends. If MCAUSER is blank, the flowed userid will be the MCAUSER; or if the MCAUSER is non-blank, this value will be the userid.
From my prior post: make sure that there are no NO switches set, and that all resource class profiles are defined. Make sure RACF rules set UACC(NONE) for important things - like the command input queue.
_________________
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
|
|
|
|
