Adding new userids

The next few sections provide examples of typical processes used when adding, deleting, or administering users. It assumes the use of RACF (which is a component of the OS/390 Security Server), since this is a standard part of the AD CD-ROM system. As with many OS/390 administrative tasks, there are a number of ways to do things. For newer owners, we recommend the following:

򐂰 Use a batch job to define new users.

򐂰 Use TSO RACF commands to alter the RACF profiles of existing users.

򐂰 Use RACF ISPF panels to work with RACF general resource profiles and other more advanced RACF functions.

򐂰 Use TSO RACF commands to manage the more straightforward RACF data set protection profiles that you may define.

These recommendations may be contrary to your experience. In particular, you may prefer to use the RACF ISPF panels for all RACF functions. This is fine if you have the experience to do it; however, many new users find the panels more difficult than the TSO commands. Also, as with many panel and menu interfaces, documentation and examples are more difficult than with command-line interfaces. We think examples of the RACF command-line interfaces are easier to read than examples of RACF panel usage.

Adding a new user usually involves several operations, not all of which involve RACF. The RACF portion can be done with the RACF panels, with TSO commands, or with a batch job that executes TSO commands. We recommend the batch job approach, and that is what is documented here. In particular, we recommend that you set up a batch job that you use

every time you add a new user. This provides a simple, repeatable method that can be used

by anyone (anyone with sufficient RACF authority, that is), with a low error potential. The specific examples here match the AD system. With minor adjustments they should be usable for other systems. Read and understand this entire section before attempting to use this job.

The following is a complete listing of a batch job to add a new user. In this example, ogden is the new userid, and ogden will have access to TSO and OMVS.

//USERADD JOB 1,BILL,MSGCLASS=X,NOTIFY=P390A //TSO EXEC PGM=IKJEFT01

//SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=*

//SYSUADS DD DSN=SYS1.UADS,DISP=SHR //SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR //SYSTSIN DD *

AU ogden NAME('BILL OGDEN') PASSWORD(ogden) OWNER(SYS1) + DFLTGRP(sys1) +

TSO(ACCTNUM(1) PROC(BILLPROC) JOBCLASS(A) MSGCLASS(X) + HOLDCLASS(X) SYSOUTCLASS(X) SIZE(40000) MAXSIZE(0)) + OMVS(HOME(/u/ogden) PROGRAM(/bin/sh) UID(525))

CONNECT ogden GROUP(WORKSHOP) AUTHORITY(CREATE) PERMIT JCL CLASS(TSOAUTH) ID(ogden) ACCESS(READ) PERMIT OPER CLASS(TSOAUTH) ID(ogden) ACCESS(NONE) PERMIT ACCT CLASS(TSOAUTH) ID(ogden) ACCESS(NONE) PERMIT 'WORKSHOP.*' ID(ogden) ACCESS(ALTER)

AD 'ogden.*' OWNER(ogden) UACC(NONE) GENERIC SETROPTS RACLIST(TSOAUTH) REFRESH

BPXBATCH SH mkdir /u/ogden BPXBATCH SH chown ogden /u/ogden

LU usery TSO OMVS LD DA('ogden.*') ALL /*

//ALIAS EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=*

//* VERIFY THAT ALIAS NAME IS UPPER CASE //SYSIN DD *

DEFINE ALIAS (NAME(OGDEN) RELATE(WORKSHOP.CATALOG)) /*

//ISPF EXEC PGM=IEFBR14

//D1 DD DSN=OGDEN.ISPF.ISPPROF,DISP=(,CATLG),VOL=SER=WORK01,

// UNIT=3390,SPACE=(TRK,(4,2,10)),DCB=(LRECL=80,RECFM=FB,BLKSIZE=0) //* VERIFY THAT ALL JCL IS UPPER CASE

To run this job (or to use the equivalent RACF commands from TSO), you must have SPECIAL authority in RACF. The P390 userid supplied with the AD system has SPECIAL authority, and we suggest you log onto TSO with this userid when adding or changing user definitions. The IBMUSER userid also has SPECIAL authority and can also be used. You can define new users with SPECIAL authority, of course, and use these new userids for further administration.

We need to explain some of the details in this job:

򐂰 There are three job steps. The first executes the TSO command processor, and supplies several RACF and other commands as input. The second executes IDCAMS and adds an ALIAS to your master catalog. The third simply allocates a new data set that will be the ISPF profile data set for this user. The ALIAS step is needed only if you have defined a user catalog (and want this new userid to be in it). The AD system, as distributed, does not have a user catalog for TSO users and you do not need this step. (TSO user data sets are cataloged in the master catalog.) The AD system will automatically create an ISPF profile data set for a new user; this is done by the CLIST that is run at logon time. However, you can create the ISPF profile data set as shown here and control where it is placed.

򐂰 Several RACF commands are executed: AU (ADDUSER), CONNECT, several PERMITs, AD

(ADDSD or add data set profile), SETROPTS, LD (LISTDSD or list data set profile), and LU

(LISTUSER). The LD and LU are optional, of course; their output should be used to verify that the AU and AD commands produced the expected results.

򐂰 The AU command includes segments for TSO and OMVS, and could be extended to include CICS and OPER segments if appropriate.

򐂰 The key parameters that must be changed for each new user are: – The userid (which is the operand just after the AU command)

– The NAME field (which can be listed in RACF reports, but which has no direct processing function, should reflect the user's name)

– The UID value in the OMVS segment

– The HOME directory in the OMVS segment (usually lowercase) – The userid in the CONNECT command

– The userid in the PERMIT commands – The userid in the AD command

– The directory names in the BPXBATCH commands (and these are usually lowercase) – The userids in the LD and LU commands

– The NAME field in the DEFINE ALIAS command (uppercase)

– The HLQ in the DSN parameter in the ISPF job step (which should be set to the new user's userid)

򐂰 Note that many of these can be changed by a single global change command using the ISPF editor.

Assuming the group names (workshop and sys1) do not change, the new userid in this example appears in several places (including directory names and MVS data HLQs). If you use a global change with a file like this, be certain that all your final JCL is upper case, the ALIAS name is upper case, and UNIX directory names are lower case. Unfortunately, there is no single change command that will make all the upper/lower case entries correct.

Other considerations for this sample job are:

򐂰 Many of the basic parameters shown will probably be the same for most of your users. These include the OWNER, DFLTGRP, ACCTNUM, PROC, JOBCLASS, MSGCLASS, HOLDCLASS, SYSOUTCLASS, SIZE, MAXSIZE, TIMEOUT, XRFSOFF, and PROGRAM fields. The values shown in the example are reasonable starting points for the AD CD-ROM systems.

򐂰 The PASSWORD field provides an expired password. The new user will be forced to select a new password the first time he logs onto TSO. You probably should select a unique PASSWORD for each new user (even though he will be forced to change it immediately), but most administrators use a constant initial password. The security exposure is real, but slight.

򐂰 The value in the ACCTNUM field must be known to RACF. If you are not planning to use the account information (and few AD owners are interested in this), we suggest using the value “ACCT#” which is already defined to RACF in the AD CD-ROM system. This account number applies only to the TSO logon account number; it is not related to the account number field in a JOB statement.

򐂰 The UACC value of NONE (in the AD statement) will prevent any other user or job from reading this user’s sets. You could set the UACC value to READ, depending on the needs of your installation. READ is a typical value for a development shop, while NONE would be more common in a commercial production operation.

򐂰 The PERMIT ACCT and PERMIT OPER commands are used primarily to control SDSF security, and this is addressed in “Understanding basic SDSF security” on page 181. These commands have side effects and you may want to delete them from this job.

򐂰 After a new user is added by using this job, you can use direct RACF commands to fine tune any unique requirements for that user. In other words, we suggest using a fairly generic set of parameters (as shown in the example) to add all new users. You would then use the RACF ALTUSER and PERMIT commands to make minor changes or additions.

򐂰 If you are not using OMVS, you would delete the associated line from the job. You might add other segments, such as OPERPARM, CICS, DCE, DFP, NETVIEW, or WORKATTR if some of these will apply to all your normal users.

򐂰 The system does not automatically assign a UID. You must manually manage UID assignment. Any number up to 2**31 can be used, but most installations prefer an orderly assignment of UIDs.

򐂰 An OMVS user (any user who has an OMVS segment in RACF) must belong to a group that also has an OMVS segment. Group SYS1, which is assigned as the default group in the job above, has an OVMS segment.

򐂰 Note that the AU command is a single command. that flows over several lines. Remember to maintain the continuation marks (which are the + symbols in the example).

򐂰 The BILLPROC in the PROC parameter is the name of the small TSO logon procedure we described in “ISPFLITE procedure” on page 45 and “ISPFLITE procedure” on page 75. You could use the full-function procedure, ISPFPROC, that is supplied with the AD system.

򐂰 The example here places the user in the default group SYS1, and connects him to group WORKSHOP. If you have defined a group structure, you would probably have more

CONNECT commands and you would probably need to tailor these for each new user. If you are using you own group structures, you want to have List of Groups enabled. See “Unexpected RACF parameters” on page 42 and “Unexpected RACF parameters” on page 72.

򐂰 If you have enabled Enhanced Generic Naming (EGN) in your RACF system, the parameter in the AD command (in the sample job above) would change to OGDEN.** (with two asterisks). By default, EGN is not enabled in the AD CD-ROM systems. For further information refer to Security Server (RACF) Security Administrator's Guide SC28-1915, or Security Server (RACF) Command Language Reference, SC28-1919.

4.4.1 Adding TSO account numbers and procedures

A TSO user must be authorized to use whatever logon account numbers and TSO logon procedures he needs to use. In the example above, account number 1 and logon procedure BILLPROC are used.10 Neither of these are present in the distributed AD system. The system administrator can make these available with the following commands:

RDEFINE TSOPROC billproc UACC(READ) RDEFINE ACCTNUM 1 UACC(READ)

The distributed AD system already has these defined:

RDEFINE ACCTNUM ACCT# UACC(READ) RDEFINE TSOPROC ISPFPROC UACC(READ) RDEFINE TSOPROC ISPFLITE UACC(READ) RDEFINE TSOPROC DBSPROC UACC(NONE)

The significance of UACC(READ) is that anyone can use these resources for their intended purpose (TSO account number or logon procedure). If the UACC is NONE, then an explicit PERMIT command is needed to authorize someone to use the resource. For example, the TSO logon procedure DBSPROC is distributed with the AD system; it provides additional DB2 options on the extended ISPF primary menu. The TSOPROC profile for DBSPROC has UACC(NONE), and explicit PERMIT commands were issued for a few users. If user ogden (in the example above) wants to use this logon procedure, then the system administrator must issue PERMIT DBSPROC CLASS(TSOPROC) ID(OGDEN) ACCESS(READ) to allow this.

If your installation is working with DB2, you may want to allow all your TSO users to use the DBSPROC logon procedure.11 You can do this by issuing PERMIT commands for all of them, or by changing the UACC for this profile to READ. The command to do this is:

RALTER TSOPROC DBSPROC UACC(READ)

If you examine the RACF data base for the distributed AD system, you will see that profiles with UACC(READ), such as the ISPFPROC profile, also have a long list of permitted users. This is redundant, since all users have default READ access. The list of permitted users is left over from an earlier AD release in which the UACC was NONE.

10 _{Very few AD installations use the TSO account number for anything. However, an account number must be specified in certain fields.}

We arbitrarily use an account number of 1. Many batch job examples also use 1 as the account number. No special RACF permission is needed to use a batch job account number.

11 _{A TSO user can specify the logon procedure he wants to use by changing a field in the logon password panel. If he is authorized to}