Hello,
We're in the process of preparing a new approach to access to MQ resources for administrators (and applications), and test results are not quite as expected.

Background:

• Migration of servers from Windows to Linux (RHEL)
• Mainly MQ clients
• Administration via runmqsc, MQ Console and MQ Explorer
• Users accounts managed by Active Directory
• MQ version 9.2.0.1

Administrators will be divided into 3 groups :

• FullAdmin
• PartialAdmin
• Reader

On the AD, the FullAdmin group was created, and account A001 is included in this group.
The script FullAdmin.mqsc gives almost all MQ rights to the FullAdmin group and ends with a REFRESH SECURITY.

On a freshly created Queue Manager (no additional CHLAUTH rules, unchanged AUTHINFO), the following tests are made with account A001 :

• CLI access via runmqsc: KO
• GUI access via MQ Console: KO
• GUI access via MQ Explorer from a workstation: KO

Everything is normal!

Now we run the FullAdmin.mqsc script on the Queue Manager. Result is :

• CLI access via runmqsc: OK
• GUI access via MQ Console: OK
• GUI access via MQ Explorer from a workstation: it depends ...
  • If in the connection parameters the box "Activate user identification" is not checked: OK (the workstation user is A001)
  • If in the connection parameters the box "Enable user identification" is checked: KO (AMQ5534E: user A001 authentication failed / 2035)

More interesting :
If we test the MQ Client access from a Windows workstation, here are the results:
From the A001 account:
If now we specify a user :

With both MQ Explorer and the MQ client, as soon as the account password is specified, the connection fails.
However, the same password used via a putty or MQConsole session is accepted.

I don't understand why when using MQ client the password is rejected.

Who would have an idea?

Thank you for your input.

------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr
------------------------------

As requested also privately, here are some additionnal information.
KO mean error.

Here in the CONNAUTH and the AUTHINFO :
1 : dis qmgr CONNAUTH
AMQ8408I: Display Queue Manager details.
QMNAME(MyQM)
CONNAUTH(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)

2 : dis authinfo(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
AMQ8566I: Display authentication information details.
AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
AUTHTYPE(IDPWOS) ADOPTCTX(YES)
DESCR( ) CHCKCLNT(REQDADM)
CHCKLOCL(OPTIONAL) FAILDLAY(1)
AUTHENMD(OS) ALTDATE(2020-11-30)
ALTTIME(14.08.29)

 Content of AMQERR after a failure :
11/30/2020 02:27:25 PM - Process(13234.20) User(mqm) Program(amqzlaa0)
Host(MyHost) Installation(Installation1)
VRMF(9.2.0.1) QMgr(MyQM)
Time(2020-11-30T13:27:25.520Z)
CommentInsert1(A08460)
CommentInsert2(MQ Explorer 9.2.0)
CommentInsert3(Pipe returned 2035 [FAILED])

AMQ5534E: User ID 'A001' authentication failed
EXPLANATION:
The user ID and password supplied by the 'MQ Explorer 9.2.0' program could not be authenticated.
Additional information: 'Pipe returned 2035 [FAILED]'.
ACTION:
Ensure that the correct user ID and password are provided by the application.
Ensure that the authentication repository is correctly configured. Look at previous error messages for any additional information.

----- amqzfuca.c : 4804 -------------------------------------------------------
11/30/2020 02:27:25 PM - Process(13234.20) User(mqm) Program(amqzlaa0)
Host(MyHost) Installation(Installation1)
VRMF(9.2.0.1) QMgr(MyQM)
Time(2020-11-30T13:27:25.520Z)
CommentInsert1(A08460)
CommentInsert2(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
CommentInsert3(CHCKCLNT(REQDADM))

AMQ5542I: The failed authentication check was caused by the queue manager CONNAUTH CHCKCLNT(REQDADM) configuration.
EXPLANATION:
The user ID 'A001' and its password were checked because the queue manager connection authority (CONNAUTH) configuration refers to an authentication information (AUTHINFO) object named 'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' with CHCKCLNT(REQDADM).
This message accompanies a previous error to clarify the reason for the user ID and password check.
ACTION:
Refer to the previous error for more information.

The second message is surprising, because the user does not belong to the mqm group and therefore should not trigger the CHCKCLNT(REQDADM).

Thanks for any ideas.

------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr
------------------------------

Original Message:
Sent: Tue December 01, 2020 06:28 AM
From: Luc-Michel Demey
Subject: Sending password in MQ Client mode

Hello,
We're in the process of preparing a new approach to access to MQ resources for administrators (and applications), and test results are not quite as expected.

Background:

• Migration of servers from Windows to Linux (RHEL)
• Mainly MQ clients
• Administration via runmqsc, MQ Console and MQ Explorer
• Users accounts managed by Active Directory
• MQ version 9.2.0.1

Administrators will be divided into 3 groups :

• FullAdmin
• PartialAdmin
• Reader

On the AD, the FullAdmin group was created, and account A001 is included in this group.
The script FullAdmin.mqsc gives almost all MQ rights to the FullAdmin group and ends with a REFRESH SECURITY.

On a freshly created Queue Manager (no additional CHLAUTH rules, unchanged AUTHINFO), the following tests are made with account A001 :

• CLI access via runmqsc: KO
• GUI access via MQ Console: KO
• GUI access via MQ Explorer from a workstation: KO

Everything is normal!

Now we run the FullAdmin.mqsc script on the Queue Manager. Result is :

• CLI access via runmqsc: OK
• GUI access via MQ Console: OK
• GUI access via MQ Explorer from a workstation: it depends ...
  • If in the connection parameters the box "Activate user identification" is not checked: OK (the workstation user is A001)
  • If in the connection parameters the box "Enable user identification" is checked: KO (AMQ5534E: user A001 authentication failed / 2035)

More interesting :
If we test the MQ Client access from a Windows workstation, here are the results:
From the A001 account:

set MQSERVER=channel/TCP/host(port)

amqsputc Q1 QM1 --> OK

If now we specify a user :

set MQSERVER=channel/TCP/host(port)

set MQSAMP_USER_ID=A001

amqsputc Q1 QM1

Sample AMQSPUT0 start

Enter password:

KO error 2035

With both MQ Explorer and the MQ client, as soon as the account password is specified, the connection fails.
However, the same password used via a putty or MQConsole session is accepted.

I don't understand why when using MQ client the password is rejected.

Who would have an idea?

Thank you for your input.

------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr
------------------------------

> Migration of servers from Windows to Linux (RHEL)

Don't forget that on Linux that 'A001' is not the same UserId as 'a001'.

> CommentInsert3(Pipe returned 2035 [FAILED])

Humm.  This smells like either the sticky bit is not set or the user ownership is not 'root'.

Check to made sure that /opt/mqm/security/ directory looks like:

dr-xr-x--- 1 root mqm 48 Mar 23 2019 security

And its contains look like:

dr-xr-x--- 1 root mqm    48 Mar 23 2019 .
dr-xr-xr-x 1 mqm  mqm  1810 Mar 23 2019 ..
-r-sr-x--- 1 root mqm 13384 Jul  5 2018 amqoamax
-r-sr-x--- 1 root mqm 13704 Jul  5 2018 amqoampx
-r-xr-xr-x 1 mqm  mqm  3639 Jul  5 2018 amqpamcf

Regards,
Roger Lacroix
Capitalware Inc.

Wen you say "Full Admin Access" do you mean "member of mqm group" or do you mean "explicitly granted all authorities"?

If former, client connection will be subject to CHLAUTH *MQADMIN rule which you suggest has not been removed.

Cheers,
Morag

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
------------------------------

Original Message:
Sent: Tue December 01, 2020 06:28 AM
From: Luc-Michel Demey
Subject: Sending password in MQ Client mode

Hello,
We're in the process of preparing a new approach to access to MQ resources for administrators (and applications), and test results are not quite as expected.

Background:

• Migration of servers from Windows to Linux (RHEL)
• Mainly MQ clients
• Administration via runmqsc, MQ Console and MQ Explorer
• Users accounts managed by Active Directory
• MQ version 9.2.0.1

Administrators will be divided into 3 groups :

• FullAdmin
• PartialAdmin
• Reader

On the AD, the FullAdmin group was created, and account A001 is included in this group.
The script FullAdmin.mqsc gives almost all MQ rights to the FullAdmin group and ends with a REFRESH SECURITY.

On a freshly created Queue Manager (no additional CHLAUTH rules, unchanged AUTHINFO), the following tests are made with account A001 :

• CLI access via runmqsc: KO
• GUI access via MQ Console: KO
• GUI access via MQ Explorer from a workstation: KO

Everything is normal!

Now we run the FullAdmin.mqsc script on the Queue Manager. Result is :

• CLI access via runmqsc: OK
• GUI access via MQ Console: OK
• GUI access via MQ Explorer from a workstation: it depends ...
  • If in the connection parameters the box "Activate user identification" is not checked: OK (the workstation user is A001)
  • If in the connection parameters the box "Enable user identification" is checked: KO (AMQ5534E: user A001 authentication failed / 2035)

More interesting :
If we test the MQ Client access from a Windows workstation, here are the results:
From the A001 account:

set MQSERVER=channel/TCP/host(port)

amqsputc Q1 QM1 --> OK

If now we specify a user :

set MQSERVER=channel/TCP/host(port)

set MQSAMP_USER_ID=A001

amqsputc Q1 QM1

Sample AMQSPUT0 start

Enter password:

KO error 2035

With both MQ Explorer and the MQ client, as soon as the account password is specified, the connection fails.
However, the same password used via a putty or MQConsole session is accepted.

I don't understand why when using MQ client the password is rejected.

Who would have an idea?

Thank you for your input.

------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr
------------------------------

When you run the test to supply the user, are you supplying the same user as you are also running the program as, or different?

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
------------------------------

Original Message:
Sent: Tue December 01, 2020 06:28 AM
From: Luc-Michel Demey
Subject: Sending password in MQ Client mode

Hello,
We're in the process of preparing a new approach to access to MQ resources for administrators (and applications), and test results are not quite as expected.

Background:

• Migration of servers from Windows to Linux (RHEL)
• Mainly MQ clients
• Administration via runmqsc, MQ Console and MQ Explorer
• Users accounts managed by Active Directory
• MQ version 9.2.0.1

Administrators will be divided into 3 groups :

• FullAdmin
• PartialAdmin
• Reader

On the AD, the FullAdmin group was created, and account A001 is included in this group.
The script FullAdmin.mqsc gives almost all MQ rights to the FullAdmin group and ends with a REFRESH SECURITY.

On a freshly created Queue Manager (no additional CHLAUTH rules, unchanged AUTHINFO), the following tests are made with account A001 :

• CLI access via runmqsc: KO
• GUI access via MQ Console: KO
• GUI access via MQ Explorer from a workstation: KO

Everything is normal!

Now we run the FullAdmin.mqsc script on the Queue Manager. Result is :

• CLI access via runmqsc: OK
• GUI access via MQ Console: OK
• GUI access via MQ Explorer from a workstation: it depends ...
  • If in the connection parameters the box "Activate user identification" is not checked: OK (the workstation user is A001)
  • If in the connection parameters the box "Enable user identification" is checked: KO (AMQ5534E: user A001 authentication failed / 2035)

More interesting :
If we test the MQ Client access from a Windows workstation, here are the results:
From the A001 account:

set MQSERVER=channel/TCP/host(port)

amqsputc Q1 QM1 --> OK

If now we specify a user :

set MQSERVER=channel/TCP/host(port)

set MQSAMP_USER_ID=A001

amqsputc Q1 QM1

Sample AMQSPUT0 start

Enter password:

KO error 2035

With both MQ Explorer and the MQ client, as soon as the account password is specified, the connection fails.
However, the same password used via a putty or MQConsole session is accepted.

I don't understand why when using MQ client the password is rejected.

Who would have an idea?

Thank you for your input.

------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr
------------------------------

Hi Morag,
The user is not a member of the mqm group. I run a script who "explicitly granted all authorities".
When testing supplying a user, it was the same one that I use to test "directly".
For me, it's as if via a SVRCONN channel, the authentication doesn't use the OS.
I probably missed something, but what?

------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr
------------------------------

Original Message:
Sent: Tue December 01, 2020 02:35 PM
From: Morag Hughson
Subject: Sending password in MQ Client mode

When you run the test to supply the user, are you supplying the same user as you are also running the program as, or different?

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com

Original Message:
Sent: Tue December 01, 2020 06:28 AM
From: Luc-Michel Demey
Subject: Sending password in MQ Client mode

Hello,
We're in the process of preparing a new approach to access to MQ resources for administrators (and applications), and test results are not quite as expected.

Background:

• Migration of servers from Windows to Linux (RHEL)
• Mainly MQ clients
• Administration via runmqsc, MQ Console and MQ Explorer
• Users accounts managed by Active Directory
• MQ version 9.2.0.1

Administrators will be divided into 3 groups :

• FullAdmin
• PartialAdmin
• Reader

On the AD, the FullAdmin group was created, and account A001 is included in this group.
The script FullAdmin.mqsc gives almost all MQ rights to the FullAdmin group and ends with a REFRESH SECURITY.

On a freshly created Queue Manager (no additional CHLAUTH rules, unchanged AUTHINFO), the following tests are made with account A001 :

• CLI access via runmqsc: KO
• GUI access via MQ Console: KO
• GUI access via MQ Explorer from a workstation: KO

Everything is normal!

Now we run the FullAdmin.mqsc script on the Queue Manager. Result is :

• CLI access via runmqsc: OK
• GUI access via MQ Console: OK
• GUI access via MQ Explorer from a workstation: it depends ...
  • If in the connection parameters the box "Activate user identification" is not checked: OK (the workstation user is A001)
  • If in the connection parameters the box "Enable user identification" is checked: KO (AMQ5534E: user A001 authentication failed / 2035)

More interesting :
If we test the MQ Client access from a Windows workstation, here are the results:
From the A001 account:

set MQSERVER=channel/TCP/host(port)

amqsputc Q1 QM1 --> OK

If now we specify a user :

set MQSERVER=channel/TCP/host(port)

set MQSAMP_USER_ID=A001

amqsputc Q1 QM1

Sample AMQSPUT0 start

Enter password:

KO error 2035

With both MQ Explorer and the MQ client, as soon as the account password is specified, the connection fails.
However, the same password used via a putty or MQConsole session is accepted.

I don't understand why when using MQ client the password is rejected.

Who would have an idea?

Thank you for your input.

------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr
------------------------------

Sorry, I wasn't clear in my question. I was trying to ask whether, in the test where you supply a user id, was the user id you were supplying, the same as the user id that the application was running under on the client machine. i.e., was the client side user id that was flowed over the FAP to the queue manager the same as the user id that would be presented in the MQCSP structure on the MQCONNX?

Cheers,
Morag

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
------------------------------

Original Message:
Sent: Tue December 01, 2020 05:34 PM
From: Luc-Michel Demey
Subject: Sending password in MQ Client mode

Hi Morag,
The user is not a member of the mqm group. I run a script who "explicitly granted all authorities".
When testing supplying a user, it was the same one that I use to test "directly".
For me, it's as if via a SVRCONN channel, the authentication doesn't use the OS.
I probably missed something, but what?

------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr

Original Message:
Sent: Tue December 01, 2020 02:35 PM
From: Morag Hughson
Subject: Sending password in MQ Client mode

When you run the test to supply the user, are you supplying the same user as you are also running the program as, or different?

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com

Original Message:
Sent: Tue December 01, 2020 06:28 AM
From: Luc-Michel Demey
Subject: Sending password in MQ Client mode

Hello,
We're in the process of preparing a new approach to access to MQ resources for administrators (and applications), and test results are not quite as expected.

Background:

• Migration of servers from Windows to Linux (RHEL)
• Mainly MQ clients
• Administration via runmqsc, MQ Console and MQ Explorer
• Users accounts managed by Active Directory
• MQ version 9.2.0.1

Administrators will be divided into 3 groups :

• FullAdmin
• PartialAdmin
• Reader

On the AD, the FullAdmin group was created, and account A001 is included in this group.
The script FullAdmin.mqsc gives almost all MQ rights to the FullAdmin group and ends with a REFRESH SECURITY.

On a freshly created Queue Manager (no additional CHLAUTH rules, unchanged AUTHINFO), the following tests are made with account A001 :

• CLI access via runmqsc: KO
• GUI access via MQ Console: KO
• GUI access via MQ Explorer from a workstation: KO

Everything is normal!

Now we run the FullAdmin.mqsc script on the Queue Manager. Result is :

• CLI access via runmqsc: OK
• GUI access via MQ Console: OK
• GUI access via MQ Explorer from a workstation: it depends ...
  • If in the connection parameters the box "Activate user identification" is not checked: OK (the workstation user is A001)
  • If in the connection parameters the box "Enable user identification" is checked: KO (AMQ5534E: user A001 authentication failed / 2035)

More interesting :
If we test the MQ Client access from a Windows workstation, here are the results:
From the A001 account:

set MQSERVER=channel/TCP/host(port)

amqsputc Q1 QM1 --> OK

If now we specify a user :

set MQSERVER=channel/TCP/host(port)

set MQSAMP_USER_ID=A001

amqsputc Q1 QM1

Sample AMQSPUT0 start

Enter password:

KO error 2035

With both MQ Explorer and the MQ client, as soon as the account password is specified, the connection fails.
However, the same password used via a putty or MQConsole session is accepted.

I don't understand why when using MQ client the password is rejected.

Who would have an idea?

Thank you for your input.

------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr
------------------------------

Hi all,
Problem solved.
On a Linux system that relies on AD for authentication, if the Queue Manager needs to validate passwords, AUTHENMD(PAM) must be specified in the AUTHINFO used.
Thanks to everyone who helped me, both in these discussions and in private.
Thanks in particular to JoshMcMQ who was the first one to tell me this solution.
The information is probably somewhere in the KC, but not necessarily where I looked for it.
I will now be able to complete the implementation of MQ resource accesses with ease :

• adding a new Queue Manager
• the arrival or departure of an MQ administrator in the group

Simply add or remove the corresponding administrator account from the AD group and the change will be effective on all the organization's Queue Managers.​

------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr
------------------------------

Original Message:
Sent: Tue December 01, 2020 06:28 AM
From: Luc-Michel Demey
Subject: Sending password in MQ Client mode

Hello,
We're in the process of preparing a new approach to access to MQ resources for administrators (and applications), and test results are not quite as expected.

Background:

• Migration of servers from Windows to Linux (RHEL)
• Mainly MQ clients
• Administration via runmqsc, MQ Console and MQ Explorer
• Users accounts managed by Active Directory
• MQ version 9.2.0.1

Administrators will be divided into 3 groups :

• FullAdmin
• PartialAdmin
• Reader

On the AD, the FullAdmin group was created, and account A001 is included in this group.
The script FullAdmin.mqsc gives almost all MQ rights to the FullAdmin group and ends with a REFRESH SECURITY.

On a freshly created Queue Manager (no additional CHLAUTH rules, unchanged AUTHINFO), the following tests are made with account A001 :

• CLI access via runmqsc: KO
• GUI access via MQ Console: KO
• GUI access via MQ Explorer from a workstation: KO

Everything is normal!

Now we run the FullAdmin.mqsc script on the Queue Manager. Result is :

• CLI access via runmqsc: OK
• GUI access via MQ Console: OK
• GUI access via MQ Explorer from a workstation: it depends ...
  • If in the connection parameters the box "Activate user identification" is not checked: OK (the workstation user is A001)
  • If in the connection parameters the box "Enable user identification" is checked: KO (AMQ5534E: user A001 authentication failed / 2035)

More interesting :
If we test the MQ Client access from a Windows workstation, here are the results:
From the A001 account:

set MQSERVER=channel/TCP/host(port)

amqsputc Q1 QM1 --> OK

If now we specify a user :

set MQSERVER=channel/TCP/host(port)

set MQSAMP_USER_ID=A001

amqsputc Q1 QM1

Sample AMQSPUT0 start

Enter password:

KO error 2035

With both MQ Explorer and the MQ client, as soon as the account password is specified, the connection fails.
However, the same password used via a putty or MQConsole session is accepted.

I don't understand why when using MQ client the password is rejected.

Who would have an idea?

Thank you for your input.

------------------------------
Luc-Michel Demey
DEMEY CONSULTING
lmd@demey-consulting.fr
------------------------------