Pages

Wednesday, February 14, 2018

Making IP connections easier between IBM i partitions

ddm server authority entries

I have mentioned in previous posts regarding using DDM files and configuring remote database connections that there is a difference in using SNA and IP for the connection protocol.

When you use SNA to connect everything performed on the remote IBM i is performed as the user profile QUSER. It is impossible to discriminate between valid requests for the files/tables and others trying to get at data they should not be authorized to.

CRTDDMF FILE(QTEMP/DDMFILE1)
          RMTFILE(OTHERLIB/RMTFILE)
          RMTLOCNAME(SYSTEM2)

The alternative is to use IP as the connection protocol, this will run the job on the remote system using the user profile of the person who submitted it. This is great for security as I can now only allow those I want to have access to the files/tables.

CRTDDMF FILE(QTEMP/DDMFILE2)
          RMTFILE(OTHERLIB/RMTFILE)
          RMTLOCNAME(SYSTEM2 *IP)

What happens when someone tries to use a DDM file, using an IP connection, without having a matching profile on the remote system?

Authorization failure on DRDA/DDM TCP/IP connection attempt.

You really do need to see the full message to establish the problem.

                 Additional Message Information

Message ID . . . . :  CPF9190       Severity . . . . . :  40
Message type . . . :  Escape


Message . . . . :   Authorization failure on DRDA/DDM TCP/IP 
  connection attempt.
Cause . . . . . :   A connection attempt failed with reason 
  code 5. The reason codes and their meanings are as follows:

   5 -- User ID not found.

As the return code is "5" I know that I do not have a matching user profile on the other system.

Does this mean I have to create every user profile on the remote system for all those people I want to have access to the files/tables? There could be hundreds!

Fortunately there is way to only create a few profiles on the remote system, and map user profiles on the local system to them. I have deliberately said a few as I would need different generic profiles on the remote system for the roles I want the local system's users to perform. Here is an example of a generic profile I would create on the remote system.

CRTUSRPRF USRPRF(GENERIC1) 
            INLMNU(*SIGNOFF)
            LMTCPB(*YES)
            TEXT('Generic usrprf for DDM *IP')
            SPCAUT(*NONE)
            PWDEXPITV(*NOMAX)
            JOBD(SOMELIB/SOMEJOBD)
            ATNPGM(*NONE)

I have tried to make this profile unusable. Its default menu is signoff, when the user signs on they are presented with a informing them they will be signed off after they press the Enter key. There capabilities have been limited, even if they get to a command line they cannot type any commands. There is no attention program.

On the local system I would not add Server Authentication Entries for the user profiles to this generic profile. For example if I was to add my user profile it would look like:

ADDSVRAUTE USRPRF(SIMON)
             SERVER(QDDMSERVER)
             USRID(GENERIC1) PASSWORD(GENERIC1)

The server name, QDDMSERVER, must be entered in upper case. This is a special server that is used for all DDM connections, between the local system and all the other systems.

I can display what has already been entered using the DSPSVRAUTE command:

DSPSVRAUTE USRPRF(SIMON)


                   Display Server Auth Entries

User profile . . . . . . . . . :   SIMON

                     User              Password
Server              ID                 Stored
QDDMSERVER          GENERIC1            *YES

You can only have one entry for each server, therefore, you might have to be creative with the user profile names on any remote systems to be able to cope with all possible permutations for securing your data.

I am sure it will come as no surprise that there is a change command for the Server Authentication Entries, CHGSVRAUTE, and a remove (delete) command, RMVSVRAUTE, too.

Now when I run a job on the remote system using an IP connection the job runs with the generic profile.

                           Work with Subsystem Jobs

Subsystem  . . . . . . . :   QBATCH

Opt  Job         User        Type     -----Status-----  Function
      TESTPGM     GENERIC1    BATCH    ACTIVE            DLY-30

 

You can learn more about this from the IBM website:

 

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

1 comment:

  1. You can use grpprf's also:
    Simplified DDM and DRDA authentication entry management using group profiles
    This enhancement allows DDM and DRDA to take advantage of a common userid and password defined in a server authentication entry under a group profile name or supplemental group profile name. The group profile name or supplemental group profile name is specified on the USRPRF parameter of the ADDSVRAUTE command.

    Delivered on: IBM i 6.1 (DB2 PTF Group SF99601 Level 25) and IBM i 7.1 (DB2 PTF Group SF99701 Level 14)
    http://ibmsystemsmag.com/blogs/i-can/archive/ibm-i-security-never-sleeps/

    ReplyDelete

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.