IBM Support

Using a Group Profile in a DDM/DRDA Server Authentication Entry

Troubleshooting


Problem

Enhancing DDM and DRDA connections to allow a server authentication entry to include a group profile.

Resolving The Problem

IBM i v6r1 and v7r1 added functionality allowing clients to inherit their group and supplemental group profiles's server authentication entries (SVRAUTE) for DDM/DRDA connections to remote systems. Previously, a SVRAUTE was required for every individual user profile.
This functionality is in the base of v7r2 and later versions of IBM i.

DDM and DRDA connections now allow group profiles to specify a server authentication entry and all member profiles of that group will use the common userid and password specified in the group profile's server authentication entries. This adds greater flexibility and ease of administration by enabling specification of a common userid and profile for DDM & DRDA connections to a large set of users under a group profile rather than having to add a server authentication entry for each individual user.


The progression of server authentication entry checking for DDM and DRDA will be as follows:

1) Check local profile for RDB or alias RDB server authentication entry for DRDA or QDDMSERVER server authentication entry for DDM. If an entry is found, it will use that server authentication entry and no further checking will be done.

2) If no entry is found in the previous step, check local profile for QDDMDRDASERVER server authentication entry. If an entry is found, it will use that server authentication entry and no further checking will be done.

3) If no entry is found in the previous step, check any group profiles for which the profile is a member for RDB or alias RDB server authentication entry for DRDA or QDDMSERVER server authentication entry for DDM. If an entry is found, it will use that server authentication entry and no further checking will be done.

4) If no entry found in the previous step, check any group profiles for which the profile is a member for QDDMDRDASERVER server authentication entry. If an entry is found, it will use that server authentication entry and no further checking will be done.

5) If no entry found in the previous step, check any supplemental group profiles for which the profile is a member for RDB or alias RDB server authentication entry for DRDA or QDDMSERVER server authentication entry for DDM. If an entry is found, it will use that server authentication entry and no further checking will be done.

6) If no entry found in the previous step, check any supplemental group profiles for which the profile is a member for QDDMDRDASERVER server authentication entry. If an entry is found, it will use that server authentication entry and no further checking will be done.

The above progression of server authentication entry checking is replicated in the table below:

Search SVRAUTEs where USRPRF = AND Server (AS) RDB or alias RDB =
Current Job User ProfileApplication Server name or QDDMSERVER
Current Job User ProfileQDDMDRDASERVER
Current Job Group ProfileApplication Server name or QDDMSERVER
Current Job Group ProfileQDDMDRDASERVER
Current Job Supplemental Group ProfileApplication Server name or QDDMSERVER
Current Job Supplemental Group ProfileQDDMDRDASERVER

If no entry has been found in all previous steps, user ID-only authentication will be used for the DDM or DRDA connection; it will be up to the application server to allow or reject that authentication method.


A new environment variable, QIBM_DDMDRDA_SVRNAM_PRIORITY can be used to force the use of server authentication entries with explicit server names before QDDMDRDASERVER for group profiles. This functionality is documented in APAR SE58556.

To enable this system wide:
ADDENVVAR ENVVAR(QIBM_DDMDRDA_SVRNAM_PRIORITY) VALUE('Y') LEVEL(*SYS)
Restarting the job maybe necessary to pick up the change.

To enable this for the job:
ADDENVVAR ENVVAR(QIBM_DDMDRDA_SVRNAM_PRIORITY) VALUE('Y') LEVEL(*JOB)

Once the environment variable is in place and set to 'Y', the search progression will become:

Search SVRAUTEs where USRPRF =AND Server (AS) RDB or alias RDB =
Current Job User ProfileApplication Server name or QDDMSERVER
Current Job Group ProfileApplication Server name or QDDMSERVER
Current Job Supplemental Group ProfileApplication Server name or QDDMSERVER
Current Job User ProfileQDDMDRDASERVER
Current Job Group ProfileQDDMDRDASERVER
Current Job Supplemental Group ProfileQDDMDRDASERVER



Example

CRTUSRPRF USRPRF(TESTTEAM) PASSWORD(yourpasswordA)
CRTUSRPRF USRPRF(
JIM) PASSWORD(Jimpassword) GRPPRF(TESTTEAM)

Signon to SYSA with TESTTEAM user profile (or profile with sufficient authority)
ADDSVRAUTE USRPRF(TESTTEAM) SERVER(QDDMDRDASERVER) USRID(youruseridB)
PASSWORD(
yourpasswordB)

Signon to SYSA with Jim's user profile
STRSQL
CONNECT TO SYSB

(SYSB is an RDB defined on the system. Omit user/using clauses.)

Connection will be attempted to SYSB with youruseridB and yourpasswordB specified on the server authentication entry under the group profile.

[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"7.1.0"}]

Historical Number

628502609

Document Information

Modified date:
18 December 2019

UID

nas8N1011074