Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi Folks, I've just improved (I hope ;o)) BlockIP so it can block those bad useres as quoted below. Thanks to Roger for the nice words, this it what makes it all worth to keep WebSphere MQ secure or at least trying to... Currently BlockIP2 can help you block: mqm, MUSR_MQADMIN and blank uids, this means that a valid userid will pass the exit, I can't block a valid user, that's up to WebSphere MQ and the operating system. I have seen some exits arround calling Windows security, so uid/password will get verified... And it's improved to handle multi, patterns input, so you can specify more networks/addresses, it's still limited to the lenght of SCYDATA (32) pos. I'm planning a version where the specification is moved to a file.. You can find BlockIP2 here: http://home19.inet.tele.dk/m-invent/tips_and_tricks.htm#BlockIP2 I hope you'll enjoy it. I think the only solution to really stop this if the MCAUSER is to be blank is to have an exit on that channel to stop this ID. If I had a magic wand, I would make it so that SVRCONN channels with blank MCAUSERs would default the userID to "knucklehead" if the client did not present one (instead of defaulting to mqm). Also, a new channel attribute called BlockMQM which could be turned on to reject (with no further exits or efforts) any connections coming in as mqm or MUSR_MQADMIN. Just my $0.02 ;o) _ Best regards Jxrgen Pedersen IBM Certified WebSphere MQ * IBM Certified Solution Designer - WebSphere MQ V5.3 IBM Certified Solution Developer - WebSphere MQ V5.3 IBM Certified WebSphere MQ Integrator * _ Fe alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi, Good stuff. Client channel or MQCHLIB (or MQSERVER) environment variable is ONLY used by C/C++/COBOL/VB type programs. IBM decided, for good or bad, that when coding for MQ base Java or Java MQ JMS programs, the MQ connection framework would not use either Client channel or MQCHLIB. Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz Quoting Benjamin Zhou <[EMAIL PROTECTED]>: > > Hi Roger, > > great insight ! > > Following your suggestion, I let my jms program on NT send 1000 msg, now I > can see the SYSTEM.DEF.SVRCONN in running state for a few seconds. > > Just one more question, why does client connection channel definition or > MQCHLIB variable has no effect on JMS program? > > best regards, > Ben > x.2474 > > > > > > > > > Roger Lacroix > > <[EMAIL PROTECTED] To: MQSeries List > <[EMAIL PROTECTED]> > alware.biz> cc: "Benjamin F. > Zhou" <[EMAIL PROTECTED]> >Subject: Re: Puzzled: > MQJE001, MQRC 2102 for non-mqm users > 01/08/2004 03:22 PM > > > > > > > > > > Hi, > > Those client channels or MQCHLLIB environment variable will have NO effect > on > your JMS program. > > (1) Normal. > (2) Channel deletion has no effect. Same as (1). > (3) Normal. > (4) It will use the default SVRCONN channel of 'SYSTEM.DEF.SVRCONN'. Again > normal. > (5) Normal. You may not be fast enough to see it be running. > (6) Normal. > > The one thing that I have noticed with version 5.3 of WMQ is that if an > application behaves well (i.e. properly closes queues and disconnects) then > > within a second or two, the SVRCONN channel goes to inactive (assuming all > 1 > connection). > > Therefore, to properly see a running SVRCONN channels, you will need to > send a > few hundred messages or put a 100ms sleep between puts. > > Hope that helps. > > Regards, > Roger Lacroix > Capitalware Inc. > http://www.captialware.biz > > > Quoting "Benjamin F. Zhou" <[EMAIL PROTECTED]>: > > > Thanks everyone for trying to clariy this for me. > > > > Actually, it was also my conviction that an MQI channel would be used for > > ANY client application to talk to a remote qmgr. I came to the last > > conclusion through a series of tests. > > > > my JMS program is on a local NT PC. it sends msg to MYQM on an AIX > server, > > websvr1. > > > > As I did usual with MQclient applications , I defined a svrconn channel > > SVRC.MYQM on MYQM on websvr and defined a client connection channel on > the > > NT PC, beside several other client channels to qmgrs on other servers. > The > > environment variable MQCHLLIB has been defined to point to the file > > mqchltab's location. I defined all these clients channels under a single > > queue manager, which has nothing to do with any other queue manager, > except > > to define all the client channels. > > > > 1. I defined a qcf this way: > > del qcf(qCF) > > def qcf(qCF) qmgr(MYQM) host(websvr1) channel(SVRC.MYQM) > > transport(client) port(1414) > > del q(reqQ) > > def q(reqQ) qmgr(MYQM) qu(TESTQ) > > end > > I run my jms program to put msg to the queue TESTQ on the remote > > MYQM, successful. > > > > 2. I removed the client channel definition on NT; run the jms program, > msg > > successfully gets on the TESTQ on MYQM. I noticed the channel SVRC.MYQM > is > > always inactive. > > > > 3. on websvr1's MYQM, I remove the svrconn channel SVRC.MYQM; run the > > program, it failed with msg: "... failed to create MQQueueManager ..." > > > > 4. on MYQM, I recreated the svrconn channel SVRC.MYQM. However, I > removed > > the property channel(SVRC.MYQM); run the program, successful. Here is the > > jndi setup script: > > del qcf(qCF) > > def qcf(qCF) qmgr(MYQM) host(websvr1) transport(client) > > port(1414) > > del q(reqQ) > > def q(reqQ) qmgr(MYQM) qu(TESTQ) > > end > > > > 5. on MYQM, I again removed svrconn channel SVRC.MYQM, run the program, > > successful. again. I checked, no svrconn channel is running, not even > > SYSTEM.DEF.SVRCONN . > > > > 6. on NT, I added back the property channel(SVRC.MYQM) in my jndi script, > > but removed host(websvr1), run the program, a
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi, Those client channels or MQCHLLIB environment variable will have NO effect on your JMS program. (1) Normal. (2) Channel deletion has no effect. Same as (1). (3) Normal. (4) It will use the default SVRCONN channel of 'SYSTEM.DEF.SVRCONN'. Again normal. (5) Normal. You may not be fast enough to see it be running. (6) Normal. The one thing that I have noticed with version 5.3 of WMQ is that if an application behaves well (i.e. properly closes queues and disconnects) then within a second or two, the SVRCONN channel goes to inactive (assuming all 1 connection). Therefore, to properly see a running SVRCONN channels, you will need to send a few hundred messages or put a 100ms sleep between puts. Hope that helps. Regards, Roger Lacroix Capitalware Inc. http://www.captialware.biz Quoting "Benjamin F. Zhou" <[EMAIL PROTECTED]>: > Thanks everyone for trying to clariy this for me. > > Actually, it was also my conviction that an MQI channel would be used for > ANY client application to talk to a remote qmgr. I came to the last > conclusion through a series of tests. > > my JMS program is on a local NT PC. it sends msg to MYQM on an AIX server, > websvr1. > > As I did usual with MQclient applications , I defined a svrconn channel > SVRC.MYQM on MYQM on websvr and defined a client connection channel on the > NT PC, beside several other client channels to qmgrs on other servers. The > environment variable MQCHLLIB has been defined to point to the file > mqchltab's location. I defined all these clients channels under a single > queue manager, which has nothing to do with any other queue manager, except > to define all the client channels. > > 1. I defined a qcf this way: > del qcf(qCF) > def qcf(qCF) qmgr(MYQM) host(websvr1) channel(SVRC.MYQM) > transport(client) port(1414) > del q(reqQ) > def q(reqQ) qmgr(MYQM) qu(TESTQ) > end > I run my jms program to put msg to the queue TESTQ on the remote > MYQM, successful. > > 2. I removed the client channel definition on NT; run the jms program, msg > successfully gets on the TESTQ on MYQM. I noticed the channel SVRC.MYQM is > always inactive. > > 3. on websvr1's MYQM, I remove the svrconn channel SVRC.MYQM; run the > program, it failed with msg: "... failed to create MQQueueManager ..." > > 4. on MYQM, I recreated the svrconn channel SVRC.MYQM. However, I removed > the property channel(SVRC.MYQM); run the program, successful. Here is the > jndi setup script: > del qcf(qCF) > def qcf(qCF) qmgr(MYQM) host(websvr1) transport(client) > port(1414) > del q(reqQ) > def q(reqQ) qmgr(MYQM) qu(TESTQ) > end > > 5. on MYQM, I again removed svrconn channel SVRC.MYQM, run the program, > successful. again. I checked, no svrconn channel is running, not even > SYSTEM.DEF.SVRCONN . > > 6. on NT, I added back the property channel(SVRC.MYQM) in my jndi script, > but removed host(websvr1), run the program, as Peter anticipated, I got the > error message: "... failed to create MQQueueManager for 'localhost:MYQM' > ..." > > Under no circumstance did I see a svrconn channel became running except > SYSTEM.ADMIN.SVRCONN, which is always running since I use remote admin. > > It is after all these tests did I arrive at the conclusion that JMS client > doesn't use MQI channel unless we explicitly require that it use one. Even > then, it is just referenced, not really used. > > Any IBMer out there can confirm or dis-confirm my argument? or further > clarify it? > > best regards. > Ben > x.2474 > > > > > > Roger Lacroix > <[EMAIL PROTECTED] To: > [EMAIL PROTECTED] > ALWARE.BIZ> cc: > Sent by: MQSeriesSubject: Re: Puzzled: > MQJE001, MQRC 2102 for non-mqm users > List > <[EMAIL PROTECTED] > C.AT> > > > 01/08/2004 12:26 PM > Please respond to > MQSeries List > > > > > > > Hi Ben, > > I believe you have some misconceptions about your JMS / JNDI values. > > First off, if you are using 'transport(client)' then you WILL be using a > SVRCONN channel - hence a MQI channel. Just because you did not specify > it, > does NOT mean you are not using one. I believe the default SVRCONN channel > used (when none is specified) is 'SYSTEM.DEF.SVRCONN'. > > Under normal circumstances, the 'MCA USER ID' field of the >
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
a VERY BIG magnifying glass!
From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>
Reply-To: MQSeries List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Date: Thu, 8 Jan 2004 14:04:41 -0500
" Nobody, except for MQAdmins, is allowed to use
the 'mqm' UserId (it is monitored)."
Roger, how do you monitor that?
-Original Message-
From: Roger Lacroix [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 12:27 PM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi Ben,
I believe you have some misconceptions about your JMS / JNDI values.
First off, if you are using 'transport(client)' then you WILL be using a
SVRCONN channel - hence a MQI channel. Just because you did not specify
it,
does NOT mean you are not using one. I believe the default SVRCONN channel
used (when none is specified) is 'SYSTEM.DEF.SVRCONN'.
Under normal circumstances, the 'MCA USER ID' field of the
'SYSTEM.DEF.SVRCONN'
is blank. This generally means that you will be connecting / opening /
getting / putting messages under the UserId of 'mqm'.
Secondly, you can implement a reasonable amount of MQ security in this
scenario
(of course, client & server security exits would be better).
At my current client, developers do not have access to the JMS / JNDI tree
in
UAT / PTE / PROD (only the SysAdmins and MQAdmins have access). Therefore,
we
code the following for the QCF or XAQCF in JMS / JNDI for WebLogic apps:
def qcf(qCF) qmgr(MYQM) host(192.168.1.12) channel(MYSVRCONN) port(1415)
transport(client) ClientId(FRED)
An alternate approach that is sometimes done (not strongly recommended) is
to
allow the developer to code the UserId in their application.
i.e.
((Message)outMessage).setStringProperty("JMSXUserID", "FRED");
In either case, we apply the necessary security to the UserId 'FRED' for
the
queue manager of 'MYQM'. Nobody, except for MQAdmins, is allowed to use
the 'mqm' UserId (it is monitored).
We have standards that state that developers, QA people, etc are not
allowed
access to the PROD queue managers unless approved but never with the 'mqm'
UserId. We assign the appropriate authority to THEIR UserId.
Since my client is a bank / brokage-house, it is a fire-able offense to
access
PROD data if you have not been approved. Hence, generally speaking, people
do
not risk it.
Hope that helps.
Regards,
Roger Lacroix
Capitalware Inc.
http://www.capitalware.biz
Quoting "Benjamin F. Zhou" <[EMAIL PROTECTED]>:
> Rob,
>
> thanks for the insight.
> However, a JMS application accesses a qmgr via a connection factory
object
> defined in the JNDI namespace, NOT through a svrconn channel on the
server,
> i,e. it's actually not using the MQI channel. It can be seen from the
> following entry in my definition script, that it actually creates a
direct
> socket connection to the host and port:
>
> def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client)
> port(1415)
>
> So such a definition makes it even more dangerous since there is no more
MQ
> level security can be activated.
>
> While writing this, it became clear to me that the above is provided as
an
> alternative to using MQI channel to access a remote qmgr in order to
avoid
> having to define a client channel on the client side. Certainly, the
above
> definition can be altered to use MQI channel instead of the host
propery:
>
> def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client)
>
> However, the first is a dangerous alternative. Any comment?
>
> regards,
> Ben
>
>
>
>
>
>
>
>
>
> "Wyatt, T. Rob"
> <[EMAIL PROTECTED] To:
> [EMAIL PROTECTED]
> MERICA.COM> cc:
> Sent by: MQSeriesSubject: Re: Puzzled:
> MQJE001, MQRC 2102 for non-mqm users
> List
> <[EMAIL PROTECTED]
> C.AT>
>
>
> 01/05/2004 10:50 AM
> Please respond to
> MQSeries List
>
>
>
>
>
>
> Benjamin,
>
> That is because the channel used by the client is using the authority of
> the
> QMgr. Unless you put an MCAUSER or a security exit that substitutes a
> different UserID on the channel, you will get administrative rights.
This
> is true of all client-connections and, yes, it is dangerous.
>
> -- T.Rob
>
> -Original Message-
> From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 05, 2004 9:55 AM
> To: [EMAIL PROTECTED]
> Subje
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi Peter,
How could I charge an outrageously large hourly rate if I give out my secrets.
I wish
Hint: If any message has a UserId of 'mqm' (for Unix) or MUSR_MQADMIN (for
Windows) or CHIN (for OS/390 - where is the QMgr name) then you know
you have a bad boy. I have created some "Q sampler programs" to look to at the
UserId field of all messages in all queues. I run it in binding mode and it
browses all messages (remember to get message of length 0 - zero) and checks
the UserId field. (It is very fast!) It is setup to run 'X' times per hour (we
use a random number).
The other thing you should do is to add a simple server-side security channel
exit to log or better verify the incoming IP address. For a PROD box, these IP
addresses should be well-known and well-defined. Here is an excellent source
for a sample (see LogIP or BlockIP):
http://d1o111.dk.telia.net/~u149101068/index.htm?tips_and_tricks.htm
Hope that helps.
Regards,
Roger Lacroix
Capitalware Inc.
http://www.capitalware.biz
Quoting "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]>:
> " Nobody, except for MQAdmins, is allowed to use
> the 'mqm' UserId (it is monitored)."
>
> Roger, how do you monitor that?
>
>
>
> -Original Message-
> From: Roger Lacroix [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 08, 2004 12:27 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
>
>
> Hi Ben,
>
> I believe you have some misconceptions about your JMS / JNDI values.
>
> First off, if you are using 'transport(client)' then you WILL be using a
> SVRCONN channel - hence a MQI channel. Just because you did not specify it,
> does NOT mean you are not using one. I believe the default SVRCONN channel
> used (when none is specified) is 'SYSTEM.DEF.SVRCONN'.
>
> Under normal circumstances, the 'MCA USER ID' field of the
> 'SYSTEM.DEF.SVRCONN'
> is blank. This generally means that you will be connecting / opening /
> getting / putting messages under the UserId of 'mqm'.
>
> Secondly, you can implement a reasonable amount of MQ security in this
> scenario
> (of course, client & server security exits would be better).
>
> At my current client, developers do not have access to the JMS / JNDI tree
> in
> UAT / PTE / PROD (only the SysAdmins and MQAdmins have access). Therefore,
> we
> code the following for the QCF or XAQCF in JMS / JNDI for WebLogic apps:
>
> def qcf(qCF) qmgr(MYQM) host(192.168.1.12) channel(MYSVRCONN) port(1415)
> transport(client) ClientId(FRED)
>
> An alternate approach that is sometimes done (not strongly recommended) is
> to
> allow the developer to code the UserId in their application.
> i.e.
> ((Message)outMessage).setStringProperty("JMSXUserID", "FRED");
>
> In either case, we apply the necessary security to the UserId 'FRED' for the
> queue manager of 'MYQM'. Nobody, except for MQAdmins, is allowed to use
> the 'mqm' UserId (it is monitored).
>
> We have standards that state that developers, QA people, etc are not
> allowed
> access to the PROD queue managers unless approved but never with the 'mqm'
> UserId. We assign the appropriate authority to THEIR UserId.
>
> Since my client is a bank / brokage-house, it is a fire-able offense to
> access
> PROD data if you have not been approved. Hence, generally speaking, people
> do
> not risk it.
>
> Hope that helps.
>
> Regards,
> Roger Lacroix
> Capitalware Inc.
> http://www.capitalware.biz
>
>
> Quoting "Benjamin F. Zhou" <[EMAIL PROTECTED]>:
>
> > Rob,
> >
> > thanks for the insight.
> > However, a JMS application accesses a qmgr via a connection factory object
> > defined in the JNDI namespace, NOT through a svrconn channel on the
> server,
> > i,e. it's actually not using the MQI channel. It can be seen from the
> > following entry in my definition script, that it actually creates a direct
> > socket connection to the host and port:
> >
> > def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client)
> > port(1415)
> >
> > So such a definition makes it even more dangerous since there is no more
> MQ
> > level security can be activated.
> >
> > While writing this, it became clear to me that the above is provided as an
> > alternative to using MQI channel to access a remote qmgr in order to avoid
> > having to define a client channel on the client side. Certainly, the above
> > definition can be altered to use MQI channel instead of the host propery:
> >
> > def qcf(qCF)
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Thanks everyone for trying to clariy this for me.
Actually, it was also my conviction that an MQI channel would be used for
ANY client application to talk to a remote qmgr. I came to the last
conclusion through a series of tests.
my JMS program is on a local NT PC. it sends msg to MYQM on an AIX server,
websvr1.
As I did usual with MQclient applications , I defined a svrconn channel
SVRC.MYQM on MYQM on websvr and defined a client connection channel on the
NT PC, beside several other client channels to qmgrs on other servers. The
environment variable MQCHLLIB has been defined to point to the file
mqchltab's location. I defined all these clients channels under a single
queue manager, which has nothing to do with any other queue manager, except
to define all the client channels.
1. I defined a qcf this way:
del qcf(qCF)
def qcf(qCF) qmgr(MYQM) host(websvr1) channel(SVRC.MYQM)
transport(client) port(1414)
del q(reqQ)
def q(reqQ) qmgr(MYQM) qu(TESTQ)
end
I run my jms program to put msg to the queue TESTQ on the remote
MYQM, successful.
2. I removed the client channel definition on NT; run the jms program, msg
successfully gets on the TESTQ on MYQM. I noticed the channel SVRC.MYQM is
always inactive.
3. on websvr1's MYQM, I remove the svrconn channel SVRC.MYQM; run the
program, it failed with msg: "... failed to create MQQueueManager ..."
4. on MYQM, I recreated the svrconn channel SVRC.MYQM. However, I removed
the property channel(SVRC.MYQM); run the program, successful. Here is the
jndi setup script:
del qcf(qCF)
def qcf(qCF) qmgr(MYQM) host(websvr1) transport(client)
port(1414)
del q(reqQ)
def q(reqQ) qmgr(MYQM) qu(TESTQ)
end
5. on MYQM, I again removed svrconn channel SVRC.MYQM, run the program,
successful. again. I checked, no svrconn channel is running, not even
SYSTEM.DEF.SVRCONN .
6. on NT, I added back the property channel(SVRC.MYQM) in my jndi script,
but removed host(websvr1), run the program, as Peter anticipated, I got the
error message: "... failed to create MQQueueManager for 'localhost:MYQM'
..."
Under no circumstance did I see a svrconn channel became running except
SYSTEM.ADMIN.SVRCONN, which is always running since I use remote admin.
It is after all these tests did I arrive at the conclusion that JMS client
doesn't use MQI channel unless we explicitly require that it use one. Even
then, it is just referenced, not really used.
Any IBMer out there can confirm or dis-confirm my argument? or further
clarify it?
best regards.
Ben
x.2474
Roger Lacroix
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
ALWARE.BIZ> cc:
Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC
2102 for non-mqm users
List
<[EMAIL PROTECTED]
C.AT>
01/08/2004 12:26 PM
Please respond to
MQSeries List
Hi Ben,
I believe you have some misconceptions about your JMS / JNDI values.
First off, if you are using 'transport(client)' then you WILL be using a
SVRCONN channel - hence a MQI channel. Just because you did not specify
it,
does NOT mean you are not using one. I believe the default SVRCONN channel
used (when none is specified) is 'SYSTEM.DEF.SVRCONN'.
Under normal circumstances, the 'MCA USER ID' field of the
'SYSTEM.DEF.SVRCONN'
is blank. This generally means that you will be connecting / opening /
getting / putting messages under the UserId of 'mqm'.
Secondly, you can implement a reasonable amount of MQ security in this
scenario
(of course, client & server security exits would be better).
At my current client, developers do not have access to the JMS / JNDI tree
in
UAT / PTE / PROD (only the SysAdmins and MQAdmins have access). Therefore,
we
code the following for the QCF or XAQCF in JMS / JNDI for WebLogic apps:
def qcf(qCF) qmgr(MYQM) host(192.168.1.12) channel(MYSVRCONN) port(1415)
transport(client) ClientId(FRED)
An alternate approach that is sometimes done (not strongly recommended) is
to
allow the developer to code the UserId in their application.
i.e.
((Message)outMessage).setStringProperty("JMSXUserID", "FRED");
In either case, we apply the necessary security to the UserId 'FRED' for
the
queue manager of 'MYQM'. Nobody, except for MQAdmins, is allowed to use
the 'mqm' UserId (it is monitored).
We have standards that state that developers, QA people, etc are not
allowed
access to the PROD queue managers unless approved but never with the 'mqm'
UserId. We assign the appropriate authority to THEIR UserId.
Since my client is a bank
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
piece of paper in a safe! one person ('safe'person) gets it out passes the
password,
notes who has it and for what, when finished makes up a new password and
puts it in the safe.
the 'safe' person is non-techie...
Michael
-Oorspronkelijk bericht-
Van: MQSeries List [mailto:[EMAIL PROTECTED] Potkay, Peter
M (PLC, IT)
Verzonden: donderdag 8 januari 2004 20:05
Aan: [EMAIL PROTECTED]
Onderwerp: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
" Nobody, except for MQAdmins, is allowed to use
the 'mqm' UserId (it is monitored)."
Roger, how do you monitor that?
-Original Message-
From: Roger Lacroix [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 12:27 PM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi Ben,
I believe you have some misconceptions about your JMS / JNDI values.
First off, if you are using 'transport(client)' then you WILL be using a
SVRCONN channel - hence a MQI channel. Just because you did not specify it,
does NOT mean you are not using one. I believe the default SVRCONN channel
used (when none is specified) is 'SYSTEM.DEF.SVRCONN'.
Under normal circumstances, the 'MCA USER ID' field of the
'SYSTEM.DEF.SVRCONN'
is blank. This generally means that you will be connecting / opening /
getting / putting messages under the UserId of 'mqm'.
Secondly, you can implement a reasonable amount of MQ security in this
scenario
(of course, client & server security exits would be better).
At my current client, developers do not have access to the JMS / JNDI tree
in
UAT / PTE / PROD (only the SysAdmins and MQAdmins have access). Therefore,
we
code the following for the QCF or XAQCF in JMS / JNDI for WebLogic apps:
def qcf(qCF) qmgr(MYQM) host(192.168.1.12) channel(MYSVRCONN) port(1415)
transport(client) ClientId(FRED)
An alternate approach that is sometimes done (not strongly recommended) is
to
allow the developer to code the UserId in their application.
i.e.
((Message)outMessage).setStringProperty("JMSXUserID", "FRED");
In either case, we apply the necessary security to the UserId 'FRED' for the
queue manager of 'MYQM'. Nobody, except for MQAdmins, is allowed to use
the 'mqm' UserId (it is monitored).
We have standards that state that developers, QA people, etc are not
allowed
access to the PROD queue managers unless approved but never with the 'mqm'
UserId. We assign the appropriate authority to THEIR UserId.
Since my client is a bank / brokage-house, it is a fire-able offense to
access
PROD data if you have not been approved. Hence, generally speaking, people
do
not risk it.
Hope that helps.
Regards,
Roger Lacroix
Capitalware Inc.
http://www.capitalware.biz
Quoting "Benjamin F. Zhou" <[EMAIL PROTECTED]>:
> Rob,
>
> thanks for the insight.
> However, a JMS application accesses a qmgr via a connection factory object
> defined in the JNDI namespace, NOT through a svrconn channel on the
server,
> i,e. it's actually not using the MQI channel. It can be seen from the
> following entry in my definition script, that it actually creates a direct
> socket connection to the host and port:
>
> def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client)
> port(1415)
>
> So such a definition makes it even more dangerous since there is no more
MQ
> level security can be activated.
>
> While writing this, it became clear to me that the above is provided as an
> alternative to using MQI channel to access a remote qmgr in order to avoid
> having to define a client channel on the client side. Certainly, the above
> definition can be altered to use MQI channel instead of the host propery:
>
> def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client)
>
> However, the first is a dangerous alternative. Any comment?
>
> regards,
> Ben
>
>
>
>
>
>
>
>
>
> "Wyatt, T. Rob"
> <[EMAIL PROTECTED] To:
> [EMAIL PROTECTED]
> MERICA.COM> cc:
> Sent by: MQSeriesSubject: Re: Puzzled:
> MQJE001, MQRC 2102 for non-mqm users
> List
> <[EMAIL PROTECTED]
> C.AT>
>
>
> 01/05/2004 10:50 AM
> Please respond to
> MQSeries List
>
>
>
>
>
>
> Benjamin,
>
> That is because the channel used by the client is using the authority of
> the
> QMgr. Unless you put an MCAUSER or a security exit that substitutes a
> different UserID on the channel, you will get administrative rights. This
> is true of all client-connections
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
" Nobody, except for MQAdmins, is allowed to use
the 'mqm' UserId (it is monitored)."
Roger, how do you monitor that?
-Original Message-
From: Roger Lacroix [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 12:27 PM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi Ben,
I believe you have some misconceptions about your JMS / JNDI values.
First off, if you are using 'transport(client)' then you WILL be using a
SVRCONN channel - hence a MQI channel. Just because you did not specify it,
does NOT mean you are not using one. I believe the default SVRCONN channel
used (when none is specified) is 'SYSTEM.DEF.SVRCONN'.
Under normal circumstances, the 'MCA USER ID' field of the
'SYSTEM.DEF.SVRCONN'
is blank. This generally means that you will be connecting / opening /
getting / putting messages under the UserId of 'mqm'.
Secondly, you can implement a reasonable amount of MQ security in this
scenario
(of course, client & server security exits would be better).
At my current client, developers do not have access to the JMS / JNDI tree
in
UAT / PTE / PROD (only the SysAdmins and MQAdmins have access). Therefore,
we
code the following for the QCF or XAQCF in JMS / JNDI for WebLogic apps:
def qcf(qCF) qmgr(MYQM) host(192.168.1.12) channel(MYSVRCONN) port(1415)
transport(client) ClientId(FRED)
An alternate approach that is sometimes done (not strongly recommended) is
to
allow the developer to code the UserId in their application.
i.e.
((Message)outMessage).setStringProperty("JMSXUserID", "FRED");
In either case, we apply the necessary security to the UserId 'FRED' for the
queue manager of 'MYQM'. Nobody, except for MQAdmins, is allowed to use
the 'mqm' UserId (it is monitored).
We have standards that state that developers, QA people, etc are not
allowed
access to the PROD queue managers unless approved but never with the 'mqm'
UserId. We assign the appropriate authority to THEIR UserId.
Since my client is a bank / brokage-house, it is a fire-able offense to
access
PROD data if you have not been approved. Hence, generally speaking, people
do
not risk it.
Hope that helps.
Regards,
Roger Lacroix
Capitalware Inc.
http://www.capitalware.biz
Quoting "Benjamin F. Zhou" <[EMAIL PROTECTED]>:
> Rob,
>
> thanks for the insight.
> However, a JMS application accesses a qmgr via a connection factory object
> defined in the JNDI namespace, NOT through a svrconn channel on the
server,
> i,e. it's actually not using the MQI channel. It can be seen from the
> following entry in my definition script, that it actually creates a direct
> socket connection to the host and port:
>
> def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client)
> port(1415)
>
> So such a definition makes it even more dangerous since there is no more
MQ
> level security can be activated.
>
> While writing this, it became clear to me that the above is provided as an
> alternative to using MQI channel to access a remote qmgr in order to avoid
> having to define a client channel on the client side. Certainly, the above
> definition can be altered to use MQI channel instead of the host propery:
>
> def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client)
>
> However, the first is a dangerous alternative. Any comment?
>
> regards,
> Ben
>
>
>
>
>
>
>
>
>
> "Wyatt, T. Rob"
> <[EMAIL PROTECTED] To:
> [EMAIL PROTECTED]
> MERICA.COM> cc:
> Sent by: MQSeriesSubject: Re: Puzzled:
> MQJE001, MQRC 2102 for non-mqm users
> List
> <[EMAIL PROTECTED]
> C.AT>
>
>
> 01/05/2004 10:50 AM
> Please respond to
> MQSeries List
>
>
>
>
>
>
> Benjamin,
>
> That is because the channel used by the client is using the authority of
> the
> QMgr. Unless you put an MCAUSER or a security exit that substitutes a
> different UserID on the channel, you will get administrative rights. This
> is true of all client-connections and, yes, it is dangerous.
>
> -- T.Rob
>
> -Original Message-
> From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 05, 2004 9:55 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
>
>
> Bob, that's a good point. I've opened a ticket with IBM on this misleading
> reason code.
>
> However, if I use client mode, the jms application ne
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Benjamin,
I don't believe that your example proves a socket connection. Rather I
believe that it demonstrates that SYSTEM.DEF.SVRCONN is set as the default.
When your application is running, do you not see an active SVRCONN instance
for it? If you disable the SYSTEM.DEF.SVRCONN, does the program still work?
According to the docs, only the JMS Pub/Sub interface supports socket
connections and then it's only to the event broker, not to the QMgr.
Anything connecting to the QMgr uses bindings or a standard MQ client
interface.
Ref:
http://publibfp.boulder.ibm.com/epubs/html/csqzaw11/csqzaw110i.htm#HDRCSQ77G
1
-- T.Rob
-Original Message-
From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 11:07 AM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Rob,
thanks for the insight.
However, a JMS application accesses a qmgr via a connection factory object
defined in the JNDI namespace, NOT through a svrconn channel on the server,
i,e. it's actually not using the MQI channel. It can be seen from the
following entry in my definition script, that it actually creates a direct
socket connection to the host and port:
def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client)
port(1415)
So such a definition makes it even more dangerous since there is no more MQ
level security can be activated.
While writing this, it became clear to me that the above is provided as an
alternative to using MQI channel to access a remote qmgr in order to avoid
having to define a client channel on the client side. Certainly, the above
definition can be altered to use MQI channel instead of the host propery:
def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client)
However, the first is a dangerous alternative. Any comment?
regards,
Ben
"Wyatt, T. Rob"
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
MERICA.COM> cc:
Sent by: MQSeries Subject: Re: Puzzled:
MQJE001, MQRC 2102 for non-mqm users
List
<[EMAIL PROTECTED]
C.AT>
01/05/2004 10:50 AM
Please respond to
MQSeries List
Benjamin,
That is because the channel used by the client is using the authority of
the
QMgr. Unless you put an MCAUSER or a security exit that substitutes a
different UserID on the channel, you will get administrative rights. This
is true of all client-connections and, yes, it is dangerous.
-- T.Rob
-Original Message-
From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED]
Sent: Monday, January 05, 2004 9:55 AM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Bob, that's a good point. I've opened a ticket with IBM on this misleading
reason code.
However, if I use client mode, the jms application needs neither +inq nor
+connect to the qmgr, to put a message to a queue. It dosn't even need a
+put/+get/+brose. It seems to me that in the case of MQClient, it is the
local qmgr that actually does the puts/gets. So no authorization is needed
at all. But this sounds too dangerous, doesn't it?
regards,
Benjamin F. Zhou
Mercedes-Benz USA
x.2474
Robert Broderick
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
OTMAIL.COM>cc:
Sent by: MQSeries Subject: Re: Puzzled:
MQJE001, MQRC 2102 for non-mqm users
List
<[EMAIL PROTECTED]
.AC.AT>
01/02/2004 03:39
PM
Please respond to
MQSeries List
Stillthe unanswered question
Why the 2102 Is something looping. I cannot see why insufficient access
authority would generate this type of error. It seems there is an
unresolved
bug.
About 2 months ago there was a discussin on the +inq for the JMS stuff and
if I remember correctly the person at that time was not getting a 2102.
bobbee
>From: "Wyatt, T. Rob" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
>Date: Fri, 2 Jan 2004 13:40:13 -0600
>
>When this happened to us, my developers were not printing the linked JMS
>exception so I did not have a reason code to look at. If I had been given
>a
>2102, it sure would have thrown me off! I like to keep the events turned
>on
>so when I was presented with the problem I very quickly found an event
>message showing the UserID, the QMgr INQ call and a 2035. Discussion with
>the user revealed that any QMgr inquiry calls were happening inside
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi Ben,
I believe you have some misconceptions about your JMS / JNDI values.
First off, if you are using 'transport(client)' then you WILL be using a
SVRCONN channel - hence a MQI channel. Just because you did not specify it,
does NOT mean you are not using one. I believe the default SVRCONN channel
used (when none is specified) is 'SYSTEM.DEF.SVRCONN'.
Under normal circumstances, the 'MCA USER ID' field of the 'SYSTEM.DEF.SVRCONN'
is blank. This generally means that you will be connecting / opening /
getting / putting messages under the UserId of 'mqm'.
Secondly, you can implement a reasonable amount of MQ security in this scenario
(of course, client & server security exits would be better).
At my current client, developers do not have access to the JMS / JNDI tree in
UAT / PTE / PROD (only the SysAdmins and MQAdmins have access). Therefore, we
code the following for the QCF or XAQCF in JMS / JNDI for WebLogic apps:
def qcf(qCF) qmgr(MYQM) host(192.168.1.12) channel(MYSVRCONN) port(1415)
transport(client) ClientId(FRED)
An alternate approach that is sometimes done (not strongly recommended) is to
allow the developer to code the UserId in their application.
i.e.
((Message)outMessage).setStringProperty("JMSXUserID", "FRED");
In either case, we apply the necessary security to the UserId 'FRED' for the
queue manager of 'MYQM'. Nobody, except for MQAdmins, is allowed to use
the 'mqm' UserId (it is monitored).
We have standards that state that developers, QA people, etc are not allowed
access to the PROD queue managers unless approved but never with the 'mqm'
UserId. We assign the appropriate authority to THEIR UserId.
Since my client is a bank / brokage-house, it is a fire-able offense to access
PROD data if you have not been approved. Hence, generally speaking, people do
not risk it.
Hope that helps.
Regards,
Roger Lacroix
Capitalware Inc.
http://www.capitalware.biz
Quoting "Benjamin F. Zhou" <[EMAIL PROTECTED]>:
> Rob,
>
> thanks for the insight.
> However, a JMS application accesses a qmgr via a connection factory object
> defined in the JNDI namespace, NOT through a svrconn channel on the server,
> i,e. it's actually not using the MQI channel. It can be seen from the
> following entry in my definition script, that it actually creates a direct
> socket connection to the host and port:
>
> def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client)
> port(1415)
>
> So such a definition makes it even more dangerous since there is no more MQ
> level security can be activated.
>
> While writing this, it became clear to me that the above is provided as an
> alternative to using MQI channel to access a remote qmgr in order to avoid
> having to define a client channel on the client side. Certainly, the above
> definition can be altered to use MQI channel instead of the host propery:
>
> def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client)
>
> However, the first is a dangerous alternative. Any comment?
>
> regards,
> Ben
>
>
>
>
>
>
>
>
>
> "Wyatt, T. Rob"
> <[EMAIL PROTECTED] To:
> [EMAIL PROTECTED]
> MERICA.COM> cc:
> Sent by: MQSeriesSubject: Re: Puzzled:
> MQJE001, MQRC 2102 for non-mqm users
> List
> <[EMAIL PROTECTED]
> C.AT>
>
>
> 01/05/2004 10:50 AM
> Please respond to
> MQSeries List
>
>
>
>
>
>
> Benjamin,
>
> That is because the channel used by the client is using the authority of
> the
> QMgr. Unless you put an MCAUSER or a security exit that substitutes a
> different UserID on the channel, you will get administrative rights. This
> is true of all client-connections and, yes, it is dangerous.
>
> -- T.Rob
>
> -Original Message-
> From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 05, 2004 9:55 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
>
>
> Bob, that's a good point. I've opened a ticket with IBM on this misleading
> reason code.
>
> However, if I use client mode, the jms application needs neither +inq nor
> +connect to the qmgr, to put a message to a queue. It dosn't even need a
> +put/+get/+brose. It seems to me that in the case of MQClient, it is the
> local qmgr that actually does the puts/gets. So no authorization is needed
> at all. But this sounds too dangerous, doesn't it?
>
> regards,
>
> Benjamin F.
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Sorry I forgot to attach the file.
Nick
-Original Message-
From: Nick Dilauro
Sent: Thursday, January 08, 2004 9:16 AM
To: 'MQSeries List'
Subject: RE: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Benjamin,
Attached is a JNDI bindings file which was created without the channel
option. You can look at it with a text editor and see that it put in a
default entry for SYSTEM.DEF.SVRCONN. If you use the channel option this
entry is replaced by your channel. You can also run your appl and see that
you are really running on the default channel. I don't think the qmgr
really has any special processing for either JMS and Java when the client is
running the Java. It's all just basic MQ from the server's point of view so
there has to be a svrconn channel.
Nick
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin
F. Zhou
Sent: Thursday, January 08, 2004 8:07 AM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Rob,
thanks for the insight.
However, a JMS application accesses a qmgr via a connection factory object
defined in the JNDI namespace, NOT through a svrconn channel on the server,
i,e. it's actually not using the MQI channel. It can be seen from the
following entry in my definition script, that it actually creates a direct
socket connection to the host and port:
def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client)
port(1415)
So such a definition makes it even more dangerous since there is no more MQ
level security can be activated.
While writing this, it became clear to me that the above is provided as an
alternative to using MQI channel to access a remote qmgr in order to avoid
having to define a client channel on the client side. Certainly, the above
definition can be altered to use MQI channel instead of the host propery:
def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client)
However, the first is a dangerous alternative. Any comment?
regards,
Ben
"Wyatt, T. Rob"
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
MERICA.COM> cc:
Sent by: MQSeries Subject: Re: Puzzled:
MQJE001, MQRC 2102 for non-mqm users
List
<[EMAIL PROTECTED]
C.AT>
01/05/2004 10:50 AM
Please respond to
MQSeries List
Benjamin,
That is because the channel used by the client is using the authority of
the
QMgr. Unless you put an MCAUSER or a security exit that substitutes a
different UserID on the channel, you will get administrative rights. This
is true of all client-connections and, yes, it is dangerous.
-- T.Rob
-Original Message-
From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED]
Sent: Monday, January 05, 2004 9:55 AM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Bob, that's a good point. I've opened a ticket with IBM on this misleading
reason code.
However, if I use client mode, the jms application needs neither +inq nor
+connect to the qmgr, to put a message to a queue. It dosn't even need a
+put/+get/+brose. It seems to me that in the case of MQClient, it is the
local qmgr that actually does the puts/gets. So no authorization is needed
at all. But this sounds too dangerous, doesn't it?
regards,
Benjamin F. Zhou
Mercedes-Benz USA
x.2474
Robert Broderick
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
OTMAIL.COM> cc:
Sent by: MQSeries Subject: Re: Puzzled:
MQJE001, MQRC 2102 for non-mqm users
List
<[EMAIL PROTECTED]
.AC.AT>
01/02/2004 03:39
PM
Please respond to
MQSeries List
Stillthe unanswered question
Why the 2102 Is something looping. I cannot see why insufficient access
authority would generate this type of error. It seems there is an
unresolved
bug.
About 2 months ago there was a discussin on the +inq for the JMS stuff and
if I remember correctly the person at that time was not getting a 2102.
bobbee
>From: "Wyatt, T. Rob" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
>Date: Fri, 2 Jan 2004 13:40:13 -0600
>
>When this happened to us, my developers were not printing the linked JMS
>exception so I did not have a reason code to look at. If I had been given
>a
>2102, it sure would have thrown me off! I like to keep the events turned
>on
>so when I was presented with the
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Benjamin,
Attached is a JNDI bindings file which was created without the channel
option. You can look at it with a text editor and see that it put in a
default entry for SYSTEM.DEF.SVRCONN. If you use the channel option this
entry is replaced by your channel. You can also run your appl and see that
you are really running on the default channel. I don't think the qmgr
really has any special processing for either JMS and Java when the client is
running the Java. It's all just basic MQ from the server's point of view so
there has to be a svrconn channel.
Nick
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin
F. Zhou
Sent: Thursday, January 08, 2004 8:07 AM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Rob,
thanks for the insight.
However, a JMS application accesses a qmgr via a connection factory object
defined in the JNDI namespace, NOT through a svrconn channel on the server,
i,e. it's actually not using the MQI channel. It can be seen from the
following entry in my definition script, that it actually creates a direct
socket connection to the host and port:
def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client)
port(1415)
So such a definition makes it even more dangerous since there is no more MQ
level security can be activated.
While writing this, it became clear to me that the above is provided as an
alternative to using MQI channel to access a remote qmgr in order to avoid
having to define a client channel on the client side. Certainly, the above
definition can be altered to use MQI channel instead of the host propery:
def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client)
However, the first is a dangerous alternative. Any comment?
regards,
Ben
"Wyatt, T. Rob"
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
MERICA.COM> cc:
Sent by: MQSeries Subject: Re: Puzzled:
MQJE001, MQRC 2102 for non-mqm users
List
<[EMAIL PROTECTED]
C.AT>
01/05/2004 10:50 AM
Please respond to
MQSeries List
Benjamin,
That is because the channel used by the client is using the authority of
the
QMgr. Unless you put an MCAUSER or a security exit that substitutes a
different UserID on the channel, you will get administrative rights. This
is true of all client-connections and, yes, it is dangerous.
-- T.Rob
-Original Message-
From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED]
Sent: Monday, January 05, 2004 9:55 AM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Bob, that's a good point. I've opened a ticket with IBM on this misleading
reason code.
However, if I use client mode, the jms application needs neither +inq nor
+connect to the qmgr, to put a message to a queue. It dosn't even need a
+put/+get/+brose. It seems to me that in the case of MQClient, it is the
local qmgr that actually does the puts/gets. So no authorization is needed
at all. But this sounds too dangerous, doesn't it?
regards,
Benjamin F. Zhou
Mercedes-Benz USA
x.2474
Robert Broderick
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
OTMAIL.COM> cc:
Sent by: MQSeries Subject: Re: Puzzled:
MQJE001, MQRC 2102 for non-mqm users
List
<[EMAIL PROTECTED]
.AC.AT>
01/02/2004 03:39
PM
Please respond to
MQSeries List
Stillthe unanswered question
Why the 2102 Is something looping. I cannot see why insufficient access
authority would generate this type of error. It seems there is an
unresolved
bug.
About 2 months ago there was a discussin on the +inq for the JMS stuff and
if I remember correctly the person at that time was not getting a 2102.
bobbee
>From: "Wyatt, T. Rob" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
>Date: Fri, 2 Jan 2004 13:40:13 -0600
>
>When this happened to us, my developers were not printing the linked JMS
>exception so I did not have a reason code to look at. If I had been given
>a
>2102, it sure would have thrown me off! I like to keep the events turned
>on
>so when I was presented with the problem I very quickly found an event
>message showing the UserID, the QMgr INQ call and a 2035. Discussion with
>the user revealed that any QMgr inquiry calls were happening inside the
>Java
>classes and n
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
I may be wrong, but the following def:
"def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client) port(1415)"
will cause your QCF to default to the SYSTEM.DEF.SVRCONN channel.I have
never heard of an MQClient connecting to a QM and not using a SVRCONN
channel, regardless of what interface was on top of that MQClient (like
JMS).
"def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client)"
Would default the QCF to the localhost, since you did not specify the
hostname.
An MQClient will always use a hostname and will come in through a SVRCONN
channel. The building of the QCF just happens to let you leave these 2
fields blank and then gives you the default values.
-Original Message-
From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 11:07 AM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Rob,
thanks for the insight.
However, a JMS application accesses a qmgr via a connection factory object
defined in the JNDI namespace, NOT through a svrconn channel on the server,
i,e. it's actually not using the MQI channel. It can be seen from the
following entry in my definition script, that it actually creates a direct
socket connection to the host and port:
def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client)
port(1415)
So such a definition makes it even more dangerous since there is no more MQ
level security can be activated.
While writing this, it became clear to me that the above is provided as an
alternative to using MQI channel to access a remote qmgr in order to avoid
having to define a client channel on the client side. Certainly, the above
definition can be altered to use MQI channel instead of the host propery:
def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client)
However, the first is a dangerous alternative. Any comment?
regards,
Ben
"Wyatt, T. Rob"
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
MERICA.COM> cc:
Sent by: MQSeries Subject: Re: Puzzled:
MQJE001, MQRC 2102 for non-mqm users
List
<[EMAIL PROTECTED]
C.AT>
01/05/2004 10:50 AM
Please respond to
MQSeries List
Benjamin,
That is because the channel used by the client is using the authority of
the
QMgr. Unless you put an MCAUSER or a security exit that substitutes a
different UserID on the channel, you will get administrative rights. This
is true of all client-connections and, yes, it is dangerous.
-- T.Rob
-Original Message-
From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED]
Sent: Monday, January 05, 2004 9:55 AM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Bob, that's a good point. I've opened a ticket with IBM on this misleading
reason code.
However, if I use client mode, the jms application needs neither +inq nor
+connect to the qmgr, to put a message to a queue. It dosn't even need a
+put/+get/+brose. It seems to me that in the case of MQClient, it is the
local qmgr that actually does the puts/gets. So no authorization is needed
at all. But this sounds too dangerous, doesn't it?
regards,
Benjamin F. Zhou
Mercedes-Benz USA
x.2474
Robert Broderick
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
OTMAIL.COM> cc:
Sent by: MQSeries Subject: Re: Puzzled:
MQJE001, MQRC 2102 for non-mqm users
List
<[EMAIL PROTECTED]
.AC.AT>
01/02/2004 03:39
PM
Please respond to
MQSeries List
Stillthe unanswered question
Why the 2102 Is something looping. I cannot see why insufficient access
authority would generate this type of error. It seems there is an
unresolved
bug.
About 2 months ago there was a discussin on the +inq for the JMS stuff and
if I remember correctly the person at that time was not getting a 2102.
bobbee
>From: "Wyatt, T. Rob" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
>Date: Fri, 2 Jan 2004 13:40:13 -0600
>
>When this happened to us, my developers were not printing the linked JMS
>exception so I did not have a reason code to look at. If I had been given
>a
>2102, it sure would have thrown me off! I like to keep the events turned
>on
>so when I was presented with the problem I very quickly found an event
>message showing the UserID, the QMgr INQ call and a 2035. Discussion with
>the user r
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Benjamin,
I think you're missing something. When you leave off the channel, I believe
it defaults to SYSTEM.DEF.SVRCONN channel. Check your bindings file (if
your using the file version) and you can see the entry.
Nick
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin
F. Zhou
Sent: Thursday, January 08, 2004 8:07 AM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Rob,
thanks for the insight.
However, a JMS application accesses a qmgr via a connection factory object
defined in the JNDI namespace, NOT through a svrconn channel on the server,
i,e. it's actually not using the MQI channel. It can be seen from the
following entry in my definition script, that it actually creates a direct
socket connection to the host and port:
def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client)
port(1415)
So such a definition makes it even more dangerous since there is no more MQ
level security can be activated.
While writing this, it became clear to me that the above is provided as an
alternative to using MQI channel to access a remote qmgr in order to avoid
having to define a client channel on the client side. Certainly, the above
definition can be altered to use MQI channel instead of the host propery:
def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client)
However, the first is a dangerous alternative. Any comment?
regards,
Ben
"Wyatt, T. Rob"
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
MERICA.COM> cc:
Sent by: MQSeries Subject: Re: Puzzled:
MQJE001, MQRC 2102 for non-mqm users
List
<[EMAIL PROTECTED]
C.AT>
01/05/2004 10:50 AM
Please respond to
MQSeries List
Benjamin,
That is because the channel used by the client is using the authority of
the
QMgr. Unless you put an MCAUSER or a security exit that substitutes a
different UserID on the channel, you will get administrative rights. This
is true of all client-connections and, yes, it is dangerous.
-- T.Rob
-Original Message-
From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED]
Sent: Monday, January 05, 2004 9:55 AM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Bob, that's a good point. I've opened a ticket with IBM on this misleading
reason code.
However, if I use client mode, the jms application needs neither +inq nor
+connect to the qmgr, to put a message to a queue. It dosn't even need a
+put/+get/+brose. It seems to me that in the case of MQClient, it is the
local qmgr that actually does the puts/gets. So no authorization is needed
at all. But this sounds too dangerous, doesn't it?
regards,
Benjamin F. Zhou
Mercedes-Benz USA
x.2474
Robert Broderick
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
OTMAIL.COM>cc:
Sent by: MQSeries Subject: Re: Puzzled:
MQJE001, MQRC 2102 for non-mqm users
List
<[EMAIL PROTECTED]
.AC.AT>
01/02/2004 03:39
PM
Please respond to
MQSeries List
Stillthe unanswered question
Why the 2102 Is something looping. I cannot see why insufficient access
authority would generate this type of error. It seems there is an
unresolved
bug.
About 2 months ago there was a discussin on the +inq for the JMS stuff and
if I remember correctly the person at that time was not getting a 2102.
bobbee
>From: "Wyatt, T. Rob" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
>Date: Fri, 2 Jan 2004 13:40:13 -0600
>
>When this happened to us, my developers were not printing the linked JMS
>exception so I did not have a reason code to look at. If I had been given
>a
>2102, it sure would have thrown me off! I like to keep the events turned
>on
>so when I was presented with the problem I very quickly found an event
>message showing the UserID, the QMgr INQ call and a 2035. Discussion with
>the user revealed that any QMgr inquiry calls were happening inside the
>Java
>classes and not in his code. We have since learned that Java will inquire
>on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it
>has to back out a GET.
>
>-- T.Rob
>
>-----Original Message-----
>From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED]
>Sent: Friday, January 02, 2004 2:24 PM
>To: [EMAIL PROTECTED]
>Subject: R
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Rob,
thanks for the insight.
However, a JMS application accesses a qmgr via a connection factory object
defined in the JNDI namespace, NOT through a svrconn channel on the server,
i,e. it's actually not using the MQI channel. It can be seen from the
following entry in my definition script, that it actually creates a direct
socket connection to the host and port:
def qcf(qCF) qmgr(MYQM) host(192.168.1.12) transport(client)
port(1415)
So such a definition makes it even more dangerous since there is no more MQ
level security can be activated.
While writing this, it became clear to me that the above is provided as an
alternative to using MQI channel to access a remote qmgr in order to avoid
having to define a client channel on the client side. Certainly, the above
definition can be altered to use MQI channel instead of the host propery:
def qcf(qCF) qmgr(MYQM) channel(MYSVRCONN) transport(client)
However, the first is a dangerous alternative. Any comment?
regards,
Ben
"Wyatt, T. Rob"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
MERICA.COM> cc:
Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC
2102 for non-mqm users
List
<[EMAIL PROTECTED]
C.AT>
01/05/2004 10:50 AM
Please respond to
MQSeries List
Benjamin,
That is because the channel used by the client is using the authority of
the
QMgr. Unless you put an MCAUSER or a security exit that substitutes a
different UserID on the channel, you will get administrative rights. This
is true of all client-connections and, yes, it is dangerous.
-- T.Rob
-Original Message-
From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED]
Sent: Monday, January 05, 2004 9:55 AM
To: [EMAIL PROTECTED]
Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Bob, that's a good point. I've opened a ticket with IBM on this misleading
reason code.
However, if I use client mode, the jms application needs neither +inq nor
+connect to the qmgr, to put a message to a queue. It dosn't even need a
+put/+get/+brose. It seems to me that in the case of MQClient, it is the
local qmgr that actually does the puts/gets. So no authorization is needed
at all. But this sounds too dangerous, doesn't it?
regards,
Benjamin F. Zhou
Mercedes-Benz USA
x.2474
Robert Broderick
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
OTMAIL.COM>cc:
Sent by: MQSeries Subject: Re: Puzzled:
MQJE001, MQRC 2102 for non-mqm users
List
<[EMAIL PROTECTED]
.AC.AT>
01/02/2004 03:39
PM
Please respond to
MQSeries List
Stillthe unanswered question
Why the 2102 Is something looping. I cannot see why insufficient access
authority would generate this type of error. It seems there is an
unresolved
bug.
About 2 months ago there was a discussin on the +inq for the JMS stuff and
if I remember correctly the person at that time was not getting a 2102.
bobbee
>From: "Wyatt, T. Rob" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
>Date: Fri, 2 Jan 2004 13:40:13 -0600
>
>When this happened to us, my developers were not printing the linked JMS
>exception so I did not have a reason code to look at. If I had been given
>a
>2102, it sure would have thrown me off! I like to keep the events turned
>on
>so when I was presented with the problem I very quickly found an event
>message showing the UserID, the QMgr INQ call and a 2035. Discussion with
>the user revealed that any QMgr inquiry calls were happening inside the
>Java
>classes and not in his code. We have since learned that Java will inquire
>on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it
>has to back out a GET.
>
>-- T.Rob
>
>-Original Message-----
>From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED]
>Sent: Friday, January 02, 2004 2:24 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
>
>
>Hi Rob,
>
>Great ! Your tip on adding inq right to non-mqm users did the trick. Here
>is the setmqaut command:
>
> setmqaut -m QMGR -t qmgr -p wasadmin +connect +inq
>
>But how did you know that a JMS appl needs inq right to the qmgr to
>establish connection? I didn't find such information on the JMS manual.
>
>thanks a lot for t
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Title: RE: Puzzled: MQJE001, MQRC 2102 for non-mqm users I found the following in the text for CSD 5 for V5.3 on AIX. It MIGHT help explain why you got a 2102 and not an access error: IY43097 - Occasionally a failure with return code 2102 (MQRC_RESOURCE_PROBLEM) occurred when trying to connect aplications to WebSphere MQ V5.3. When a large number of applications attempted to perform a get operation with large buffer sizes, the shared memory set was extended, but with incorrect permissions. This meant that applications run under a user id which did not have mqm as its primary group could not connect to this extent, getting EACCESS from shmat. This was returned as a resource problem. -Original Message- From: Dawson, John [mailto:[EMAIL PROTECTED]] Sent: 07 January 2004 10:52 To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Peter,  When referring to the WMQ manuals, be sure that you visit http://www-306.ibm.com/software/integration/mqfamily/support/readme/cli530_r ead_2.html for the manual updates as there is a lot of corrected information regarding SSL. Regards, John Dawson Phone: 972.281.4016 Fax   : 972.281.4904 mailto:[EMAIL PROTECTED]  -Original Message- From:  Heggie, Peter [mailto:[EMAIL PROTECTED]] Sent:  Wednesday, January 07, 2004 2:32 PM To: [EMAIL PROTECTED] Subject:   Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Thanks.. I see there is a redbook on Implementing MQ security from May 2003.. Is that the latest publication on MQ and SSL? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Wednesday, January 07, 2004 2:55 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users "I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ?" From an MQ perspective, it is the same as when it first came out with 5.3. -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED]] Sent: Monday, January 05, 2004 12:30 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users That's right.. I have heard this before. I could use the incoming userid and incoming machine name and perform a lookup in a table and get an assigned userid that has the correct priviledges. And that's about halfway to the better solution of SSL and certificates. Our organization has not implemented application level SSL and certificates so a homegrown solution may be our only current option. I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Monday, January 05, 2004 12:12 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users But the real user could be some loser that defines the ID "mqm" on their machine, logs on with that ID, and then your QM has no choice but to let him do whatever they want! -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED]] Sent: Monday, January 05, 2004 12:10 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users I'm sorry - I took the documentation to mean that for non-Java clients, on Windows and UNIX, the userid in the MQCD is the currently logged on user and that the environment variables are not referencved. So if I could verify that it was not a Java client, then I could rely on the userid to be the real user. Peter Heggie This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Gu
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
That's a very valuable reference! thanks Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Dawson, John Sent: Wednesday, January 07, 2004 3:52 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Peter, When referring to the WMQ manuals, be sure that you visit http://www-306.ibm.com/software/integration/mqfamily/support/readme/cli5 30_r ead_2.html for the manual updates as there is a lot of corrected information regarding SSL. Regards, John Dawson Phone: 972.281.4016 Fax: 972.281.4904 mailto:[EMAIL PROTECTED] -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 2:32 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Thanks.. I see there is a redbook on Implementing MQ security from May 2003.. Is that the latest publication on MQ and SSL? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Wednesday, January 07, 2004 2:55 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users "I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ?" >From an MQ perspective, it is the same as when it first came out with 5.3. -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:30 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users That's right.. I have heard this before. I could use the incoming userid and incoming machine name and perform a lookup in a table and get an assigned userid that has the correct priviledges. And that's about halfway to the better solution of SSL and certificates. Our organization has not implemented application level SSL and certificates so a homegrown solution may be our only current option. I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Monday, January 05, 2004 12:12 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users But the real user could be some loser that defines the ID "mqm" on their machine, logs on with that ID, and then your QM has no choice but to let him do whatever they want! -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:10 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users I'm sorry - I took the documentation to mean that for non-Java clients, on Windows and UNIX, the userid in the MQCD is the currently logged on user and that the environment variables are not referencved. So if I could verify that it was not a Java client, then I could rely on the userid to be the real user. Peter Heggie This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Thanks.. That's the one Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of earMERC Roberts Sent: Wednesday, January 07, 2004 3:40 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users the redbook is here: http://publib-b.boulder.ibm.com/Redbooks.nsf/9445fa5b416f6e32852569ae006 bb65f/3effa2807d4b649e85256b750055b5f7?OpenDocument Ernest Roberts IT - Sr Sys Prog MBUSA, LLC - Forwarded by Ernest Roberts/171/DCAG/DCX on 01/07/2004 03:40 PM - "Heggie, Peter" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .NGRID.COM> cc: Sent by: Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users MQSeries List <[EMAIL PROTECTED] en.AC.AT> 01/07/2004 03:31 PM Please respond to MQSeries List Thanks.. I see there is a redbook on Implementing MQ security from May 2003.. Is that the latest publication on MQ and SSL? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Wednesday, January 07, 2004 2:55 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users "I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ?" >From an MQ perspective, it is the same as when it first came out with 5.3. -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:30 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users That's right.. I have heard this before. I could use the incoming userid and incoming machine name and perform a lookup in a table and get an assigned userid that has the correct priviledges. And that's about halfway to the better solution of SSL and certificates. Our organization has not implemented application level SSL and certificates so a homegrown solution may be our only current option. I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Monday, January 05, 2004 12:12 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users But the real user could be some loser that defines the ID "mqm" on their machine, logs on with that ID, and then your QM has no choice but to let him do whatever they want! -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:10 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users I'm sorry - I took the documentation to mean that for non-Java clients, on Windows and UNIX, the userid in the MQCD is the currently logged on user and that the environment variables are not referencved. So if I could verify that it was not a Java client, then I could rely on the userid to be the real user. Peter Heggie This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Peter, When referring to the WMQ manuals, be sure that you visit http://www-306.ibm.com/software/integration/mqfamily/support/readme/cli530_r ead_2.html for the manual updates as there is a lot of corrected information regarding SSL. Regards, John Dawson Phone: 972.281.4016 Fax: 972.281.4904 mailto:[EMAIL PROTECTED] -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 2:32 PM To: [EMAIL PROTECTED] Subject:Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Thanks.. I see there is a redbook on Implementing MQ security from May 2003.. Is that the latest publication on MQ and SSL? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Wednesday, January 07, 2004 2:55 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users "I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ?" >From an MQ perspective, it is the same as when it first came out with 5.3. -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:30 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users That's right.. I have heard this before. I could use the incoming userid and incoming machine name and perform a lookup in a table and get an assigned userid that has the correct priviledges. And that's about halfway to the better solution of SSL and certificates. Our organization has not implemented application level SSL and certificates so a homegrown solution may be our only current option. I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Monday, January 05, 2004 12:12 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users But the real user could be some loser that defines the ID "mqm" on their machine, logs on with that ID, and then your QM has no choice but to let him do whatever they want! -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:10 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users I'm sorry - I took the documentation to mean that for non-Java clients, on Windows and UNIX, the userid in the MQCD is the currently logged on user and that the environment variables are not referencved. So if I could verify that it was not a Java client, then I could rely on the userid to be the real user. Peter Heggie This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
the redbook is here: http://publib-b.boulder.ibm.com/Redbooks.nsf/9445fa5b416f6e32852569ae006bb65f/3effa2807d4b649e85256b750055b5f7?OpenDocument Ernest Roberts IT - Sr Sys Prog MBUSA, LLC - Forwarded by Ernest Roberts/171/DCAG/DCX on 01/07/2004 03:40 PM - "Heggie, Peter" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .NGRID.COM> cc: Sent by: Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users MQSeries List <[EMAIL PROTECTED] en.AC.AT> 01/07/2004 03:31 PM Please respond to MQSeries List Thanks.. I see there is a redbook on Implementing MQ security from May 2003.. Is that the latest publication on MQ and SSL? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Wednesday, January 07, 2004 2:55 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users "I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ?" >From an MQ perspective, it is the same as when it first came out with 5.3. -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:30 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users That's right.. I have heard this before. I could use the incoming userid and incoming machine name and perform a lookup in a table and get an assigned userid that has the correct priviledges. And that's about halfway to the better solution of SSL and certificates. Our organization has not implemented application level SSL and certificates so a homegrown solution may be our only current option. I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Monday, January 05, 2004 12:12 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users But the real user could be some loser that defines the ID "mqm" on their machine, logs on with that ID, and then your QM has no choice but to let him do whatever they want! -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:10 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users I'm sorry - I took the documentation to mean that for non-Java clients, on Windows and UNIX, the userid in the MQCD is the currently logged on user and that the environment variables are not referencved. So if I could verify that it was not a Java client, then I could rely on the userid to be the real user. Peter Heggie This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Thanks.. I see there is a redbook on Implementing MQ security from May 2003.. Is that the latest publication on MQ and SSL? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Wednesday, January 07, 2004 2:55 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users "I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ?" >From an MQ perspective, it is the same as when it first came out with 5.3. -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:30 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users That's right.. I have heard this before. I could use the incoming userid and incoming machine name and perform a lookup in a table and get an assigned userid that has the correct priviledges. And that's about halfway to the better solution of SSL and certificates. Our organization has not implemented application level SSL and certificates so a homegrown solution may be our only current option. I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Monday, January 05, 2004 12:12 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users But the real user could be some loser that defines the ID "mqm" on their machine, logs on with that ID, and then your QM has no choice but to let him do whatever they want! -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:10 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users I'm sorry - I took the documentation to mean that for non-Java clients, on Windows and UNIX, the userid in the MQCD is the currently logged on user and that the environment variables are not referencved. So if I could verify that it was not a Java client, then I could rely on the userid to be the real user. Peter Heggie This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
"I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ?" >From an MQ perspective, it is the same as when it first came out with 5.3. -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:30 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users That's right.. I have heard this before. I could use the incoming userid and incoming machine name and perform a lookup in a table and get an assigned userid that has the correct priviledges. And that's about halfway to the better solution of SSL and certificates. Our organization has not implemented application level SSL and certificates so a homegrown solution may be our only current option. I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Monday, January 05, 2004 12:12 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users But the real user could be some loser that defines the ID "mqm" on their machine, logs on with that ID, and then your QM has no choice but to let him do whatever they want! -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:10 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users I'm sorry - I took the documentation to mean that for non-Java clients, on Windows and UNIX, the userid in the MQCD is the currently logged on user and that the environment variables are not referencved. So if I could verify that it was not a Java client, then I could rely on the userid to be the real user. Peter Heggie This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
That's right.. I have heard this before. I could use the incoming userid and incoming machine name and perform a lookup in a table and get an assigned userid that has the correct priviledges. And that's about halfway to the better solution of SSL and certificates. Our organization has not implemented application level SSL and certificates so a homegrown solution may be our only current option. I've been off the MQ board for six months.. Has implementing SSL gotten any easier with MQ 5.3.5 ? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Monday, January 05, 2004 12:12 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users But the real user could be some loser that defines the ID "mqm" on their machine, logs on with that ID, and then your QM has no choice but to let him do whatever they want! -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:10 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users I'm sorry - I took the documentation to mean that for non-Java clients, on Windows and UNIX, the userid in the MQCD is the currently logged on user and that the environment variables are not referencved. So if I could verify that it was not a Java client, then I could rely on the userid to be the real user. Peter Heggie This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
But the real user could be some loser that defines the ID "mqm" on their machine, logs on with that ID, and then your QM has no choice but to let him do whatever they want! -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 12:10 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users I'm sorry - I took the documentation to mean that for non-Java clients, on Windows and UNIX, the userid in the MQCD is the currently logged on user and that the environment variables are not referencved. So if I could verify that it was not a Java client, then I could rely on the userid to be the real user. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Monday, January 05, 2004 11:56 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Peter, If you could do that, what would it gain you? In general you want ALL client connections to use low-privileged IDs or else they have full administrative rights to the QMgr. It is trivial on Java and not too much harder in other languages to specify any ID - mqm for instance - to the client MCA. Since the client can assert any ID, why would you trust some types of client and not others? -- T.Rob -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 11:11 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Here is an excerpt from the doc (Clients/Chapter 7) >>> Access control in WebSphere MQ is based upon the user identifier associated with the process making MQI calls. For WebSphere MQ clients, the process that issues the MQI calls is the server-connection MCA. The user identifiers used by the server-connection MCA are that contained in the MCAUserIdentifier and LongMCAUserIdentifier fields of the MQCD. The contents of these fields are determined by: - Any values set by security exits - The user ID (for clients on UNIX systems, Windows 2000, Windows NT, and Windows XP ) or MQ_USER_ID environment variable (for other clients) from the client. - MCAUSER (in the server-connection channel definition). Depending upon the combination of settings of the above, the user-identifier fields are set to appropriate values. If a server-connection security exit is provided, the user-identifier fields can be set by the exit. Otherwise they are determined as follows: If the server-connection channel MCAUSER attribute is nonblank, this value is used. If the server-connection channel MCAUSER attribute is blank, the user ID received from the client is used. However, for the clients that use the MQ_USER_ID environment variable to supply the user ID, it is possible that no environment variable is set. In this case, the user ID that started the server-connection channel is used. For Java client connections, if the client application does not provide a user ID then no client user identification is provided to the server. <<< Looking at a server connection channel, I see the MCA userid field is blank, but the connection is coming from a Windows XP machine. I would have thought, based on the documentation above that, except for Java client apps, for the UNIX and Windows (W2k, NT, XP) clients that the logged on userid is automatically placed in the MCA UserID field. But I guess not. It is only placed in the MQCD exit block, available for an exit to place the contents in the MCA User field. Has anyone figured out how to determine if an incoming connection is coming from a Java client? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Monday, January 05, 2004 10:50 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Benjamin, That is because the channel used by the client is using the authority of the QMgr. Unless you put an MCAUSER or a security exit that substitutes a different UserID on the channel, you will get administrative rights. This is true of all client-connections and, yes, it is dangerous. -- T.Rob Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privi
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
I'm sorry - I took the documentation to mean that for non-Java clients, on Windows and UNIX, the userid in the MQCD is the currently logged on user and that the environment variables are not referencved. So if I could verify that it was not a Java client, then I could rely on the userid to be the real user. Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Monday, January 05, 2004 11:56 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Peter, If you could do that, what would it gain you? In general you want ALL client connections to use low-privileged IDs or else they have full administrative rights to the QMgr. It is trivial on Java and not too much harder in other languages to specify any ID - mqm for instance - to the client MCA. Since the client can assert any ID, why would you trust some types of client and not others? -- T.Rob -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 11:11 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Here is an excerpt from the doc (Clients/Chapter 7) >>> Access control in WebSphere MQ is based upon the user identifier associated with the process making MQI calls. For WebSphere MQ clients, the process that issues the MQI calls is the server-connection MCA. The user identifiers used by the server-connection MCA are that contained in the MCAUserIdentifier and LongMCAUserIdentifier fields of the MQCD. The contents of these fields are determined by: - Any values set by security exits - The user ID (for clients on UNIX systems, Windows 2000, Windows NT, and Windows XP ) or MQ_USER_ID environment variable (for other clients) from the client. - MCAUSER (in the server-connection channel definition). Depending upon the combination of settings of the above, the user-identifier fields are set to appropriate values. If a server-connection security exit is provided, the user-identifier fields can be set by the exit. Otherwise they are determined as follows: If the server-connection channel MCAUSER attribute is nonblank, this value is used. If the server-connection channel MCAUSER attribute is blank, the user ID received from the client is used. However, for the clients that use the MQ_USER_ID environment variable to supply the user ID, it is possible that no environment variable is set. In this case, the user ID that started the server-connection channel is used. For Java client connections, if the client application does not provide a user ID then no client user identification is provided to the server. <<< Looking at a server connection channel, I see the MCA userid field is blank, but the connection is coming from a Windows XP machine. I would have thought, based on the documentation above that, except for Java client apps, for the UNIX and Windows (W2k, NT, XP) clients that the logged on userid is automatically placed in the MCA UserID field. But I guess not. It is only placed in the MQCD exit block, available for an exit to place the contents in the MCA User field. Has anyone figured out how to determine if an incoming connection is coming from a Java client? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Monday, January 05, 2004 10:50 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Benjamin, That is because the channel used by the client is using the authority of the QMgr. Unless you put an MCAUSER or a security exit that substitutes a different UserID on the channel, you will get administrative rights. This is true of all client-connections and, yes, it is dangerous. -- T.Rob Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This e-mail and any files transmitted with it, are confidential to National Grid and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please reply to this message and let the sender know. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Peter, If you could do that, what would it gain you? In general you want ALL client connections to use low-privileged IDs or else they have full administrative rights to the QMgr. It is trivial on Java and not too much harder in other languages to specify any ID - mqm for instance - to the client MCA. Since the client can assert any ID, why would you trust some types of client and not others? -- T.Rob -Original Message- From: Heggie, Peter [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 11:11 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Here is an excerpt from the doc (Clients/Chapter 7) >>> Access control in WebSphere MQ is based upon the user identifier associated with the process making MQI calls. For WebSphere MQ clients, the process that issues the MQI calls is the server-connection MCA. The user identifiers used by the server-connection MCA are that contained in the MCAUserIdentifier and LongMCAUserIdentifier fields of the MQCD. The contents of these fields are determined by: - Any values set by security exits - The user ID (for clients on UNIX systems, Windows 2000, Windows NT, and Windows XP ) or MQ_USER_ID environment variable (for other clients) from the client. - MCAUSER (in the server-connection channel definition). Depending upon the combination of settings of the above, the user-identifier fields are set to appropriate values. If a server-connection security exit is provided, the user-identifier fields can be set by the exit. Otherwise they are determined as follows: If the server-connection channel MCAUSER attribute is nonblank, this value is used. If the server-connection channel MCAUSER attribute is blank, the user ID received from the client is used. However, for the clients that use the MQ_USER_ID environment variable to supply the user ID, it is possible that no environment variable is set. In this case, the user ID that started the server-connection channel is used. For Java client connections, if the client application does not provide a user ID then no client user identification is provided to the server. <<< Looking at a server connection channel, I see the MCA userid field is blank, but the connection is coming from a Windows XP machine. I would have thought, based on the documentation above that, except for Java client apps, for the UNIX and Windows (W2k, NT, XP) clients that the logged on userid is automatically placed in the MCA UserID field. But I guess not. It is only placed in the MQCD exit block, available for an exit to place the contents in the MCA User field. Has anyone figured out how to determine if an incoming connection is coming from a Java client? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Monday, January 05, 2004 10:50 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Benjamin, That is because the channel used by the client is using the authority of the QMgr. Unless you put an MCAUSER or a security exit that substitutes a different UserID on the channel, you will get administrative rights. This is true of all client-connections and, yes, it is dangerous. -- T.Rob Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Here is an excerpt from the doc (Clients/Chapter 7) >>> Access control in WebSphere MQ is based upon the user identifier associated with the process making MQI calls. For WebSphere MQ clients, the process that issues the MQI calls is the server-connection MCA. The user identifiers used by the server-connection MCA are that contained in the MCAUserIdentifier and LongMCAUserIdentifier fields of the MQCD. The contents of these fields are determined by: - Any values set by security exits - The user ID (for clients on UNIX systems, Windows 2000, Windows NT, and Windows XP ) or MQ_USER_ID environment variable (for other clients) from the client. - MCAUSER (in the server-connection channel definition). Depending upon the combination of settings of the above, the user-identifier fields are set to appropriate values. If a server-connection security exit is provided, the user-identifier fields can be set by the exit. Otherwise they are determined as follows: If the server-connection channel MCAUSER attribute is nonblank, this value is used. If the server-connection channel MCAUSER attribute is blank, the user ID received from the client is used. However, for the clients that use the MQ_USER_ID environment variable to supply the user ID, it is possible that no environment variable is set. In this case, the user ID that started the server-connection channel is used. For Java client connections, if the client application does not provide a user ID then no client user identification is provided to the server. <<< Looking at a server connection channel, I see the MCA userid field is blank, but the connection is coming from a Windows XP machine. I would have thought, based on the documentation above that, except for Java client apps, for the UNIX and Windows (W2k, NT, XP) clients that the logged on userid is automatically placed in the MCA UserID field. But I guess not. It is only placed in the MQCD exit block, available for an exit to place the contents in the MCA User field. Has anyone figured out how to determine if an incoming connection is coming from a Java client? Peter Heggie -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, T. Rob Sent: Monday, January 05, 2004 10:50 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Benjamin, That is because the channel used by the client is using the authority of the QMgr. Unless you put an MCAUSER or a security exit that substitutes a different UserID on the channel, you will get administrative rights. This is true of all client-connections and, yes, it is dangerous. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Bob, that's a good point. I've opened a ticket with IBM on this misleading reason code. However, if I use client mode, the jms application needs neither +inq nor +connect to the qmgr, to put a message to a queue. It dosn't even need a +put/+get/+brose. It seems to me that in the case of MQClient, it is the local qmgr that actually does the puts/gets. So no authorization is needed at all. But this sounds too dangerous, doesn't it? regards, Benjamin F. Zhou Mercedes-Benz USA x.2474 Robert Broderick <[EMAIL PROTECTED] To: [EMAIL PROTECTED] OTMAIL.COM>cc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List <[EMAIL PROTECTED] .AC.AT> 01/02/2004 03:39 PM Please respond to MQSeries List Stillthe unanswered question Why the 2102 Is something looping. I cannot see why insufficient access authority would generate this type of error. It seems there is an unresolved bug. About 2 months ago there was a discussin on the +inq for the JMS stuff and if I remember correctly the person at that time was not getting a 2102. bobbee >From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users >Date: Fri, 2 Jan 2004 13:40:13 -0600 > >When this happened to us, my developers were not printing the linked >JMS exception so I did not have a reason code to look at. If I had >been given a 2102, it sure would have thrown me off! I like to keep >the events turned on >so when I was presented with the problem I very quickly found an event >message showing the UserID, the QMgr INQ call and a 2035. Discussion with >the user revealed that any QMgr inquiry calls were happening in
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Benjamin, That is because the channel used by the client is using the authority of the QMgr. Unless you put an MCAUSER or a security exit that substitutes a different UserID on the channel, you will get administrative rights. This is true of all client-connections and, yes, it is dangerous. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 9:55 AM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Bob, that's a good point. I've opened a ticket with IBM on this misleading reason code. However, if I use client mode, the jms application needs neither +inq nor +connect to the qmgr, to put a message to a queue. It dosn't even need a +put/+get/+brose. It seems to me that in the case of MQClient, it is the local qmgr that actually does the puts/gets. So no authorization is needed at all. But this sounds too dangerous, doesn't it? regards, Benjamin F. Zhou Mercedes-Benz USA x.2474 Robert Broderick <[EMAIL PROTECTED] To: [EMAIL PROTECTED] OTMAIL.COM>cc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List <[EMAIL PROTECTED] .AC.AT> 01/02/2004 03:39 PM Please respond to MQSeries List Stillthe unanswered question Why the 2102 Is something looping. I cannot see why insufficient access authority would generate this type of error. It seems there is an unresolved bug. About 2 months ago there was a discussin on the +inq for the JMS stuff and if I remember correctly the person at that time was not getting a 2102. bobbee >From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users >Date: Fri, 2 Jan 2004 13:40:13 -0600 > >When this happened to us, my developers were not printing the linked JMS >exception so I did not have a reason code to look at. If I had been given >a >2102, it sure would have thrown me off! I like to keep the events turned >on >so when I was presented with the problem I very quickly found an event >message showing the UserID, the QMgr INQ call and a 2035. Discussion with >the user revealed that any QMgr inquiry calls were happening inside the >Java >classes and not in his code. We have since learned that Java will inquire >on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it >has to back out a GET. > >-- T.Rob > >-Original Message- >From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] >Sent: Friday, January 02, 2004 2:24 PM >To: [EMAIL PROTECTED] >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > >Hi Rob, > >Great ! Your tip on adding inq right to non-mqm users did the trick. Here >is the setmqaut command: > > setmqaut -m QMGR -t qmgr -p wasadmin +connect +inq > >But how did you know that a JMS appl needs inq right to the qmgr to >establish connection? I didn't find such information on the JMS manual. > >thanks a lot for the insight ! > >Ben > > > > > > > > "Wyatt, T. Rob" > <[EMAIL PROTECTED] To: >[EMAIL PROTECTED] > MERICA.COM> cc: > Sent by: MQSeriesSubject: Re: Puzzled: >MQJE001, MQRC 2102 for non-mqm users > List > <[EMAIL PROTECTED] > C.AT> > > > 01/02/2004 12:44 PM > Please respond to > MQSeries List > > > > > > >Benjamin, > >Are the classpaths the same between the two UserIDs? If you are on Unix, >try > >echo $CLASSPATH | tr ":" "\n" > >...from each user's command line and compare. There are generally two >types >of problems that manifest themselves differently under different users - >security, which you covered, and environment. > >Incidentally, you did not mention whether you gave the user Inquire on the >QMgr and queues. JMS will inquire the QMgr right after connecting. This >usually generates 2035's though. > >-- T.Rob > >-Original Message- >From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] >Sent: Friday, January 02, 2004 11:48 AM >To: [EMAIL PROTECTED] >Subject: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > >Hi, > >first, happy new year to every
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
looks like the svrconn channel definition is running with the default value of ' ' which means that all clients connect and run with "mqm" authority. This is not very secure ... Consider using a security exit solution to protect your client channels and set a userid based on cryptographic credentials. Dave -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Benjamin F. Zhou Sent: 05 January 2004 14:55 To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Bob, that's a good point. I've opened a ticket with IBM on this misleading reason code. However, if I use client mode, the jms application needs neither +inq nor +connect to the qmgr, to put a message to a queue. It dosn't even need a +put/+get/+brose. It seems to me that in the case of MQClient, it is the local qmgr that actually does the puts/gets. So no authorization is needed at all. But this sounds too dangerous, doesn't it? regards, Benjamin F. Zhou Mercedes-Benz USA x.2474 Robert Broderick <[EMAIL PROTECTED] To: [EMAIL PROTECTED] OTMAIL.COM>cc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List <[EMAIL PROTECTED] .AC.AT> 01/02/2004 03:39 PM Please respond to MQSeries List Stillthe unanswered question Why the 2102 Is something looping. I cannot see why insufficient access authority would generate this type of error. It seems there is an unresolved bug. About 2 months ago there was a discussin on the +inq for the JMS stuff and if I remember correctly the person at that time was not getting a 2102. bobbee >From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users >Date: Fri, 2 Jan 2004 13:40:13 -0600 > >When this happened to us, my developers were not printing the linked JMS >exception so I did not have a reason code to look at. If I had been given >a >2102, it sure would have thrown me off! I like to keep the events turned >on >so when I was presented with the problem I very quickly found an event >message showing the UserID, the QMgr INQ call and a 2035. Discussion with >the user revealed that any QMgr inquiry calls were happening inside the >Java >classes and not in his code. We have since learned that Java will inquire >on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it >has to back out a GET. > >-- T.Rob > >-Original Message----- >From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] >Sent: Friday, January 02, 2004 2:24 PM >To: [EMAIL PROTECTED] >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > >Hi Rob, > >Great ! Your tip on adding inq right to non-mqm users did the trick. Here >is the setmqaut command: > > setmqaut -m QMGR -t qmgr -p wasadmin +connect +inq > >But how did you know that a JMS appl needs inq right to the qmgr to >establish connection? I didn't find such information on the JMS manual. > >thanks a lot for the insight ! > >Ben > > > > > > > > "Wyatt, T. Rob" > <[EMAIL PROTECTED] To: >[EMAIL PROTECTED] > MERICA.COM> cc: > Sent by: MQSeriesSubject: Re: Puzzled: >MQJE001, MQRC 2102 for non-mqm users > List > <[EMAIL PROTECTED] > C.AT> > > > 01/02/2004 12:44 PM > Please respond to > MQSeries List > > > > > > >Benjamin, > >Are the classpaths the same between the two UserIDs? If you are on Unix, >try > >echo $CLASSPATH | tr ":" "\n" > >...from each user's command line and compare. There are generally two >types >of problems that manifest themselves differently under different users - >security, which you covered, and environment. > >Incidentally, you did not mention whether you gave the user Inquire on the >QMgr and queues. JMS will inquire the QMgr right after connecting. This >usually generates 2035's though. > >-- T.Rob > >-Original Message- >From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] >Sent: Friday, January 02, 2004 11:48 AM >To: [EMAIL PROTECTED] >Subject: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > >Hi, &
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Bob, that's a good point. I've opened a ticket with IBM on this misleading reason code. However, if I use client mode, the jms application needs neither +inq nor +connect to the qmgr, to put a message to a queue. It dosn't even need a +put/+get/+brose. It seems to me that in the case of MQClient, it is the local qmgr that actually does the puts/gets. So no authorization is needed at all. But this sounds too dangerous, doesn't it? regards, Benjamin F. Zhou Mercedes-Benz USA x.2474 Robert Broderick <[EMAIL PROTECTED] To: [EMAIL PROTECTED] OTMAIL.COM>cc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List <[EMAIL PROTECTED] .AC.AT> 01/02/2004 03:39 PM Please respond to MQSeries List Stillthe unanswered question Why the 2102 Is something looping. I cannot see why insufficient access authority would generate this type of error. It seems there is an unresolved bug. About 2 months ago there was a discussin on the +inq for the JMS stuff and if I remember correctly the person at that time was not getting a 2102. bobbee >From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users >Date: Fri, 2 Jan 2004 13:40:13 -0600 > >When this happened to us, my developers were not printing the linked JMS >exception so I did not have a reason code to look at. If I had been given >a >2102, it sure would have thrown me off! I like to keep the events turned >on >so when I was presented with the problem I very quickly found an event >message showing the UserID, the QMgr INQ call and a 2035. Discussion with >the user revealed that any QMgr inquiry calls were happening inside the >Java >classes and not in his code. We have since learned that Java will inquire >on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it >has to back out a GET. > >-- T.Rob > >-Original Message- >From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] >Sent: Friday, January 02, 2004 2:24 PM >To: [EMAIL PROTECTED] >Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > >Hi Rob, > >Great ! Your tip on adding inq right to non-mqm users did the trick. Here >is the setmqaut command: > > setmqaut -m QMGR -t qmgr -p wasadmin +connect +inq > >But how did you know that a JMS appl needs inq right to the qmgr to >establish connection? I didn't find such information on the JMS manual. > >thanks a lot for the insight ! > >Ben > > > > > > > > "Wyatt, T. Rob" > <[EMAIL PROTECTED] To: >[EMAIL PROTECTED] > MERICA.COM> cc: > Sent by: MQSeriesSubject: Re: Puzzled: >MQJE001, MQRC 2102 for non-mqm users > List > <[EMAIL PROTECTED] > C.AT> > > > 01/02/2004 12:44 PM > Please respond to > MQSeries List > > > > > > >Benjamin, > >Are the classpaths the same between the two UserIDs? If you are on Unix, >try > >echo $CLASSPATH | tr ":" "\n" > >...from each user's command line and compare. There are generally two >types >of problems that manifest themselves differently under different users - >security, which you covered, and environment. > >Incidentally, you did not mention whether you gave the user Inquire on the >QMgr and queues. JMS will inquire the QMgr right after connecting. This >usually generates 2035's though. > >-- T.Rob > >-Original Message- >From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] >Sent: Friday, January 02, 2004 11:48 AM >To: [EMAIL PROTECTED] >Subject: Puzzled: MQJE001, MQRC 2102 for non-mqm users > > >Hi, > >first, happy new year to everyone. > >while trouble-shooting a WAS application's MQRC2102 problem, I wrote a >simple jms program to put msg to a queue. > >The program runs without problem if I start it as "mqm", but if I logon as >a different user than mqm, got the same MQJE001, MQRC 2102 exception. >I explicitely allowed that user the right to connect to the same qmgr and >put/get to the queues, and run the sample executible amqsput, amqsget >without any problem. > >
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Stillthe unanswered question Why the 2102 Is something looping. I cannot see why insufficient access authority would generate this type of error. It seems there is an unresolved bug. About 2 months ago there was a discussin on the +inq for the JMS stuff and if I remember correctly the person at that time was not getting a 2102. bobbee From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Date: Fri, 2 Jan 2004 13:40:13 -0600 When this happened to us, my developers were not printing the linked JMS exception so I did not have a reason code to look at. If I had been given a 2102, it sure would have thrown me off! I like to keep the events turned on so when I was presented with the problem I very quickly found an event message showing the UserID, the QMgr INQ call and a 2035. Discussion with the user revealed that any QMgr inquiry calls were happening inside the Java classes and not in his code. We have since learned that Java will inquire on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it has to back out a GET. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 2:24 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi Rob, Great ! Your tip on adding inq right to non-mqm users did the trick. Here is the setmqaut command: setmqaut -m QMGR -t qmgr -p wasadmin +connect +inq But how did you know that a JMS appl needs inq right to the qmgr to establish connection? I didn't find such information on the JMS manual. thanks a lot for the insight ! Ben "Wyatt, T. Rob" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] MERICA.COM> cc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List <[EMAIL PROTECTED] C.AT> 01/02/2004 12:44 PM Please respond to MQSeries List Benjamin, Are the classpaths the same between the two UserIDs? If you are on Unix, try echo $CLASSPATH | tr ":" "\n" ...from each user's command line and compare. There are generally two types of problems that manifest themselves differently under different users - security, which you covered, and environment. Incidentally, you did not mention whether you gave the user Inquire on the QMgr and queues. JMS will inquire the QMgr right after connecting. This usually generates 2035's though. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 11:48 AM To: [EMAIL PROTECTED] Subject: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi, first, happy new year to everyone. while trouble-shooting a WAS application's MQRC2102 problem, I wrote a simple jms program to put msg to a queue. The program runs without problem if I start it as "mqm", but if I logon as a different user than mqm, got the same MQJE001, MQRC 2102 exception. I explicitely allowed that user the right to connect to the same qmgr and put/get to the queues, and run the sample executible amqsput, amqsget without any problem. MQRC 2102 is resource problem, but I don't understand why it happen to WAS users, but not to mqm, and only happens to jms applications. Any idea would be greatly appreciated. Benjamin F. Zhou Messaging & Integration Research & Technology, ITM Mercedes-Benz USA x.2474 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Get reliable dial-up Internet access now with our limited-time introductory offer. http://join.msn.com/?page=dept/dialup Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
When this happened to us, my developers were not printing the linked JMS exception so I did not have a reason code to look at. If I had been given a 2102, it sure would have thrown me off! I like to keep the events turned on so when I was presented with the problem I very quickly found an event message showing the UserID, the QMgr INQ call and a 2035. Discussion with the user revealed that any QMgr inquiry calls were happening inside the Java classes and not in his code. We have since learned that Java will inquire on queue objects as well, to obtain values for BOQUEUE and BOTHRESH if it has to back out a GET. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 2:24 PM To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi Rob, Great ! Your tip on adding inq right to non-mqm users did the trick. Here is the setmqaut command: setmqaut -m QMGR -t qmgr -p wasadmin +connect +inq But how did you know that a JMS appl needs inq right to the qmgr to establish connection? I didn't find such information on the JMS manual. thanks a lot for the insight ! Ben "Wyatt, T. Rob" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] MERICA.COM> cc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List <[EMAIL PROTECTED] C.AT> 01/02/2004 12:44 PM Please respond to MQSeries List Benjamin, Are the classpaths the same between the two UserIDs? If you are on Unix, try echo $CLASSPATH | tr ":" "\n" ...from each user's command line and compare. There are generally two types of problems that manifest themselves differently under different users - security, which you covered, and environment. Incidentally, you did not mention whether you gave the user Inquire on the QMgr and queues. JMS will inquire the QMgr right after connecting. This usually generates 2035's though. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 11:48 AM To: [EMAIL PROTECTED] Subject: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi, first, happy new year to everyone. while trouble-shooting a WAS application's MQRC2102 problem, I wrote a simple jms program to put msg to a queue. The program runs without problem if I start it as "mqm", but if I logon as a different user than mqm, got the same MQJE001, MQRC 2102 exception. I explicitely allowed that user the right to connect to the same qmgr and put/get to the queues, and run the sample executible amqsput, amqsget without any problem. MQRC 2102 is resource problem, but I don't understand why it happen to WAS users, but not to mqm, and only happens to jms applications. Any idea would be greatly appreciated. Benjamin F. Zhou Messaging & Integration Research & Technology, ITM Mercedes-Benz USA x.2474 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi Rob, Great ! Your tip on adding inq right to non-mqm users did the trick. Here is the setmqaut command: setmqaut -m QMGR -t qmgr -p wasadmin +connect +inq But how did you know that a JMS appl needs inq right to the qmgr to establish connection? I didn't find such information on the JMS manual. thanks a lot for the insight ! Ben "Wyatt, T. Rob" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] MERICA.COM> cc: Sent by: MQSeries Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users List <[EMAIL PROTECTED] C.AT> 01/02/2004 12:44 PM Please respond to MQSeries List Benjamin, Are the classpaths the same between the two UserIDs? If you are on Unix, try echo $CLASSPATH | tr ":" "\n" ...from each user's command line and compare. There are generally two types of problems that manifest themselves differently under different users - security, which you covered, and environment. Incidentally, you did not mention whether you gave the user Inquire on the QMgr and queues. JMS will inquire the QMgr right after connecting. This usually generates 2035's though. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 11:48 AM To: [EMAIL PROTECTED] Subject: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi, first, happy new year to everyone. while trouble-shooting a WAS application's MQRC2102 problem, I wrote a simple jms program to put msg to a queue. The program runs without problem if I start it as "mqm", but if I logon as a different user than mqm, got the same MQJE001, MQRC 2102 exception. I explicitely allowed that user the right to connect to the same qmgr and put/get to the queues, and run the sample executible amqsput, amqsget without any problem. MQRC 2102 is resource problem, but I don't understand why it happen to WAS users, but not to mqm, and only happens to jms applications. Any idea would be greatly appreciated. Benjamin F. Zhou Messaging & Integration Research & Technology, ITM Mercedes-Benz USA x.2474 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Also, can you run it under a debugger or have it dump some kind of debugging info to determine where it is chewing up memory. bobbee From: "Wyatt, T. Rob" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users Date: Fri, 2 Jan 2004 11:44:31 -0600 Benjamin, Are the classpaths the same between the two UserIDs? If you are on Unix, try echo $CLASSPATH | tr ":" "\n" ...from each user's command line and compare. There are generally two types of problems that manifest themselves differently under different users - security, which you covered, and environment. Incidentally, you did not mention whether you gave the user Inquire on the QMgr and queues. JMS will inquire the QMgr right after connecting. This usually generates 2035's though. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 11:48 AM To: [EMAIL PROTECTED] Subject: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi, first, happy new year to everyone. while trouble-shooting a WAS application's MQRC2102 problem, I wrote a simple jms program to put msg to a queue. The program runs without problem if I start it as "mqm", but if I logon as a different user than mqm, got the same MQJE001, MQRC 2102 exception. I explicitely allowed that user the right to connect to the same qmgr and put/get to the queues, and run the sample executible amqsput, amqsget without any problem. MQRC 2102 is resource problem, but I don't understand why it happen to WAS users, but not to mqm, and only happens to jms applications. Any idea would be greatly appreciated. Benjamin F. Zhou Messaging & Integration Research & Technology, ITM Mercedes-Benz USA x.2474 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Enjoy a special introductory offer for dial-up Internet access limited time only! http://join.msn.com/?page=dept/dialup Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Benjamin, Are the classpaths the same between the two UserIDs? If you are on Unix, try echo $CLASSPATH | tr ":" "\n" ...from each user's command line and compare. There are generally two types of problems that manifest themselves differently under different users - security, which you covered, and environment. Incidentally, you did not mention whether you gave the user Inquire on the QMgr and queues. JMS will inquire the QMgr right after connecting. This usually generates 2035's though. -- T.Rob -Original Message- From: Benjamin F. Zhou [mailto:[EMAIL PROTECTED] Sent: Friday, January 02, 2004 11:48 AM To: [EMAIL PROTECTED] Subject: Puzzled: MQJE001, MQRC 2102 for non-mqm users Hi, first, happy new year to everyone. while trouble-shooting a WAS application's MQRC2102 problem, I wrote a simple jms program to put msg to a queue. The program runs without problem if I start it as "mqm", but if I logon as a different user than mqm, got the same MQJE001, MQRC 2102 exception. I explicitely allowed that user the right to connect to the same qmgr and put/get to the queues, and run the sample executible amqsput, amqsget without any problem. MQRC 2102 is resource problem, but I don't understand why it happen to WAS users, but not to mqm, and only happens to jms applications. Any idea would be greatly appreciated. Benjamin F. Zhou Messaging & Integration Research & Technology, ITM Mercedes-Benz USA x.2474 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Puzzled: MQJE001, MQRC 2102 for non-mqm users
Maybe it's your profile for the userid and how it allocates it's resources. One of the developers had an issue here giving the same error (after a volume test) they increased the storage requirements for the JVM and it ran OK after that. Compare the profile of mqm with your user Id. I don't know if this is true BUT maybe ther is also a group profile being executed?? bobbee From: "Benjamin F. Zhou" <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Puzzled: MQJE001, MQRC 2102 for non-mqm users Date: Fri, 2 Jan 2004 11:47:48 -0500 Hi, first, happy new year to everyone. while trouble-shooting a WAS application's MQRC2102 problem, I wrote a simple jms program to put msg to a queue. The program runs without problem if I start it as "mqm", but if I logon as a different user than mqm, got the same MQJE001, MQRC 2102 exception. I explicitely allowed that user the right to connect to the same qmgr and put/get to the queues, and run the sample executible amqsput, amqsget without any problem. MQRC 2102 is resource problem, but I don't understand why it happen to WAS users, but not to mqm, and only happens to jms applications. Any idea would be greatly appreciated. Benjamin F. Zhou Messaging & Integration Research & Technology, ITM Mercedes-Benz USA x.2474 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ Check your PC for viruses with the FREE McAfee online computer scan. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Puzzled: MQJE001, MQRC 2102 for non-mqm users
Hi, first, happy new year to everyone. while trouble-shooting a WAS application's MQRC2102 problem, I wrote a simple jms program to put msg to a queue. The program runs without problem if I start it as "mqm", but if I logon as a different user than mqm, got the same MQJE001, MQRC 2102 exception. I explicitely allowed that user the right to connect to the same qmgr and put/get to the queues, and run the sample executible amqsput, amqsget without any problem. MQRC 2102 is resource problem, but I don't understand why it happen to WAS users, but not to mqm, and only happens to jms applications. Any idea would be greatly appreciated. Benjamin F. Zhou Messaging & Integration Research & Technology, ITM Mercedes-Benz USA x.2474 Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
