IBM System Storage Ideas Portal
Hide about this portal


This portal is to open public enhancement requests against IBM System Storage products. 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 Functionality already exists
Workspace IBM Spectrum Virtualize / FlashSystem
Created by Guest
Created on May 10, 2022

RELATED IDEAS

Add 'fail-back to local' authentication for Remote Authentication users

See this idea on ideas.ibm.com

Ideally, for Cyber-Security, all Spectrum Virtualize logins should be set up for Remote Authentication, with MFA (Security Verify/future ADFS?). And the Superuser account would be the only Local account, disabled per SGC Best Practices.

However, it is very common that the supporting AD/LDAP/SV/ADFS servers are hosted on the very storage that is utilizing them for Remote Authentication. This can present a dilemma in situations where those supporting servers are not available, including a Cyber-Attack. In such a situation, on-site access (or IBM Support assistance) is required to turn on the superuser account in order to gain login access to the storage system. (And in the meantime, bad actors who have taken control of your supporting infrastructure are working hard to compromise your storage as much as possible.)

This could be mitigated by implementing a 'fail-back' mechanism, where specifically configured Remote Authentication users would utilize locally configured password/SSH key to authenticate to the storage system in the event that supporting Remote Authentication/MFA servers/services are not reachable by the storage system for a specified amount of time. i.e. Remote Authentication is enforced at all times for the given Remote Auth. user, until the Remote Authentication services time-out is reached, at which point the Remote Authentication user account would accept local authentication credentials.

Cisco TACACS/RADIUS has had this implementation for remote authentication for at last a dozen years, and I've observed it being implemented at numerous high-security network infrastructures.

Idea priority High
  • Admin
    Philip Clark
    Reply
    |     Jan 13, 2023

    For multifactor authentication, this is already supported. There is a parameter when you configure MFA that selects what behaviour you want:

    svctask chauthmultifactorverify -failmode ( secure | insecure )

    • Secure: means that if the MFA server can't be reached that you can't login

    • Insecure: means that if the MFA server can't be reached that you can login with just a single factor

    In the security world, "insecure" mode is frowned on. A more secure way of configuring your system is to have secure MFA enabled for most of your users and then have some other way of accessing your system when the MFA server is broken. For example you could configure a security admin without MFA but with CLI only access using a SSH key + password as a way of getting emergency access to your system.

    The technician port also provides another way of getting emergency access - although you will obviously need physical access to use this.


    For remote authentication, you can enable/disable MFA and password+SSH key controls on a per user group basis. You can also choose whether a user group has CLI, REST and GUI access. For example:

    • Create an emergency_access user group with a local SecurityAdmin user, configure this with password+SSH key for best security and disable GUI+REST access so that you have to use the SSH key and a password to login

    • Create another user group using remote LDAP authentication, no MFA and enable just REST access and use this for automation (e.g. Ansible playbooks)

    • All the other user groups use remote LDAP authentication + MFA and/or Single Sign On. Best security practice says you do not permit a fall-back to allow these users to login if LDAP/MFA/SSO is not working.


    One additional observation is that these security best practices are hard to find. So we have opened a development epic to enhance the documentation and help provide some of these best practices above.

    Thanks,
    FlashSystem Team

    philipclark@ibm.com

  • Guest
    Reply
    |     Jun 7, 2022

    Alternatively: Enable creation of an account that uses only local authentication. Make this account disabled whenever remote authentication services are operational, and automatically enabled when remote authentication is not operational.

  • Admin
    Philip Clark
    Reply
    |     Jun 7, 2022

    Thank you for submitting this Idea. We are currently evaluating your request.


    Thanks,

    SpecV Team


    philipclark@ibm.com

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.

Contact IBM Privacy Terms of use Accessibility