| Author |
Message
|
| fjb_saper |
 Posted: Mon Feb 23, 2015 2:20 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
|
| Back to top |
|
 |
| ivanachukapawn |
| Posted: Mon Feb 23, 2015 2:31 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| Wow! That Morag post is dynamite! Thanks for the link. I thought it was a post on mqseries.net and employed the mqseriesnet search feature - |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Feb 23, 2015 2:44 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Tue Feb 24, 2015 12:12 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
I currently have this negative CHLAUTH record in the configuration:
Profile: SYSTEM.*
Channel Auth Type: Address Map
Address: *
User Source: No access
After I create the Back-Stop rule (which will block all remote access via channels) would it be advisable to delete the SYSTEM.* blocking rule (in that this blocking is already solicited by the Back-Stop rule)? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 24, 2015 2:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
It's safe to leave it. If ever you need to remove the backstop rule the system channels are still protected... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Mar 02, 2015 12:56 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
I configured the backstop-rule and have positive rules to authorize mq admins and application users. The queue managers are clustered and implement an architecture featuring queueing a request to a clustered queue and then dequeuing a reply from a local queue. The remote system dequeues the request and then queues the reply to our local queue - this connection for the reply is on CLUSTER RECEIVER channel TO.OURQMGRNAME. In order to have this connection work despite the "back-stop rule" I configured CHLAUTH as follows:
Channel Auth Profile Name: TO.OURQMGRNAME
Channel Auth Type: User Map
Client User ID: mqm
User Source: map
MCA User ID: mqm
this results in a 2035. I guess 'mqm' is not correct for the user name on a connection attempt via CLUSTER SENDER channel. Do you have an idea as to how to configure CHLAUTH correctly for the CLUSTER RECEIVER? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Mar 02, 2015 1:05 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well you are probably being hit by the backstop rule.
Try and open access on the cluster receiver channel for your subnet. (chlauth)
On the full repository you can be more fiddle and add the qmgr name.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Mar 02, 2015 1:13 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
fjb,
It occurred to me to try subnet - but this MQ is common service for many applications (50+) - each app can queue requests to remote queue managers in very large clusters - hundreds of servers and queue managers in a changing landscape. we don't have luxury of knowing in advance subnets and remote queue manager names. that's why I tried a CHLAUTH record which specified User Map with client ID = mqm. I thought that should work if in fact 'mqm' is the user ID on a connection attempt via CLUSTER SENDER. apparently, that is not the case. Perhaps I could specify * for Client User ID? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 02, 2015 1:18 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There's a default blockuser rule for all id's under the *MQADMIN class, which includes mqm.
So you need to put in a blockuser rule that is more specific to your clusrcvr and doesn't block mqm. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Mar 02, 2015 1:33 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
would running
set CHLAUTH (*) TYPE(BLOCKUSER) USERLIST (*MQADMIN) ACTION(REMOVE)
allow the remote cluster queue manager to get a connection ? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 02, 2015 1:36 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| ivanachukapawn wrote: |
would running
set CHLAUTH (*) TYPE(BLOCKUSER) USERLIST (*MQADMIN) ACTION(REMOVE)
allow the remote cluster queue manager to get a connection ? |
Yes...
but then it would also allow anyone else to connect as mqm.
Safer to do
| Code: |
| SET CHLAUTH(<pattern that matches your clusrcvr names>) TYPE(BLOCKUSER) USERLIST('thisuserdoesnotexist') ACTION(ADD) |
where the pattern is something like "*.CLUSRCVR" or however you are naming your cluster receivers. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 03, 2015 8:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I don't think this is the root problem. AFAIK the *MQADMIN rule is only valid for SVRCONN type channel.
I still believe it has to do with the backstop rule saying ip * usermap noaccess.
If your cluster is well behaved you should have a limited number of subnets to open it for. Worst case scenario, just create an allow rule for all ips (*) for the cluster receiver channel.
_________________
MQ & Broker admin
Last edited by fjb_saper on Tue Mar 03, 2015 8:06 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 03, 2015 8:05 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| BLOCKUSER rules get applied after all USERMAP rules have been applied. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 03, 2015 8:09 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Tue Mar 03, 2015 8:23 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| you guessed it, it is the "worst case scenario" (6 remote full REPOS QMs for badly behaved clusters with subnet list which is not manageable) - Thanks for your suggestion (allowing all IPs on the cluster receiver) I'm gonna try that. |
|
| Back to top |
|
|
|
|
