Securing DDM files

Using DDM files is a very easy way to access data from another IBM i. I frequently use them to pass data from one IBM i partition to another and back.

All I need to do is to create the DDM file with the following command and be able to access the data in the file SOMEFILE in the library SOMEIB in the IBM i partition RMTSYS.

Create DDM File (CRTDDMF) Type choices, press Enter. DDM file . . . . . . > DDMFILE Library . . . . . > QTEMP Remote file: File . . . . . . . > SOMEFILE Library . . . . > SOMELIB Remote location: Name or address . > RMTSYS Type . . . . . . . . . *SNA *SNA, *IP

A very simple CL program to copy data from the file SOMEFILE could look like:

01 PGM 02 DLTF FILE(QTEMP/DDMFILE) 03 MONMSG MSGID(CPF2105) 04 CRTDDMF FILE(QTEMP/DDMFILE) RMTFILE(SOMELIB/SOMEFILE) + RMTLOCNAME(RMTSYS) 05 DLTF FILE(QTEMP/TESTFILE) 06 MONMSG MSGID(CPF2105) 07 CPYF FROMFILE(QTEMP/DDMFILE) + TOFILE(QTEMP/TESTFILE) MBROPT(*ADD) + CRTFILE(*YES) 08 ENDPGM

The program will not alarm most programmers. As the default communication type for DDM files is *SNA, this means that when I go to access a file on the remote system the DDM file uses the user profile QUSER. If the user profile QUSER is not excluded from the remote file I could copy the employee master file from the production server to the test server, and learn how much all my managers are paid.

The simplest solution to stop that from happening is to exclude QUSER from all files. If I do that how can I access remote data without using QUSER?

I need to change the communication type, the last parameter on the first page of the CRTDDMF command, to *IP, and I will use TCP/IP as the communication protocol.

04 CRTDDMF FILE(QTEMP/DDMFILE) RMTFILE(SOMELIB/SOMEFILE) + RMTLOCNAME(RMTSYS *IP)

When using TCP/IP as the communication type when DDM makes the connection to the remote system and requests the data it uses the same user profile as the one that is running the job on the local system. Not a problem for me as I have the same user profile on both. But what about all the other users?

If another user was the run that CL program, using TCP/IP, without having their user profile on the remote system, they would receive the following messages in their job log:

Database connection started over TCP/IP. Database connection ended over TCP/IP. Authorization failure on DRDA/DDM TCP/IP connection attempt. Cannot assign or release DDM file(s).

I can see that DDM failed due to an authorization failure. If I prompt the third message I get more details:

Message ID . . . . . . : CPF9190 Message type . . . . . : Diagnostic Date sent . . . . . . : 06/24/18 Message . . . . : Authorization failure on DRDA/DDM TCP/IP connection attempt. Cause . . . . . : A connection attempt failed with reason code 6. The reason codes and their meanings are as follows: 6 -- User ID not valid. For an IBM i server this could mean a damaged user profile or PASSWORD(*NONE).

In my experience the real explanation of why reason code 6 happens in that there is no matching user profile on the remote system.

Does this mean I need to create a user profile on the remote system for everyone on the local system? Fortunately the answer is no.

IBM i provides me with Server Authority Entries. This allows me to provide a user id and password that will be sent via the TCP/IP communications to the remote system for a user profile.

First thing I need to do is to check that I can use server authority on the local IBM i. I use the following command to display the Retain Server Security Data system value, QRETSVRSEC.

DSPSYSVAL QRETSVRSEC

The system value must be '1' so that the entered data is saved.

On the IBM i I am using the system value is '1', therefore, I can proceed to the next step: to create a generic user profile on the remote system. When I create any generic profile I always ensure that the Initial menu and Limit capabilities are set to *SIGNOFF and *YES.

CRTUSRPRF USRPRF(GENERIC) PASSWORD(GENERIC) INLMNU(*SIGNOFF) LMTCPB(*YES)

Back on the local system I can add my user profile to the Server Authority table using the ADDSVRAUTE command:

ADDSVRAUTE USRPRF(LOCALUSER1) SERVER(QDDMSERVER) USRID(GENERIC) PASSWORD(GENERIC)

The DDM server is QDDMSERVER. When entering its name at any command prompt, etc, it must be entered in upper case. qddmserver is not the name the of the DDM server.

When I have added the user profile I can use the DSPSVRAUTE to view the entry I just added.

DSPSVRAUTE USRPRF(LOCALUSER1) Display Server Auth Entries User profile . . . . . : LOCALUSER1 User Password Server ID Stored QDDMSERVER GENERIC *YES

There is also a change command too.

CHGSVRAUTE USRPRF(LOCALUSER1) SERVER(QDDMSERVER) USRID(GENERIC) PASSWORD(NEWPASSWD)

And a remove command.

RMVSVRAUTE USRPRF(LOCALUSER1) SERVER(QDDMSERVER)

Alas, there is not a WRKSVRAUTE command with IBM i.

By using this method I only make changes on the local system.

I like using programs to perform everyday tasks. For example I have a CL program that creates a new user profile, and then makes a Server Authority entry for the new profile. This way no-one can forget to make a server entry for the new profile.

01 ADDSVRAUTE ?*USRPRF(&NEWUSER) ?*SERVER(QDDMSERVER) + ?*USRID(GENERIC) ?*PASSWORD(GENERIC) 02 MONMSG MSGID(CPF6801 CPF224F) EXEC(LEAVE) /* F3 pressed */ 03 MONMSG MSGID(CPF226C) EXEC(DO) /* Not auth to run cmd */

If you are unfamiliar with what the question marks do within a command read the post on selective prompts of CL commands.

 

• QRETSVRSEC system value
• Client security in a TCP/IP network
• ADDSVRAUTE command
• CHGSVRAUTE command
• RMVSVRAUTE command

 

This article was written for IBM i 7.3, and should work for earlier releases too.