DRDA application server security in an APPC network
When the target system is an i5/OS® operating system, several elements are used together to determine whether a request to access a remote file is allowed.
User-related security elements
The user-related security elements include the SECURELOC parameter on the target system, the user ID sent by the source system (if allowed), the password for the user ID sent by the source system, and a user profile or default user profile on the target system.
Object-related security elements
The object-related security elements include the DDMACC parameter and, optionally, a user exit program supplied by the user to supplement normal object authority controls.
User-related elements of target security
A valid user profile must exist on the application server (AS) to process distributed relational database work. You can specify a default user profile for a subsystem that handles communications jobs on the i5/OS operating system.
The name of the default user profile is specified on the DFTUSR parameter of the Add Communications Entry (ADDCMNE) command on the AS. The ADDCMNE command adds a communications entry to a subsystem description used for communications jobs.
If a default user profile is specified in a communications subsystem, whether the AS is a secure location or not determines if the default user profile is used for this request. The SECURELOC parameter on the Create Device Description (APPC) (CRTDEVAPPC) command, or the secure location designation on an APPN remote location list, specifies whether the AS is a secure location.
- If *YES is specified for SECURELOC or secure location on the AS, the AS considers the application requester (AR) a secure location. A user ID and an Already Verified indicator are expected from the AR with its request. If a user profile exists on the AS that matches the user ID sent by the requester, the request is allowed. If not, the request is rejected.
- If *NO is specified for the SECURELOC parameter on the AS, the AS does not consider the AR a secure location. Although the AR still sends a user ID, the AS does not use this for the request. Instead, a default user profile on the AS is used for the request, if one is available. If no default user profile exists on the AS, the request is rejected.
- If *VFYENCPWD is specified for SECURELOC on the AS, the AS considers the AR a secure location, but requires that the user ID and its password be sent (in encrypted form) to verify the identity of the current user. If the user profile exists on the AS that matches the user ID sent by the requester, and that requester has the same password on both systems, the request is allowed. Otherwise, the request is rejected.
The following table shows all of the possible combinations of the elements that control SNA SECURITY(PGM) on the i5/OS operating system. A Y in any of the columns indicates that the element is present or the condition is met. An M in the PWD column indicates that the security manager retrieves the user's password and sends a protected (encrypted) password if password protection is active. If a protected password is not sent, no password is sent. A protected password is a character string that APPC substitutes for a user password when it starts a conversation. Protected passwords can be used only when the systems of both partners support password protection and when the password is created on a system that runs i5/OS V5R3, or later, or OS/400® V2R2, or later.
Table 1. Remote access to a distributed relational database Row UID PWD1 AVI SEC(Y) DFT Valid Access 1 Y Y Y Y Y Use UID 2 Y Y Y Y Reject 3 Y Y Y Y Use UID 4 Y Y Y Reject 5 Y Y Y Y Use UID 6 Y Y Y Reject 7 Y Y Y Use UID 8 Y Y Reject 9 Y Y Y Y Y Use UID 10 Y Y Y Y Reject 11 Y Y Y Y Use UID 12 Y Y Y Reject 13 Y M3 Y Y Use DFT or UID2 14 Y M3 Y Use DFT or UID2 15 Y M3 Y Reject or UID2 16 Y M3 Reject or UID2 17 Y Y Used DFT 18 Y Reject 19 Y Use DFT 20 Reject Key:
- UID
- User ID sent
- PWD
- Password sent
- AVI
- Already Verified Indicator set
- SEC(Y)
- SECURELOC(YES) specified
- DFT
- Default user ID specified in communication subsystem
- Valid
- User ID and password are valid
- Use UID
- Connection made with supplied user ID
- Use DFT
- Connection made with default user ID
- Reject
- Connection not made
- If password protection is active, a protected password is sent.
- Use UID when password protection is active.
- If password protection is active, the password for the user is retrieved by the security manager, and a protected password is sent; otherwise, no password is sent.
To avoid having to use default user profiles, create a user profile on the AS for every AR user that needs access to the distributed relational database objects. If you decide to use a default user profile, however, make sure that users are not allowed on the system without proper authorization. For example, the following command specifies the default user parameter as DFTUSER(QUSER); this allows the system to accept job start requests without a user ID or password from a communications request. The communications job is signed on using the QUSER user profile.
ADDCMNE SBSD(SAMPLE) DEV(*ALL) DFTUSER(QUSER)
Parent topic:
Elements of security in an APPC network