× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Not so fast!

Good ol' What's-His-Name, formerly of IBM, would disagree (and I do, too).

W-H-N has a video (from Midrange mag??) WAYNE EVANS!!  (brain's got lousy
retrieval time) Wayne recommends using AS/400 security on the objects to
control access.  And points out several loopholes in the exit program
strategy.

I don't remember the problems with exit points (other than finding them
all), but the security strategy is (basically):

        - All objects (files and programs) owned by an OBJOWNER profile.

        - All files have OBJOWNER *ALL (or *CHANGE) authority
        - All files have QUSER *EXCLUDE authority

        - All users sign on as QUSER-level

        - All programs Adopt OBJOWNER authority (USRPRF(*OWNER))

        - All users granted *USE rights to the programs, not the files!

        - *PUBLIC authority *EXCLUDE (to prevent PCs from reading your files)
        - *PUBLIC authority *USE (if you don't mind PCs copying your files
from 400 to PC)

(I hope I didn't leave anything out...)

This scheme does the following:  QUSER-level users can not change your
files.  Ever.  ODBC will not be able to change anything on the 400.  You
have to grant QUSER *CHANGE rights to each and every file you want them to
be able to change (use an authorization list!).

QUSERs can change your files by using your programs.  IE they sign on and
their initial program points them to a menu, which they can use because
they have *USE rights to the program.  The program, owned by OBJOWNER and
adopting OBJOWNER authority, can update the files.

There are more details, but this covers the basics.

--Paul E Musselman
PAulMmn@ix.netcom.com





>Gary,
>
>The most effective way to prevent ODBC access to AS/400 data is to write
>or buy
>Exit Programs that monitor your network interfaces.  By setting Exit Points at
>the network entrance to your system, you can block and/or regulate ODBC, File
>Transfer (including FTP) and Remote Command request that are sent it's
>way.  The
>IBM manual "Client Access/400 for DOS and OS/2 Technical Reference V3R1"
>explains
>how to write exit programs, or you take a look at our offering at
>www.400security.com .
>
>John Earl   johnearl@toolnet.com
>
>>Gary Munroe wrote:
>
>> We are just in the process of setting up ODBC to our AS/400 (v3r2) and
>> looking at security.  Specifically, how we could set it up so that people
>> that currently have a signon to the AS/400 could be prevented from
>>connecting
>> via ODBC.  Any additional information on ODBC security (other than standard
>> AS/400 file security) would be helpful too.
>>
>> Thanks.
>> | Gary Munroe                                                      |


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.