| 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: 20768 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: 20768 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: 20768 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: 1967 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 | 
		  
		  	
		   | 
		
		
		    | 
		
		
		  | 
		    
		   |