No argument there. In fact, we have more than one system thhat we infrequently run 2nd level, and all could be ipled 1st level if needed in an emergency.
Regards, Richard Schuh ________________________________ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, October 11, 2007 5:31 AM To: [email protected] Subject: Re: Initial User Directory I think it is a *very good* idea to keep a system - whether it's a starter system or whatever - that does not have an ESM and is an "unmodified" system, and isolated from the production system - that can be used as a CYA system if something were to happen and your production system becomes unusable and you can't IPL. The starter system is a very good vehicle for this - since it is typically insulated from the production system. Unless, of course, you use it to build your production system... A system like this can (and does...) save a lot of hearts from stopping when you have that aweful feeling the moment you realize you are in deep doo-doo. "Schuh, Richard" <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System <[email protected]> 10/09/2007 03:56 PM Please respond to The IBM z/VM Operating System <[email protected]> To [email protected] cc Subject Re: Initial User Directory There sure seem to be a lot of auditors who have too much time on their hands. Too many in the legislative branch of government, as well. I have enough to do without having to spend a lot of time doing busy work satisfying rules that make no sense. The way that I see it is that there are two distinctly different purposes that are being discussed as though they were one. There is a starter system that is used to create a production system and there is what some see as a shrink-wrapped, ready to go, production system that is largely a myth (even though some try to use the starter system for this purpose). These two serve different purposes and should be held to different standards. The proposals in this thread do nothing to enhance the security of a production system that has been built without carrying all of the standard ids across from the starter system. Instead, they only create more work that is of very little, if any, benefit. Regards, Richard Schuh -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Brian Nielsen Sent: Tuesday, October 09, 2007 11:00 AM To: [email protected] Subject: Re: Initial User Directory 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 >========================= ========================== ========================
