| Author |
Message
|
| fjb_saper |
 Posted: Tue Mar 10, 2015 1:58 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Remove the allow ip rule and check why it is not working... 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| ivanachukapawn |
| Posted: Wed Mar 11, 2015 11:04 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| when the IP rule is missing, the connection gets blocked by the backstop rule. (I ran Match (RUNCHECK) ALL) When the IP rule is present (allowing access for specified subnet) the connection is not blocked. But knowing that doesn't seem to help answer the question, which is: How can another connection avoid blockage by the backstop rule when there is no Host/IP rule allowing. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 11, 2015 11:36 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ivanachukapawn wrote: |
| when the IP rule is missing, the connection gets blocked by the backstop rule. (I ran Match (RUNCHECK) ALL) When the IP rule is present (allowing access for specified subnet) the connection is not blocked. But knowing that doesn't seem to help answer the question, which is: How can another connection avoid blockage by the backstop rule when there is no Host/IP rule allowing. |
Which version of MQ did you run it on ? My V8.0.0.2 did not quite behave that way...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Wed Mar 11, 2015 11:37 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 11, 2015 11:47 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
if it doesn't behave as described, open a PMR...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Tue Mar 17, 2015 5:54 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Just to clear something up here, you do not need any IP Address information on a TYPE(USERMAP) rule in order for it to over-ride the back stop rule (i.e. a TYPE(ADDRESSMAP) rule which matches all IP Addresses).
This is because the TYPE(USERMAP) rule is more specific than the TYPE(ADDRESSMAP) rule, so if it matches, it wins. Simple as. No need for IP Address restrictor in order to make it more specific, it just is more specific by TYPE.
To work out why you are being blocked, please post the error message from the queue manager error log showing that your channel was blocked. This contains all you need to work out what rule blocked you.
Cheers
Morag 
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Tue Mar 17, 2015 11:17 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Thank you Morag, I appreciate your help in understanding this deepening mystery.
I removed the IP from the USERMAP rule and attempted the connection. As expected, I got a 2035 response - and an error log message
| Quote: |
AMQ9777: Channel was blocked
EXPLANATION:
The inbound channel 'IEP.RUP.SVRCONN.1' was blocked from address
'172.16.134.103' because the active values of the channel matched a record
configured with USERSRC(NOACCESS). The active values of the channel were
'CLNTUSER()'.
|
I ran DIS CHLAUTH (CHANNELNAME) MATCH(RUNCHECK) ALL and confirmed that the connection attempt matched the backstop-rule.
So now we have an idea as to why the connection attempt matched the backstop-rule and not the USERMAP rule - ostensibly because CLNTUSER was not supplied. AMQ9777 says "the active values of the channel were 'CLNTUSER()'. Not sure how that could be - because when address subnet is supplied in the USERMAP record, now it matches and allows the connection. So I guess a remaining questions is:
Why is the active value of the channel 'CLNTUSER()' when IP is not supplied on the USERMAP record, and userID is obviously present when IP is supplied on the USERMAP record?
Incidentally, I know that the userID is being supplied for this connection because the application authorization is all setup in OAM - and if the OAM config is removed, the user cannot connect to the QMGR and access queues etc. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 17, 2015 11:30 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
A good step forward. Now find out why no client user is being supplied when you think it should be there?. What API are you using for the connection to the queue manager?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Tue Mar 17, 2015 12:00 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
FJB
I'm thinking that when IP is supplied on the CHLAUTH USERMAP record for this UserID and the connection attempt succeeds, that this confirms that the userID is being supplied - the USERMAP record works only when the IP is supplied and matches - the UserID in the USERMAP rule. So perhaps an accurate question to ask would be =
[quote]How could the userID be missing on the connection attempt being made with a USERMAP record with blank ADDRESS - but is not missing when the connection attempt is made when the USERMAP record has a subnet specified in the ADDRESS field. Smoke and mirrors.
I suggest (from decades of experience as an application architect/developer) that the indicated procedure for analyzing this would be to debug the MQI API during the connection attempt - both on the client and the server - attempt to make some sense out of this.
But now we come to FJB question #2 -
| Quote: |
| What API are you using for the connection to the queue manager? |
Good question! but we don't like the answer - which is "a proprietary MQ API wrapper for which there is no source code (its lost). I know how ridiculously insane that sounds, but in this storyline, I am not the architect - (just an MQ admin) so cannot accept responsibility. And three more notes: The wrapper is proprietary, this wrapper's author is no longer available, and the wrapper is inextricably embedded in the source of multiple applications running on hundreds of VMs. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 17, 2015 12:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ivanachukapawn wrote: |
But now we come to FJB question #2 -
| Quote: |
| What API are you using for the connection to the queue manager? |
Good question! but we don't like the answer - which is "a proprietary MQ API wrapper for which there is no source code (its lost). I know how ridiculously insane that sounds, but in this storyline, I am not the architect - (just an MQ admin) so cannot accept responsibility. And three more notes: The wrapper is proprietary, this wrapper's author is no longer available, and the wrapper is inextricably embedded in the source of multiple applications running on hundreds of VMs. |
So the reason you're not seeing the userId when you know you supplied it could be in the wrapper code. Depending on how old that wrapper code is, it might be beneficial to redo a wrapper from the base up and document it.
The V8 client having changed a lot about presenting user and password you might have to do that anyways...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Tue Mar 17, 2015 12:55 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
FJB
You wrote
| Quote: |
| So the reason you're not seeing the userId when you know you supplied it could be in the wrapper code. |
You're right - it could be wrapper code. But I'm thinking the unthinkable - the problem might be in MQ code for CHLAUTH.
I suggest that the problem might be in MQ Code because:
#1 The USERMAP rule specifying both CLNTUSER and ADDRESS works - there is a match, and the CLNT gets a connection. Correct me if I am wrong but this USERMAP rule couldn't work (getting a match) unless the client supplied an ID which matched the CLNTUSER field in the record.
#2. There is plenty of evidence that UserID is being supplied. That is because the application(s) depend on the configured OAM authorizing the user QMGR connection and Queue access. When, there is a mistake in OAM configuration, the client applications receive authorization errors.
#3. Only evidence supporting the hypothesis that UserID is not being supplied is the text from the AMQ9777 error messages which says:
| Quote: |
The active values of the channel were
'CLNTUSER()'. |
I suggest that the code behind the generation of this error is faulty - maybe conditionally looking in the wrong place for UserID -
About the wrapper: No argument. It should be rewritten: When we finally get around to MQ 8 I suspect that we will disable Connection Authentication - the architects do not want to even think about replacing the wrapper with a rewrite. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 17, 2015 1:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ivanachukapawn wrote: |
FJB
You wrote
| Quote: |
| So the reason you're not seeing the userId when you know you supplied it could be in the wrapper code. |
You're right - it could be wrapper code. But I'm thinking the unthinkable - the problem might be in MQ code for CHLAUTH.
I suggest that the problem might be in MQ Code because:
#1 The USERMAP rule specifying both CLNTUSER and ADDRESS works - there is a match, and the CLNT gets a connection. Correct me if I am wrong but this USERMAP rule couldn't work (getting a match) unless the client supplied an ID which matched the CLNTUSER field in the record. |
If you follow up my posts in this thread, I got it to work as described and designed on my 8.0.0.2 qmgr.
| ivanachukapawn wrote: |
| #2. There is plenty of evidence that UserID is being supplied. That is because the application(s) depend on the configured OAM authorizing the user QMGR connection and Queue access. When, there is a mistake in OAM configuration, the client applications receive authorization errors. |
Maybe... depends. Are you using some kind of client side security exit?, may be there is indeed a bug in your version that has been fixed in a later fix pack? Are you on the latest fix pack?
| ivanachukapawn wrote: |
#3. Only evidence supporting the hypothesis that UserID is not being supplied is the text from the AMQ9777 error messages which says:
| Quote: |
The active values of the channel were
'CLNTUSER()'. |
I suggest that the code behind the generation of this error is faulty - maybe conditionally looking in the wrong place for UserID -
About the wrapper: No argument. It should be rewritten: When we finally get around to MQ 8 I suspect that we will disable Connection Authentication - the architects do not want to even think about replacing the wrapper with a rewrite. |
Why disable connauth? Use mqccred client side exit for your applications... (no change to the app code, kind of, because you may up ending using a channel table...) and let everybody else supply username and password.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Tue Mar 17, 2015 1:43 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| Well, what I see is concrete evidence that the application is supplying UserID on the connection attempt, because the connection is made only when a USERMAP CHLAUTH record is supplied which specifies the UserID (and an IP subnet). Aren't I right about that? I conclude that the UserID is being supplied, because the attempt matches UserID to CLNTUSER in the record. But then when the same connection attempt is made when the USERMAP CHLAUTH record does not specify IP subnet, then error message AMQ9777 claims that the CLNTUSER field is blank. This is contradictory behavior - same client connection attempt being made - no changes to client - but contradictory claims being made by CHLAUTH as to whether UserID was supplied. I am running MQ 7.5.0.4 (latest fixpack) - did you guys run CHLAUTH tests on MQ 7.5.0.4? |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Mar 18, 2015 3:33 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Ivana, it works for me on 7.5.0.4 as described by Morag. I created a new qmgr, deleted all default chlauth records, enabled chlauth on qmgr and added these two records:
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) DESCR('Back-stop rule')
SET CHLAUTH(SYSTEM.DEF.SVRCONN) TYPE(USERMAP) CLNTUSER('jcv') MCAUSER('mqm')
With only first one added, I cannot connect, with both of them, I can.
I didn't investigate much further, trying somehow to confuse chlauth about sent client user id, so sorry if this wasn't helpful. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 18, 2015 5:37 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
@ivanachukapawn Can you bounce your qmgr? Then check again...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
