|
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 mailing list archive is Copyright 1997-2025 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.