Just to make a correction to my previous note before
anyone jumps in:

I would want to leave the MCAUSER blank so that
I can tell who put the message onsee whothe message on
the queue. Svrconn does not show the userid but the
connectin name.

Thanks,

Ruzi

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 R <[EMAIL PROTECTED]> wrote:
> > 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 even 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
> > > would be much
> > > appreciated.
> > >
> > > Thanks in advance,
> > >
> > > Ruzi
> > >
> > > 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
>
>

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

Reply via email to