IBM Power Ideas Portal


This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas

  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Add a new idea Subscribe
Status Not under consideration
Workspace IBM i
Categories Security
Created by Guest
Created on Apr 23, 2019

RELATED IDEAS

Need enhancements to ADDSVRAUTE and CHGSVRAUTE command functionality

The use of the ADDSVRAUTE and CHGSVRAUTE commands is limited and prevents us from communicating with more than 1 system without changing the SVTAUTE command.

To communicate with additional systems, the CHGSVRAUTE command has to be used to set the remote user ID and password.

This requires the programs to issue the CHGSVRAUTE command regularly and this is a SOX and PCI exposure that fails security audit requirements.


Use Case:

We use DDM to communicate with multiple end systems that do not share the same user profile on those systems example:
System 1 - user is USER1.
System 2 - user is USER2.
System 3 - user is USER3.
System 4 - user is USER4.

The local user is USER0.

Communicating with System 2 followed by communicating to system 4 requires using CHGSVRAUTE each time.

Using remote command and/or DDM to any of the above systems requires using the CHGSVRAUTE command each time otherwise the communication fails.

Creating a common user ID is not permitted in many companies subject to SOX and PCI audits.


Idea priority High
  • Guest
    Reply
    |     Dec 11, 2020

    IBM does not intend to provide an additional solution to this request at this time, so it is being closed. The options provided in a prior comment provide a solution to requirement.

  • Guest
    Reply
    |     Apr 20, 2020

    Does one of these options available today satisfy the requirement?

    Option 1:
    An administrator can specify a different server authentication entry for each target system whereby the SERVER keyword on the ADDSVRAUTE CL command is the associated RDB name. This requires that the administrator change their DDM files to be RDB DDM files via the CHGDDMF CL command. They would specify *RDB on the RMTLOCNAME keyword and the RDB name on the RDB keyword. This also allows for two-phase commit with DDM if TCP/IP - side benefit. This works the same for DRDA. Each server authentication entry would then specify the target side user profile and password. Using an approach where each local user shares a set of target profiles per system looses auditing accountability for the changes. IBM recommends the local user and the remote user user profiles be the same to retain this accountability. This option can still be used to implement that but does have more overhead.

    Option 2:
    An administrator could instead have a matching user profile on the source and target for every user connecting, Both userid and password must match for this implementation. Also, the QPWDLVL system value would have to match (pre-7.4 limitation). This would allow them to use the conjoined mutual authentication method to connect (if no server authentication entry exists). See environment variable QIBM_CONJOINED_MUT_AUTH to enable this option. Option 2 does not eliminate Option 1. They can co-exist. Users can still use server authentication entries or SQL CONNECT statements that specify a password which will always take precedence over the Option 2 implementation.

    https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/ddp/rbal1sourcesecurity.htm

  • Guest
    Reply
    |     May 17, 2019

    You may need to call me.

    The PROBLEM is with the QDDMSERVER option.

    I work with a number of systems and LPARS. The remote systems have the same USER ID but each have different passwords. As a result, when I push data to the remote systems using DDM, I have to enter the password every time. This prevents me from automating the processes as the password has to be changed every time. Our corporate security team do not want us to store the passwords outside of the OS as that opens the company to security risks. As a result, I am unable to implement programmatically changing the password every time I communicate with another system.

    I get the following error message each time: CPF9190 or CPF9172..

  • Guest
    Reply
    |     May 16, 2019

    The purpose of the SVRAUTE entries is to identify the remote user ID and password to use to connect to the specified server for the local user ID. If the remote user ID was included in the key, then there could be multiple entries for a specified server, and so there wouldn't be a way to determine which of the remote user IDs to use.

    Is there a reason you can't do this:

    ADDSVRAUTE USRPRF(USER0) SERVER(SYSTEM1) USRID(USER1) PASSWORD()
    ADDSVRAUTE USRPRF(USER0) SERVER(SYSTEM2) USRID(USER2) PASSWORD()
    ADDSVRAUTE USRPRF(USER0) SERVER(SYSTEM3) USRID(USER3) PASSWORD()
    ADDSVRAUTE USRPRF(USER0) SERVER(SYSTEM4) USRID(USER4) PASSWORD()

  • Guest
    Reply
    |     May 1, 2019

    Due to processing by IBM, this request was reassigned to have the following updated attributes:
    Brand - Servers and Systems Software
    Product family - Power Systems
    Product - IBM i
    Component - Security
    Operating system - IBM i
    Source - Client

    For recording keeping, the previous attributes were:
    Brand - Servers and Systems Software
    Product family - Power Systems
    Product - IBM i
    Component - Languages - CL (Control Language)
    Operating system - IBM i
    Source - Client

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.