User Profile Backup
Question: You recommended that AS/400 installations back up user profiles on a regular basis. During a security audit, I used the Display Object Description (DSPOBJD) command to determine when user profiles were last saved. The date in individual user profiles was several months old, but the client told me that the company performs a Save Security Data (SAVSECDTA) on a nightly basis. Is the save date updated for user profiles shown by DSPOBJD? If not, how can I confirm that the profiles are being saved?
Answer: The SAVSECDTA command does not update the save date on individual user profiles, so the DSPOBJD of a user profile will not report the last save of user profiles. However, when user profiles are saved with either a Save Security Data (SAVSECDTA) or a Save System (SAVSYS) command, the last save date for the data area QSAVUSRPRF is updated to show the save date of all user profiles. The contents of the data are not changed, just the date of the last save. To see when user profiles were last saved, issue the following command:
DSPOBJD OBJ(QSYS/QSAVUSRPRF) OBJTYPE(*SAVUSRPRF
) The display in Figure 1 shows that the user profiles were last saved 2/21/98, using a SAVSECDTA command.
Application Security Is Not Sufficient
Question: Our AS/400 installation makes extensive use of a manufacturing application package. The application user profiles are limited to selecting options from application menus and are restricted from entering AS/400 commands. I have been told that there are additional security exposures, because the users attach to the AS/400 using
Client Access. Would you please explain these exposures and suggest how to prevent them?
Answer: Your concern about potential security exposures is valid. Menu security is helpful but not adequate to protect your AS/400 from users who have Client Access/400. Many AS/400 installations incorrectly assume application security adequately prevents users from accessing data outside of the application. Restricting users to application menus and preventing them from accessing a command line by specifying LMTCPB(*YES) in their user profiles is a good start, but this measure does not eliminate all other potential exposures.
A knowledgeable PC user can use client functions to access data outside of your application. The following exposures exist when users attach to the AS/400 from a PC:
• PC file transfer. After a PC user starts the router, he can use file transfer (file upload and download) for files if the user profile or group profile is authorized to the file. File transfer can be performed without sign-on to the AS/400 once the router has been started.
Recommended action: Install exit programs to restrict file transfer. You may want to limit file transfer to specific libraries. The May 1997 “Security Patrol” column in MC illustrates exit programs that restrict file transfer to specific libraries. The exit programs are specified using the Work with Registration Information (WRKREGINF) command. Two exit programs are required, because you should prevent file transfer from both the “original” (DOS and Windows 3.1) and “optimized” (OS/2 and Windows 95/NT) clients.
• Remote commands. Users can sign on and issue remote commands even when their user profiles prevent commands. This exposure exists for users running the DOS or Windows 3.1 clients. (You may be tempted to solve the problem by upgrading those users to the Windows 95 or NT clients, but you should protect the AS/400 from the potential exposure of someone hooking up via a PC running DOS or Windows 3.1.)
Recommended action: Install an exit program that restricts remote commands. The July 1995 “Security Patrol” column in MC illustrates an exit program that will restrict use of remote commands. The exit program to restrict remote commands is specified in the network attribute DDMACC. You can view the network attributes with the Display Network Attributes (DSPNETA) command.
• Access outside application. Many software applications assign the individual user profiles as members of either a group profile that is the owner of production data or, even worse, a group profile that has *ALLOBJ special authority. This design allows the application to function without any security restrictions. Potential security exposures are introduced when the users perform operations outside the application.
Recommended action: Change the application so that users are not members of the group profile that either owns objects or has *ALLOBJ authority.
Some third-party application packages recommend using either the *ALLOBJ user profile or the user profile that owns all production objects. For most third-party applications (BPCS or J.D. Edwards), you can implement an authority plan based on adopted authority, but this process requires significant planning.
The users will need to be assigned a group profile that has no authority to production data. Users are authorized to application programs that adopt the needed access. The application will require modifications to adopt a user profile that is authorized to the data.
The principal theme is that users are not members of groups that own or are authorized to the data. The users run application programs that adopt the access of their owner’s user profile. The adopted authority gives the user access to the data inside the application but gives no access when the user performs other operations, such as file transfer or ODBC, outside the application.
(For more information on implementing a security strategy, see “Application-only Access: Security Exposures Revealed,” MC, January 1996 and “Application-only Access: Implementing the Strategy,” MC, February 1996.)
• Mapping network drive. Users of Windows 95 or NT client can map a network drive to the AS/400 Integrated File System (IFS). Many users are authorized to all objects, so they could accidentally use Windows Explorer on the mapped drive and delete, rename, and move AS/400 objects. For more about this exposure, see “Security Patrol,” MC, June
1997.
Recommended action: Eliminating this exposure is easy. The QPWFSERVER authorization list, provided by IBM, controls access to the QSYS.LIB file system. QPWFSERVER is shipped with a public authority of *USE, which allows anyone access to the QSYS.LIB file system. To prevent this access, use the Edit Object Authority (EDTOBJAUT) command to change the *PUBLIC authority to *EXCLUDE. If a user attempts to access the QSYS.LIB folder, Client Access informs him that he is not authorized to the folder. (The authorization list will not prevent users with *ALLOBJ authority access.)
Checking Default Passwords
Question: I would like to run a CL program to check that no user’s password is the same as the user profile. Do you have any sample I can use?
Answer: OS/400’s Analyze Default Password (ANZDFTPWD) command provides a report of the profiles that have passwords that are the same as the profile names. It will also (optionally) disable the profiles or expire the passwords. You can use the command or select option 1 from the SECTOOLS menu to check the password of all profiles in your system.
Display Object Description - Full
Library 1 of 1
Object . . . . . . . : QSAVUSRPRF Attribute . . . . . :
Library . . . . . : QSYS Owner . . . . . . . : QSYS
Type . . . . . . . . : *DTAARA Primary group . . . : *NONE
Save/Restore information:
Save date/time . . . . . . . . . . : 02/21/98 05:03:24
Restore date/time . . . . . . . . :
Save command . . . . . . . . . . . : SAVSECDTA
Sequence number . . . . . . . . . : 109
Tape volumes . . . . . . . . . . . : MC
File label ID . . . . . . . . . . : QFILEUPR
Figure 1: This display shows the last date that user profiles were saved
LATEST COMMENTS
MC Press Online