RACF (part of OS/390 Security Server) is a trademark of IBM. This newsletter is not affiliated with IBM in any way.
Why Not Offer to Host a RUG Meeting?
Most RUGs work on a volunteer basis, and a great way to help share info with others is to host a meeting in your area. See Stu's web site http://www.stuhenderson.com/index.html (and the info below) to find the RUG closest to you.
Denver RUG Starting Up Again
Contact Don Huber (303) 893-4701 for more info.
Albany RUG Starting Up
Contact Manny Morales at (518) 285- 2554 for more info.
Sacarmento RUG May Be Starting
Call Remillo DuBose at (916) 558-4184 for more info and to offer to help out.
To Get a Free Subscription to This Newsletter
See last page of this issue under "RACF User Services"
NEW YORK RUG Meeting Dates
On Wednesdays, from 1 to 5 PM: on July 14, 1999. Mark your calendars now. See inside for details.
BALTIMORE/WASHINGTON RUG
Meeting Dates On Thurdays, from 9AM to Noon: The BWRUG will not meet in July. The next meeting will be in October. Mark your calendars now. See inside for details. -------------------------------------------
Greater St. Louis RUG Meets 3rd
Wednesday of March, June, Sept., and Dec. Contact June Dabbs at (314) 362-0836 for more info. ("Greater" means that you are welcome to come share info if you have ever heard of St. Louis.)
Chicago RUG in Illinois.
Call Patricia Diya of Downers Grove at (630) 810-514 for info on the Chicago RUG.
Other RUGs May Start Soon, Do You Want to Run One?
We have had several requests for someone to run a RUG in Nebraska, Ohio, Southern California, and other sites. If someone local will volunteer to be the contact point for any of these places, we will gladly publish his or her name and phone, so that others can contact directly. (If you aren't able to run a RUG, perhaps you could volunteer to host a meeting?)
Interesting Products Column
We have not evaluated these, but think every RACF shop should know about them.
Our Candidates for RACF Rules of Thumb
Let us know what you think should be added to this list:
Fifteen Minute Project to Improve Your RACF
Activate the UNIXMAP resource class if you are going to assign UIDs to RACF userids. (RACF uses the user record, OMVS segment, to map the RACF userid to the UNIX UID. The UNIXMAP resource class maps in the other direction.) This is a performance improvement for any time OMVS needs to translate a UID to a RACF userid, or a GID to a RACF group name. For example, this is useful in making error messages more clear, and in describing who can access an OMVS file with the ls -l command. If you already have started assigning UIDs and GIDs, IBM gives us a free REXX exec in SYS1.SAMPLIB named IRR39858 to initialize the UNIXMAP rules.
Here's how to turn it on:
SETR GENERIC(UNIXMAP) AUDIT(UNIXMAP) CLASSACT(UNIXMAP)
You don't have to define the rules for this class. Either run the REXX exec or activate the class before you start assigning UIDs and GIDS. After you activate the class, RACF will keep the rules up-to-date automatically.
A Brief How-To on the OPERCMDS Class (How to Save Yourself Some Grief)
We understand from the RACF List Server that the new version of FTP (File Transfer Protocol under TCP/IP) on OS/390 requires you to use the OPERCMDS resource class. Supposedly, FTP doesn't even check to see whether the class is active or not. This would be a large irritation, except that you need to have OPERCMDS protection to have good security anyhow. So if you don't have OPERCMDS active now, take these easy steps to start it up:
1) Understand that operator commands can come into your system from many different sources: operator consoles, batch jobs, TSO users, NJE and RJE connections, and software programs. TSO users who are authorized can issue the CONSOLE command to turn their TSO session into a "virtual console".
Several items control who can issue which operator commands. These controls include:
You will define rules in the OPERPARMS class, and permit users and groups to them. With this class though, some of the userids will be people; some will be consoles; some will be remotes and NJE nodes. You are still just permitting userids to resource rules. The trick (and it's simple) is to define the consoles and so on as userids to RACF.
2) You will want to review how consoles are defined in the CONSOLxx members of SYS1.PARMLIB. Review these with your system programmer, looking for these items:
3) Assuming that you want all the consoles to be automatically logged on with a RACF userid, learn the names of the consoles from the system programmer (in SYS1.PARMLIB(CONSOLxx) and define these names, both as userids and as consoles:
ADDGROUP GRPCONS DATA('GROUP OF ALL CONSOLES') OWNER(SYS1)
ADDUSER consolename DFLTGRP(GRPCONS) OWNER(GRPCONS) ...
RDEF CONSOLE consolename UACC(NONE) OWNER(GPRCONS) ...
and repeat the last two for each consolename.
After this is set up in RACF, invite the system programmer to change the entry in SYS1.PARMLIB(CONSOLxx) to have the consoles logged onto their respective RACF userids automatically. The operand is LOGON(AUTO). Once he does this, each console will automatically be logged on at IPL time with the userid which is spelled the same as the console name.
4) Any console which is not defined in CONSOLxx in SYS1.PARMLIB will be an EMCS console, for example a TSO session which is turned into a console by issuing the TSO command CONSOLE. Only users with an OPERPARM segment and a TSO segment on their userids can do this. They also need READ permission to the CONSOLE rule in the TSOAUTH class. They also need READ authority to an OPERCMDS class rule named MVS.MCSOPER.userid where userid is the userid of the TSO user.
To let a TSO userid GEORGE turn his TSO session into a master console:
AU GEORGE SUPGROUP(...) ... TSO(...) OPERPARM(...)
RDEF OPERCMDS MVS.MCSOPER.GEORGE UACC(NONE) ...
PE MVS.MCSOPER.GEORGE CLASS(OPERCMDS) ID(GEORGE) ACC(READ)
RDEF TSOAUTH CONSOLE UACC(NONE) ...
PE CONSOLE CLASS(TSOAUTH) ACC(READ) ID(GEORGE)
5) Issue SETR GENERIC(OPERCMDS) AUDIT(OPERCMDS) to turn on generics and to cause all rule changes to be logged to SMF. Then issue RL OPERCMDS * ALL to list all currently defined commands. Look at DSMON or SETR LIST to determine whether the OPERCMDS class is ACTIVE.
6) Issue RDEF OPERCMDS ** UACC(ALTER) AUDIT(ALL) to catch any calls not covered by a more specific rule. Start running the RACF report writer or other SMF reporter to catch all rules covered by this and other backstop rules.
7) Rules in the OPERCMDS class all have names beginning with a sub-system name,
so you can issue a rule to cover each of : all MVS commands, all JES commands,
and all RACF commands. Issue these commands to provide more specific
backstop rules:
RDEF OPERCMDS MVS.** UACC(ALTER) AUDIT(ALL)
RDEF OPERCMDS JES2.** UACC(ALTER) AUDIT(ALL) (or JES3 if you are)
RDEF OPERCMDS RACF.** UACC(ALTER) AUDIT(ALL)
8) Meet with your MVS, JES, and RACF system programmers, as well as your lead computer room operators to discuss who should be permitted to issue which operator commands. Refer them to the IBM manual "MVS Planning: Operations", GC28-1760. For JES operator commands, see the JES manual "Initialization and Tuning". Remember that operator commands can be issued from RJE, from NJE, from TSO sessions which are permitted to the CONSOLE rule in the TSOAUTH resource class, and from programs, as well as from consoles in the computer room. Agree on who the "owner" is for OPERCMDS (in the same sense that the head of the Payroll department is the owner of the payroll data) and have that person sign off on the rules. Now if the auditors try to give you grief about OPERCMDS rules, you can point to the sign-off document and respond "I'm just following company policy by carrying out the rules the owner approved. So, go audit that." (Say it with a smile.)
9) Now you define operator commands to RACF and permit the appropriate userids to them. Note that these will not take effect until you activate the OPERCMDS class in step 10 below. For example, all the MVS commands are considered to be grouped into three MCS categories: MASTER (which corresponds to RACF CONTROL permission), ALL(SYS,IO,CONS) (which corresponds to RACF UPDATE permission), and INFO (which corresponds to RACF READ permission). So as a starting point, you might start with these three categories and permit the consoles to them appropriately. Here's one way to do it for the MASTER category:
RDEF OPERCMDS (MVS.CONFIG MVS.CONTROL.M MVS.DUMP +
MVS.FORCE.* MVS.IOACTION MVS.QUIESCE MVS.RESET.CN +
MVS.SETSSI.* MVS.SWITCH.CN.* MVS.TRACE.MT +
MVS.VARYAUTH.CN MVS.VARYAUTH.CONSOLE +
MVS.VARY.GRS MVS.VARY.HARDCPY +
MVS.VARY.MSTCONS MVS.VARYFORCE.DEV +
MVS.VARY.WLM MVS.VARY.XCF) +
DATA('MCS MASTER AUTHORITY COMMAND') UACC(NONE) +
OWNER(GRPCONS)
PERMIT (MVS.CONFIG MVS.CONTROL.M MVS.DUMP +
MVS.FORCE.* MVS.IOACTION MVS.QUIESCE MVS.RESET.CN +
MVS.SETSSI.* MVS.SWITCH.CN.* MVS.TRACE.MT +
MVS.VARYAUTH.CN MVS.VARYAUTH.CONSOLE +
MVS.VARY.GRS MVS.VARY.HARDCPY +
MVS.VARY.MSTCONS MVS.VARYFORCE.DEV +
MVS.VARY.WLM MVS.VARY.XCF) +
ID(GRPCONS) ACCESS(CONTROL)
You will want to cover the other commands, including JES and RACF commands, and permit other users as well. The list is not long, the IBM manuals list the names of all the rules, and your sysprogs and operators will be able to guide you.
10) When you are ready to activate OPERCMDS, issue the following: SETR CLASSACT(OPERCMDS) RACLIST(OPERCMDS) LIST
11) If you are the cautious type, create a batch job with TYPERUN=HOLD on the JOB card to issue the following RACF TSO command in batch, under your userid: SETR NOCLASSACT(OPERCMDS) LIST). This will de-activate the OPERCMDS class, but only when the job is released. Tell the operators not to release the job unless there is RACF trouble with operator commands. Delete the job after a week or so.
13) Stay in touch with George Fogg on the RACF List Server to get answers to any tough questions.
New Features Coming this Fall with RACF 2.8
These new features are said to include:
NYRUG (New York RACF Users Group) and BWRUG (Baltimore/ Washington RUG) NEWS
NYRUG: At Our Next Meeting
Time: Wednesday, July 14, 1999. (Wear some Red White and Blue to celebrate Bastille Day!!) From 1PM until it's too late to go back to the office.
Place: The Bank of New York will host our next meeting. Speakers will include Bob Hansel of RSH Consulting who will speak on tuning RACF for performance. This presentation has been well received at other RUGs. You do not want to miss it. Also, a speaker from Lockstar will describe "What RACF Administrators Must Know and Do About PKI". If you want to be more than a RACF clerk, and you aren't sure what PKI is, then you want to hear this. As always, we will finish with a Q&A session, with answers from some of the top RACF specialists in the state.
==============================================================
BWRUG (Baltimore/Washington RUG):
The BW RUG will not meet in July. See you in October.
Permanently Interesting Products Column
We have not evaluated these, but think every RACF shop should know about them.
HG RACF and Security Training 1998 Schedule:
The Henderson Group offers its RACF and computer security/audit seminars around the country and on-site too. See the details below or call (301) 229-7187 for a free seminar catalog.
1) HG04 Effective RACF Administration (formerly called How to Implement and Administer RACF
Effectively) ($1695)
Sept.27-Oct. 1, 1999 in New York City
Nov. 15-19, 1999 in Washington, DC
Feb. 21-25, 2000 in Clearwater, FL
2) HG05 Advanced RACF Administration ($850)
Sept. 21-22, 1999 in Washington, DC
3) HG17 How to Be an Effective OS/390 (MVS) Data Security Officer) (covers CICS, VTAM, DB2, JES, and
other security along with MVS security, SAF, and OS/390)
($1150)
Oct. 18-20, 1999 in Washington, DC
4) HG40 Mastering Windows NT Security
[This course will expand to 3 days in the second half of 1999.] RACF User Services (Key Phone Numbers / Addresses)
RACF User Services (Newsletter Subscriptions / Key Phone Numbers / Addresses)
RACF List Server on the Internet
To join, send E-mail to the administrator for the server. (Don't send it to the server itself or your request will be routed to every subscriber.) For example, if your name is John Smith and you want to subscribe, then send this E-mail:
subscribe racf-l john smith
to the address: listserv@listserv.uga.edu
The reply will include directions on how to get info such as a list of all subscribers, an index to previous comments, and a command summary.
Other Internet places: