0

I do see below log in queue manager error log : AMQ9557: Queue Manager User ID initialization failed for 'msgw' EXPLANATION: The call to initialize the User ID 'msgw' failed with CompCode 2 and Reason 2035. If an MQCSP block was used, the User ID in the MQCSP block was ''. ACTION: Correct the error and try again.

Did the same setup on QA environment, but there was no such error in the log. Please advise.

I have installed MQ version 8 on rhel7 : 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 15 17:36:42 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux when the application is trying to connect they are getting MQRC 2538. When I check my logs I saw the above mentioned error. All permissions are present on queue manager and queue level.

Application should be able to connect to the queue manager without any errors in queue manager log

piyali
  • 1
  • 1
  • Check the `CONNAUTH` `AUTHINFO` object's `ADOPTCTX` setting. It is probably `YES` on the working queue manager. – JoshMc May 27 '19 at 17:05
  • Is the version of MQ on the working and non-working queue managers the same? – JoshMc May 27 '19 at 17:06
  • QA(working queue manager): QMNAME(DPMSGQ1) ACCTCONO(DISABLED) COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE) CONFIGEV(DISABLED) CONNAUH(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) ...................................... AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) ADOPTCTX(NO) DESCR( ) CHCKCLNT(NONE) CHCKLOCL(OPTIONAL) FAILDLAY(1) ALTDATE(2019-03-07) ALTTIME(10.43.38) – piyali May 28 '19 at 05:44
  • Production(not working queue manager): QMNAME(DPMSGP1) ACCTCONO(DISABLED) CMDEV(DISABLED) CMDLEVEL(800) COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE) CONFIGEV(DISABLED) CONNAUTH(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) ................................. AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) ADOPTCTX(NO) DESCR( ) CHCKCLNT(NONE) CHCKLOCL(OPTIONAL) FAILDLAY(1) ALTDATE(2019-05-27) ALTTIME(06.20.27) – piyali May 28 '19 at 05:47
  • @JoshMc : Thank you for your suggestion. I have verified queue manager's attribute for both QA and prod its the same. Also both the queue managers are on the same version 8.0.0.11.One thing m not sure whether that is helpful, QA is on stand alone node where as Prod has a failover node(HA).Please find screenshot of below : – piyali May 28 '19 at 05:51
  • On the linux hosts does this command come back on both? `id -a msgw` – JoshMc May 28 '19 at 07:17
  • @JoshMc : it is showing no such user on both the servers . – piyali May 28 '19 at 08:25
  • What is the user `msgw`? Do you connect from an application running as that user? In the working setup do you connect as a different user? – JoshMc May 28 '19 at 13:46
  • I just wanted to add that you tell us that you got error 2538 (which is MQRC_HOST_NOT_AVAILABLE) which is not related to your AMQ9557 in the error log. Have you solved the 2538 yet? – Morag Hughson May 28 '19 at 19:55
  • @Morag Hughson, MQRC 2538 was faced at publisher end when they were trying to connect to QM, So I checked queue manager logs and saw above mentioned error. – piyali May 29 '19 at 14:09
  • @JoshMc: I have checked with application(publisher team), they said that msgw is some deamons that they use at their end . – piyali May 29 '19 at 14:11
  • Please check the channel itself to see if the MCAUSER is filled in on the working channel (or any difference between those channels). Check for any CHLAUTH rules on the working server that might map the MCAUSER for you to another user ID. – JoshMc May 29 '19 at 14:46
  • MQRC 2538 tells you that the client was unable to connect to the queue manager. Therefore there will be no error in the queue manager error logs related to that error. You are combining two different problems. The AMQ9557 that you are following is not related to the MQRC 2538. Please ensure you look in the client side error log for the system receiving the MQRC 2538. – Morag Hughson May 29 '19 at 20:41
  • Thank you all for your help. I tried to create the user "msgw" on MQ server and provided permission which have resolved the issue . – piyali Jun 03 '19 at 04:11
  • @JoshMc- Could you please provide details on what worked to resolve the issue? I'm also getting the same error message.Appreciate any help or insight. Thanks in advance!! – testbg testbg May 20 '21 at 09:56

2 Answers2

0

This resolves most of the 2035 authentication issue, without disabling chlauth.

Create a new user on your computer, for instance – testuser Set that user as the MCAuser of your channel. (Go to channel properties and set testuser as your MCAuser

Go to your Queue manager -> Right click -> Object authorities -> Manage Create Authorities. Then click on New, and put the user name under entity. Select all, and execute all the commands

Under Object authorities of Queue manager we also have Manage Queue manager authority records, click on it, then click on new. Put the user name(testuser) as your entity, and select all to execute all the commands

Go to your Queue -> Right click -> Object authorities -> Manage Queue authority records. Perform the same actions as above for the queue that you are using (select it under specific profiles)

Go to your channel -> Right click -> Object authorities -> Manage Channel authority records. Perform the same as above.

Restart your queue manager or, perform the following in command line Runmqsc

Refresh security(*)

End

Saugato
  • 1
  • 2
  • Giving all on the queue manager if it includes altusr world still allow the user to elevate authority to an admin. Refresh security is not required when you simply add authority, it is only required if you have tried to access the qmgr with one set of group memberships and then later added a group to the user for which you have provide authority. The qmgr will cache the user's groups the first time it tries to access and only refreshes this if you run refresh security or restart the qmgr. – JoshMc Feb 01 '23 at 14:52
-2

The error code usually means that the queue manager has been created to use the Object Authority Manager (OAM). By default the queue manager is created this way and will attempt to authenticate each user against the credentials on the node where the MQ server is running.

We have other authentications methods in place before users can execute our applications, so we don't want any connecting user authenticated against the OS credentials where the MQ server is running. Therefore we export this environment variable:

export MQSNOAUT=yes

just prior to issuing the 'crtmqm' command to create the queue manager.

You will see these entries in you qm.ini file if the queue manager has been created with OAM enabled: .

Service:
    Name=AuthorizationService
    EntryPoints=14 
ServiceComponent:
    Service=AuthorizationService
    Name=MQSeries.UNIX.auth.service
    Module=amqzfu
    ComponentDataSize=0

If these entries aren't there, then the queue manager was created with OAM disabled.

Jerry Fowler
  • 1
  • 1
    I would express that I think this is a terrible idea, any user that has local access to that server can access any object on the queue manager as well as perform MQ administrative functions. If you have a MQ listener enabled and the queue manager has any SVRCONN channel that is not disabled in some way or does not force authentication of the client connecting, then anyone with access the the network where your MQ server runs can connect to that SVRCONN and have access to all objects as well as perform MQ administrative functions. – JoshMc May 28 '19 at 16:12