Pages

Wednesday, July 4, 2018

Securing DDM files

making ddm file connections secure

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.

 

 

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

4 comments:

  1. Simon,

    I thought this article on securing DDM files was excellent and most informative. Could you possibly do the same for creating and securing DDM data queues?

    ReplyDelete
  2. Simon, great read with very good examples. Thanks for sharing.
    Hope you have a great afternoon.

    ReplyDelete
  3. I wondering a little bit about the ADDSVRAUTE step; I assume your user profile is LOCALUSER1; I get that this connects LOCALUSER1 to GENERIC; but if you have 200 users that want to use the application, do you need to make an entry for each user? Can you use a group profile? Thanks

    ReplyDelete
    Replies
    1. I would try using adding the group profile and see if that gives you the functionality you desire.

      Delete

To prevent "comment spam" all comments are moderated.
Learn about this website's comments policy here.

Some people have reported that they cannot post a comment using certain computers and browsers. If this is you feel free to use the Contact Form to send me the comment and I will post it for you, please include the title of the post so I know which one to post the comment to.