Description of problem:
Allow the user to change an expired password as a part of the User Portal login process
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Attempt to log on to the User Portal with an account that's expired in Red Hat IdM
2. Message is displayed showing password has expired.
No further action is possible and no further information is provided to the user for how to change his/her expired password.
A password change dialog appearing allowing the user to change his/her expired password as a part of the login process to the User Portal.
Some further info:
>> 2. This creates a problem, as every time a password is reset in IPA, it's automatically set to be
>> expired so the user will change password at next logon.
>> Is there a way around this?
> use the IPA web form to change the password by the user.
This is a manual process for the user to be aware of and will generate calls to the helpdesk. I believe it would create a much better user experience to allow the password to the changed as a part of the login procedure.
Or adding an option to work the same way as our current Secure Global Desktop solution allows us to do; Logging in the user with the expired password, and then the password is being changed as a part of the login procedure to the Linux Desktop.
And this is a scenario that will be coming up often, as that every time a new user is added or a password is reset for an existing user in Red Hat IdM, the password is set to be expired so that the user is forced to change it on next logon, and no option is provided in Red Hat IdM to work around this.
In our environment the users who will use the Linux VDI solution through the User Portal will be using a Windows desktop and this will be their only link into the Linux environment where they're required to log on using a username and password from Red Hat IdM.
3.3 allows adding a message of the day (motd) which can be use to specify the url.
next step will be to add such url at per-domain level via manage-domain.
can we use this bug to track the per-domain level url message?
after that is implemented, worth revisiting if trying to solve per specific authentication domains the change password integrated implementation (since there is no standard to doing this)
*** Bug 1037843 has been marked as a duplicate of this bug. ***
Ok. I have not found the motd option in 3.3 yet. I'm testing RHEV 3.3 beta. Was this motd feature removed in RHEV?
Would your path to implementing a password change mechanism for Red Hat IdM (IPA) be easier as the IPA team has already developed this for their web interface, and perhaps some of this can be re-used for ovirt/rhev?
packaging/etc/engine-config/engine-config.properties:UserMessageOfTheDay.description="Message of the day to be displayed in the User Po
you can set UserMessageOfTheDay via the config utility
I don't have the 3.3 beta env available to me just now, but I suppose this will have to do for 3.3.
However I would like to keep the request open for enabling a password change feature in (hopefully) the next version of ovirt/rhev.
The generic ldap provider will be able to change password if ldap server supports the rfc or modify attribute.
The question is if we can make it in time to modify the UI as well.
supported at extension side if ldap support password modify extended request and supports anonymous bind to achieve this (support changing expired password).
* active directory does not support password modify extended request.
* ipa supports password modify extended request but for some reason it requires non anonymous bind
so in theory we can support in future ipa, after it will be fixed.
the effort is still to enable the front-end/backup logic.
AAA extension API support password modify, LDAP extension supports the password modify extension, now it is the engine task to actually use it.
Your provider will be the first that support proper password change, I suggest you implement the engine side as well.
moving to 4.0, wasn't delivered feature freeze
This is an automated message.
This Bugzilla report has been opened on a version which is not maintained anymore.
Please check if this bug is still relevant in oVirt 3.5.4.
If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution)
If it's an RFE please update the version to 4.0 if still relevant.
I requested this feature for changing password on an IPA domain as a part of the login process to the user portal. As far as I am aware IPA still only supports password changes over Kerberos.
Alon, why setting version to the unmaintained 3.3?
According to https://bugzilla.redhat.com/page.cgi?id=fields.html#version
If bug report is a feature request, it should be set to the version you would like to see problem fixed in.
So it should be 4.0.0.
this is an issue in 3.3, removed version if you think it is a feature request and not a bug... feature request should have the target release, not version.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Ravi - this should move to you, right?
And depends on the SSO RFE, right?
Oved is right this depends on SSO RFE and will be handled as part of the SSO work targeted for 4.0