| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ Server 8.0 Client Channel Security |
« View previous topic :: View next topic » |
| Author |
Message
|
| tczielke |
 Posted: Tue Sep 02, 2014 9:15 am Post subject: |
 |
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Hi LouML,
It is possible I am misunderstanding the main point of your original post, but I was curious. Do you want to use the new functionality with MQ v8 that requires a password for your non mqm user ids to connect to the queue manager? Or instead, would you like to just turn it off and have things work like they did at 7.5?
I ran into something similar when I started working with v8 queue managers with my sandbox environment.
The existing 7.5 queue manager that got upgraded to v8 worked right away, because the upgrade set the new CONNAUTH queue manager attibute to spaces and turned off this new connection authentication functionality.
However, when I created a new v8 queue manager, the qmgr CONNAUTH attribute was turned on by default, and most of my channels started failing with that "User Id Initializiation Failed" error for my channels that run under a non mqm id. After a little research, I set the CONNAUTH to spaces, and I was back in business.
I guess it wasn't clear to me if you really wanted to use the new CONNAUTH functionality at v8, or if instead you would like to just turn it off and have your v8 qmgr run like 7.5 in regards to CONNAUTH.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Tue Sep 02, 2014 11:32 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Quote: |
After a little research, I set the CONNAUTH to spaces, and I was back in business.
|
Wouldn't it be better to control it on individual channels rather than the whole QMGR?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| tczielke |
| Posted: Tue Sep 02, 2014 11:44 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
That could be true. I plan on doing more research on how CONNAUTH works, before we decide if/how we would use it for v8 in a real Test or Prod environment. I really haven't done a lot of research on v8, to be honest.
Setting CONNAUTH to spaces was more of a quick and dirty solution for my sandbox environment to get things working with minimal effort with my new v8 queue manager. Basically, look what MQ did for the 7.5 - > 8.0 upgrade, and match it for a new v8 queue manager.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| LouML |
| Posted: Wed Sep 03, 2014 2:25 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| tczielke wrote: |
Hi LouML,
It is possible I am misunderstanding the main point of your original post, but I was curious. Do you want to use the new functionality with MQ v8 that requires a password for your non mqm user ids to connect to the queue manager? Or instead, would you like to just turn it off and have things work like they did at 7.5?
I ran into something similar when I started working with v8 queue managers with my sandbox environment.
The existing 7.5 queue manager that got upgraded to v8 worked right away, because the upgrade set the new CONNAUTH queue manager attibute to spaces and turned off this new connection authentication functionality.
However, when I created a new v8 queue manager, the qmgr CONNAUTH attribute was turned on by default, and most of my channels started failing with that "User Id Initializiation Failed" error for my channels that run under a non mqm id. After a little research, I set the CONNAUTH to spaces, and I was back in business.
I guess it wasn't clear to me if you really wanted to use the new CONNAUTH functionality at v8, or if instead you would like to just turn it off and have your v8 qmgr run like 7.5 in regards to CONNAUTH. |
We're trying to use the new MQ 8.0 functionality.
Currently, all of our queue managers are 7.5 on Unix (Solaris 10). Our Unix team is driving a migration to Linux (RedHat 6). Since they just delivered our first Dev Linux servers, we decided to kill two birds with one stone and install 8.0 to avoid having to upgrade later.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| LouML |
| Posted: Thu Sep 04, 2014 3:07 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| mqjeff wrote: |
| LouML wrote: |
Spent the past week on vacation, not thinking about this at all.
Now, back to the office... where an email from my Unix Admin is asking me if MQ uses a specific PAM configuration file in /etc/pam.d ? Or could he just create /etc/pam.d/mq ? |
Don't think so.
MQ doesn't know anything about PAM, afaik. MQ just uses standard os libraries to access "local" users and groups. You configure PAM to make LDAP the source of "local" users and groups. Again, it's not an MQ specific thing, it's an OS specific thing. |
The Unix admin is adamant that he needs to setup a configuration file in /etc/pam.d but is unsure what to call it. He also said he would need the name of the PAM service.
I guess it's time to put in a call to IBM.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| LouML |
| Posted: Mon Oct 06, 2014 4:05 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
Update.
I reached out to T Rob about this issue. We had him in a few years back to help with security. In his reply he cc'd a few IBM guys because he took issue with the way the following tech note was written
http://www-01.ibm.com/support/docview.wss?uid=swg21194750
T Rob stated:
The Tech note falls down because it confuses PAM with OAM:
The authorization service component supplied with the WebSphere MQ products is called the Object Authority Manager (OAM). The authorization service enables you to augment or replace the authority checking provided for queue managers by writing your own authorization service component.
If you choose to use Vintela VAS, which uses PAM, this is supported. However, be aware that it has not been tested with WebSphere MQ.
Despite what the Technote says, PAM replaces or augments /etc/group and /etc/passwd, and *not* the OAM.
From there, the IBM guys got in touch and we discussed my issue. They asked me to open a PMR for tracking purposes while they worked in parallel with me and the lab.
The lab came back with this for my Unix admins:
If it (i.e. Vintela VAS) can supply passwords from its server that can then be read via nsswitch (on Linux that would typically be done by adding its module to the "shadow" entry in /etc/nsswitch.conf in the same way as NIS/YP does) then I would expect MQ to work with it. If it does not support supplying passwords via nsswitch but instead requires the authenticator to invoke its services via PAM, then today's MQ will not work with it.
To which my admins replied with:
VAS uses nsswitch.conf just like yp/nis. The passwd shadow group entries have a vas4 option in there. I have found that IBM products in the past do not cooporate well with nsswitch but sometimes use PAM. If you are saying you don’t use PAM either than I think this CONNAUTH option has to be disabled and we move forward without it.
The lab came back with this for me:
The lab requests that you attempt to connect a C client program to your V8 queue manager. They want to check if it is a Java (i.e. MQ Explorer) related issue.
They suggest running something simple like amqsputc (Note the trailing 'c' for client). The binaries for this are usually found in (MQ_INSTALLATION_PATH)\Tools\c\Samples\Bin on MS Windows.
A couple of pointers to help you set it up (if necessary 
http://www-01.ibm.com/support/knowledgecenter/#!/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q023960_.htm << MQ V8 Knowledge Center
https://www.ibm.com/developerworks/community/blogs/messaging/entry/bitesize_blogging_mq_v8_samples_can_use_user_id_and_password?lang=en << Developerworks Blog Entry
Let me know the results of the C program test.
We tried this amqsputc and amqscnxc and it still fails with reason code 2035.
So, as tczielke said, disabling CONNAUTH works.
I followed up with the IBM guys to see if this was working as intended or would there be some fix in the future. They replied that to the best of their knowledge, it's working as intended.
So their suggestion is for us to disable PAM, which the Unix admins do not want to do.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| markt |
| Posted: Mon Oct 06, 2014 4:37 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
PAM and nsswitch are very different things. They can interact in interesting ways, but do not provide the same services. I tjhink T-Rob's comments are a bit misleading here: PAM does not augment /etc/passwd. It just provides ways to authenticate usernames.
nsswitch makes OS services like getpwnam and getgrent look in multiple repositories transparently. And those functions are used by MQ for authorisation AND the V8 authentication. Make sure you are using MQ V8.0.0.1 because on some platforms the original code did have issues with the shadow passwords, particularly if it was not a locally-defined user (eg was being supplied via NIS).
MQ does not - and does not claim to - support PAM authentication modules. If that is desired then open an RFE.
Sometimes products/solutions hook into both PAM and nsswitch, but you need to be clear about the distinctions. |
|
| Back to top |
|
|
| LouML |
| Posted: Mon Oct 06, 2014 5:00 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
Thanks for the prompt reply Mark.
By the way, I'm wondering if this PAM issue is the same reason I'm having problems connecting to my server using the 'Administrated Servers' feature in MS0P.
Anyway, for clarification, here's the full reply from T Rob (which he gave me permission to share):
Glad to hear you are working on WMQ upgrades. The v8 code has a lot of useful features. I have copied a couple of my WMQ buddies at IBM because of a concern I have with the Technote you linked to. It's rubbish. I'll explain why.
WMQ on UNIX in versions prior to v8 does not check a password. The Technote applies to pre-v8 WMQ so let's explain it on those terms and then move to v8 specifics later. In v7.5 and earlier, WMQ makes an OS call where it presents the ID from the connection to obtain the list of groups of which it is a member. The call is, or is equivalent to, the UNIX getgrent (Get Group Entries) call. Assuming the user is not in the mqm group, WMQ then compares the user's group memberships (and ID for Windows) to all the access control lists that were set using setmqaut or SET AUTHREC against the object and options used in the API call. This results in a yes/no response from the OAM.
On a plain vanilla UNIX box the getgrent call hits the /etc/passwd and /etc/group files. What PAM does is to allow you to have UNIX use some other identity store in addition to or instead of the files in /etc. For example, PAM lets you use your Active Directory or NIS+ for all your user IDs and groups. Regardless of how PAM is configured and what is behind it, the result of the getgrent call is identical to WMQ: given an ID, here are the groups with which it is associated. There is no impact to how WMQ is installed or configured, no change to OAM, only a requirement to get PAM configured correctly.
The Tech note falls down because it confuses PAM with OAM:
The authorization service component supplied with the WebSphere MQ products is called the Object Authority Manager (OAM). The authorization service enables you to augment or replace the authority checking provided for queue managers by writing your own authorization service component.
If you choose to use Vintela VAS, which uses PAM, this is supported. However, be aware that it has not been tested with WebSphere MQ.
Despite what the Technote says, PAM replaces or augments /etc/group and /etc/passwd, and *not* the OAM.
Whether a particular PAM integration works with WMQ depends on whether PAM is set up to honor UNIX conventions. For example, it *must* be capable of returning to WMQ that the mqm account is in the mqm group. Because of restrictions in Active Directory that do not permit IDs and groups to have the same name, PAM integrations to Active Directory frequently fail on this point. It is possible to use a group name like mqm-group and still have PAM return the expected "mqm" from Active Directory by configuring AD to return an alternate field (which the accounts admin must maintain). Similarly, LDAP-based ID/group stores of all flavors often permit characters longer than the MQ recognizes on UNIX, or else they permit embedded characters that are invalid on UNIX such as spaces. When these are passed as-is by PAM, WMQ on UNIX understandably chokes on them. This is true even where WMQ on Windows has no problem with the same accounts, by the way.
So it doesn't matter so much which 3rd party thing you plug into PAM but rather whether it is capable of (and configured to) respond to getgrent or equivalent OS call with values that make sense to a UNIX system in general and to WMQ in particular. Furthermore, ANY configuration related to PAM is done on the UNIX side and not on the WMQ side. The UNIX Sysadmin has to figure out the PAM settings and the WMQ Admin can at best tell that person "it needs to support groups and IDs with the same name, ensure IDs are unique to within 12 characters, make sure only valid characters are returned in an ID, and oh by the way the space character is not considered valid."
With me so far? Great! Let's talk about WMQ V8.
In V8, WMQ will go a step beyond previous versions in that it can now validate a password supplied with the ID at connect time. This is great because that's the behavior many customers believed it already had when they noticed the ID and password fields in the connection data structure and in the WMQ Explorer dialog. Problem was older versions included the field so that customers might write an exit that would check the password, not because WMQ did the checking. As of V8, WMQ now can do that check on your behalf.
This behavior differs significantly from prior versions so the WMQ Admin has some responsibilities here. These are described in the Connection Authentication section of the Infocenter here:
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q113240_.htm
If the QMgr uses the OS for ID and password, the same requirements we had in v7.5 and earlier still apply. Any PAM module that returns values that make sense in a UNIX context will work. More often than not the problem is not with the PAM module itself but how it has been configured and how the store behind it has been defined.
The QMgr can also query an LDAP database directly rather than hit the OS. This is useful when, for example, the users connecting are all on Active Directory but the UNIX server still uses native /etc/group and /etc/passswd files. Rather than set the QMgr's host server up with PAM, it is possible to have it query LDAP directly. That requires an AUTHINFO object as described here:
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q113270_.htm
(Note: please assume that the multiple lines of the example RUNMQSC command actually end with + characters, contrary to what the example displays. I've reported this error to the Infocenter team.)
Note that the AUTHINFO SECCOM attribute asks whether you wish to use TLS for the connection to the LDAP server. IF YOU SPECIFY NO then the LDAP ID and password as well as the ID and password passed during the connection will be PASSED OVER THE NETWORK IN PLAIN TEXT!! Please keep in mind that this relates to the connection between the QMgr and the LDAP server ONLY at this point.
Assuming that the LDAP ID check is working, let's look at how we get the credentials for that ID check over a client connection because these can also be exposed in plaintext on the network. The normal procedure is that the client provides the ID and password in the MQCSP during the connection. If the client and QMgr use TLS on the channel with a non-NULL cipher, then the entire exchange including user credentials is encrypted to the same level as the channel. There are no cases in which the channel connects yet the credentials are exposed in this configuration. That's your target scenario.
But many shops wanted WMQ to check the ID and password so that they didn't need to set up TLS on the channels. WMQ addresses this by encrypting the credential exchange when possible. What does "when possible" mean? Specifically, both the QMgr and the client MUST beat v8 because this function uses a feature of the TLS handshake called Server Name Indication or SNI. Older versions of the WMQ client came before SNI was invented. Whether or not they ever get SNI (or even could get it given their architecture) in a future release is not known. At least, not to me. For planning purposes, assume that they will not. The result is that pre-V8 clients cannot secure your ID and password on a non-SSL channel.
IBM recognized this as well. The MQCSP Password Protection attribute of the client and QMgr configuration ini files can be set such that the connection is refused if it is not possible to encrypt the ID and password. Please see here:
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q118710_.htm
It is my recommendation that once you get through testing the secured configuration make sure that that the Queue manager PasswordProtection value in qm.ini is set to ALWAYS. This ensures that passwords are not exposed in the event that someone forgets to set up TLS, CONNAUTH or other security control. Rather than succeed with an exposure, this setting makes the connection fail.
Still with me? Awesome! Let me sum up:
• The Technote is rubbish. Ignore it until IBM fixes it. I've copied the people who can help with that
• Make sure that PAM returns an ID and group that make sense in a UNIX and an MQ context and given the restrictions that I mentioned.
• PAM is NOT a replacement for the OAM, does not interact with it as an exit, and does not change how MQ is configured.
• Note the errors in the Infocenter in which the line continuation characters were removed from all the MQSC commands. Refer to the MQSC section which is (hopefully!) syntactically correct.
• Don't disable TLS for your client channels.
• Make CLIENTAUTH(OPTIONAL) if you like once you have v8 QMgrs with ID and password checking, just so long as SSLCIPH is non-blank and specifies a non-NULL cipher.
• If you define new non-TLS channels (or wish to turn TLS off on an existing channel) make sure the client code is at v8.
• Make sure that that the Queue manager PasswordProtection value in qm.ini is set to ALWAYS.
You may have noticed that these recommendations don't touch on the PAM configuration. That's because I don't have enough expertise in that area to provide reliable advice. I have been on engagements where we plowed through getting PAM working and making sure it returned the correct values but it's not something I do often and do not remember the details. I expect the IBM folks or the MQ List Server can provide MUCH better advice there than I can.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 10, 2014 6:03 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Thanks Dude for posting this, it will be a handy reference for many. And thanks T.Rob.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hughson |
| Posted: Tue Jan 20, 2015 3:45 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| LouML wrote: |
| But many shops wanted WMQ to check the ID and password so that they didn't need to set up TLS on the channels. WMQ addresses this by encrypting the credential exchange when possible. What does "when possible" mean? Specifically, both the QMgr and the client MUST be at v8 because this function uses a feature of the TLS handshake called Server Name Indication or SNI. Older versions of the WMQ client came before SNI was invented. Whether or not they ever get SNI (or even could get it given their architecture) in a future release is not known. At least, not to me. For planning purposes, assume that they will not. The result is that pre-V8 clients cannot secure your ID and password on a non-SSL channel. |
While it is true that both ends of the client must be at V8 in order for password encryption to take place, and it is also true that to use SNI both ends of the client connection must be at V8, it must be clarified that SNI plays no role in password protection. Just wanted to make that clear.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| jcv |
| Posted: Sat Jan 24, 2015 2:55 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| I think that SNI makes possible presenting different certificates per channel during SSL handshake, and that password protection on channels without SSL uses 3DES encryption. However, how exactly is the secret symmetric key shared between client and server in that case is unknown to me. I also think that maybe password hashing is better than password encrypting, but of course, that was impossible since you don't have storing of passwords under your control. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
