none
Can you disable "unlock only" in MIM SSPR? RRS feed

  • Question

  • Is it possible to configure the MIM SSPR portal to revert back to the behavior of FIM 2010 R2, and not show the options for "reset & unlock" and "unlock only"?  I would like it to just be the FIM 2010 R2 behavior of "reset & unlock" if possible.

    Thanks!


    Keith


    Monday, July 11, 2016 4:44 PM

Answers

  • Unsupported I'm sure... but there's nothing else to stop you editing Default.aspx in the Password Reset Portal folder and hiding the <div> tags surrounding the radio buttons (e.g. <div style="display:none">).

    • Marked as answer by Keith Crosby Thursday, July 14, 2016 1:20 PM
    Thursday, July 14, 2016 1:01 PM

All replies

  • Hello,

    I don't think so, as at least it is integrated into the binaries of the add-in, which you can not modify.

    You maybe have a chance to hide it from the web-pages but never thought about that, but I assume that is also not possible, too.

    What is the scenario that reset (which also do an unlock) should be used but not "unlock only" ?

    /Peter


    Peter Stapf - ExpertCircle GmbH - My blog: JustIDM.wordpress.com

    Tuesday, July 12, 2016 1:04 PM
  • The scenario is a domain migration.  We've updated MIM to reset passwords in the new domain, which then sync back to the old domain.  The problem is that not all users are using their new accounts yet.  Those that are have no issue, but those that are not do not get the unlock in the old domain.  So, we wanted to look into our options, one being hiding the ability to unlock only for now.  Once the migration is complete, there is no issue and we go back to normal. 

    Keith

    Tuesday, July 12, 2016 1:27 PM
  • Unsupported I'm sure... but there's nothing else to stop you editing Default.aspx in the Password Reset Portal folder and hiding the <div> tags surrounding the radio buttons (e.g. <div style="display:none">).

    • Marked as answer by Keith Crosby Thursday, July 14, 2016 1:20 PM
    Thursday, July 14, 2016 1:01 PM
  • Not a bad idea - Thanks!

    We've already had to do some temporary modification of that file to add some javascript to manipulate the supplied username and make sure it authenticates to the proper domain regardless of what the user enters, so what's one more change?


    Keith

    Thursday, July 14, 2016 1:20 PM