| Author |
Message
|
| George Carey |
 Posted: Wed Nov 30, 2011 1:39 pm Post subject: order |
 |
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Need to put the default rules back in some how and still have my more specific rule work.
The rule processing order is needing to be understood me thinks !
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Nov 30, 2011 2:24 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There's a fair amount of discussion of how precedence works for rules here.
In particular
| Quote: |
| A channel authentication record using a user ID or queue manager name takes priority over a record using an IP address. |
So you had a rule that blocked access to the mqm user, and a rule that allowed access to any IP address and mapped it to mqm user.
The rule blocking the mqm user took precedence.
EDIT:
You don't actually want to restore the default rules. The default rules are designed to block remote administrative access. You are trying to specifically allow remote administrative access, and then control exactly who and where can use remote administrative access. |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu Dec 01, 2011 1:43 pm Post subject: precedence order |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Yes, I had perused that a bit, I will have to study it.
It appears at least as convoluted and labyrinthine as the QMGR name resolution process.
Would be nice if a prose paragraph or two could be written that would encapsulate the gist of these rules at a higher normative perspective.
Thanks for the feedback on this.
...
A last question on this (hopefully). Is this bulleted list from the v7.1 InfoCenter documentation a statement of the exact and complete set of functions that can be done with the chlauth command or just a sample of the things that can be done ?
========
Channel authentication records can be created to perform the following functions:
•To block connections from specific IP addresses.
•To block connections from specific user IDs.
•To set an MCAUSER value to be used for any channel connecting from a specific IP address.
•To set an MCAUSER value to be used for any channel asserting a specific user ID.
•To set an MCAUSER value to be used for any channel having a specific SSL or TLS Distinguished Name (DN).
•To set an MCAUSER value to be used for any channel connecting from a specific queue manager.
•To block connections claiming to be from a certain queue manager unless the connection is from a specific IP address.
•To block connections presenting a certain SSL or TLS certificate unless the connection is from a specific IP address.
=================
GTC
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Dec 02, 2011 2:20 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
Sorry to come so late to the party... 
I struggled with this aswell...
the *MQADMIN blockuser is the last rule so after all the mapping has been done and somehow you manage to get some sort of *MQADMIN access this rule is enforced:
chlauth(*) type(blockuser) userlist(*MQADMIN)
to 'unlock' the *MQADMIN block for a specfific channel like for example MYSVRCONN
would be:
chlauth(MYSVRCONN) type(blockuser) userlist(nouser)
this is a specific blockuser rule for MYSVRCONN and overrules the general (*) blockuser rule only for this channel and lets you in... with admin authority if your userid has admin authority...
you can still use the block access from other IP addresses then yours to block access...
Hope this helps... took me some time to realise it... 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Dec 02, 2011 2:43 am Post subject: Re: precedence order |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| George Carey wrote: |
Thanks for the feedback on this.
...
A last question on this (hopefully). Is this bulleted list from the v7.1 InfoCenter documentation a statement of the exact and complete set of functions that can be done with the chlauth command or just a sample of the things that can be done ? |
The permutations that are possible are all of the permutations of legal "SET CHLAUTH" statements.
And then the interactions of each of those types with each other. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Wed Apr 10, 2013 8:22 am Post subject: Channel Authentication not working |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
I followed this thread with great interest thinking that I too would be able to leave CHLAUTH(ENABLED) and still use MQExplorer. But alas, that is not the case. I did a removeall and cleaned out the existing authentication records for SYSTEM.ADMIN.SVRCONN. Then I tried the following recommended/endorsed SET CHLAUTH command:
set chlauth(system.admin.svrconn) type(addressmap) address(*) usersrc(map) mcauser('mqm') action(replace) and still was not authorized to connect the qmgr using SYSTEM.ADMIN.SVRCONN. So then I cleaned out the existing authentication record, and created my own (based on info from the MQ7.5 Info Center) which is:
set chlauth (SYSTEM.ADMIN.SVRCONN) TYPE(USERMAP) ACTION(REPLACE) CLNTUSER('ivanachukapawn') MCAUSER('mqm') - but with the same result = not authorized to connect: I could use some help in getting CHLAUTH to work - |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Apr 10, 2013 8:26 am Post subject: Re: Channel Authentication not working |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| ivanachukapawn wrote: |
I followed this thread with great interest thinking that I too would be able to leave CHLAUTH(ENABLED) and still use MQExplorer. But alas, that is not the case. I did a removeall and cleaned out the existing authentication records for SYSTEM.ADMIN.SVRCONN. Then I tried the following recommended/endorsed SET CHLAUTH command:
set chlauth(system.admin.svrconn) type(addressmap) address(*) usersrc(map) mcauser('mqm') action(replace) and still was not authorized to connect the qmgr using SYSTEM.ADMIN.SVRCONN. So then I cleaned out the existing authentication record, and created my own (based on info from the MQ7.5 Info Center) which is:
set chlauth (SYSTEM.ADMIN.SVRCONN) TYPE(USERMAP) ACTION(REPLACE) CLNTUSER('ivanachukapawn') MCAUSER('mqm') - but with the same result = not authorized to connect: I could use some help in getting CHLAUTH to work - |
what other CHLAUTH rules are in place?
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Wed Apr 10, 2013 8:37 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| no other records. I became aware of the functional problems related to multiple authentical records (including the default record) - so I have been doing a REMOVEALL followed by a DISPLAY CHLAUTH (SYSTEM.ADMIN.SVRCONN) to ensure that no records exist - prior to the SET CHLAUTH records I posted earlier. Really puzzled about this. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Apr 10, 2013 8:50 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
So these default rules (notice the (*)! ) are all gone?
| Code: |
dis chlauth(*)
1 : dis chlauth(*)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
AMQ8878: Display channel authentication record details.
CHLAUTH(*) TYPE(BLOCKUSER)
USERLIST(*MQADMIN) |
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 10, 2013 9:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
At this point, the recommendation is to add a specific BLOCKUSER rule that applies to SYSTEM.ADMIN.SVRCONN - well, really, to some *specific* non-default SVRCONN that doesn't have a well known name - that will be more specific than the SYSTEM.* rule and only block non-existent users.
Then the MCAUSER on the channel can be MQM and the mqm user is not blocked by the chlauth rules on the channel. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Wed Apr 10, 2013 10:08 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| they weren't gone. I had removed only the authorization records for (SYSTEM.ADMIN.SVRCONN). THANKS! Once I removed every swinging authorization record (through permutations of set CHLAUTH action(REMOVE) and (REMOVEALL) commands) THEN I was automatically connected. I am very grateful for your help. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Apr 10, 2013 10:18 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| ivanachukapawn wrote: |
| they weren't gone. I had removed only the authorization records for (SYSTEM.ADMIN.SVRCONN). THANKS! Once I removed every swinging authorization record (through permutations of set CHLAUTH action(REMOVE) and (REMOVEALL) commands) THEN I was automatically connected. I am very grateful for your help. |
I repeat!!! you should NOT remove all CHLAUTH records!!!
find out WHY you are blocked!!! see event viewer on windows!!!
Hint!!! you need 2 extra rules to allow remote admin in for a custom new ADMIN channel!!!
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Wed Apr 10, 2013 10:43 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
I guess I'll need more than a hint to rectify this configuration. I don't know what records I need to re-instate or why it is bad to remove them. I do know that I could not get connected until I removed them. I can look at the event log to find out what was blocking me before, but really have no way of knowing even then what records need to be re-instated. Until now, the MQ7.5 Info Center has been my only source of information regarding CHLAUTH. Do you know of another (more complete) source of information on this subject?
My plan now is to delete this qmgr and start over (I have that latitude, its a sandbox environment) - Then I will carefully try again to get MQExplorer connected (without disabling CHLAUTH or removing all channel authentication records). |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Apr 10, 2013 2:09 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Apr 10, 2013 6:45 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
CHLAUTH rules for MQ administration / Explorer in v7.1 (and later) are covered in Section 9.2.7 of the new MQ security Redbook, available at http://www.redbooks.ibm.com/abstracts/sg248069.html
The 3 default rules do not need to be changed.
A new rule can be added to prevent the default rule CHLAUTH(*) TYPE(BLOCKUSER) USERLIST(*MQADMIN) from blocking all MQ admin MCA userids from all SVRCONN channels:
set chlauth('YOUR.ADMIN.CHL') type(blockuser) action(replace) +
descr('Rule to allow MQ admin userids on this channel') +
userlist('nobody')
This takes precedence over the default rule because it applies to the specific channel name. All it does is block a MCAUSER that would never be used anyway, and therefore allows MCAUSER to become other user, including admins.
_________________
Glenn |
|
| Back to top |
|
|
|
|
