This portal is to open public enhancement requests for IBM Sterling products and services. 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).
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:
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 an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
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.
Thank you Henry for your feedback. We didnt emphasise that a password is only temporarily stored on disk. We envision the steps in a customer’s script being:
Pull a password from a password vault into an LCU file
Execute the Windows CLI
Delete the LCU file
The password is only on disk during the execution of the Windows CLI.
Regards,
James
If I am understanding the proposed solution correctly, it unfortunately does not satisfy all requirements from a PNC perspective. With the proposed solution, the credentials would still be stored and/or accessed locally on the server running connect:direct. Yes, the credentials in cddef.bin are encrypted, but that is current functionality. So, we see just two minor benefits with the proposed solution:
The user running LCU would no longer need to access a centralized password vault such as CyberArk to fetch the password in order to enter it into the LCU utility.
The password would not need to be exposed to the person running the LCU utility.
Our recommendation is to fetch the password using the password exit in real time, when outbound transmissions are initiated either by the Connect:Direct CLI or Connect:Direct File Agent. Essentially, we'd like to use the existing Proxy/Local Authority/Password exit process for these type of outbound transmissions. This would have the following benefits:
Static credentials would not longer be stored locally on the server (cddef.bin), reducing risk that with the proper tools, someone with knowledge of the encryption method could decrypt the credentials
Passwords could be changed / cycled by a centralized password vault such as CyberArk as often as required by company policy, it could be daily.
Same dynamic password solution for all transmissions, no matter how initiated and direction.
Hello team,
Attached the detailed solution draft for the RFE. We would be happy to provide a walk through if you need. Please let me know your thoughts.
Thanks,
James
Dear IBM,
Please kindly progress this enhancement to delivery - please include the Password Exit feature in the CD Windows CLI in a future product release of Connect Direct.
The rapidly changing security landscape in the banking and finance sector requires all passwords to be stored securely in a Password Vault. Inside the Vault, passwords can be reset without impacting file transfer batches, because the password gets fetched in real time. This approach improves the security posture of the file transfer process. By adding the Password Exit functionality to the CD Windows CLI, it enables outbound file transfers to operate at the same level as inbound / proxy users.
The expectation is that adding password exit to CD Windows CLI will be slightly easier this time around because it has been built once before for proxy users.
I am working in a major ('big four') Australian bank that has audit and compliance requirements for password security.
Hello John,
There are no programmatic APIs for client connection utility. The purpose of the client connection utility is to enable current Windows users to configure connection defaults in their registry. Providing password exit support for the utility is not aligned with the broader market needs and product trajectory. We genuinely see the need to add the password exit support in CD Windows CLI. We have got a similar RFE request from other banking customer , if the idea resonates with your use case, please feel free to upvote/ comment against the RFE. This will help us to prioritize the RFE as the reach is higher.
Thanks,
James
The Password Exit feature covers proxy users can the functionality be made available for client connection users?
Thank you for taking the time to provide your ideas to IBM. We appreciate your willingness to share details about your experience and your recommendations.
After our initial review, We would like to further discuss this enhancement with you. I have included some key members from our development team for our bi-weekly call coming Monday so that we can discuss this quickly.
Look forward to connect with you. Thanks and Appreciate your patience.
Thanks,
Product Management