Joakim K

Done! Thank you.

I have confirmed that the PassiveNode key is set to false. In the application error log, these two errors seem to occur every 10 minutes that might be related to this? Application Error (1000) Faulting application name: wmiprvse.exe, version: 10.0.17763.1, time stamp: 0xdd9b741c Faulting module name: Microsoft.Management.Infrastructure.Native.ni.dll, version: 10.0.17763.1, time stamp: 0xb00293f9 Exception code: 0xc0000005 Fault offset: 0x0000000000068620 Faulting process id: ***** Faulting application start time: 0x01d632025977c9b5 Faulting application path: *\system32\wbem\wmiprvse.exe Faulting module path:*\Windows\assembly\NativeImages_v4.0.30319_64\Microsoft.M870d558a#\21970153b91daa4f6910864f3eb49d43\Microsoft.Management.Infrastructure.Native.ni.dll Report Id: 5b280a22-db8e-40bb-8428-88e280cc2457 Faulting package full name: Faulting package-relative application ID: .NET Runtime (1026) Application: wmiprvse.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.AccessViolationException at Microsoft.Management.Infrastructure.Native.ClassHandle.ReleaseHandle() at System.Runtime.InteropServices.SafeHandle.InternalFinalize() at System.Runtime.InteropServices.SafeHandle.Finalize()

I am having an issue with the password reset feature. If I expire an password enabled for reset, it takes many hours in the queue before it gets reset. In the debug log, it just says this every minute: 2020-05-20 11:18:08 - Starting processing CheckInPasswordResets. 2020-05-20 11:18:08 - Finished processing CheckInPasswordResets. 2020-05-20 11:19:08 - Starting processing of records already in the Password Reset Queue. 2020-05-20 11:19:08 - There are 0 records in the queue to process. 2020-05-20 11:19:08 - Finished processing of records already in the Password Reset Queue. But if I check in the Webportal, it is sitting in the queue. Eventually, it will realise it has a queue item and handle it properly (It could be related to "kicking on things", as it worked directly after performing an upgrade of passwordstate after disabling maintaince mode - But not by just putting it in maintainence mode for a few minutes). Any ideas what the problem might be and how to further debug this? EDIT: Might be worth mentioning that the database is running on an Azure SQL instance and that nothing interesting shows up in the IIS Event viewer log

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.

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.

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!

Has anyone gotten Kerberos authentication working with remote sessions in Passwordstate? (just add the user you choose to authenticate with in the remote session to the "Protected users" group in AD to enforce Kerberos).

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)

I would desperately need support in the API for adding remote session credentials and assign permissions to them. Right now this is blocking us from rolling out PasswordState as a remote session management solution.