none
Supressing Registration Page After Login - Suggestions RRS feed

  • Question

  • I inherited a FIM 2010 R2 environment and I'm quickly trying to learn the ropes but I've run into an interesting situation that I was hoping to get some help with.  I work for a retail chain that uses desktop machines for their registers.  In some of our locations, when a cashier logs on to a register/PC they are immediately presented with the FIM Password Registration web page.  This causes a problem for several reasons, but the biggest concerns are that 1) Cashiers have limited access/control of the desktop so they can't always easily close out of the window, 2) Most locations use one account to log on to all of the registers and the passwords are centrally maintained.  They do not want Joe Cashier randomly changing the password on accident and bringing down the retail floor.

    Ideally, these accounts would be separated out in their own OU and not be part of the Password Reset scope.  Unfortunately, this is not the case.  I'm working on getting that changed, but it's going to be awhile before that can get approved and completed.  In the meantime, I need another solution to suppress that registration page.

    We can register the account in FIM, but that's one more step towards someone being able to accidentally change it and I'm not entirely comfortable with that.  So here are my questions:

    1. Is there a way to simply prevent the logon page from coming up regardless of if the account is registered or not?
    2. On the FIM Admin Portal when Editing a User-->Advanced View-->Extended Attributes, there is a "Register" checkbox.  Does checking this box tell the environment that the account is "registered" and will then stop the registration page from showing up?
    3. In the same area, would the "AD User Cannot Change Password" prevent the password from being changed using the FIM Password Reset process?
    4. Is there something else I'm not thinking of that I can try?

    Any help or suggestions is appreciated!

    Wednesday, November 6, 2013 3:38 PM

Answers

  • The set's "Criteria-based members" is probably the way to go.  For example, if the accounts are called pos_1, pos_2, etc., add a rule "Account Name not starts with 'pos_'".

    There are many ways to construct sets but the above is a simple way if you're not very familiar with FIM.

    This will solve two problems at once: the users not in the set won't be prompted to enroll, and those that might have already enrolled won't be permitted to use the SSPR portal.


    Steve Kradel, Zetetic LLC

    • Marked as answer by HuskerSMJ Monday, November 11, 2013 9:19 PM
    Wednesday, November 6, 2013 4:41 PM

All replies

  • The best approach is to modify the Password Reset Users set to exclude the accounts, which does not require changing their OU in AD; anything less is not really going to get the job done.

    FIM SSPR is a password "set" not a "change," so the ADUC option will have no effect.


    Steve Kradel, Zetetic LLC

    Wednesday, November 6, 2013 4:04 PM
  • Thanks for the reply.  So looking at the Password Reset Users Set window, would I add this account to the "Members To Remove" field under the Manually-managed Members tab?  There are no accounts listed in the Current Members field, so I wasn't sure if this was the correct place or not.
    Wednesday, November 6, 2013 4:29 PM
  • The set's "Criteria-based members" is probably the way to go.  For example, if the accounts are called pos_1, pos_2, etc., add a rule "Account Name not starts with 'pos_'".

    There are many ways to construct sets but the above is a simple way if you're not very familiar with FIM.

    This will solve two problems at once: the users not in the set won't be prompted to enroll, and those that might have already enrolled won't be permitted to use the SSPR portal.


    Steve Kradel, Zetetic LLC

    • Marked as answer by HuskerSMJ Monday, November 11, 2013 9:19 PM
    Wednesday, November 6, 2013 4:41 PM
  • Steve has pointed out the most proper solution. Another way to solve it would be to remove the SSPR client from those computers. That however would prevent anyone from using those computers to do a password reset (which may or may not be desired).

    David Lundell, Get your copy of FIM Best Practices Volume 1 http://blog.ilmbestpractices.com/2010/08/book-is-here-fim-best-practices-volume.html

    Wednesday, November 6, 2013 11:20 PM
  • Steve,

    OK, I'm going to give the rule a shot.  Couple of questions on the rule setup:

    1. do I need to have the single apostrophe's in the rule, or was that just something you put in to identity the username in your post?
    2. Once I create the rule and submit it, is there anything I need to do on the portal, the servers, or on the client to make that change visible?  How long should it take before I should see it take effect?

    Dave,

    Thanks, also, for the response.  That was something we have considered and done for some immediate need machines, but it's not the best solution for us.  There's too many machines we'd have to hit to uninstall the client, and with my predecessors not having the best (read any) standardization for PC naming conventions, it's not always easy to tell the yes machines from the no machines to do it remotely.  Doing it by user account would be ideal.

    Friday, November 8, 2013 2:20 PM
  • The single quotes are just for clarity in the post; you won't want to enter them into the Set's expression criteria.

    The new behavior will be effectively immediately on saving the changes to the Password Users Set.


    Steve Kradel, Zetetic LLC

    Friday, November 8, 2013 2:34 PM
  • Thanks Steve.  Your suggestion solved my problem.  I appreciate the help!!
    Monday, November 11, 2013 9:19 PM