ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » MQ v 7.1 chlauth

Post new topic  Reply to topic Goto page Previous  1, 2, 3  Next
 MQ v 7.1 chlauth « View previous topic :: View next topic » 
Author Message
George Carey
PostPosted: Wed Nov 30, 2011 1:39 pm    Post subject: order Reply with quote

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
View user's profile Send private message Visit poster's website AIM Address
mqjeff
PostPosted: Wed Nov 30, 2011 2:24 pm    Post subject: Reply with quote

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
View user's profile Send private message
George Carey
PostPosted: Thu Dec 01, 2011 1:43 pm    Post subject: precedence order Reply with quote

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
View user's profile Send private message Visit poster's website AIM Address
Michael Dag
PostPosted: Fri Dec 02, 2011 2:20 am    Post subject: Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2602
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
View user's profile Send private message Visit poster's website MSN Messenger
mqjeff
PostPosted: Fri Dec 02, 2011 2:43 am    Post subject: Re: precedence order Reply with quote

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
View user's profile Send private message
ivanachukapawn
PostPosted: Wed Apr 10, 2013 8:22 am    Post subject: Channel Authentication not working Reply with quote

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
View user's profile Send private message
Michael Dag
PostPosted: Wed Apr 10, 2013 8:26 am    Post subject: Re: Channel Authentication not working Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2602
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
View user's profile Send private message Visit poster's website MSN Messenger
ivanachukapawn
PostPosted: Wed Apr 10, 2013 8:37 am    Post subject: Reply with quote

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
View user's profile Send private message
Michael Dag
PostPosted: Wed Apr 10, 2013 8:50 am    Post subject: Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2602
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
View user's profile Send private message Visit poster's website MSN Messenger
mqjeff
PostPosted: Wed Apr 10, 2013 9:03 am    Post subject: Reply with quote

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
View user's profile Send private message
ivanachukapawn
PostPosted: Wed Apr 10, 2013 10:08 am    Post subject: Reply with quote

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
View user's profile Send private message
Michael Dag
PostPosted: Wed Apr 10, 2013 10:18 am    Post subject: Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2602
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
View user's profile Send private message Visit poster's website MSN Messenger
ivanachukapawn
PostPosted: Wed Apr 10, 2013 10:43 am    Post subject: Reply with quote

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
View user's profile Send private message
Michael Dag
PostPosted: Wed Apr 10, 2013 2:09 pm    Post subject: Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2602
Location: The Netherlands (Amsterdam)

starting over is a very good plan!
_________________
Michael



MQSystems Facebook page
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
gbaddeley
PostPosted: Wed Apr 10, 2013 6:45 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2, 3  Next Page 2 of 3

MQSeries.net Forum Index » General IBM MQ Support » MQ v 7.1 chlauth
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.