Hello all, the CHALAUTH rules is always a theme that confuses me...

Sometimes I don't understand more simple scenarios, I'm following the Techdoc-7041997.

I have a Linux queue manager (v9.3) with a SVRCONN channel with MCAUSER('mqm')  

I Want to block access from all ip's 

I have a rule like this, expecting to block all addresses, but it is not blocking. 

CHLAUTH(MY.CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(NOACCESS) WARN(NO) 

What I'm I missing? 

Thanks!

Hi Joao,

Have you ensured that CHLAUTH is turned on?

Issue:

DISPLAY QMGR CHLAUTH

and check that it is ENABLED. If it is DISABLED, then issue:-

ALTER QMGR CHLAUTH(ENABLED)

A good way to test what is going on with CHLAUTH rules is to use the MATCH(RUNCHECK) feature of DISPLAY CHLAUTH. For example, issue the following command:

DISPLAY CHLAUTH(MY.CHANNEL) ADDRESS('1.2.3.4') CLNTUSER(your-client-side-user-id) MATCH(RUNCHECK) ALL

The response to this command will be the CHLAUTH rule that an inbound connection with these values would match. If it's a record with USERSRC(NOACCESS) then it will be blocked. If it is another record, then you now know why it is being let in.

Also, if your CHLAUTH rules are currently disabled, this response will be accompanied by this message:-

AMQ8898W: Display channel authentication record details - currently disabled.

Cheers,
Morag

Hello all, the CHALAUTH rules is always a theme that confuses me...

Sometimes I don't understand more simple scenarios, I'm following the Techdoc-7041997.

I have a Linux queue manager (v9.3) with a SVRCONN channel with MCAUSER('mqm')  

I Want to block access from all ip's 

I have a rule like this, expecting to block all addresses, but it is not blocking. 

CHLAUTH(MY.CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(NOACCESS) WARN(NO) 

What I'm I missing? 

Thanks!

Hi Morag! 

Hours and hours around this, reading, testing, define channel, define rule, delete all, repeat, delete, repeat and I have...

     4 : DISPLAY QMGR CHLAUTH 
AMQ8408I: Display Queue Manager details.
   QMNAME(QMTEST)                          CHLAUTH(DISABLED)

:)

well... I guess I have to stop for today ..

Many thanks for pointing this

Hi Joao,

Have you ensured that CHLAUTH is turned on?

Issue:

DISPLAY QMGR CHLAUTH

and check that it is ENABLED. If it is DISABLED, then issue:-

ALTER QMGR CHLAUTH(ENABLED)

A good way to test what is going on with CHLAUTH rules is to use the MATCH(RUNCHECK) feature of DISPLAY CHLAUTH. For example, issue the following command:

DISPLAY CHLAUTH(MY.CHANNEL) ADDRESS('1.2.3.4') CLNTUSER(your-client-side-user-id) MATCH(RUNCHECK) ALL

The response to this command will be the CHLAUTH rule that an inbound connection with these values would match. If it's a record with USERSRC(NOACCESS) then it will be blocked. If it is another record, then you now know why it is being let in.

Also, if your CHLAUTH rules are currently disabled, this response will be accompanied by this message:-

AMQ8898W: Display channel authentication record details - currently disabled.

Cheers,
Morag

Hello all, the CHALAUTH rules is always a theme that confuses me...

Sometimes I don't understand more simple scenarios, I'm following the Techdoc-7041997.

I have a Linux queue manager (v9.3) with a SVRCONN channel with MCAUSER('mqm')  

I Want to block access from all ip's 

I have a rule like this, expecting to block all addresses, but it is not blocking. 

CHLAUTH(MY.CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(NOACCESS) WARN(NO) 

What I'm I missing? 

Thanks!

Hi All,

Interesting topic.

Now that Joao found  that CHLAUTH is disabled, what are the tasks that needs to be performed after enabling CHLAUTH?

Hi Morag! 

Hours and hours around this, reading, testing, define channel, define rule, delete all, repeat, delete, repeat and I have...

     4 : DISPLAY QMGR CHLAUTH 
AMQ8408I: Display Queue Manager details.
   QMNAME(QMTEST)                          CHLAUTH(DISABLED)

:)

well... I guess I have to stop for today ..

Many thanks for pointing this

Hi Joao,

Have you ensured that CHLAUTH is turned on?

Issue:

DISPLAY QMGR CHLAUTH

and check that it is ENABLED. If it is DISABLED, then issue:-

ALTER QMGR CHLAUTH(ENABLED)

A good way to test what is going on with CHLAUTH rules is to use the MATCH(RUNCHECK) feature of DISPLAY CHLAUTH. For example, issue the following command:

DISPLAY CHLAUTH(MY.CHANNEL) ADDRESS('1.2.3.4') CLNTUSER(your-client-side-user-id) MATCH(RUNCHECK) ALL

The response to this command will be the CHLAUTH rule that an inbound connection with these values would match. If it's a record with USERSRC(NOACCESS) then it will be blocked. If it is another record, then you now know why it is being let in.

Also, if your CHLAUTH rules are currently disabled, this response will be accompanied by this message:-

AMQ8898W: Display channel authentication record details - currently disabled.

Cheers,
Morag

Hello all, the CHALAUTH rules is always a theme that confuses me...

Sometimes I don't understand more simple scenarios, I'm following the Techdoc-7041997.

I have a Linux queue manager (v9.3) with a SVRCONN channel with MCAUSER('mqm')  

I Want to block access from all ip's 

I have a rule like this, expecting to block all addresses, but it is not blocking. 

CHLAUTH(MY.CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(NOACCESS) WARN(NO) 

What I'm I missing? 

Thanks!

After enabling chlauth there is a need to determine which connections will be allowed.
Then establish the chlauth with appropriate mcauser set for those specific IP addresses and or users that should be allowed to use the channel.
There should always be a default rule to not allow connection (as the one Joao stated). An alternative is to set the mcauser on the channel itself so no-one can connect anyway (which I would recommend as that will work even if chlauth is disabled).

Please note that there is a default chlauth to not allow any user that has mqm access, so if he user matches a local user with mqm group access then the connection will not be allowed due to this rule. 

Hi All,

Interesting topic.

Now that Joao found  that CHLAUTH is disabled, what are the tasks that needs to be performed after enabling CHLAUTH?

Hi Morag! 

Hours and hours around this, reading, testing, define channel, define rule, delete all, repeat, delete, repeat and I have...

     4 : DISPLAY QMGR CHLAUTH 
AMQ8408I: Display Queue Manager details.
   QMNAME(QMTEST)                          CHLAUTH(DISABLED)

:)

well... I guess I have to stop for today ..

Many thanks for pointing this

Hi Joao,

Have you ensured that CHLAUTH is turned on?

Issue:

DISPLAY QMGR CHLAUTH

and check that it is ENABLED. If it is DISABLED, then issue:-

ALTER QMGR CHLAUTH(ENABLED)

A good way to test what is going on with CHLAUTH rules is to use the MATCH(RUNCHECK) feature of DISPLAY CHLAUTH. For example, issue the following command:

DISPLAY CHLAUTH(MY.CHANNEL) ADDRESS('1.2.3.4') CLNTUSER(your-client-side-user-id) MATCH(RUNCHECK) ALL

The response to this command will be the CHLAUTH rule that an inbound connection with these values would match. If it's a record with USERSRC(NOACCESS) then it will be blocked. If it is another record, then you now know why it is being let in.

Also, if your CHLAUTH rules are currently disabled, this response will be accompanied by this message:-

AMQ8898W: Display channel authentication record details - currently disabled.

Cheers,
Morag

Hello all, the CHALAUTH rules is always a theme that confuses me...

Sometimes I don't understand more simple scenarios, I'm following the Techdoc-7041997.

I have a Linux queue manager (v9.3) with a SVRCONN channel with MCAUSER('mqm')  

I Want to block access from all ip's 

I have a rule like this, expecting to block all addresses, but it is not blocking. 

CHLAUTH(MY.CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(NOACCESS) WARN(NO) 

What I'm I missing? 

Thanks!

Hi All,

Interesting topic.

Now that Joao found  that CHLAUTH is disabled, what are the tasks that needs to be performed after enabling CHLAUTH?

Hi Morag! 

Hours and hours around this, reading, testing, define channel, define rule, delete all, repeat, delete, repeat and I have...

     4 : DISPLAY QMGR CHLAUTH 
AMQ8408I: Display Queue Manager details.
   QMNAME(QMTEST)                          CHLAUTH(DISABLED)

:)

well... I guess I have to stop for today ..

Many thanks for pointing this

Hi Joao,

Have you ensured that CHLAUTH is turned on?

Issue:

DISPLAY QMGR CHLAUTH

and check that it is ENABLED. If it is DISABLED, then issue:-

ALTER QMGR CHLAUTH(ENABLED)

A good way to test what is going on with CHLAUTH rules is to use the MATCH(RUNCHECK) feature of DISPLAY CHLAUTH. For example, issue the following command:

DISPLAY CHLAUTH(MY.CHANNEL) ADDRESS('1.2.3.4') CLNTUSER(your-client-side-user-id) MATCH(RUNCHECK) ALL

The response to this command will be the CHLAUTH rule that an inbound connection with these values would match. If it's a record with USERSRC(NOACCESS) then it will be blocked. If it is another record, then you now know why it is being let in.

Also, if your CHLAUTH rules are currently disabled, this response will be accompanied by this message:-

AMQ8898W: Display channel authentication record details - currently disabled.

Cheers,
Morag

Hello all, the CHALAUTH rules is always a theme that confuses me...

Sometimes I don't understand more simple scenarios, I'm following the Techdoc-7041997.

I have a Linux queue manager (v9.3) with a SVRCONN channel with MCAUSER('mqm')  

I Want to block access from all ip's 

I have a rule like this, expecting to block all addresses, but it is not blocking. 

CHLAUTH(MY.CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(NOACCESS) WARN(NO) 

What I'm I missing? 

Thanks!

This doc has some scenarios explained: 

ibm.com/support/pages/system/files/inline-files/Techdoc-7041997-4-CHLAUTH _0.pdf

what I want to do isto map an user, from a Wndows machine with MQExplorer on it, to a Linux user. With the correct rules it's possible to map a user coming from a defined ip address to a local user on the Linux machine, the user on e Linux machine must exist. If you to map an external user to, for example "mqm" user, you need to change the default qmgr AUTHINFO. In a test environment this is ok to do, but opens qmgr administration to remote users, maybe not to good idea in a production environment 

Thanks

Hi All,

Interesting topic.

Now that Joao found  that CHLAUTH is disabled, what are the tasks that needs to be performed after enabling CHLAUTH?

Hi Morag! 

Hours and hours around this, reading, testing, define channel, define rule, delete all, repeat, delete, repeat and I have...

     4 : DISPLAY QMGR CHLAUTH 
AMQ8408I: Display Queue Manager details.
   QMNAME(QMTEST)                          CHLAUTH(DISABLED)

:)

well... I guess I have to stop for today ..

Many thanks for pointing this

Hi Joao,

Have you ensured that CHLAUTH is turned on?

Issue:

DISPLAY QMGR CHLAUTH

and check that it is ENABLED. If it is DISABLED, then issue:-

ALTER QMGR CHLAUTH(ENABLED)

A good way to test what is going on with CHLAUTH rules is to use the MATCH(RUNCHECK) feature of DISPLAY CHLAUTH. For example, issue the following command:

DISPLAY CHLAUTH(MY.CHANNEL) ADDRESS('1.2.3.4') CLNTUSER(your-client-side-user-id) MATCH(RUNCHECK) ALL

The response to this command will be the CHLAUTH rule that an inbound connection with these values would match. If it's a record with USERSRC(NOACCESS) then it will be blocked. If it is another record, then you now know why it is being let in.

Also, if your CHLAUTH rules are currently disabled, this response will be accompanied by this message:-

AMQ8898W: Display channel authentication record details - currently disabled.

Cheers,
Morag

Hello all, the CHALAUTH rules is always a theme that confuses me...

Sometimes I don't understand more simple scenarios, I'm following the Techdoc-7041997.

I have a Linux queue manager (v9.3) with a SVRCONN channel with MCAUSER('mqm')  

I Want to block access from all ip's 

I have a rule like this, expecting to block all addresses, but it is not blocking. 

CHLAUTH(MY.CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(NOACCESS) WARN(NO) 

What I'm I missing? 

Thanks!

Hi Joao,

You are correct that opening for remote admin rights to a production environment is not a good thing.
What I have done is to provide certain capabilities to testers (using MQExplorer) in lower environments, like stopping and starting channels.

BTW mqm is the default MQ admin user on Linux.
 
If the MQ client itself does not provide a user (and password) then the local user running the MQ client is passed in the connection and that could be an LDAP user (authenticated on the e.g. Windows machine where MQ Explorer is running)

What I have done was to open up for anyone to display only MQ object information (not change and not browse messages) by using a local user on the Linux machine. That local user was granted access to display set of MQ object types. 
I have provided a guide for that. The example statements provided may help you, although the example is not using specific IP.

This doc has some scenarios explained: 

ibm.com/support/pages/system/files/inline-files/Techdoc-7041997-4-CHLAUTH _0.pdf

what I want to do isto map an user, from a Wndows machine with MQExplorer on it, to a Linux user. With the correct rules it's possible to map a user coming from a defined ip address to a local user on the Linux machine, the user on e Linux machine must exist. If you to map an external user to, for example "mqm" user, you need to change the default qmgr AUTHINFO. In a test environment this is ok to do, but opens qmgr administration to remote users, maybe not to good idea in a production environment 

Thanks

Hi All,

Interesting topic.

Now that Joao found  that CHLAUTH is disabled, what are the tasks that needs to be performed after enabling CHLAUTH?

Hi Morag! 

Hours and hours around this, reading, testing, define channel, define rule, delete all, repeat, delete, repeat and I have...

     4 : DISPLAY QMGR CHLAUTH 
AMQ8408I: Display Queue Manager details.
   QMNAME(QMTEST)                          CHLAUTH(DISABLED)

:)

well... I guess I have to stop for today ..

Many thanks for pointing this

Hi Joao,

Have you ensured that CHLAUTH is turned on?

Issue:

DISPLAY QMGR CHLAUTH

and check that it is ENABLED. If it is DISABLED, then issue:-

ALTER QMGR CHLAUTH(ENABLED)

A good way to test what is going on with CHLAUTH rules is to use the MATCH(RUNCHECK) feature of DISPLAY CHLAUTH. For example, issue the following command:

DISPLAY CHLAUTH(MY.CHANNEL) ADDRESS('1.2.3.4') CLNTUSER(your-client-side-user-id) MATCH(RUNCHECK) ALL

The response to this command will be the CHLAUTH rule that an inbound connection with these values would match. If it's a record with USERSRC(NOACCESS) then it will be blocked. If it is another record, then you now know why it is being let in.

Also, if your CHLAUTH rules are currently disabled, this response will be accompanied by this message:-

AMQ8898W: Display channel authentication record details - currently disabled.

Cheers,
Morag

Hello all, the CHALAUTH rules is always a theme that confuses me...

Sometimes I don't understand more simple scenarios, I'm following the Techdoc-7041997.

I have a Linux queue manager (v9.3) with a SVRCONN channel with MCAUSER('mqm')  

I Want to block access from all ip's 

I have a rule like this, expecting to block all addresses, but it is not blocking. 

CHLAUTH(MY.CHANNEL) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(NOACCESS) WARN(NO) 

What I'm I missing? 

Thanks!