Simple RACF Question - Can the RACF database be shared with z/OS?
Happy New Year folks - I need a sanity-check, please ... 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 RAC F database between a z/VM system and a z/OS system. I'm sure that this bel ief 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 ... On page 4 of SC24-6149-01 it unequivocally states that (subject to a numb er of caveats such as needing to reside on full-pack minidisks) the database CAN be shared. Hmm - can anyone who's actually current on RACF (rather than simply a book-learner such as myself) please help me out with an indication of today's thinking as far as the sharing of a RACF database is concerned. (This is specifically sharing with z/OS.) (I see possible responses ranging from, Don't even THINK about it! through, It's possible but only a masochist would do it and, It can be done but there are restrictions up to, It's a breeze - just follow the rules.) In the hope that I'm not stirring up a hornet's-nest and with thanks in anticipation. Jeff Gribbin
Re: Simple RACF Question - Can the RACF database be shared with z/OS?
Jeff, We used to do this until recently, it worked well and we would be still if someone had not done a silly that would have caused too much effort to resolve. When you are running stable versions of RACF on both Z/OS and Z/VM then there is no issue. The thing that you have to be aware of is that the database has to be updated to the level of the highest level of RACF using the database. Up until recent years it was always Z/OS that was ahead so they always applied the RACF version updates but, with Z/VM 5.4, this was ahead of the RACF server on Z/OS so we had to do the database update. What happened to us is that the Z/OS folks came to upgrade to 1.7 and applied their RACF database updates (because they always had and they didn't need to coordinate). This, in fact, downgraded the RACF database and caused some pointer corruption. Their reaction was, of course, that we had corrupted their database and that we should get off it and sort out the corruption that we had caused. That is the only gotcha I know about. Colin Allinson VM Systems Support Amadeus Data Processing GmbH
Re: Simple RACF Question - Can the RACF database be shared with z/OS?
Jeff, The last time I read about, all RACF documents says that it is possible. But, only when the zOS doesn't work in Sysplex. This restriction killed my chances to do tests... __ Clovis From: Jeff Gribbin jeff.grib...@gmail.com To: IBMVM@LISTSERV.UARK.EDU Date: 05/01/2011 10:12 Subject: Simple RACF Question - Can the RACF database be shared with z/OS? Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Happy New Year folks - I need a sanity-check, please ... 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 RAC F database between a z/VM system and a z/OS system. I'm sure that this bel ief 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 ... On page 4 of SC24-6149-01 it unequivocally states that (subject to a numb er of caveats such as needing to reside on full-pack minidisks) the database CAN be shared. Hmm - can anyone who's actually current on RACF (rather than simply a book-learner such as myself) please help me out with an indication of today's thinking as far as the sharing of a RACF database is concerned. (This is specifically sharing with z/OS.) (I see possible responses ranging from, Don't even THINK about it! through, It's possible but only a masochist would do it and, It can be done but there are restrictions up to, It's a breeze - just follow the rules.) In the hope that I'm not stirring up a hornet's-nest and with thanks in anticipation. Jeff Gribbin
Re: Simple RACF Question - Can the RACF database be shared with z/OS?
gclo...@br.ibm.com wrote :- Jeff, The last time I read about, all RACF documents says that it is possible. But, only when the zOS doesn't work in Sysplex. This restriction killed my chances to do tests... Clovis We were successfully sharing with a Z/OS sysplex so this is not an absolute restriction. However, like other volumes that we still share with them, (CA1 catalog etc.), I think they have to set some definition so that physical reserve/release is recognised for that volume. I cannot ask them because we no longer have any Z/OS sysprogs on site. Colin Allinson VM Systems Support Amadeus Data Processing GmbH
Re: Simple RACF Question - Can the RACF database be shared with z/OS?
On Wednesday, 01/05/2011 at 07:12 EST, Jeff Gribbin jeff.grib...@gmail.com 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 alan_altm...@us.ibm.com IBM Endicott
Re: Simple RACF Question - Can the RACF database be shared with z/OS?
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: james.ol...@dom.com -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Wednesday, January 05, 2011 9:14 AM To: IBMVM@LISTSERV.UARK.EDU 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 jeff.grib...@gmail.com 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 alan_altm...@us.ibm.com 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.
Re: Simple RACF Question - Can the RACF database be shared with z/OS?
Alan Altmark alan_altm...@us.ibm.com wrote:- I am the one who has suggested publicly that just because you *can* share, it does not follow that you *should* share. I fully understand and respect Alan's views on the Con's of sharing RACF databases - but there are some Pro's as well. One of the biggest issues we faced when the RACF databases were split and we stopped sharing was that of user currency and cleanup. Users have a defined userid in the organisation (the same on Z/OS and Z/VM). It is a, (quite sensible), auditing requirement that, after a period of inactivity, we revoke userids and then, after a further inactive period, we delete them. We have users that never log on to TSO but who do submit jobs from VM. If they don't submit jobs to z/OS for a while then their z/OS account no longer has any idea that they are still active users and they get deleted. Colin Allinson VM Systems Support Amadeus Data Processing GmbH
Re: Simple RACF Question - Can the RACF database be shared with z/OS?
Thankyou Alan - that succinctly lifts my understanding to the level of, It's physically possible but really, really inadvisable because ... followed by exactly the concerns that I would have felt compelled to raise here had the consensus been that it really was as easy as the manual appears to suggest. I instinctively feel that the, 'right' way to do shared security is via a single logical server that is consulted and which pronounces on all access requests that arise within its domain of influence - in other words, within z/VM, an ESM that acts as a channel between CP and the True Lord of Security, simply passing requests in one direction and decisions in the other direction. Shared datasets were good in their day, but that day has now passed. Many thanks to all for the excellent responses - I am now content that, when asked, I can honestly deliver an accurate picture of RACF's capabilities and limitations in this area. Cheers folks. Jeff :-)
