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 » CHLAUTH problem with VIP address

Post new topic  Reply to topic
 CHLAUTH problem with VIP address « View previous topic :: View next topic » 
Author Message
smeunier
PostPosted: Fri Jan 19, 2018 8:16 am    Post subject: CHLAUTH problem with VIP address Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Fri Jan 19, 2018 9:09 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
smeunier
PostPosted: Mon Jan 22, 2018 8:12 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Mon Jan 22, 2018 11:38 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

Is there anything in the channels local address?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
smeunier
PostPosted: Mon Jan 22, 2018 12:57 pm    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Tue Jan 23, 2018 5:53 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
hughson
PostPosted: Tue Feb 20, 2018 2:02 pm    Post subject: Re: CHLAUTH problem with VIP address Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » CHLAUTH problem with VIP address
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.