Author |
Message
|
smeunier |
Posted: Fri Jan 19, 2018 8:16 am Post subject: CHLAUTH problem with VIP address |
|
|
 Partisan
Joined: 19 Aug 2002 Posts: 305 Location: Green Mountains of Vermont
|
Environment:
Name: WebSphere MQ
Version: 8.0.0.4
Level: p800-004-151017
BuildType: IKAP - (Production)
Platform: WebSphere MQ for Linux (x86-64 platform)
Mode: 64-bit
O/S: Linux 3.10.0-514.26.2.el7.x86_64
InstName: Installation1
InstDesc:
Primary: Yes
InstPath: /opt/mqm
DataPath: /var/mqm
MaxCmdLevel: 802
LicenseType: Production
Issue: Unable to put a rule in place that satisfies the error below. Other IP addresses are not an issue, but this one is.
The IP address is from a F5 Load balancer that emits this address and not the source server IP. This may be the VIP
although it is not the address that the user uses to connect to the F5 (which I would consider the real VIP). It may be a VIP for the resource to the QMGR. Regardless, it is the address trying to pass the rule.
The standard default backstop CHLAUTH rules are in place as well as the following rules to authorize the IP address. I have also included the
results of a RUNCHECK, which identies the rule that it matches, so I'm not sure why I get the error or how to correct it.
The Error:
Channel Blocked Warning [2578]
Event Type : Channel
Queue Manager Name : MQHUB22
Connection Name : 10.42.11.202
Reason Qualifier : Channel Blocked NoAccess
Channel Name : FC9PF.SVRCONN
Client User Id : erkel
Appl Name : Governor
Blocking all channel access for the channel
AMQ8878: Display channel authentication record details.
CHLAUTH(FC9PF.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
WARN(YES)
Allowing this Address for specific user
AMQ8878: Display channel authentication record details.
CHLAUTH(FC9PF.SVRCONN) TYPE(USERMAP)
ADDRESS(10.42.11.202) CLNTUSER(erkel)
MCAUSER(erkel)
Results of RUNCHECK
8 : DISPLAY CHLAUTH('FC9PF.SVRCONN') MATCH(RUNCHECK) ALL ADDRESS('10.42.11.202') CLNTUSER('erkel')
AMQ8878: Display channel authentication record details.
CHLAUTH(FC9PF.SVRCONN) TYPE(USERMAP)
DESCR(Allow 10.42.11.202 access)
CUSTOM( ) ADDRESS(10.42.11.202)
CLNTUSER(erkel) MCAUSER(erkel)
USERSRC(MAP) CHCKCLNT(ASQMGR)
Is this a Virtual IP problem? in my non-networking mind, from an MQ perspective, I should be able to block/authorize an IP
address whether Virtual or static. Any ideas on why the rule would does not work or how to resolve the issue? |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Jan 19, 2018 9:09 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Ok so your backstop rule is in warn mode.
You need to look at the log to see why you cannot connect.
It could be that you are not passing the user in the correct CSP structure...
Regardless of the "true" IP of the F5 you need to authorize the IP that is displayed in the channel status, once you got it to run. And disable reverse DNS lookup if you haven't already done so.
 _________________ MQ & Broker admin |
|
Back to top |
|
 |
smeunier |
Posted: Mon Jan 22, 2018 8:12 am Post subject: |
|
|
 Partisan
Joined: 19 Aug 2002 Posts: 305 Location: Green Mountains of Vermont
|
Quote: |
And disable reverse DNS lookup if you haven't already done so. |
This I will do, as it was enabled for using hostnames in the CHLAUTHS, but fact is, we never do.
Quote: |
Ok so your backstop rule is in warn mode. |
If I understand your implication here, your indicating to turn warn mode off and let it fail to see what that reason is. I could do that, but here is an interesting observation.
A specific application ran on many servers for data movement. Those application all used the same SVRCONN channel. No CHLAUTH errors were generated with that configuration. To have further separation, I created a separate SVRCONN channel. for the applications to use. This would allow me to see what connections are coming from what servers for that application. Identical definitions(other than name) were defined for CHALAUTHS as for the original channel. When the applications started up with the new SVRCONN channels, this is when the errors started showing. I had them revert back to the singular channel and the errors went away. Very strange. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Jan 22, 2018 11:38 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Is there anything in the channels local address?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
smeunier |
Posted: Mon Jan 22, 2018 12:57 pm Post subject: |
|
|
 Partisan
Joined: 19 Aug 2002 Posts: 305 Location: Green Mountains of Vermont
|
Quote: |
Is there anything in the channels local address? |
Not sure I understand the root of that question. Local Address is not a valid parameter for SVRCONN channels. These problems are related to SVRCONN channels. |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Jan 23, 2018 5:53 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
smeunier wrote: |
Quote: |
Is there anything in the channels local address? |
Not sure I understand the root of that question. Local Address is not a valid parameter for SVRCONN channels. These problems are related to SVRCONN channels. |
Sorry that would then be the local address field of the listener...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
hughson |
Posted: Tue Feb 20, 2018 2:02 pm Post subject: Re: CHLAUTH problem with VIP address |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
smeunier wrote: |
Issue: Unable to put a rule in place that satisfies the error below. Other IP addresses are not an issue, but this one is.
The IP address is from a F5 Load balancer that emits this address and not the source server IP. This may be the VIP
although it is not the address that the user uses to connect to the F5 (which I would consider the real VIP). It may be a VIP for the resource to the QMGR. Regardless, it is the address trying to pass the rule.
The standard default backstop CHLAUTH rules are in place as well as the following rules to authorize the IP address. I have also included the
results of a RUNCHECK, which identies the rule that it matches, so I'm not sure why I get the error or how to correct it.
The Error:
Channel Blocked Warning [2578]
Event Type : Channel
Queue Manager Name : MQHUB22
Connection Name : 10.42.11.202
Reason Qualifier : Channel Blocked NoAccess
Channel Name : FC9PF.SVRCONN
Client User Id : erkel
Appl Name : Governor
Blocking all channel access for the channel
AMQ8878: Display channel authentication record details.
CHLAUTH(FC9PF.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
WARN(YES)
Allowing this Address for specific user
AMQ8878: Display channel authentication record details.
CHLAUTH(FC9PF.SVRCONN) TYPE(USERMAP)
ADDRESS(10.42.11.202) CLNTUSER(erkel)
MCAUSER(erkel)
Results of RUNCHECK
8 : DISPLAY CHLAUTH('FC9PF.SVRCONN') MATCH(RUNCHECK) ALL ADDRESS('10.42.11.202') CLNTUSER('erkel')
AMQ8878: Display channel authentication record details.
CHLAUTH(FC9PF.SVRCONN) TYPE(USERMAP)
DESCR(Allow 10.42.11.202 access)
CUSTOM( ) ADDRESS(10.42.11.202)
CLNTUSER(erkel) MCAUSER(erkel)
USERSRC(MAP) CHCKCLNT(ASQMGR)
Is this a Virtual IP problem? in my non-networking mind, from an MQ perspective, I should be able to block/authorize an IP
address whether Virtual or static. Any ideas on why the rule would does not work or how to resolve the issue? |
I recall various changes being made in MQ V8 fix pacs which changed the behaviour of the client flowed user ID and how CHLAUTH interacted with it. It seemed to settle down again at V9.0.4 which is what prompted me to write Behaviour changes in MQ V9.0.4 - CONNAUTH/CHLAUTH - you might want to look into APAR IT12825 and the use of the qm.ini ChlauthEarlyAdopt attribute.
To determine whether the problem you are seeing is a problem with the user ID or with the VIP, I would suggest removing your TYPE(USERMAP) CHLAUTH rule and one at a time trying each of the following CHLAUTH rules to see which one works and which one fails to give you the access you want.
Code: |
SET CHLAUTH(FC9PF.SVRCONN) TYPE(ADDRESSMAP) ADDRESS('10.42.11.202') MCAUSER('erkel') |
Code: |
SET CHLAUTH(FC9PF.SVRCONN) TYPE(USERMAP) CLNTUSER('erkel') MCAUSER('erkel') |
Then you'll know whether it is the client side user or the VIP that you are actually having problems with.
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
|