| Author | Message | 
		
		  | vicks_mq | 
			  
				|  Posted: Thu Apr 04, 2019 5:38 am    Post subject: Can we Add New CHLAUTH while channel is running? |   |  | 
		
		  | Disciple
 
 
 Joined: 03 Oct 2017Posts: 162
 
 
 | 
			  
				| Hi, we have an application connecting via CLNCONN - SVRCONN channel. 
 We just added the following CHLAUTH on our SVRCONN channel while the channel was still RUNNING.
 
 SET CHLAUTH('ABC.TO*') TYPE(ADDRESSMAP) ADDRESS('IPAddress1') USERSRC(CHANNEL) ACTION(ADD)
 SET CHLAUTH('ABC.TO*') TYPE(ADDRESSMAP) ADDRESS('IPAddress2') USERSRC(CHANNEL) ACTION(ADD)
 
 Do we need to do any refresh command at QMGR or does the application need to stop and start for it to take affect?
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | PeterPotkay | 
			  
				|  Posted: Thu Apr 04, 2019 10:43 am    Post subject: |   |  | 
		
		  |  Poobah
 
 
 Joined: 15 May 2001Posts: 7723
 
 
 | 
			  
				| CHLAUTH rules are evaluated / enforced when at connection time. 
 Restart the app.
 Or, restart the channel.
 _________________
 Peter Potkay
 Keep Calm and MQ On
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | vicks_mq | 
			  
				|  Posted: Thu Apr 04, 2019 11:00 am    Post subject: |   |  | 
		
		  | Disciple
 
 
 Joined: 03 Oct 2017Posts: 162
 
 
 | 
			  
				| 
   
	| PeterPotkay wrote: |  
	| CHLAUTH rules are evaluated / enforced when at connection time. 
 Restart the app.
 Or, restart the channel.
 |  
 We have SVRCONN channel i think they can't be "restarted" from MQSC.
 I can ask the application team to restart but it is PRD environment and they are not gonna be happy.
  |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | Vitor | 
			  
				|  Posted: Thu Apr 04, 2019 11:05 am    Post subject: |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 11 Nov 2005Posts: 26093
 Location: Texas, USA
 
 | 
			  
				| 
   
	| vicks_mq wrote: |  
	| I can ask the application team to restart but it is PRD environment and they are not gonna be happy.  |  
 It's a hard, cruel universe filled with injustice and pain.
   
 Or that might just be my universe.
 
 Anyway, this is why your Prod environment has change control, maintenance windows, rolling restart capabilities and all the other joy that fills our lives; sooner or later you have to do stuff like this. Or a DR test. Or (gasp) recovering from an application problem.
 _________________
 Honesty is the best policy.
 Insanity is the best defence.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | Vitor | 
			  
				|  Posted: Thu Apr 04, 2019 11:07 am    Post subject: |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 11 Nov 2005Posts: 26093
 Location: Texas, USA
 
 | 
			  
				| Unless your application team are Agile, in which case you can just wait until the end of their next sprint. _________________
 Honesty is the best policy.
 Insanity is the best defence.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | vicks_mq | 
			  
				|  Posted: Thu Apr 04, 2019 11:08 am    Post subject: |   |  | 
		
		  | Disciple
 
 
 Joined: 03 Oct 2017Posts: 162
 
 
 | 
			  
				| 
   
	| Vitor wrote: |  
	| 
   
	| vicks_mq wrote: |  
	| I can ask the application team to restart but it is PRD environment and they are not gonna be happy.  |  
 It's a hard, cruel universe filled with injustice and pain.
   
 Or that might just be my universe.
 
 Anyway, this is why your Prod environment has change control, maintenance windows, rolling restart capabilities and all the other joy that fills our lives; sooner or later you have to do stuff like this. Or a DR test. Or (gasp) recovering from an application problem.
 |  
 Whenever we add any new SSL certificate in our QMGR , we just run a MQSC command "REFRESH Security" and it does the job and no one is wiser.
 
 I was hoping that making changes in CHLAUTH also should have similar command which can reflect new changes.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | PeterPotkay | 
			  
				|  Posted: Thu Apr 04, 2019 11:08 am    Post subject: |   |  | 
		
		  |  Poobah
 
 
 Joined: 15 May 2001Posts: 7723
 
 
 | 
			  
				| 
   
	| vicks_mq wrote: |  
	| We have SVRCONN channel i think they can't be "restarted" from MQSC.
 
 |  
 They can.
 _________________
 Peter Potkay
 Keep Calm and MQ On
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | Vitor | 
			  
				|  Posted: Thu Apr 04, 2019 11:38 am    Post subject: |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 11 Nov 2005Posts: 26093
 Location: Texas, USA
 
 | 
			  
				| 
   
	| PeterPotkay wrote: |  
	| 
   
	| vicks_mq wrote: |  
	| We have SVRCONN channel i think they can't be "restarted" from MQSC.
 
 |  
 They can.
 |  
 To the possible annoyance of any application team whose application is currently connected to it.
 
 Hence my comment about change windows and so forth.
 _________________
 Honesty is the best policy.
 Insanity is the best defence.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | Vitor | 
			  
				|  Posted: Thu Apr 04, 2019 11:41 am    Post subject: |   |  | 
		
		  |  Grand High Poobah
 
 
 Joined: 11 Nov 2005Posts: 26093
 Location: Texas, USA
 
 | 
			  
				| 
   
	| vicks_mq wrote: |  
	| Whenever we add any new SSL certificate in our QMGR , we just run a MQSC command "REFRESH Security" and it does the job and no one is wiser. |  
 Not quite the same thing; that's a change to the queue manager's internal configuration and if done incorrectly a lot of people can be unexpectedly the wiser.
 
 
 
   
	| vicks_mq wrote: |  
	| I was hoping that making changes in CHLAUTH also should have similar command which can reflect new changes. |  
 Unless the new rules block someone unexpectedly.
 
 But raise an RFE and post the link to gather support. Votes get changes......
 _________________
 Honesty is the best policy.
 Insanity is the best defence.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | mvic | 
			  
				|  Posted: Thu Apr 04, 2019 2:06 pm    Post subject: |   |  | 
		
		  |  Jedi
 
 
 Joined: 09 Mar 2004Posts: 2080
 
 
 | 
			  
				| 
   
	| Vitor wrote: |  
	| [But raise an RFE and post the link to gather support. Votes get changes...... |  I would have thought that changing/adding a CHLAUTH rule for CHL1 would have effect on the next client that connected to CHL1.
 But I haven't tested that that is true.
 (And I wonder if the OP has tested, and can tell us the answer to the question they first posted!).
 My point is, maybe the OP already has the behavior they want, without need for an RFE.
 
  |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | hughson | 
			  
				|  Posted: Fri Apr 05, 2019 12:02 am    Post subject: Re: Can we Add New CHLAUTH while channel is running? |   |  | 
		
		  |  Padawan
 
 
 Joined: 09 May 2013Posts: 1967
 Location: Bay of Plenty, New Zealand
 
 | 
			  
				| 
   
	| vicks_mq wrote: |  
	| Hi, we have an application connecting via CLNCONN - SVRCONN channel. 
 We just added the following CHLAUTH on our SVRCONN channel while the channel was still RUNNING.
 
 SET CHLAUTH('ABC.TO*') TYPE(ADDRESSMAP) ADDRESS('IPAddress1') USERSRC(CHANNEL) ACTION(ADD)
 SET CHLAUTH('ABC.TO*') TYPE(ADDRESSMAP) ADDRESS('IPAddress2') USERSRC(CHANNEL) ACTION(ADD)
 
 Do we need to do any refresh command at QMGR or does the application need to stop and start for it to take affect?
 |  How do these rules affect the currently running client application? You are adding two rules to allow client applications from two specific IP address to use the MCAUSER defined on the SVRCONN channel (or to use the flowed client side user ID if none is defined on the SVRCONN).
 
 How are the client applications currently running? Are they gaining or losing access as a result of the addition of these CHLAUTH commands. Presumably they can't be gaining access or they would not currently be successfully running for you consider stopping them to pick up the change. If they are losing access that they currently shouldn't have, then shouldn't you be forcing them to stop [STOP CHANNEL(svrconn-name) MODE(FORCE) STATUS(INACTIVE)] to ensure that they do not continue to have access they shouldn't have?
 
 If the new rules don't actually change how the applications are running, maybe just makes the CHLAUTH rules clearer - or maybe just in preparation to adding a backstop rule later, then just wait until they stop and restart naturally, and upon the next connection made from the client application, the new rules will be enforced.
 
 Cheers,
 Morag
 _________________
 Morag Hughson @MoragHughson
 IBM MQ Technical Education Specialist
 Get your IBM MQ training here!
 MQGem Software
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | vicks_mq | 
			  
				|  Posted: Fri Apr 05, 2019 1:25 am    Post subject: Re: Can we Add New CHLAUTH while channel is running? |   |  | 
		
		  | Disciple
 
 
 Joined: 03 Oct 2017Posts: 162
 
 
 | 
			  
				| 
   
	| hughson wrote: |  
	| 
   
	| vicks_mq wrote: |  
	| Hi, we have an application connecting via CLNCONN - SVRCONN channel. 
 We just added the following CHLAUTH on our SVRCONN channel while the channel was still RUNNING.
 
 SET CHLAUTH('ABC.TO*') TYPE(ADDRESSMAP) ADDRESS('IPAddress1') USERSRC(CHANNEL) ACTION(ADD)
 SET CHLAUTH('ABC.TO*') TYPE(ADDRESSMAP) ADDRESS('IPAddress2') USERSRC(CHANNEL) ACTION(ADD)
 
 Do we need to do any refresh command at QMGR or does the application need to stop and start for it to take affect?
 |  How do these rules affect the currently running client application? You are adding two rules to allow client applications from two specific IP address to use the MCAUSER defined on the SVRCONN channel (or to use the flowed client side user ID if none is defined on the SVRCONN).
 
 How are the client applications currently running? Are they gaining or losing access as a result of the addition of these CHLAUTH commands. Presumably they can't be gaining access or they would not currently be successfully running for you consider stopping them to pick up the change. If they are losing access that they currently shouldn't have, then shouldn't you be forcing them to stop [STOP CHANNEL(svrconn-name) MODE(FORCE) STATUS(INACTIVE)] to ensure that they do not continue to have access they shouldn't have?
 
 If the new rules don't actually change how the applications are running, maybe just makes the CHLAUTH rules clearer - or maybe just in preparation to adding a backstop rule later, then just wait until they stop and restart naturally, and upon the next connection made from the client application, the new rules will be enforced.
 
 Cheers,
 Morag
 |  Hi Morag, yes earlier we had no CHLAUTH but later in MQ audit , it was found that we are running a SVCONN channel without CHLAUTH. So, that is when I decided to add it. Client application is continue to run so not sure whether the CHLAUTH rules are in affect or not but no bad news is good news, I believe.
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  | hughson | 
			  
				|  Posted: Fri Apr 05, 2019 1:40 am    Post subject: Re: Can we Add New CHLAUTH while channel is running? |   |  | 
		
		  |  Padawan
 
 
 Joined: 09 May 2013Posts: 1967
 Location: Bay of Plenty, New Zealand
 
 | 
			  
				| 
   
	| vicks_mq wrote: |  
	| earlier we had no CHLAUTH but later in MQ audit , it was found that we are running a SVCONN channel without CHLAUTH. So, that is when I decided to add it. |  So had you also added a backstop rule? Or can channels that don't match these rules also run anyway? If I can guess your channel name and port number, can I successfully connect to your queue manager? How does adding these rules meet your audit requirement?
 
 
 
   
	| vicks_mq wrote: |  
	| Client application is continue to run so not sure whether the CHLAUTH rules are in affect or not but no bad news is good news, I believe. |  So this sounds like there is no need, yet, to stop and restart the application. It will naturally restart at some future time and the new CHLAUTH rules will apply at that point. If this is just the start of your journey to secure your queue manager, I'm sure there will be other reasons to annoy the application owners later!
   
 Cheers,
 Morag
 _________________
 Morag Hughson @MoragHughson
 IBM MQ Technical Education Specialist
 Get your IBM MQ training here!
 MQGem Software
 |  | 
		
		  | Back to top |  | 
		
		  |  | 
		
		  |  |