Re: Security Exit point monitoring

Hi John and Charles

That was mostly my question (more in hope than expectation) so thanks
for the answer. It was pretty much as I expected but I had a client
that wanted to know.

Rob to answer your question the guys I am talking to know they have a
lot of users that use the Excel plug-in and they quite sensibly want
to protect themselves against their excel users updating the database.
At the same time they don't want to break their other ODBC
applications (you might be surprised how many of these exist outside
in the real world). Like a lot of places they don't have a complete
and accurate list of the profiles and other identifying features that
these things use so they asked if there was another way to avoid the
effort that might be required.


On Fri, May 28, 2010 at 12:56 AM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

On Thu, May 27, 2010 at 6:08 AM, John Earl <john.earl@xxxxxxxxxxxxxx> wrote:

If I understand your question correctly, then the answer is,
unfortunately, no.  There is no way for the IBM i side Exit Program to
know anything about which client side program initiated a remote SQL
access attempt.  The i side just knows that it received a remote SQL
request, it can see the SQL string along with some basic identifying
information about he job on the i (User name, etc.).  The i side exit
program can also find other information on the i about the job such as
IP address, group profile membership, LMTCPB status, etc, but there is
nothing in the data string passed that would identify any information
about the client side program that launched the request in the first
place.

Actually, that's not quite true anymore...

With 6.1, IBM added some special registers,:
CURRENT CLIENT_ACCTNG
CURRENT CLIENT_APPLNAME
CURRENT CLIENT_PROGRAMID
CURRENT CLIENT_USERID
CURRENT CLIENT_WRKSTNNAME


Granted you have to modify your client applications to pass the values
along, but you could do so then restrict the activities allowed by
connections, such as those from Excel, that have blanks for the
current values.

Charles
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.