So when all's said and done:
user1 has the mcauser = user1
user2 has the mcauser = user2
...
userb has the mcauser = userb
userc has the mcauser = userc
Which is the standard behavior when MCAUSER is blank. You only need 1
SVRCONN and no exits.
Regards,
Dennis
-----Original Message-----
From: Ruzi R [mailto:[EMAIL PROTECTED]
Sent: Monday, March 15, 2004 1:07 PM
To: [EMAIL PROTECTED]
Subject: Re: Many Client connections - how many svrconn channels?
> From what I can tell, both kinds of users can still
> connect. And once
> connected, either kind of user can do exactly the
> same things as had
> they connected on the other SVRCONN. The only thing
> you've done is
> added front-end complexity for choosing the right
> SVRCONN.
For example:
Svrconn123 on QM1 is limited to user1, user2 and user3
with MCAUSER blank.
SvrconnABC on QM1 is limited to userA, userB and userC
with MCAUSER blank.
BlockIP2 will prevent anyone from accessing QM1 via
Svrconn123 other than user1, user2 and user3. So the
MCAUSER will be populated by one of these userids.
Similarly SvrconnABC would be available only to userA,
userB and userC. This is my understanding of how I can
make use of BlockIP2. Of course I cannot prevent
anyone from impersonating one of the userids. I could
use the one of the valid userids in MCAUSER. Or create
a specific userid to put in MCAUSER having the same
level of privilages as the others (e.g. user1, 2 and
3). But I fail to see the reason for it since BlockIP2
will only let the userids I specify have access to QM1
via the security exit. Am I missing something?
I said:
>>>I have set up 10-15 users with a dedicated
>>>SVRCONN
>>> channels with the MCUSER set to their respective
>>> userids and giving each userid a limited
>>>accesss.
You said:
>Why the dedicated SVRCONN's? You get exactly the
>same security with one
>SVRCONN where MCAUSER is blank.
>
> I'm confused.
Using separate svrconn channels with MCAUSER set to an
ID with limited access is one of the things that can
be done to prevent unauthorized access. And this is
highly recommended on this list. Because leaving the
MCAUSER blank creates a security exposure
--apparently, it is very easy for a client to present
mqm userid to the svrconn channel-- which is done in
the application code like Java... (Of course you would
need SSL as well to really secure the channel). For
this reason, I think it is best to have a dedicated
svrconn for each client connection with MCAUSER set to
their id having limited access.
Ruzi
--- "Miller, Dennis" <[EMAIL PROTECTED]> wrote:
> Maybe I'm misunderstaning your goal, but I don't see
> what BLOCKIP2
> accomplishes if you leave MCAUSER blank. Suppose you
> want two levels of
> access: limited and unlimited. So you set up an
> SVRCONN for each,
> leaving MCAUSER blank on both. Then, you block
> limited users (or IP
> addresses) from one of the SVRCONNs. So what? As
> far as security is
> concerned, both SVRCONNs are identical.
>
> From what I can tell, both kinds of users can still
> connect. And once
> connected, either kind of user can do exactly the
> same things as had
> they connected on the other SVRCONN. The only thing
> you've done is
> added front-end complexity for choosing the right
> SVRCONN.
>
> Let's stand back and look at your original
> statement:
>
> > > I have set up 10-15 users with a dedicated
> SVRCONN
> > > channels with the MCUSER set to their respective
> > > userids and giving each userid a limited access.
>
>
> Why the dedicated SVRCONN's? You get exactly the
> same security with one
> SVRCONN where MCAUSER is blank.
>
> I'm confused.
>
>
>
> -----Original Message-----
> From: Ruzi R [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 12, 2004 6:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Many Client connections - how many
> svrconn channels?
>
>
> > But if you've got relatively few access levels,
> you
> > can define a svrconn
> > with appropriate MCAUSER for each and then
> restrict
> > which users are
> > permitted to use which connections from the exit.
>
> Thanks Dennis. However, I think it would be safe and
> maybe better to leave MCAUSER blank. Because
> BLOCKIP2 will allow only the users (and IP
> addresses)
> in the security exit file anyway. This would come in
> handy during a problem investigation -- for example,
> things like inquiring the status of the svrconn
> channel or the userid of the message on the queue
> etc. would indicate the actual user rather than the
> group userid.
>
> Ruzi
> --- "Miller, Dennis" <[EMAIL PROTECTED]> wrote:
> > I took a look at the BLOCKIP2 URL provided by SID.
> > Very neat. I did
> > notice that BLOCKIP2 only supports setting the
> > MCAUSER on SSL channels.
> > But if you've got relatively few access levels,
> you
> > can define a svrconn
> > with appropriate MCAUSER for each and then
> restrict
> > which users are
> > permitted to use which connections from the exit.
> >
> >
> >
> > -----Original Message-----
> > From: Ruzi R [mailto:[EMAIL PROTECTED]
> > Sent: Friday, March 12, 2004 11:49 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Many Client connections - how many
> > svrconn channels?
> >
> >
> > Dennis,
> >
> > BlockIP2 is the latest version of BlockIP. It is a
> > secrity exit program. I don't have the link on the
> > computer that I am using right now. Maybe, someone
> > on
> > the list will post it. It basically lets you
> > specify
> > the "userids and the IP addresses" from which the
> > client connections will be made.
> >
> > Most (if not all) of these clients will have the
> > same authority. I am
> > thinking of leaving the MCAUSER blank on an
> svrconn
> > and specify the
> > userids in a file to be used by the security exit.
> I
> > think this would do
> > what I want to acheive. Maybe I could secure this
> > file by giving access
> > only to MQ admins and MUSR_MQADMIN.
> >
> > What would you or or anyone else suggest?
> >
> > Thanks,
> >
> > Ruzi
> >
> >
> > --- "Miller, Dennis" <[EMAIL PROTECTED]> wrote:
> > > I don't see the point of dedicating svrconn's to
> a
> > > specific number of
> > > clients. Dedicating a svrconn a specific
> MCAUSER
> > > and sharing it among
> > > many clients is a different story. Seems you
> > would
> > > only need one
> > > MCAUSER+srvrconn for each authority level.
> > >
> > > But to gain a semblence of security from either
> of
> > > those schemes, you
> > > still need to control client access to the
> > > srvrcon's. Not sure how you
> > > accomplish that. Unfortunately, I do not know
> > what
> > > BlockIP2 is
> > > about(and neither does Google).
> > >
> > > -----Original Message-----
> > > From: Ruzi R [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, March 11, 2004 12:35 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Many Client connections - how many
> > svrconn
> > > channels?
> > >
> > >
> > > Hi all,
> > >
> > > We have over 200 users requiring client
> connection
> > > from their Windows2000 workstations to the queue
> > > managers on Windows 2000 (WMQ 5.3). The company
> > does
> > > not have and is unwilling to buy any third
> > product
> > > right now or in the foreseeable future.
> > >
> > > I have set up 10-15 users with a dedicated
> SVRCONN
> > > channels with the MCUSER set to their respective
> > > userids and giving each userid a limited access.
> > I
> > > have started using BlockIP2 as well. I have
> > brought
> > > up the use of SSL but the company is reluctant
> to
> > > do
> > > that (I don t know about all the concerns
> > > surrounding
> > > the issue probably something political that I
> > don
> > > t
> > > get involved in as a contractor).
> > >
> > > Because I want to make the client connections as
> > > secure as possible with what I have at my
> > disposal,
> > > I
> > > feel that I should set up the rest of the 200
> > > clients
> > > (most of whom will be in the Prod env.) the
> same
> > > way
> > > as the others: Dedicated svrconn channel with
> > > MCAUSER
> > > populated with a userid having limited access,
> and IPBlock2. But
> > > then again, since all of the interfaces
> > > are internal, maybe I could dedicate 1 svrconn
> to,
> > > say, 20 people. I can still give limited access
> to
> > > the
> > > users, leave the MCUSER blank and specify the
> > valid
> > > IP addresses in
> > > IPBlock2. What do you think? Any ideas/insights
>
=== message truncated ===
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
