1

I wrote a MQ 7.5 Connection routine in C# as bellow, but gets "2035" Error

using IBM.WMQ;
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                MQEnvironment.Hostname = "192.168.163.63";
                MQEnvironment.Port = 1418;
                MQEnvironment.UserId = "mq";
                MQEnvironment.Password = "mq";
                MQEnvironment.Channel = "ServerChannel";

                MQQueueManager queueManager = new MQQueueManager("QueueManager1418");
            } catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
        }
            Console.ReadKey();
        }
    }
}

and at the same time/ same machine I wrote bellow JAVA MQ Connection which works well!!! 

import com.ibm.mq.MQEnvironment;
import com.ibm.mq.MQQueueManager;

public class Program {
    public static void main(String[] args) {
        MQEnvironment.hostname = "192.168.163.63";
        MQEnvironment.port = 1418;
        MQEnvironment.userID = "mq";
        MQEnvironment.password = "mq";
        MQEnvironment.channel = "ServerChannel";
        try{
            MQQueueManager queueManager = new MQQueueManager("QueueManager1418");
            System.out.println("Connected");
        }catch (Exception ex){
            System.out.println(ex.getMessage());
        }
    }
}

What can I do?

JoshMc
  • 10,239
  • 2
  • 19
  • 38
Moh Tarvirdi
  • 685
  • 1
  • 13
  • 25
  • Please, add 2035 error description – Seyf Oct 10 '16 at 11:04
  • IBM 2035 MQRC_NOT_AUTHORIZED in WMQ – Moh Tarvirdi Oct 10 '16 at 12:44
  • I didn't mean this :). Usually there is some description, for example: Entity 'user@computer' has insufficient authority to access object 'TEST.QUEUE'. The specified entity is not authorized to access the required object. The following requested permissions are unauthorized: put/passid Ensure that the correct level of authority has been set for this entity against the required object, or ensure that the entity is a member of a privileged group. – Seyf Oct 11 '16 at 08:12
  • You can find the error in the AMQERR log files. – Tim McCormick Oct 11 '16 at 12:21

1 Answers1

0

In Java when you set MQEnvironment.userID to a value, that value is actually passed to the MQ Queue Manager as the asserted user id.

In C# when set MQEnvironment.UserId to a value, that value is not passed to the MQ Queue Manager, instead the id the C# process is running under is passed as the asserted user id.

The asserted user is what MQ will use determine what authorizations you have if it is not overridden by other configurations such as the SVRCONN channel's MCAUSER or CHLAUTH rules that map it to another id.

With your Java app you send mq as the asserted user id and this likely has the proper permissions to connect to the queue manager, for example +connect +dsp.

With your C# app you send what ever userid you are running the process as and this user id likely does not have the proper permisisons to connect to the queue manager.

This would indicate that your MQ SVRCONN channel has a blank MCAUSER and no CHLAUTH rules in place to override this value.

One way to fix this issue is by setting the SVRCONN channel's MCAUSER to mq. This would be done with a command like ALTER CHL(ServerChannel) CHLTYPE(SVRCONN) MCAUSER('mq'). This would then override the asserted user id and MQ will always use the user id mq to determine what authorizations you have unless you have CHLAUTH rules that map it to some other user id.

If you leave it blank, then anyone can easily assert any user id. If you did not disable CHLAUTH and did not change any of the default CHLAUTH rules on a new MQ 7.1 or later queue manager, then user ids with MQ Administrator authority would be blocked from connecting by default. If you did disable CHLAUTH or removed the rule which blocks user ids with MQ Administrator authority, then anyone can just assert a user id with MQ Administrator authority.

I would suggest that you read more on MQ security to decide how you want to further secure your MQ Queue managers. If you have further questions please post them as new questions on Stackoverflow using the tag which is monitored by many people with MQ knowledge (Some even from IBM).

You can view many good MQ security related presentations at T.Rob's website.

Capitalware sponsors the MQ Technical Conference each year and the prior years' sessions (many of which are MQ security related) are archived under MQTC v2.0.1.7's Sessions Page (look at the bottom under Previous MQTC Sessions).

JoshMc
  • 10,239
  • 2
  • 19
  • 38