We do not share a RACF database, but use a copy of the zOS RACF database for our z/VM system. We make all changes thru the zOS system, and copy/replace the z/VM RACF database quarterly or as needed. VM security does not change significantly and the Auditors are happy with this.
============================================= Jim Olson Dominion Resource Services, Inc Senior Software Engineer OSS - Operating System Support Phone: (804) 771-3456, Tie Line: 8-736-3456 Email: [email protected] -----Original Message----- From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Alan Altmark Sent: Wednesday, January 05, 2011 9:14 AM To: [email protected] Subject: Re: Simple RACF Question - Can the RACF database be shared with z/OS? On Wednesday, 01/05/2011 at 07:12 EST, Jeff Gribbin <[email protected]> wrote: > I've not used RACF on VM for a few decades and I believed that, as z/OS > advanced, there came a time when it was no longer possible to share a RACF > database between a z/VM system and a z/OS system. I'm sure that this belief > was based upon statements made by people that I trust, plus my own > understanding of the disparity between RACF development on z/OS and its > development on z/VM, but ... I am the one who has suggested publicly that just because you *can* share, it does not follow that you *should* share. As the documentation says, you CAN share the database with z/OS. However, the database MUST be protected by Reserve/Release. That means that in a SYSPLEX, GRS on z/OS must be configured to allow ENQs issued for the RACF databases to use Reserve. And, for most, that rules out a sysplex, which is taking explicit advantage of GRS rings/stars. As you suggest, RACF/MVS and RACF/VM are different products with different development streams targeted to different audiences, all managed by different organizations. While the two groups are reasonably coupled from a Design point of view (we don't want to step on each others' toes), they march to the beat of different drummers. A few short years ago the VM side accidentally shifted some bytes in a database control field mapping macro, causing classes on z/OS and older versions of RACF/VM to be mysteriously turned off. We found the bug fairly quickly and resolved the issue, but the APAR wasn't pretty, requiring a utility to repair the database. From an admin point of view, some of the commands work differently on z/VM than on z/OS. Example: On z/VM you can define a user with no password and no password phrase, or just a password phrase. You can't do that on z/OS (the same way). From a security point of view, I don't like db sharing outside of a cluster. The local SMF logs do not (cannot) record changes made by other systems, even though they affect the local system. Further, you are giving the "alien" system access to, and control of, secrets it does not need to posses. If the alien system is hacked, the db is exposed. Likewise, if VM is hacked, the z/OS system is vulnerable. (No need to crack a password, just change it.) And because of the logging, you will never know it happened. I'd like to see z/OS and z/VM customers (e.g. via zBLC and Requirements) put pressure both RACFs to bring RRSF to VM or to enhance the LDAP interface so that LDAP replication and/or IBM Tivoli Directory Integrator can be used to propagate profiles and database settings (SETROPTS) among an arbitrary set of RACF instances. A single point of management for RACF (VM+MVS) is a desirable thing - I get it. But sharing the database is a case of the tail wagging the dog. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 [email protected] IBM Endicott CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
