Joakim K Posted January 31, 2019 Share Posted January 31, 2019 The password reset portal password policy does not have any way of making "require password complexity" work as intended. The options are: Minimum LowerCase Characters * : Minimum UpperCase Characters * : Minimum Numeric Characters * : Minimum Symbol Characters * : Preferred Password Length* : Requires Upper And Lower Case* : Yes No Failed Reset Message* AD on the other hand, only supports setting complexity true or false. If it is true, you need 3 out of 4 character types (UPPERCASE,lowercase,numbers, special characters). My suggestion is that you either change the "Requires Upper And Lower Case * "-option to "Active directory policy requires password complexity", or adding that option as a new option. (It would also be super neat if you could implement a feature of prompting the user that the failed password reset is because of it existing in the haveibeenpwned database, right now it is giving the same error as you are submitting in this policy) Link to comment Share on other sites More sharing options...
support Posted February 1, 2019 Share Posted February 1, 2019 Hi Joakim, The Policies in our Password Reset Portal are designed so you can set a minimum requirement, and if the user fails to meet the requirements it will give them a detailed explanation of what requirement they haven't met, ie "Still required: 1 capital letter" or "Still required: 3 more letters". (I'm adlibbing here, but this is approximately what the error says). You cannot click Save until you have met the requirements. If the user passes that first "Passwordstate Policy" it will also fall back to Active Directory and check the complexity requirement for the user in AD. The user may have a more strict password policy in AD which they'll also have to meet to reset their password. If they fail this AD requirement then it will error saying "Did not meet Password Complexity Requirements", in which case they'll have to try again. Also, with the haveibeenpwned check, we deliberately omitted using this terminology in our error message, because the portal is designed for day to day users who aren't IT savvy as such, and most non IT people wouldn't know what haveibeenpwned is. We thought it would be confusing so left it at a very general message which is "Password Not Allowed. Please try again" Regards, Support. Link to comment Share on other sites More sharing options...
Joakim K Posted February 1, 2019 Author Share Posted February 1, 2019 Yes, but personally I think it would be better if the passwordstate policy could be more "AD-friendly", and an option could be just "require AD complexity", checking for 3 out of 4 character types being used. To get around this, we have enforced uppercase, lowercase and numbers, but that is annoying some of the users that are used to being able to use special characters instead. Is the haveibeenpwnd error message working even if you set a custom Failed Reset Message? If so I was mistaken, sorry! Link to comment Share on other sites More sharing options...
support Posted February 1, 2019 Share Posted February 1, 2019 Thanks for your request Joakim - we'll need to look into how we could improve this in a future release - which may be a bit tricky when different users can have different Fine Grained Password Policies applied to their account. Regards Click Studios Link to comment Share on other sites More sharing options...
Joakim K Posted February 2, 2019 Author Share Posted February 2, 2019 True! if possible - the best solution might be to have the portal adhere to the output of Get-AdresultantPasswordPolicy -identity "user that needs the password reset". If so, that would be the only setting we need. Link to comment Share on other sites More sharing options...
support Posted February 2, 2019 Share Posted February 2, 2019 Hi Joakim, We do adhere to any password policies applied to a user's account, assuming they pass the Password Policy settings set within Passwordstate first. But it sounds like you want our Password Policies to somehow mimic what AD also does. Regards Click Studios Link to comment Share on other sites More sharing options...
Joakim K Posted February 3, 2019 Author Share Posted February 3, 2019 Exactly! We do not wish our ADresultantpolicy and passwordstate policy to differ (except the haveibeenpwned check), and my guess is that that goes for most customers. Link to comment Share on other sites More sharing options...
support Posted February 3, 2019 Share Posted February 3, 2019 Okay, thanks Joakim. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.