| Author |
Message
|
| mqdogsbody |
 Posted: Sat Apr 27, 2013 3:01 am Post subject: |
 |
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| Vitor wrote: |
| Beg to differ. WMQ relies on the underlying OS for this feature. If the underlying OS has in fact handed this off to LDAP or similar, and LDAP does not properly provide the information WMQ needs it's not an MQ question. |
Again I don't want to quibble (much though I love doing so). At the Solaris level it works: axlsvqa1 can read a file with group infosys and no world access.
| Vitor wrote: |
| For the record, I tend to agree with @mvic and suspect that it's related to your LDAP configuration. I've seen this sort of thing before where WMQ (and Oracle, and DB2) all claim people are not members of groups they patently are members of[...] in each instance of my experience the problem has been resolved [...] |
Ah, now this is all useful and interesting stuff! Trouble is I know b. all about LDAP
| Vitor wrote: |
| In all instances, the sys admins are your first port of call. If only to provide a trace of what's going on in the OS when WMQ calls out for security. |
I'll have a word with my local friendly Unix admin and see what they can do.
| Vitor wrote: |
| Which OS is this, and what are you using for LDAP services? |
"SunOS 5.10 Generic_142900-03 sun4u sparc SUNW,SPARC-Enterprise" No idea about LDAP. I will ask.
Anyway, thanks (and thanks to mvic). I now feel that I am on some kind of track. The final answer may not be a good one but at least I will have had an answer. (And I can reconcile my understanding if the documentation with the behaviour I observe.)
If MQ is sensitive to the way LDAP is set up, is there no IBM documentation on this? I am off to do some Googling... |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Sat Apr 27, 2013 5:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqdogsbody wrote: |
| If MQ is sensitive to the way LDAP is set up, is there no IBM documentation on this? |
For clarity: WMQ neither permits nor denies access to objects. At certain times (MQCONN, MQOPEN, MQPUT1, etc.) WMQ will ask the underlying ESM (external security manager) if there is a rule that allows/denies access.
It is possible that LDAP can be involved. You will need to understand if, and to what extent, LDAP and other security-ish software is involved. http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=%2Fcom.ibm.mq.csqzal.doc%2Ffg16900_.htm
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mvic |
| Posted: Sat Apr 27, 2013 5:58 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
I guess you might have been referring to an operating system other than the OP's, but do remember we are talking about MQ running on the Solaris operating system here.
| bruce2359 wrote: |
| For clarity: WMQ neither permits nor denies access to objects. |
On Solaris, AIX etc. a queue manager stores a list of authorization information saying what authorization is to be granted or denied to users (known in the MQ manuals as "principals") and/or the groups they are in. The list is given to the queue manager by the MQ admin by using setmqaut commands.
| Quote: |
| At certain times (MQCONN, MQOPEN, MQPUT1, etc.) WMQ will ask the underlying ESM (external security manager) if there is a rule that allows/denies access. |
On Solaris, AIX etc. at certain times, a queue manager will ask the operating system (which might or might not have delegated this responsibility to another system) what username the user's application process is running as, and what groups that user is in. The rules for what each user and group can do with objects in the queue manager are stored in the queue manager. The rules are specific to each queue manager, which is incompatible with the idea that they are stored by something called an ESM outside the queue manager.
Fair enough if you were referring to some other OS that I don't know, but we are talking about Solaris in this thread.
Lastly, the LDAP link in the above post is not directly relevant to the subject of MQ authorization checks. When LDAP (or anything else, for that matter) is the subsystem holding the user/group information on behalf of the OS, then a queue manager does not know that, and cannot know. It just calls the OS calls it always calls. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Apr 27, 2013 8:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I freely admit my limited knowledge of Solaris-specific innards.
OAM is the ESM to which I was referring. For MQI calls and commands, the qmgr asks OAM if a rule exists that allows or denies access.
Here is a summary-level explanation of WMQ authorization service with OAM: http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzas.doc%2Ffa12780_.htm
Yes, OAM maintains access control lists (ACLs) for a qmgr instance in the SYSTEM.AUTH.DATA.QUEUE.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Apr 27, 2013 10:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqdogsbody wrote: |
| I would also imagine that this would be a "well-known problem". We can't be the only people who have tried running MQ 6 on Solaris using LDAP. |
You're the only people running Solaris the way your sys admins have it configured in combination with the way you've got your LDAP configured.
Also 2 experienced posters have both seen instances of this before. How much more "well known" do you want?
| mqdogsbody wrote: |
| Well, I don't want to quibble over semantics but my view is that if the Unix-level access stuff displays the right behaviour (and it does - I did experiment) then the question "Is it an O/S problem" gets the answer "No - the O/S gets it right". If MQ doesn't get it right we have to look at MQ. |
Yet you are quibbling over semantics. If the Unix level access works correctly, WMQ makes an OS call to obtain security information and is returned the wrong information where's the problem?
Especially as the WMQ calls can't be modified and the OS configuration can be modified. Or as I like to phrase it, "corrected".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Sun Apr 28, 2013 7:04 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| OAM is the ESM to which I was referring. For MQI calls and commands, the qmgr asks OAM if a rule exists that allows or denies access. |
That's why I was getting confused. The OAM is MQ's default implementation of what is known as an Authorization Service. I would guess 99.9% of the world's MQ installations are using it, thus making it "external" to the qmgr only in principle, though not in normal practice. The phrase ESM is unknown to MQ on distributed platforms. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Apr 28, 2013 8:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mvic wrote: |
| bruce2359 wrote: |
| OAM is the ESM to which I was referring. For MQI calls and commands, the qmgr asks OAM if a rule exists that allows or denies access. |
That's why I was getting confused. The OAM is MQ's default implementation of what is known as an Authorization Service. I would guess 99.9% of the world's MQ installations are using it, thus making it "external" to the qmgr only in principle, though not in normal practice. The phrase ESM is unknown to MQ on distributed platforms. |
I wasn't intending to confuse. I was trying to emphasize (reiterate) the 'external' nature of security on WMQ. I was trying to reinforce the mantra that WMQ doesn't authorize.
WMQ access authorization on midrange and z/OS is done by an external service. WMQ calls the external service using the service-specific API, and waits for a response.
No harm, no fowl.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mvic |
| Posted: Sun Apr 28, 2013 12:38 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| WMQ access authorization on midrange and z/OS is done by an external service. WMQ calls the external service using the service-specific API, and waits for a response. |
Again restricting my comments to Solaris/AIX etc. only... what you said is semantically correct. But MQ's OAM is built into a distributed queue manager you create with crtmqm. You have to work very hard to unpick the OAM from a qmgr, and replace it with your own Authorization Service. And 99.9% of sites have no need to do so. Therefore I would argue that it should not be regarded as an external service, except by those few people who need it to be so. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Apr 28, 2013 7:55 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I agree, it's the product delivery default. Perhaps discussing it here is OT.
I mention it for the benefit of those who don't know where/how/why authorization is implemented, and for those who continue to refer to WMQ doing authorization.
Squirrel!
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Apr 29, 2013 7:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The manuals say the permissions for an ID should be the combination of authorizations held by all the groups that ID is a member of.
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/fa15980_.htm
| Quote: |
| If a principal is a member of more than one user group, the principal effectively has the combined authorities of all those user groups. |
Apparently you have evidence that contradicts this statement.
The userID axlsvqa1 is a member of the group infosys.
The O/S commands confirm this membership.
The MQ commands show the MQ authorities that infosys has.
They also show that the axlsvqa1 ID does not have the permissions that infosys has.
I think you are correct in questioning this. It does appear wrong. Open a PMR and please share the results with us.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Mon Apr 29, 2013 8:10 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
Thanks.
| PeterPotkay wrote: |
| It does appear wrong. Open a PMR and please share the results with us. |
Sadly this is MQ 6, which is EOSL
| Code: |
Name: WebSphere MQ
Version: 6.0.2.5
CMVC level: p600-205-080922
BuildType: IKAP - (Production)
|
I shall have to wait until we migrate to MQ7.
For now I guess I will just have to try and get people into the habit of granting access to the primary group of their system user when creating queues. What makes it annoying is that
- mqadmin has infosys as its primary group
- most system user accounts also have infosys as their primary group
- ... so things "just work"
- ... except in production, where the system user has its own private group
Aaaaaaaaaaaargh!
_________________
-- mqDB -- |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Apr 29, 2013 8:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqdogsbody wrote: |
Thanks.
| PeterPotkay wrote: |
| It does appear wrong. Open a PMR and please share the results with us. |
Sadly this is MQ 6, which is EOSL |
So the behavior concerning primary group versus all groups is likely to have changed... and likely to have a number of bugs in it anyway...
and make sure that you haven't moved to a newer OS level that was not supported at that level of MQ.... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Apr 29, 2013 1:04 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqdogsbody wrote: |
| As I explained in another message, I am a little confused about how MQ authorization works w.r.t. UNIX groups. |
See if this from T.Rob helps. The section on Authorizing groups and principals.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqdogsbody |
| Posted: Fri May 03, 2013 2:37 am Post subject: |
|
|
Acolyte
Joined: 01 Jun 2010
Posts: 71
|
| bruce2359 wrote: |
| mqdogsbody wrote: |
| As I explained in another message, I am a little confused about how MQ authorization works w.r.t. UNIX groups. |
See if this from T.Rob helps. |
Thanks. I think I have now enough quotations from the manuals to make it clear what should happen. That being so, it seemc clear that what is happening is not what should happen. (See PeterPotkay's message.)
| bruce2359 wrote: |
| The section on Authorizing groups and principals. |
Like nearly everything else this concentrates on what happens when "aut" is granted ("You say 'principal'; I hear 'group'"), not when it is checked. (The main thing I took from that section was "So happy I am not on Windows!")
I haven't read the whole thing carefully, but this sentence in the first paragraph gives me the info I am seeking:
| T.Rob Wyatt wrote: |
| The effective access is the combination of all applicable profiles, from all applicable groups or accounts. |
and later
| T.Rob Wyatt wrote: |
| This next example illustrates that rights can accumulate from multiple profiles when the principal involved is a member of multiple groups and these groups have differing access rights. |
Thanks all. I am not sure there's much I can do until we migrate to a supported version!
_________________
-- mqDB -- |
|
| Back to top |
|
|
| mvic |
| Posted: Fri May 03, 2013 3:47 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqdogsbody wrote: |
| Thanks all. I am not sure there's much I can do until we migrate to a supported version! |
There is something to do - make your OS use simple files-based user/group db, if only for a little while, and see if the problem remains. IMHO this is where the problem is, not in MQ. No amount of upgrading MQ will fix this, if the problem is below the OS interfaces. |
|
| Back to top |
|
|
|
|
