× 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.



Hi Dean,

I am an SSA GT person in house who understands iSeries security (I'm an
ex-IBM Rochester geek in fact, so kinda got to know it a little bit while
working where they invent the box). I also happen to years ago instigate the
fixing of all the problems you are incorrectly complaining about in your
note, and instigated changing our build process so that our new BPCS
releases had the ability to set up this type of database security 'out of
the box'.

Your answer is off-base, considering that we (SSA GT) fully support AS/400
database security (via several BMRs (mainly 51582) which recompiled all our
secured source programs to *OWNER authority checking) for all V6 and higher
releases of BPCS and have done now for years.  The BPCS CD secured objects
will also be recompiled with this new option if a customer will escalate BMR
62812.

I have repeatedly posted  information in detail to this group stating which
BMRs to obtain for older BPCS releases to enable this function (and which
also contain a hefty README. It is easy to secure your BPCS database from
ODBC and any unauthorized user access by applying the security BMRs and
following the README instructions to change some things in your environment.

Please search the BPCS-L ARCHIVES or the SSA GT OGS Online web site BMR
database, and you will find all BMRs required for setting up database
security via use of programs with *OWNER authority and Adopt Authority *YES,
as well as the required programs which access command line functions set to
*USER and *NO, as well as a FULL OGS document stating to users the varied
and sundry options for making this work for them (how to set your files, how
to change the owner from SSA and how to NOT put the SSA Group Profile on
your users profiles if you keep the database owner as SSA). On 6002 and
6004, you may want to look into command line access and escalate BMRs that
were already completed on 6100 and 80 BPCS to secure this better, or if you
have BPCS source, frankly it's pretty easy to do yourself.

Ownership of BPCS objects by user SSA is most certainly NOT and has NOT for
several years now, been a REQUIREMENT on supported release of V6 and higher
BPCS (ie, 6002, 6004, 6100, 8000, 8100) due to these BMRs. New releases (8.0
and up) are SHIPPED with this type of compile option on the program objects
and install instructions contain an appendix explaining the varied options
to set up this optional database security (appendix D, I believe on 8.1).

If you do this to your database, there is no need to mess around with ODBC
checking programs - the AS/400 database security will take care of it for
you.

Thanks,

Genyphyr Novak
SSA GT
----- Original Message -----
From: <DAsmussen@aol.com>
To: <bpcs-l@midrange.com>
Sent: Sunday, February 09, 2003 10:55 PM
Subject: Re: Security in 6.02 and 6.04


> Dear Fmanriq,
>
> I cannot believe that, in all this time, you haven't even received a
"please
> clarify this" question.  For security, you start at the BPCS level
assigning
> people as users and allowing access on a program-by-program basis via
SYS600.
>  Later versions (yours included, I believe) allow function key and action
> code security for a limited number of programs.
>
> The _real_ security starts at the AS/400 (iSeries/400) level, and SSA/GT
does
> not support this because I do not believe that they have a single person
"in
> house" that understands AS/400 security.  However, I have implemented the
> following scenario at a client site without repercussions.  Understand
that
> it helps if you have a development machine to test this on first.
>
> Everything is set to an ownership of "SSA".  This is an SSA requirement,
even
> though object ownership is irrelevant in the overall scheme of AS/400
> security.  All programs and files are set for *PUBLIC to *EXCLUDE.  This
> prevents anonymous FTP and ODBC from accessing critical files.
>
> What, specifically, are you trying to secure?
>
> Regards,
>
> Dean Asmussen
> Enterprise Systems Consulting, Inc.
> Fuquay-Varina, NC  USA
> E-mail:  DAsmussen@aol.com
>
> "There is one difference between the taxidermist and the tax collector --
the
> taxidermist leaves the hide." -- Mortimer Caplin
>
> In a message dated 1/31/03 11:57:53 PM Eastern Standard Time,
> fmanriq@yahoo.com writes:
>
>
> > We have some BPCS instalation in a customer versions
> > 6.02 and 6.04.
> >
> > We need to know which general security issues could we
> > implemented for improve security.
> >
> > How can we improve security by ODBC connection.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.