I have my 'starter system' available until I am in production on the
next level of VM. I use the 'starter system' as my maintenance/test
system. As for other system that may or may not work the same way, I
have installed TurboLinux, RHEL, and SLES on mainframe systems with
corresponding levels on x86. None of those systems had default passwords
for default userids. And that linux on x86 environment is where the
auditors and cyber/network security people come from. I don't think I
have never met a mainframer who was actually accepted as an auditor or
cyber/network security person.
What really triggered my interest in this, is spending a good portion of
this morning customizing the user directory and DIRMAINT on my new 5.3
system that I am installing via multiple layers of network encrypted
slowness. I was tired of having to do this every time I install a system
(4.1, 4.2, 4.3 ,4.4, 5.1, 5.2, 5.3, etc) and realizing that the
newbies out there who are trying to juggle their original z/OS systems
with the new z/VM and linux systems might not get this step complete
before their auditors and security people give them grief about it.
Stracka, James (GTI) wrote:
Once a year
-----Original Message-----
*From:* The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] *On Behalf Of *Huegel, Thomas
*Sent:* Tuesday, October 09, 2007 2:50 PM
*To:* IBMVM@LISTSERV.UARK.EDU
*Subject:* Re: Initial User Directory
Why are we trying to fix something that isn't really broken?
How often do we install a new system once every 2-3 years? And how
long does the install system live before going production, a few
weeks? What can be hacked on the install system?
Don't other systems/products work the same way? ICCF TSO have
default passwords that need to be changed ??
I still think it is just a learning curve.
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Brian Nielsen
Sent: Tuesday, October 09, 2007 1:00 PM
To: IBMVM@LISTSERV.UARK.EDU
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
LOGONBY
users. The LOGONBY statement(s) would all list the single userid (eg.
INSTALL) deliverd with a password. That INSTALL userid should get
deleted
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
installations
>> 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
personal
>> 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
>=========================================================================
__________________________________________________________________
<< ella for Spam Control >> has removed VSE-List messages and set
aside VM-List for me
You can use it too - and it's FREE! http://www.ellaforspam.com
------------------------------------------------------------------------
This message w/attachments (message) may be privileged, confidential or
proprietary, and if you are not an intended recipient, please notify the
sender, do not use or share it and delete it. Unless specifically
indicated, this message is not an offer to sell or a solicitation of any
investment products or other financial product or service, an official
confirmation of any transaction, or an official statement of Merrill
Lynch. Subject to applicable law, Merrill Lynch may monitor, review and
retain e-communications (EC) traveling through its networks/systems. The
laws of the country of each sender/recipient may impact the handling of
EC, and EC may be archived, supervised and produced in countries other
than the country in which you are located. This message cannot be
guaranteed to be secure or error-free. This message is subject to terms
available at the following link:
http://www.ml.com/e-communications_terms/. By messaging with Merrill
Lynch you consent to the foregoing.
------------------------------------------------------------------------
