DRDA server security in an APPC network

When the server system is an IBM® i 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 server system, the user ID sent by the client system (if allowed), the password for the user ID sent by the client system, and a user profile or default user profile on the server 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 server security

A valid user profile must exist on the server to process distributed relational database work. You can specify a default user profile for a subsystem that handles communications jobs on the IBM i operating system.

The name of the default user profile is specified on the DFTUSR parameter of the Add Communications Entry (ADDCMNE) command on the server. 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 server 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 server is a secure location.

  • If *YES is specified for SECURELOC or secure location on the server, the server considers the client a secure location. A user ID and an Already Verified indicator are expected from the client with its request. If a user profile exists on the server that matches the user ID sent by the client, the request is allowed. If not, the request is rejected.
  • If *NO is specified for the SECURELOC parameter on the server, the server does not consider the client a secure location. Although the client still sends a user ID, the server does not use this for the request. Instead, a default user profile on the server is used for the request, if one is available. If no default user profile exists on the server, the request is rejected.
  • If *VFYENCPWD is specified for SECURELOC on the server, the server considers the client 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 server that matches the user ID sent by the client, and that client 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 IBM i 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 IBM i 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
  1. If password protection is active, a protected password is sent.
  2. Use UID when password protection is active.
  3. 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 server for every client 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