Q: I want to use DDM to access files on a remote system. Because the files contain sensitive information, they have been secured. The DDM job on the target system gets authorization failures for user profile QUSER. Is it possible to run the DDM job on the remote system with the QSECOFR user profile?
A: It is possible to configure your systems so that you can run DDM requests with a profile other than QUSER. Before I get into the configuration details, some background information is valuable so that you understand DDM security.
1 shows a typical DDM configuration. A program running on system A uses a DDM file to access the data from the PAY file on system B. The system that initiates the DDM request (system A) is called the SOURCE DDM system. The system that receives the request (system B) is called the TARGET DDM system. DDM starts a job on the target system to access the PAY file which is protected using standard AS/400 security.
Figure 1 shows a typical DDM configuration. A program running on system A uses a DDM file to access the data from the PAY file on system B. The system that initiates the DDM request (system A) is called the SOURCE DDM system. The system that receives the request (system B) is called the TARGET DDM system. DDM starts a job on the target system to access the PAY file which is protected using standard AS/400 security.
The communication configuration at the target system has a major role in the user profile used to access the data. The secure location attribute of the communication configuration at the TARGET system determines the user profile used to access the file. The two options follow:
1. If the communication configuration at the target system specifies SECURELOC(*NO), the DDM job at the target system runs using the default user specified in the communications entry of the communication subsystem. The default user is specified in the DFTUSR parameter of the Add Communications Entry (ADDCMNE) or Change Communications Entry (CHGCMNE) command.
2. If the communication configuration at the target system specifies SECURELOC(*YES), the DDM job at the target system runs using the same user profile that originated the request on the source system. Therefore, when SECURELOC(*YES) is used, the same user profile must be defined on both the SOURCE and TARGET systems.
See the next question in "Security Patrol" for information about the commands used to specify the secure location attribute.
The term SECURELOC confuses many users. A value of *YES does not mean that the communications transmission is secure. The opposite is true because the source system can start jobs on the target system by sending a user profile name and no password. The target system assumes the user was properly verified at the source system. The communication term for this support is "already verified." The source system has already verified the user and the target system agrees to accept a user profile name and no password to start a job.
As the administrator of system B, you should only specify SECURELOC(*YES) in the communication configuration when system A is part of your organization. You should be confident that good security practices are being used on the system. Do not specify SECURELOC(*YES) to systems outside your organization as this would allow people to run jobs as QSECOFR if they can sign on as QSECOFR on the other system.
Of the following methods to have jobs run as QSECOFR on system B, only the second method should be used.
1. Change the default user of the communications entry to a user profile that uses QSECOFR as its group profile. (You cannot explicitly specify QSECOFR as the default user of a communication entry.) This change would constitute poor security practice because every DDM request would run under QSECOFR. The default user is also used for the DDM Submit Remote Command (SBMRMTCMD) command that allows remote systems to run CL commands on the target system. Using a default user profile that uses QSECOFR as its group profile represents a serious security exposure.
2. Change the communication con-figuration to specify SECURELOC(*YES). The target system must have the same user profile as the source system. This is easy in the case of QSECOFR but now all DDM jobs for users other than QSECOFR on system A must have a matching user profile on system B.
Chapter 4 of IBM's Distributed Data Management Guide (SC41-9600) gives more details about the security of target-system DDM jobs.
Q: Where do you specify SECURELOC(*YES)?
A: SECURELOC can be specified two different ways based on the type of communication configuration.
1. The first method is used to specify the secure location value on an APPC device. This method can only be used when the device is not APPN-capable and the local address is not '00'. The Create Device Description (CRTDEVAPPC) or the Change Device Description (CHGDEVAPPC) command can be used to create or change these values. The SECURELOC parameter is shown in the following example:
CRTDEVAPPC DEVD(T8189DEV2) + RMTLOCNAME(T8189NY) + ONLINE(*NO) + LCLLOCNAME(T8189LA) + CTL(T8189CTL) APPN(*NO) + SECURELOC(*YES) + TEXT('APPC Device + Description')
2. If the device is APPN-capable, APPN(*YES), and the local location address is '00', LOCADR(00), the secure location value is obtained from the APPN remote location configuration list.
To define or change a list of remote location entries for APPN, use the Create Configuration List (CRTCFGL) or the Change Configuration List (CHGCFGL) command. When the CRTCFGL or CHGCFGL command is used to define remote location names with a secure location value of *YES, the list type (TYPE) parameter must be *APPNRMT. For example:
CRTCFGL TYPE(*APPNRMT) + APPNRMTE(*PROMPT)
The APPNRMTE(*PROMPT) parameter causes the system to prompt with the full- screen entry display shown in 2.
The APPNRMTE(*PROMPT) parameter causes the system to prompt with the full- screen entry display shown in Figure 2.
With a secure location value of *YES, I recommend the use of a second configuration parameter called LOCPWD (location password) for extra assurance that you are connecting with the proper system. A location password can be specified for an APPC device or through the remote location configuration list depending on where the secure location value is specified. The location password validates incoming SNA BIND commands for session establishment for both the local and remote locations. The password is a hexadecimal value with a maximum of 16 characters.
The location password and secure location values are ignored in a system with minimal (Level 10) security. For more information about APPN security, see the APPN Guide (SC41-8188).
Security Patrol: Security Questions & Answers
Figure 1 DDM Communications Example
UNABLE TO REPRODUCE GRAPHIC
Security Patrol: Security Questions & Answers
Figure 2 Create Configuration List Prompt
Create Configuration List MCPGMR 07/25/94 11:52:49 Configuration list . . : QAPPNRMT Configuration list type : *APPNRMT Text . . . . . . . . . : *BLANK Type information, press Enter. --------------------------APPN Remote Locations--------------------------- Remote Remote Control Remote Network Local Control Point Location Secure Location ID Location Point Net ID Password Loc ________ *NETATR *NETATR ________ *NETATR ________________ *NO ________ *NETATR *NETATR ________ *NETATR ________________ *NO ________ *NETATR *NETATR ________ *NETATR ________________ *NO ________ *NETATR *NETATR ________ *NETATR ________________ *NO ________ *NETATR *NETATR ________ *NETATR ________________ *NO ________ *NETATR *NETATR ________ *NETATR ________________ *NO ________ *NETATR *NETATR ________ *NETATR ________________ *NO ________ *NETATR *NETATR ________ *NETATR ________________ *NO More... F3=Exit F11=Display session information F12=Cancel F17=Top F18=Bottom
LATEST COMMENTS
MC Press Online