Now I use the websphere MQ client connect to remote MQ Server(7.0 version) using c#, and occurs a problem of authority,Which is the user running the MQ client application have insufficient authority to access qmgr.Then I use the 'setmqaut' command to grand the user sufficient authority and it works.
I think it's not very convenient and must be a better way.May via adding user's IP in MQ Server? But I have no idea how to do it.
Any suggestions would be greatly appreciated.
Thanks
WebSphere MQ does not perform any authentication. Local applications are authenticated by the operating system and so their ID can be trusted. (By definition, if you cannot trust the local OS authentication then the entire server is compromised.) Just as with local connections, WMQ trusts that the ID connecting remotely is genuine. It is up to the WMQ administrator to determine what level of authentication to employ. In WMQ v7 there are two choices - authenticate with SSL/TLS channels, or use a channel exit to authenticate.
In either case, it is the channel's MCAUSER value that decides what ID is used for authorization. If the MCAUSER is left blank then the channel will use the user ID that the client sends. In your case you received a 2035 error because the client sent an ID that was not in the administrative (mqm) group. Had your client sent the ID 'mqm' (or on Windows 'MUSR_MQADMIN'), the connection would have succeeded. If your program is Java or JMS, the ability to select the ID presented is part of the API. Just tell the QMgr who you want to be.
If you are willing to allow remote connections to execute OS commands on the server, then just put the administrative ID in the channel's MCAUSER. (For example, MCAUSER('mqm') on UNIX/Linux or typically MCAUSER('MUSR_MQADMIN') for Windows.) However, be aware that remote users with admin rights can remotely execute arbitrary OS command-line code using the QMgr. This is a feature of WMQ and not a bug, hence we NEVER recommend this in Production. In fact, I personally recommend that development environments enable security. Waiting until Production to figure out how to authenticate connections and what authorizations are needed often leads to unnecessary deployment delays.
If you want to use IP filtering to mitigate that threat, you can either move to WMQ v7.1 which includes this feature natively, or use an exit such as BlockIP2. Either of these solutions will allow you to create rules that filter incoming connection requests by IP address, user ID, etc.
Note that on a v7.0 QMgr all the channels are unprotected by default. So even if you filter incoming requests on one channel, if the others are left in their default state, anyone can still connect and execute commands as the administrator. For a comprehensive review of all this, please take a look at the Hardening WebSphere MQ presentation at t-rob.net. Scroll down to the v7.0 presentations.
Related
I am using IBM WebSphere MQ 8.x and would like to secure it.
How can I secure my WebSphere Queue Messaging with username/password, so that only valid user can perform operations.
this is how I am accessing Queue right now
Context jndiContext = getInitialContext();
String qcf= getJMSDetailsBean().getQueueConnectionFactory();
QueueConnectionFactory qconFactory = (QueueConnectionFactory) jndiContext.lookup(qcf);
qcon = qconFactory.createQueueConnection();
Could you please guide me on below:
How can I secure my MQ first?
After #1, How can I access MQ using QueueConnectionFactory ?
Thanks
Like many other things in technology there are multiple ways to accomplish the task you are asking about, below describes one method using the IBM MQ provided functionality.
To answer the simpler question first, if you want to pass a username and password to MQ you can call createQueueConnection with the arguments of username and password
createQueueConnection("username", "password")
On the MQ side if you can upgrade I would suggest you move to 9.0.0.5 LTS, if you cannot upgrade to v9.0 then I suggest you upgrade to 8.0.0.10 + IFIX IT25591, you can download the IFIX for this right from the APAR page at the top.
You do not mention which Operating system the queue manager is running on. For most operating system versions you can configure the queue manager to validate credentials against either the Operating System (IDPWOS) or LDAP (IDPWLDAP). You will point the QMGR CONNAUTH property to an AUTHINFO object with AUTHTYPE of either of the above options.
On Unix Operating Systems such as Linux you can configure IDPWOS authentication method (AUTHENMD) as either OS (uses crypt and compare against shadow password entries) or PAM (uses Pluggable Authentication Module). If you go with IDPWOS I recommend PAM because it can provided crypt and compare support (same as the OS method) but also supports anything you can do with PAM, for example authenticate against Windows Active Directory.
For security you want to tell MQ to adopt the user that is authenticated, this is the ADOPTCTX(YES) setting on the AUTHINFO object. You should configure the queue manager for ChlauthEarlyAdopt=Y in the qm.ini file (Note these are both now the default behavior in MQ v9.0.4 CD and higher and on 9.1.0.0 LTS (also 9.1.1 CD) and higher.
If you are sure you want every SVRCONN channel on the queue manager to require a valid username/password to be sent you can set CHCKCLNT(REQUIRED) on the AUTHINFO object. If you need to be more granular you can set this to CHCKCLNT(OPTIONAL) which means if a username and password is present, the password needs to be valid for the username, but it also means if a password is not provided MQ will not attempt authentication. You may want this if you for example have some existing channels where you use a different authentication method such as TLS certificates, or a security exit. If it is set to OPTIONAL at the QMGR level, you can setup CHLAUTH rules to uplift the setting to CHCKCLNT(REQUIRED) for specific channels.
Remember that if you make any changes to the queue manager CONNAUTH settings you need to run REFRESH SECURITY TYPE(CONNAUTH) for those to take effect.
If the MQ client is at MQ v8 or higher, the password if sent on a non-TLS channel will be protected by default with a 3DES encryption, the exception here is for Java and JMS clients you must enabled MQCSP mode (compatibility is the default).
The setting PasswordProtection=always can be set in the qm.ini to ensure that MQ enforces that the password must either be protected by the password protection feature or use a TLS channel with a non-NULL cipherspec. This also means that on non-TLS channels any client that is less than v8 will be rejected.
I'll update this answer provide some example commands to implement the settings above, please let me know if this answer is going in the direction you are looking for?
I scanned the Fix list for IBM MQ Version 8.0 and found the following of interest either related to CONNAUTH or security in general that are fixed in versions later than 8.0.0.3, this is not a complete list there are many more:
8.0.0.5:
IT12825: IBM MQV8: A CLIENT APPLICATION FAILS TO CONNECT TO A QUEUE MANAGER WITH ERROR AMQ9777: CHANNEL WAS BLOCKED.
IT11645: AN IBM MQ V8 CLIENT CONNECTION IS INCORRECTLY ALLOWED WHEN PASSWORDPROTECTION=ALWAYS AND USER_AUTHENTICATION_MQCSP=FALSE
CVE-2015-7473: IBM WebSphere MQ Improper access control for some local MQSC commands
CVE-2016-0259: IBM WebSphere MQ Improper access control for some display commands in local runmqsc
8.0.0.6:
CVE-2016-3052: IBM MQ Java clients might send a password in clear text
8.0.0.7:
IT18052: ChlauthEarlyAdopt modifications
8.0.0.8:
IT22419: All username/password authentication requests hang. Queue manager is configured to request via PAM
IT21306: Ensure consistency among mechanisms for enabling MQCSP authentication mode in Java
IT21384: Setting COM.IBM.MQ.CFG.JMQI.USEMQCSPAUTHENTICATION=Y does not enable the MQCSP authentication mode after IT15833
8.0.0.10:
IT20275: USERMAP CHLAUTH rules and ChlauthEarlyAdopt do not map to the correct user
8.0.0.11 (not release yet):
IT25591: Connection to queue manager fails after upgrade to MQ 8.0.0.10, error log reports user missing CTRL authority on qmgr (AMQ8077)
(First of all, sorry for my poor English)
I've got MQ client (v6.0 or higher). I use mqic32.dll to connect to MQ server. I call MQCONNX to connect to the Queue Manager. MCAUser is not specified for this manager. So, I authenticated at server as a current Windows user.
Well, my program option's window has a 'Test' button and 'Login' Edit. When 'Test' pressed, I call MQCONNX - MQOPEN - MQCLOSE - MQDISQ functions sequence to test the connection/queue opening. There are 2 types of users who starts my application - admin & operator. Admin sets options and performs connection tests, simple users sends and recieves MQ messages. They shoul log in Windows as different Windows users.
And my question is:
I call MQCONNX() being logged as Admin. What parameters (among MQCD struct [sub]fields) should i set for MQ server authenticate me as Operator.
Yes, I can start new process (CreateProcessWithLogonW) as an Operator. But is there a decision keeping me in single process?
I know, using client java- libs I can specify user. So, I think, there should be equivalent ability for mqic32.dll, am I right?
I authenticated at server as a current Windows user.
The queue manager does not authenticate an incoming connection. It will use the UserID to check if the user can do those particular actions i.e. MQCONN, MQOPEN, MQPUT, etc.. But that is not authentication.
If you have not implemented an MQ security solution then anyone can connect with any UserID they want.
I call MQCONNX() being logged as Admin. What parameters (among MQCD struct [sub]fields) should i set for MQ server authenticate me as Operator.
You need to create a client-side security exit and use MQCSP structure but it will not do you any good if you do not have a server-side security exit to read it.
Note: You cannot protect your queue manager from a client-side point of view because anyone can simply download one of the free MQ SupportPacs or one of the many free MQ applications and use it to connect to your queue manager. You need an MQ security solution that is implemented at the queue manager.
I'm a beginner on WebSphere MQ, I was working on MQ 6 and it was working fine, but now I've installed MQ 7.1 and when I try to create a new Queue Manager I can do it But it can't connect and it gives me the following error :
Do you have any idea about that? Thank you :)
You can look up any WebSphere MQ error code if either the WebSphere MQ Client or Server are installed using the mqrc command. In this case:
C:\Users\MUSR_MQADMIN>mqrc 2059
2059 0x0000080b MQRC_Q_MGR_NOT_AVAILABLE
The 2059 usually indicates that the listener is not running or the queue manager is down. There's a different error code if the listener is running and the QMgr name is wrong and another one if the connection is made to the right QMgr but the channel name is wrong. Sometimes you can get a 2059 if the channel was closed at the server side by an exit but since you didn't mention any exits, I'm assuming in this case that its listener problem.
Hopefully by now you are defining a listener object rather than using inetd or the runmqlsr command. Defining an object and setting it to start and stop under QMgr control is the most reliable way to configure it.
Once you get past the 2059, you should be aware that as of WMQ V7.1, the queue managers are secure by default and won't accept any remote client connections unless you explicitly authorize them. This is the opposite of the behavior of V6 where on a newly defined queue manager running a listener, anyone with a TCP route to it could administer it and remotely execute OS code as the mqm user. So I expect that the next problem you run into will be 2035 errors.
I've been told this means more work for the WMQ administrator. The only case in which that's true is if the V6 or earlier queue manager had been configured without security. If the tasks to secure a V7.0 QMgr are compared to the tasks to provision access on a v7.1 and higher QMgr are compared, provisioning access turnds out to be easier. However if you liked the V7.0 behavior, you can always alter the QMgr to disable CHLAUTH rules. Needless to say, leaving security enabled is highly encouraged.
To debug security errors, alter the QMgr to enable authorization events using the runmqsc command ALTER QMGR AUTHOREV(ENABLED). Next, download and install SupportPac MS0P into WebSphere MQ Explorer. Then when you do get a security error, use WebSphere MQ Explorer to look at the queue. Right-click on the queue and select the option to parse the event messages. This will tell you in excruciating detail all the information you need to debug the authorization error.
Finally, if you wish to read up on the new security features, go to t-rob.net/links and look at the conference presentations there. There are also some articles indexed if you scroll down.
In the screen-shot, I see hostname "127.0.0.1" and port # 1414. If it is a local queue manager then connect directly to it.
Also, each queue manager MUST use a unique port number. If you had it working with WMQ v6 queue manager, is this the same queue manager? If not, then make sure each queue manager uses a different port number (i.e. 1415, 1416, etc...)
I got same problem. but i resolved this by :
1. created a listener manually (define lstr(lstr1) port(xxxx) control(qmgr)
2. setmqaut mcauser('mqm').
I need to share a QM and its listener between multiple clients in order to utilize system resources.
my concern is security - access control.
as all clients will have access to the listener port i can't use firewall to manage access rights.
how can i make sure a client can only access his specific queues under the shared QM?
i know i can assign MCAUSER to client level channels, but still, what makes a client being able to only connect to a specific channel?
i have assigned an MCAUSER to a channel and set permissions.
now, from the client java JMS API, how do I connect to that specific channel, and what forbids other clients from connecting to this specific channel?
You are on the right track. I would recommend reading the security presentations from the IBM conference as background. Go to this page and scroll down a bit.
Remember that the client can specify any channel name other than the one you provisioned for them so in addition to setting MCAUSER on the one channel, you need to have set it on all channels. Channels named SYSTEM.DEF.* and SYSTEM.AUTO.* should be disabled with an MCAUSER that cannot be used as a valis user ID. We are currently recommending MCAUSER('*NOACCESS') since *NOACCESS is a reserved word in WMQ V7.1 and later.
Now that you've blocked the unused channels, you need to arrange to map the client connections to their respective user IDs. The way you do this is different depending on which version of WMQ QMgr that you have. In V7.0 and earlier it requires an exit. The BlockIP2 exit at MrMQ.dk is one that the community has contributed to over the years and is owned and maintained by an IBMer. In V7.1 and later the functions in BlockIP2 have been implemented natively in WMQ as CHLAUTH rules.
Specifically, the exit or in V7.1 the CHLAUTH rules allow you to map the connecting client's asserted ID, IP address or SSL Distinguished Name to a user ID to place into MCAUSER when the channel connection is made.
If you need to validate user ID and password, then you would need to write or purchase an exit to do that. Neither WMQ nor BlockIP2 validate ID and password at this time. However, business partners such as Capitalware sell exits which do just that. If you wished to write such an exit, the BlockIP2 source code is a good place to start.
I am new to Websphere, and at this client site, we are running an older version of Websphere in an older version of RAD. I used a python script to define a queue factory and some queues, using a script provided by another individual at the site. However, there was not mention of a queue manager in the script. It appears that the queues are created, I can see that they are defined in the Admin Console. Same is true for the queue factory. The admin console does not seem to expose the name of a queue manager, however.
I have been googling for a few days trying several different angles, but always come back to no answer. There seems to be tool called MQ Explorer, but that comes with Websphere MQ, which is not installed. No one here seems to have tried anything like this before, of if they have, may not have attempted what it is I am trying to achieve.
Ideally, what I would like to do would be to connect to the queue with a third party tool called MQ Visual Edit, for example.
There are about 3 or 4 questions here. Let's see if I can address all of them.
First, creating administered objects is completely separate from defining queues in the queue manager. Typically, the WebSphere MQ admin defines the queues and topics, then provides the host, port, channel, QMgr and queue/topic names to the WAS admin who then generates the matching connection factory and queue or topic objects. Defining the WAS objects does not create the corresponding WMQ objects, nor does it even imply that they exist. From your description, it sounds as though they may not have been defined on the QMgr.
In fact, it is not even obvious from your description that you are using MQ as your transport. If WAS is configured to use it's own JMS implementation (System Integration Bus or SIBus for short) then the connection factories and other objects may point to SIBus instead of WMQ. If you created a QCF for WMQ then someone should have already provided the details you are requesting - QMgr name, host, port and channel name.
WMQ Explorer is available as a free, stand-alone download called SupportPac MS0T. In order to use it, or any of the other 3rd party desktop tools such as MQ Visual Edit or SupportPac MO72 you will need to know the QMgr name as well as host, port and channel name. In addition, if the WMQ admin has enabled any security, you will need to be authorized to connect and, at a minimum, inquire on WMQ objects. The WMQ admin will provide these details to you. Assuming you have the QMgr details and are sufficiently authorized, just download and install SupportPac MS0T and point it at WMQ. Instructions on all things WMQ (including WMQ Explorer) are at the Infocenter pages. Since the stand-alone WMQ Explorer is V7 you will want the V7 Infocenter for any Explorer help. If the QMgr is at V6 then you may need to refer to the V6 Infocenter as well.
That answers the questions in the body of your post. The answer to the question in the title - how do I find out the QMgr name - is "ask the WMQ administrator." You should be given the name when you get the host, port and channel. That said, you often do not need it. A WMQ client will connect to any QMgr if provided the host, port and channel. This is what allows your client app to fail over to a different QMgr. Things like WMQ Explorer are the exception because they should not fail over. If you have a primary and backup QMgr, you typically want WMQ Explorer to see them both at the same time (so for example that you can configure them identically) and if one QMgr is down you want Explorer to report it as such. Therefore Explorer requires a QMgr name but most apps do not.