Goossens

I have created a Powershell script that exports the PasswordState configuration data to JSON files. Feel free to try it out: https://github.com/ServaasGoossens/PasswordStateConfig2Json.

+1 for an export of all the configuration values in the Administration area. JSON format would be my preference.

+1

+1 In general, I prefer to use the Windows Integrated API instead of API keys. But the use case would be similar. Also: ability to move password lists from one folder to another using the API

+1 A roadmap would be great, even if you cannot promise any timelines.

+1 FIDO U2F is important, but FIDO2 with passwordless logins should not be ignored either. The best choice is probably to add support for WebAuthn to PasswordState. As I understand it, this would allow the use of U2F devices as a 2nd factor as well as FIDO2 devices for passwordless login. This includes Passkeys, Yubikeys, Windows Hello and others. Platform support for WebAuthn is very good nowadays. Refs: https://fidoalliance.org/fido2-2/fido2-web-authentication-webauthn/ https://www.nitrokey.com/blog/2022/fido2-webauthn-passkeys-2022-and-2023 https://support.yubico.com/hc/en-us/articles/360016615020-Operating-system-and-web-browser-support-for-FIDO2-and-U2F Related:

+1 Please include Windows Hello (which is also FIDO2 certified)

+1 for the password list recycle bin

+1 Slightly related:

+1 We have also started sending PasswordState's log data to a SIEM. Given PasswordState's support for sending log data to a syslog server, I assumed that the syslog standard would be followed. But, unfortunately, we observe that the data sent over TCP does not comply to RFC 6587 section 3.4, nor does it comply to RFC 5424 section 6. Besides, a more structured log format would be much appreciated, using a modern standard, as described by JohnB above. Thank you.

+1. Imho, -UseSSL should be the default in all scripts that do WinRM. Another option (or workaround) would be to allow disabling built-in powershell scripts. I can then add my own versions of the scripts and be sure that the originals can no longer be used.

+1

+1

+1 This request is similar to the one below:

+1

Please consider these two features: To make time based access easier to use, I'd like to set a default expiration time in the password list options, so that new permissions have time based access enabled unless it's explicitly disabled. To make the existing option "time based access mandatory" more effective, it should be possible to set a maximum expiration time. As an illustration of how I envision these options I made this rough mock-up:

+1

+1, a more complete REST API supporting create/read/update/delete for all main entities (including permissions) would be really helpful.

+1

+1

+1 Also: I'd rather have the current - bad - password stored in PasswordState (so that its quality and replacement can be monitored) than having it stored somewhere outside PasswordState. So, first securely store the bad password and then replace it by a good one (which can not always be done immediately).

+1

On our PasswordState server (V9, several build nrs), this intermittent error occurred several times, with weeks and even months in between. In the end, we found that it was caused by a bug in .NET version 4.7. When the issue occurs, the event log has warnings containing the following: Log Name: Application Source: ASP.NET 4.0.30319.0 Level: Warning […] Exception information: Exception type: HttpException Exception message: The file '/Default.aspx' has not been pre-compiled, and cannot be requested. Further symptoms: Restarting the website or rebooting the server does not solve the issue. Restoring a recent backup of the VM solves the problem. The following references led me to the bug in .NET 4.7: https://techcommunity.microsoft.com/t5/iis-support-blog/the-file-has-not-been-pre-compiled-error-and-solution/ba-p/945340 This intermittent error may show up in Event Viewer when your application fails to load: “The file has not been pre-compiled, and cannot be requested”. The intermittent nature of the issue makes it difficult to troubleshoot it but there are a couple of possible root causes and solutions. There is a known bug in .NET Framework 4.7.x that causes this issue https://stackoverflow.com/questions/55272598/sporadic-error-the-file-has-not-been-pre-compiled-and-cannot-be-requested According to Microsoft this is caused by a known bug with the .Net Framework versions 4.7.x triggered by memory pressure in the web server worker process. When [this specific issue] occurs, the .Net Framework creates a .delete file next to the assembly to mark it as stale. This will prevent the worker process from loading the file back into memory cache and causes the compilation error you are seeing. https://github.com/microsoft/dotnet/blob/main/releases/net48/dotnet48-changes.md .NET Framework 4.8 Release Notes Fixed an issue introduced in ASP.NET 4.7, where the unexpected removal of a particular type of cache item can result in an orphaned *.delete file that prevents web applications from running. [750653, System.Web.dll, Bug, Build:3734] I found one *.delete file in the "Temporary ASP.NET Files" folder, named "PasswordstateResources.dll.delete". Its timestamp matched the time of the first event log warning (and the time users started reporting issues). Deleting this *.delete file solves the problem. The real solution, in this case, is to upgrade to .NET 4.8. The stackoverflow article referenced above has several suggestions for a workaround while using .NET 4.7. We chose to temporarily set the private memory recycling conditions on the application pool in IIS, until we are ready to upgrade .NET.

Note that there's an RSS feed for the announcements forum (at the bottom). This forum has a new message per release.

+1