This is an IBM Automation portal for Integration 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).
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.
We have increasingly strict compliance requirements to fulfil, including ensuring that no unnecessary authority records exist. that would help us a lot.
This feature would be absolutely helpful - especially if you have taken over an aging system where the focus was not necessarily on this data and the correct order (first delete the permissions in MQ and then the user in LDAP) was almost never followed.
Yes, there are workarounds (thanks to Mark), but this is not necessarily the safe solution I might advocate in good conscience for a production system.
This issue occurs if a user or group can't be resolved in their original location/dn. Isn't a /FORCE option or similar possible to develop, to enforce remove an AUTHREC entry by an MQ administrator?
This is something we would like to implement in a future version of MQ - but it is not just a matter of igoring the "id no longer exists" error.
Any updates should be exposed to both the MQSC "SET AUTHREC" interface and the "setmqaut" interface.
Note IBM opened APAR IT14316 to address this then later canceled the APAR. I hope this RFE can be implemented. I understand the need to check if the user or group exists when adding OAM authority, but when issuing '-remove' the check should not be in place.