Skip to Main Content
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 (

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 ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Workspace IBM i
Categories IBM i Access Family
Created by Guest
Created on Apr 14, 2020

IBM i ACS Client - Lock down connection settings for Single Sign On

We recently configured SSO for deployment and will be using Kerberos for authentication. We currently are using AD for authentication to the AS/400. A user could circumvent the client configuration for IBM i signon information and change "Use Kerberos authentication; do not prompt" to use IBM i Access Client Solutions setting. We would like to be able to lock down that setting so it cannot be changed in the client. We use SSO so that once the AD account is disabled they would no longer be able to login to the AS/400. The way the settings are today, they could change the setting in the client and if the AS/400 profile is not disabled right away, they would be able to still login to the AS/400. This is related to our internal controls for SSO and prior to deployment of the new client would like this setting locked down with a setting or configurable only by an administrator.

Use Case:

AD account gets automatically disabled from our HR system when an employee is terminated, but secondary systems are not always locked down immediately until a ticket is processed. By SSO and AD being leveraged, the employee would no longer be able to login to the AS/400. If they are able to change the setting in the client, they could circumvent SSO/Kerberos and login with their IBM credentials. This cannot happen for us.

Idea priority High
  • Guest
    Jul 31, 2020

    Thank you for submitting your Request For Enhancement. After evaluating your submission, the decision at this time is to not provide this support.
    Please see an earlier post for our recommended "best practice".

  • Guest
    Jul 28, 2020

    The CAAC has reviewed this requirement and recommends that IBM not implement this request. The recommendation from IBM, as described below, is a "best practice" that should be followed.

    Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.

    For more information about CAAC, see

    For more details about CAAC's role with RFEs, see

    Nancy Uthke-Schmucki - CAAC Program Manager

  • Guest
    Apr 20, 2020

    Instead of locking down the settings on the client, a more secure way would be to always have the user profile on the server set to PASSWORD(*NONE) on all your systems. This would prevent the user from using their credentials to access the system and would require kerberos for any interface requiring authentication. Once the AD account is disabled, they would have no way to sign on.

    Does this satisfy the requirement. If not, please explain.