RACF Users' News # 43

December, 1997 Newsletter

Issue No. 43

RACF is a trademark of IBM. This newsletter is not affiliated with IBM in any way.


Learn What Other Shops Found Out With the Password Cracker Program

Many of us have used the free password cracker program (which guesses RACF and ACF2 passwords, and tells us which ones are correct guesses). [See page 8 for how to get your free copy; Please note that E-mail is a much better way to ask for it!]. Many of us apparently have found that a large number of passwords in our shops are guessable. (The record I've heard so far is 50 percent of the passwords in one shop, and, no, I won't tell you where. The "50 percent" is interesting; where it happened is confidential.)

Kurt Meiser of ITSS, the author of the program, is offering to compile user experiences and to share them with us, while maintaining complete confidentiality. You can tell him what you've learned, what passwords worked and didn't work in your shop, and what percent of passwords you were able to guess in your shop.

Kurt will keep it all confidential, but will combine it with others to make a presentation to RACF user groups. Let him know at kmeiser@ibm.net, or if you're not on the net, mail to: ITTS, 11 Phillips Rd, Poughkeepsie, NY 12603 USA. Thanks for sharing.

RACF Release Cycle Revealed

We can expect a new release each Spring and Fall. Some RUGs are interested in teleconferencing with IBM to get details of new releases from developers rather than from marketing people. If your RUG is interested, let your IBM rep know, or give Stu a call. Also ask your local IBM rep if he or she will host your next meeting at their teleconferencing facilities.

NEW YORK RUG Meeting Date for January (REVISED)

On Wednesdays, from 1 to 5 PM: Jan. 28, 1998; and April 22, 1998. Mark your calendars now. On January 28: Dan Tum Suden of IBM will describe IBM's new tool for single signon: GSO. He will also describe the new mainframe firewall which you get for free with RACF when you get the OS/390 Security Server). PLUS: If you have questions about RACF and CICS, a panel of knowledgeable speicalists will be there to answer them in our dedicate RACF/CICS QandA! We will have a Q&A session for other topics separately. Directions to the NYRUG Jan. meeting: IBM in Manhattan, 590 Madison Ave., Room 610. (The cross street is about 56th or 57th.)

BALTIMORE/WASHINGTON RUG Meeting Date for January On Thurdays, from 9AM to Noon: No meeting in January, 1998; but then April 23, 1998. Mark your calendars now.


Corrected Contact for TAMPA RUG

Jim Cuddy is making it happen. For more info, to join, or to volunteer to help, call Jim at (800) 237-8931 Ext. 78192.

Carolinas RUG Continues

Bill Sharber of First Citizens Bank is the new head. Contact him for more info at (919) 779-8148.

Jacksonville RUG Comes Alive

Tommy Shelton of Barnett Banks is taking the lead. Call him at (904) 987-7635 to take part.

RACF/DB2 Exit Details

IBM's offers a new exit from DB2 to let RACF control DB2 security (as opposed to DB2's internal security, which is based on the GRANT and REVOKE commands and the Seven Security Tables in DB2's catalog). The name of the exit is DSNX@XAC. It gets control from DB2 at three different times: DB2 system start-up, DB2 system shut-down, and whenever DB2's internal security is normally called.

The exit can be tailored, based on its return codes to DB2. One return code value tells DB2 to allow the access; another says to fail it; a third tells DB2 to use its internal security as if the exit hadn't been called at all. This lets you phase in use of the exit gradually. You can do this by setting it up to allow or fail based on RACF if there is a matching RACF rule. Set it up so that if there is no matching RACF rule, it gives a return code to tell DB2 to use the old, internal security.

The names of the RACF resource classes come in two flavors: the standard names and the tailored names (much like using TCICSTRN in some CICS regions, but some other class name like T$PRDTRN in other regions). The names of the rules are different, depending upon whether you use the standard class names or the tailored class names. Whichever you use (and you can use both), you will need to know the names of the DB2 subsystems.

To Learn the Names of the DB2 SubSystems, look in SYS1.PARMLIB for members with names starting with IEFSSN. Each DB2 subsystem will be defined in one of these members with a line containing ,DSN3INI, Just to the left of ",DSN3INI," will be a name of up to four characters. This is the subsystem name. For example, it might be DB2T for the test DB2 subsystem, and DB2P for the production DB2. You would see these names in lines starting like this:


These are the same subsystem names you use in the DSNR resource class.

The Standard Class Names all begin with MDSN, followed by two characters describing what they protect: MDSNBP for bufferpools, MDSNCL for collections, MDSNDB for databases, MDSNPK for packages, MDSNPN for plans, MDSNSG for storage groups, MDSNSM for subsystems, MDSNTB for tables, and MDSNTS for tablespaces.

Each of these has a grouped version, similar to the way TCICSTRN has GCICSTRN.

When you use the standard class names, you put the subsystem name as the first part of each rule's name. For example, in the class MDSNTB, you might have two rules names DB2T.**, and DB2P.**.

The Tailored Class Names all begin with the letter M, followed by the subsystem name, followed by the two characters described above for standard class names, followed by a special character (such as # or $). For example, the class names for tables might be: MDB2TTB$ in for the test subsystem and MDB2PTB$ in the production subsystem.

Each of these has a grouped versions, similar to the way TCICSTRN has GCICSTRN. With the tailored names, your sysprog must define the names in two places (the SAF router table and the RACF class descriptor table) before you can use them.

When you use the tailored class names, you do not put include the subsystem name in the name of the rule. This is because with tailored class names, the subsystem is already included in the name of the class.

When Your DBA Learns That You Can Protect Several Similarly Named Tables With a Single Rule (ending in an *), he or she will be sooo jealous. They might even change the way they name things.

Password History Change Improvement

Before RACF release 4, when you changed someone else's password, the old password was not stored in the user record, to prevent it from being re-used. As of RACF release 4, IBM has improved this by putting the old password into the password history of the user record whether you change the password for someone else, or whether you change your own password.

HG Sponsors New Web Site to Share InfoSecInfo

The Henderson Group's new web site (at http://www.stuhenderson.com) provides articles on computer security, back issues of the RACF Users News, hot links to other sites, information on RACF user groups, and other info on infosec. If you have information you'd like to make available to others (with credit to you), contact Stu at (301) 229-7187 or email him at stu@www.stuhenderson.com.


CICS release 4 uses the SURROGAT class for some special purposes. You will want to know how to define these rules before they are needed. In general, CICS 4 insists that everything which goes on in a region must have a RACF userid associated with it. (Note for example, the use of preset terminal security to associate a userid with a terminal definition. Note also the use of the default userid specified in the DFHSIT [or SIT] macro.)

A second operand in the DFHSIT macro determines whether CICS makes SURROGAT class checks. If the CICS system programmer specified a SIT with XUSER=YES, then CICS does RACF SURROGAT checking.

CICS makes these checks to determine whether the CICS region's userid should be permitted to use the:

How to Control Use of the APPCLU Resource Class with CICS

This class is used with APPC to prove that the other end of the communication session is with who you think it is. This is easier to understand when you think of making a phone call. The phone number you dial is comparable to the LU or logical unit that APPC uses to make a connection. Your VTAM system programmer assigns the LUs, the same way (almost) that your phone company assigns your home a telephone number.

To make sure that APPC is connecting to the right LU, it can use the APPCLU resource class in RACF. The records in this class contain encryption keys. APPC at one location takes a random number, encrypts it with the key from APPCLU, and sends it to the other APPC location. The second location gets the same key from his RACF database, decrypts the random number, and re-encrypts it with a second key (which is also obtained from the APPCLU records in the RACF database). The second location now sends the re-encrypted random number back to the first location, which decrypts it (you guessed it, using the second key which he gets from the APPCLU records in his RACF database). If the result is the same as the random number he started out with, he says to himself "That must be location x (or whatever the other LU is) because only location x knows both of those encryption keys!".

Very few shops use this class.

If you choose not to use it too, this should be the result of a sensible risk assessment, not because the APPC people don't know your name.

To turn off use of this class in a CICS region, specify XAPPC=NO in the DFHSIT macro for the region.

Use of this class outside of CICS is primarily with APPC/MVS, which we may cover in a future issue.

Fifteen Minute Project to Improve Your RACF

Try these SETR rules, which are all safe (with exceptions noted) and which can get your shop ready for various RACF improvements and/or keep auditors off your back:

If you aren't familiar with any of these operands, or why they might help you, why not take a minute to look them up?

Interesting Products Column

We have not evaluated these, but think every RACF shop should know about them.

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)  
                        Feb. 23-27, 1998 in Clearwater, FL
                        May 4-8, 1998 in Atlanta
                        Sept. 21-25, 1998 in NYC
                        Nov. 16-20, 1998 in Washington, DC

  2)        HG05 (formerly HG44) Advanced RACF Administration  ($850)     
                        March 2-3, 1998 in Clearwater, FL
                        April 20-21, 1998 in NYC
                        Dec. 10-11, 1998 in Washington, DC

  3)        HG17 How to Be an Effective Mainframe Data Security Officer) 
            (covers CICS, VTAM, DB2, JES, and other security along with MVS 
            security, SAF, and OS/390) 
            (3 days in 1998 for $1150)
                        Mar. 30-Apl 1, 1998 in Denver, CO
                        May 27-29, 1998 in NYC
                        Dec. 7-9, 1998 in Washington, DC

  4)        HG40 Mastering Windows NT Security ($850)  
                        April 6-7, 1998 in Atlanta
                        Oct. 19-20, 1998 in Washington, DC

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@uga.cc.uga.edu or LISTSERV@UGA.BITNET.

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:

Georgia RUG home page on the Internet

IBM RACF home page:

IBM S/390 home page, including RACF:

IBM FTP site, including RACF stuff:

IBMLink at: http://www.ibmlink.com

Palace Guard:




the Henderson Group: