0

Per my understanding XMS .NET will authenticate with the credentials of the logged in user, which is what our app is doing now running on a Windows server. But we have been asked to move this app into a Linux Docker container and I am unsure of how XMS .NET is now trying to authenticate. The process is running under root, so I'm assuming it is trying to authenticate with that and is failing.

sac80644
  • 103
  • 1
  • 5
  • What version of XMS/MQ are you at? There is XMSC.USERID and XMSC.PASSWORD connection factory properties that can be used specify your own userid and password which will be used to authenticate with queue manager. – Shashi Feb 04 '20 at 11:21
  • What version of MQ is the queue manager? – JoshMc Feb 04 '20 at 12:03
  • There is a lot of reading between the lines of your question.It will make the task of answering your question easier if we are not having to make assumptions. It currently reads as though you have already tried to migrate the code, so I guess it is already using .net core. But the migrated code is failing to authenticate. Is this correct? If so what error are you seeing? – chughts Feb 04 '20 at 13:46
  • @Shashi we are at IBM MQ 7 and from what I have read and tried, XMS tries to use the account of the person running the process, so in the case and Windows account. The XMSC.USERID is ignored, right? https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.msc.doc/prx_userid.htm – sac80644 Feb 04 '20 at 17:10
  • @chughts so yes, this .net core process is already in production on a Windows server, but we have been asked to migrate it to a Linux Docker container. Basically, how to authenticate a client running on Linux to the Queue Manager running on a Windows server. I have been able to get it to work by creating the same service account in the Linux container that we use in the Windows domain and run it using that account, but it is an ugly work around. I keep seeing something about security exits? – sac80644 Feb 04 '20 at 17:29
  • 1
    The MQ version that is running your queue managers MUST be MQ V8.0 or higher to perform authentication or you need to use a 3rd party solution (i.e. security exit) like Capitalware's [MQAUSX](https://capitalware.com/mqausx_overview.html) that works with all releases of MQ. – Roger Feb 04 '20 at 20:32
  • @Roger, this issue has come back up. I do not see that MQ V8.0 or higher offers any more solution to this. Per IBM the XMSC_USERID has to match that of the currently logged on user (https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.msc.doc/prx_userid.htm). Security exist seems like the only solution. – sac80644 Jun 18 '20 at 18:11
  • Hi, MQ v8 (which is out of support now) added CONNAUTH, this allows you to pass a userid and password from .NET to MQ to be authenticated on the server. What you describe working when it runs on windows is no authentication at all, it means the queue manager is accepting the ID your process is running under on windows, but it is not authenticating it. As you saw in docker you just created that ID and worked, but that same example anyone that can connect to the IP and port of your queue manager can do the same. – JoshMc Oct 08 '20 at 22:19
  • Using CONNAUTH you send both a username and password and MQ will authenticate it against either the OS or LDAP depending on how the MQ admin configures it. The other option is to present a cert to the queue manger and have the queue manager validate the DN value of the cert you present and map you to a specific MCAUSER on the channel. Both of these allow your client to prove to the queue manager that you are authorized to connect. – JoshMc Oct 08 '20 at 22:21

1 Answers1

0

So sorry I did not post the solution to my question earlier, but basically, the IBM MQ server has a service account in a Windows domain which we need to authenticate as. If you run the XMS .NET client using Windows impersonation you can connect to the MQ as that service account. We put this XMS .NET client in a Linux Docker container, created this service account in the Linux container, and it runs under that account. IBM allows this as "cross domain" authentication. Violla!

sac80644
  • 103
  • 1
  • 5
  • See my comments on your question, for what you setup there is no authentication going on. Anyone that has network access to your windows queue manager can do the same thing you did and connect. Enabling CONNAUTH on the queue manager and having the client send both a username and a password will actually authenticate and you would not need to worry about creating the user in the Docker container. – JoshMc Mar 20 '21 at 01:00
  • "IBM allows this as "cross domain" authentication." is a false statement. – JoshMc Mar 21 '21 at 01:17
  • I will have to talk to my Dev Ops guys who set up the Queue Manager about using CONNAUTH. Currently, you do have to be running a client under a specific service account in order to get access to the Queue, but technically I agree you are not being authenticated by the Queue Manager. IBM does seem to "allow" this. – sac80644 Apr 16 '21 at 21:00
  • It only allows this if you do not configure it to require authentication which is possible and recommended. – JoshMc Apr 16 '21 at 22:58
  • Did you mean "not recommended?" My understanding is that this is the "out of the box" setting, so I can see how DevOps people may have not changed this default behavior. I am obviously an IBM MQ noob and depend on my IBM MQ administrator to know more than I do. I do read considerable documentation before asking questions here so I really appreciate your input. – sac80644 Apr 17 '21 at 01:14
  • I mean configuring it to require authentication is recommended, but I can see now I wasn't very clear . In my opinion out of the box is not restrictive enough so I agree it can be difficult for those new to MQ administration. – JoshMc Apr 17 '21 at 07:13