| Author |
Message
|
| George Carey |
 Posted: Tue Nov 29, 2011 3:22 pm Post subject: MQ v 7.1 chlauth |
 |
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
OK, what gives I cannot get the MQExplorer v7.1 on Linux to connect to the Queue Manager without disabling 'chlauth' on the qmgr .
I have set the mcauser to 'mqm' on the channel definition (trying to force it ... but no go)
I have used the set chlauth command as follows:
set chlauth(system.admin.svrconn) type(addressmap) address(*) usersrc(map) mcauser('mqm') action(replace)
I get nothing but Access not permitted. You are not authorized to perform this operation (AMQ4036)
I do 'alter qmgr chlauth(disabled)' and all works fine of course.
So what am I missing on v7.1 permission setup ?
(I will add this just for completeness but quite sure not relevant ... the Linux strmqcfg GUI output is being sent back through a putty session to a Windows box running 'Xming' x-windows manager ... working fine so as I say likely not relevant)
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
 |
| George Carey |
| Posted: Wed Nov 30, 2011 8:21 am Post subject: Anybody ? |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Anybody ... playing/using v 7.1 MQExplorer on Linux yet and have any such issues ?
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 30, 2011 8:29 am Post subject: Re: Anybody ? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| George Carey wrote: |
| Anybody ... playing/using v 7.1 MQExplorer on Linux yet and have any such issues ? |
Apparently not.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 30, 2011 8:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So, first step.
Does the channel accept connections from a Windows MQ Explorer?
second step -
Does dis chlauth(*) confirm that the right channel name is in force?
third step -
did you need to put the '*' in quotes to avoid it being interpreted by something other than runmqsc?
I've reviewed the doc, and you appear to have a correct configuration on the chlauth statement. But it might not end up the right configuration because of above. |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed Nov 30, 2011 8:54 am Post subject: works if chlauth disabled ... so other configs good |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
| Quote: |
So, first step.
Does the channel accept connections from a Windows MQ Explorer? |
From my original post text:
| Quote: |
| I do 'alter qmgr chlauth(disabled)' and all works fine of course. |
Need I say more ?
Quote not needed ... have tried other option also don't work. But disabling 'chlauth' allows MQExplorer to connect and work.
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 |
|
|
| mqjeff |
| Posted: Wed Nov 30, 2011 10:25 am Post subject: Re: works if chlauth disabled ... so other configs good |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| George Carey wrote: |
| Quote: |
So, first step.
Does the channel accept connections from a Windows MQ Explorer? |
From my original post text:
| Quote: |
| I do 'alter qmgr chlauth(disabled)' and all works fine of course. |
Need I say more ? |
Yes. I asked the question about a Windows MQ Explorer in order to determine if it's a specific issue with connections from a LINUX MQ explorer.
Certainly disabling chlauth would allow things to work - the rule you created isn't enforced then.
So it's not clear if you've eliminated the possibility that it's the linux MQ explorer doing the wrong thing or if the channel authorization rule is wrong.
If it works with chlauth enabled from a Windows MQ Explorer but fails from the Linux one, that's one thing. If it works or fails from both, that's something else.
And the dis chlauth(*) showed that the channel name had been properly folded to UPPER CASE so that it matched SYSTEM.ADMIN.SVRCONN? |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed Nov 30, 2011 12:05 pm Post subject: Windows |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
I over looked the Windows qualifier on the MQ Explorer.
I have an MS0T MQExplorer Client that I can try from my windows box.
It should fail as well ... but I will see ... valid thing to check.
The dis chlauth(*) shows the channel names folded to upper case.
Will let you know on the Windows MQExplorer ... any other ideas ?
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed Nov 30, 2011 12:20 pm Post subject: MS0T |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
The behavior of the MS0T support pac MQExplorer client v7.0
is the the same as the Linux explorer, namely:
1.) It connects straight up with channel authorization records disabled
2.) It gives Access not permitted. You are not authorized to perform this operation (AMQ4036) when they are enabled.
This is a puzzlement ?
_________________
"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 12:31 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
In poking around at my local, windows, 7.1. qmgr... I noticed that it had already configured a generic chlauth rule for me at some point to disallow remote administrative access...
In fact, I noticed several default rules were already defined. The one in question that might have effect here is the usermap for denying access to *MQADMIN.
That is, it's likely that your chlauth record is allowing access to the IP Address, mapping the incoming user to the mqm user, and then the mqm user is blocked by the usermap.
So make sure that you don't have a usermap that denies *MQADMIN or specifically mqm. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 30, 2011 12:34 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
if you alter the the usermap rule to enable WARN, you might see for sure that it's the one doing the block.
EDIT, I guess it's not a usermap rule, it's a blockuser rule.
| Code: |
| dis chlauth(*) type(blockuser) |
Last edited by mqjeff on Wed Nov 30, 2011 12:39 pm; edited 1 time in total |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed Nov 30, 2011 12:34 pm Post subject: the rule |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Trying to fall back on a little logic:
1.)Either the rule to permit access is not being seen/recognized by the QMGR
2.)Or the rule syntax is not correctly set to give the permissions I am expecting
1.) could be caused by a bug or by a mis-installation of some kind.
2.) could be caused by a misunderstanding of the set chlauth command
MQExplorer in V7.1 does not put any special files in the /home/mqm directory I hope as I was deleting files/directories there that I did not know their purpose and that I had not created.
_________________
"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 12:40 pm Post subject: Re: the rule |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| George Carey wrote: |
Trying to fall back on a little logic:
1.)Either the rule to permit access is not being seen/recognized by the QMGR
2.)Or the rule syntax is not correctly set to give the permissions I am expecting |
I think it's
3). The rule to permit access is being seen and recognized and applied. Another rule to deny access is then being enforced. |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed Nov 30, 2011 1:01 pm Post subject: Order of rules |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
I see three rules the most specific is for my system.admin.svrconn channel
others exist for
chlauth(system.*) usersrc(blockaccess)
and
chlauth(*) type(blockuser) userlist(*MQADMIN)
So what is the order of enforcement of the rule ?
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed Nov 30, 2011 1:11 pm Post subject: command syntax |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
This is not a correct command syntax ...
set chlauth(system.admin.svrconn) type(addressmap) address(*) usersrc(map) mcauser('mqm') action(replace)
Apparently I did not type this command as is as it does not work now giving a parameter not allowed for this channel authentication user source value error ... I can't seem to get the correct syntax in my trial and errors yet.
Correction ... putting a warn(yes) in above syntax does not work taking it out and it works !!!
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed Nov 30, 2011 1:33 pm Post subject: action (remove) |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
removing the other two rules allows me to connect !!
Not sure that is what I ultimately want to do, however !
Wondering what the default behavior is with no rules in the channel authentication repository ?
Answer: It is same as Pre v7.1 authentication !
(which of course makes sense!)
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
|
|
