Simplify ADDUSER support with ALTER access to IRR.PASSWORD.RESET

This item is a valid requirement but unlikely to be given high enough priority to be placed into the product plan. If this requirement is high value, please re-open it, or open a new requirement.

I recommend a slight modification to this idea. Have ALTER access allow setting passwords for PROTECTED IDs but only with resources IRR.PWRESET.TREE | .GROUP so that the scope of this authority can be restricted. IRR.PWRESET.EXCLUDE resources could further limit the scope.

As this has been requested longer ago it would be nice to get a clearer status whether it has a chance to get implemented within a shorter time range. Can you provide such a clearer status? Many thanks in advance...

Please be so kind and let me know a further status, as the customer ask me sometimes about it. Thanks.

The colleague from the original PMR asked me for a more detailed status. As I do not have direct contact to development I only can add a further comment here. He would like to see some progress as the status "Uncommitted Candidate" is seen for a long time already and no update happened since Nov 16, 2016.
Is there a time period that we can expect a new update or can the status be kept without update for a terribly long time and if so how long can it be?
Many thanks in advance for a short explanation on this.

Several comments have been added in the meantime, including mine on 24 Oct 2016. I meant this comment as being more information but the status of the RFE does not change from "Need more information". So, what exactly do you need and how to provide it? I thought that a comment is the right and only way. Can you give me some clarification on this? Many thanks in advance...

Thanks for your update. All what you wrote is clear and accepted. But the customer asked for a solution, and from my point of view it should be possible for a security team like us (my team) is able to delegate to activate protected users as well without system special authority. And exactly this is missing. Therefor the suggestion. If there is no need to delegate this functionality, we must not use alter access to the profile.

We are talking about a really very large account with a lot of systems. The problem is, the protected attribute and so the user help desk (they are a lot of people) have authorization by IRR.PASSWORD.RESET Profile.
The Customer process is, when userids have been defined with ADDUSER procedure, the user help desk have to set a initial password. But they can not do it. And we can not give all people of the team special or group special.
From my point of view the security team should be able to give needed authorization by the Facility profile as well for protected user. This makes sense from my point of view. Thanks.

Eliminating the security exposure in z/OS V2R2 was excellent, of course. Changing the the processing for creating new IDs is not that easy as it is a combination of an automated process (where the installation does not want add explicit temporary passwords) and setting a temporary password in a next step by people being authorized as low as possible. This processing could be continued to be used when accepting this small request.

Note that prior to V2R2, adding a user without specifying a password did not define a user without a password, the user's password defaulted to the name of his or her default group. This was a security exposure which we eliminated in V2R2. Have you considered updating your procedures to specify a password at ADDUSER time? This password will also be expired like one set by a HELP desk person with IRR.PASSWORD.RESET authority. We believe that specifying ADDUSER with an expired password is no less secure than requiring the user to contact the HELP desk to get one assigned.

Creating a new RFE based on Community RFE #95051 in product z/OS.