I'd like to see all but one delivered userid be NOLOG, AUTOONLY, or 
LBYONLY and a LOGONBY statement in the directory PROFILE(s) of the LOGONB
Y 
users.  The LOGONBY statement(s) would all list the single userid (eg. 

INSTALL) deliverd with a password.  That INSTALL userid should get delete
d 
sometime during the installation process and replaced with customer 
defined userids.  Since it's only purpose is to allow logging on to the 

LOGONBY userids, the INSTALL userid needs no MDISKS and only the absolute
 
bare minimum of statements required to define a userid.

The customer can update the LOGONBYs and PROFILEs as needed to fit their 

requirements.  Showing an auditor that the INSTALL userid and references 

to it have been deleted should go a long way.

Brian Nielsen


On Tue, 9 Oct 2007 10:48:56 -0400, Alan Altmark <[EMAIL PROTECTED]>
 
wrote:

>On Tuesday, 10/09/2007 at 10:01 EDT, Thomas Kern <[EMAIL PROTECTED]>

>wrote:
>> I would like it to go a step further, like with some linux installatio
ns
>> that ask for a root password and another userid to be added. I like
>> having ALL system related userids be AUTOONLY, LBYONLY, NOLOG or have 
a
>> randomly generated password. All userids that need to actually need to

>> be logged onto must have a LOGONBY record authorizing that initial
>> sysprog userid. After that initial setup, it isn't hard to replace the

>> passwords for those users that need to logged on. No one ever really
>> needs the password to those accounts if properly LOGONBY authorized.
>> That random password could be randomized daily, until you can properly

>> divide all accounts into the proper AUTOONLY, LBYONLY, NOLOG or person
al
>> password categories.
>
>Understand that if we were to go this way, the Old School "let the
>customer decide" wouldn't be there.  So I would ask that those who would

>object to such a change to speak up.
>
>The only thing that holds the directory in its current state is inertia.

>With a sufficiently large outside force, its direction can be changed.
>
>Alan Altmark
>z/VM Development
>IBM Endicott
>========================
=========================
========================

Reply via email to