DRDA and DDM server access control using user exit programs

A security feature of the Distributed Relational Database Architecture™ (DRDA) server, for use with both Advanced Program-to-Program Communication (APPC) and TCP/IP, extends the use of the DDMACC parameter of the Change Network Attributes (CHGNETA) command to DRDA.

The parameter previously applied only to DDM file I/O access. The DRDA usage of the function is limited to connection requests, however, and not to requests for data after the connection is made.

If you do not choose to use this security function, you normally do not need to do anything. The only exception is if you are currently using a DDM user exit program that is coded to reject operations if an unknown function code is received, and you are also using DRDA to access data on that system. In this case, you must change your user exit program so that a '1' is returned to allow DRDA access if the function code is 'SQLCNN '.

To use the user exit program for blocking or filtering DRDA connections, you need to create a new DRDA user exit program, or change an existing one.

Note: If your system is configured with multiple databases (ASP groups), the user exit program must reside in a library in the system database (on an auxiliary storage pool in the range 1-32).

You can find general instructions for creating a DRDA user exit program below.

This security feature adds a DRDA function code to the list of request functions that can be input to the program in the input parameter structure. The function code, named 'SQLCNN ' (SQL connect request), indicates that a DRDA connection request is being processed (see the FUNC parameter in Example: DRDA and DDM server access control using user exit program). The APP (application) input parameter is set to '*DRDA ' instead of '*DDM ' for DRDA connection request calls.

When you code user exit programs for DRDA, the following fields in the parameter structure might be useful:

  • The USER field allows the program to allow or deny DRDA access based on the user profile ID.
  • The RDBNAME field contains the name of the RDB to which the user wants to connect. This can be the system database or a user database (ASP group). This field can be useful if you want to deny access to one or more databases in an environment where multiple databases are configured.
  • The SRVNAME parameter in the topic Example: DRDA and DDM server access control using user exit program might or might not be set by the caller of the user exit program. If it is set, it indicates the name of the client system. If it is not set, it has the value *N. It is always set when the DRDA application requester is a IBM i product.
  • The TYPDEFN parameter gives additional information about the type of client that is connecting. For an IBM mainframe, TYPEDEFN is QTDSQL370. For a IBM i product, it is QTDSQL400. For an Intel PC, it is QTDSQLX86. For an RS/6000® client, it is QTDSQLASC.
  • The PRDID (product ID) parameter identifies the product that is attempting to connect, along with the product's release level. Here is a partial list of the first three characters of these codes (You should verify the non-IBM codes before you use them in user exit programs):
    QSQ
    IBM Db2® for i
    DSN
    IBM DB2® for z/OS®
    SQL
    IBM DB2 for Linux, UNIX, and Windows (formerly called DDCS)
    ARI
    IBM DB2 for VSE & VM
    GTW
    Oracle Corporation products
    GVW
    Grandview DB/DC Systems products
    XDB
    XDB Systems products
    IFX
    Informix® Software products
    SIG
    StarQuest products
    STH
    FileTek products
    JCC
    IBM DB2 Universal Driver for SQLJ and JDBC
    The rest of the field is structured as vvrrm, where vv is version, rr is release, and m is modification level.

If the user exit program returns a RTNCODE value of 0, and the connection request came from an IBM i client, then the message indicating the connection failure to the user will be SQ30060, User is not authorized to relational database ... In general, the response to a denial of access by the user exit program is the DRDA RDBATHRM reply message, which indicates that the user is not authorized to the relational database. Different client platforms might report the error differently to the user.

Restrictions:

  • If a function check occurs in the user exit program, the program returns the same reply message, and the connection attempt will fail. The user exit program must not do any committable updates to Db2 for i, or unpredictable results might occur.
  • You should not use user exit programs to attempt to access a file that was opened in a prior call of the prestart server job.
  • Prior to V5R2, a further restriction resulted when the prestart jobs used with the TCP/IP server were recycled for subsequent use. Some cleanup is done to prepare the job for its next use. Part of this processing involves using the Reclaim Activation Group (RCLACTGRP) command with the ACTGRP parameter with value of *ELIGIBLE. As a result, attempts to use any residual linkages in the prestart server job to activation groups destroyed by the RCLACTGRP can result in MCH3402 exceptions (where the program tried to refer to all or part of an object that no longer exists). One circumvention to this restriction is to set the MAXUSE value for the QRWTSRVR prestart jobs to 1 as follows: CHGPJE SBSD(QSYSWRK) PGM(QRWTSRVR) MAXUSE(1).