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.
You can use grpprf's also:
ReplyDeleteSimplified 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/