samnorth

Something to chew on for future releases for sure. Thanks for the response.

We consistently have users to request access to multiple passwords, and currently it doesn't appear there's a way to respond to multiple requests at once. Am I missing something, or should I submit this as a feature request. Thank you for your time in advance.

Any updates on adding a multi-factor timeout setting for users?

Greetings! I noticed that emails generated by the Community service don't pass email SPF authentication checks, and also that they aren't being DKIM signed. As a result, all emails from "Click Studios Community <support@clickstudios.com.au>" will end up in our spam filters and I'm sure other email systems as well. Here is a section from the headers of a recent message: Received-SPF: neutral (google.com: 202.136.110.111 is neither permitted nor denied by best guess record for domain of support@clickstudios.com.au) client-ip=202.136.110.111; Authentication-Results: mx.google.com; spf=neutral (google.com: 202.136.110.111 is neither permitted nor denied by best guess record for domain of support@clickstudios.com.au) smtp.mailfrom=support@clickstudios.com.au From what I can tell there isn't even an SPF record for the clickstudios.com.au domain. The DKIM signature isn't critical but ClickStudios should at least have an SPF record configured to validate where email is sourcing from for the domain. Adding an SPF record to your DNS zone file should be fairly easy and quick to resolve I would think. Thanks in advance. Ryan

Thanks for the reply and no worries on the delay. 1. Makes sense that you would presumably need to support full self-registration within all supported MFA solutions. We do have our own on-premise Duo self-registration portal that users are using, so this isn't a huge issue for us. 2. Great news! Thanks for considering this feature for an upcoming feature request. If your team has further questions for our side, please let me know. Thanks! Ryan

Does PasswordState support the use of TLS 1.2, and if so what are the minimum system requirements (IIS version, PasswordState version, etc) for this? I couldn't find an existing thread on this, and also didn't see anything in the recent change logs. My apologies if I overlooked this in a previous thread.

Any comments / thoughts on the separate 2-factor timeout option here? Multiple teams use this solution throughout the day, and we want to avoid lengthening the login session timout value. Allowing a separate timeout value for 2-factor verification would be a valuable feature addition. Suggestions for re-triggering a user to resubmit 2-factor auth could include attributes such as: the source IP of the requster's device changes, browser cookie is different because the user issued a login from a different browser, etc.

I have a few requests here. 1. We're starting to leverage Duo for multi-factor authentication (MFA) quite heavily within our company. The current Duo integration works well for pre-configured users within Duo, but unfortunately lacks support for Duo's "inline self-service enrollment" feature. Reference: https://guide.duosecurity.com/enrollment We would like to see this capability added to help aide in registering new and current PasswordState users with our Duo application. 2. As an add-on to the current & future MFA capabilities, I would like to see a separate timeout value for the MFA token. This feature would provide administrators with the ability to set a separate timeout period value for MFA tokens, which would be separate from the login session timeout value. Example: We could set the inactivity timer for logins to 15 minutes, but a value of 8 hours for MFA tokens. This way users don't have to go through the MFA process again until the 8 hour time period expires.

Thanks for the info. I'll be applying the update tomorrow night during change window, and will provide feedback following the completion.

I'm trying to upgrade our instance from 7.1 (Build 7185) to the newest version 7.2 (Build 7200), but I continue to receive an error when upgrading via the web GUI (see attachment "UserName incorrect"). I'm able to perform a backup from the web GUI with these same configured credentials without issue (see attachment "Backup successful"). Any thoughts on why I'm experiencing what appears to be a conflicting scenario? Thanks in advance.

So good call on a few angles here. I'm not going to close the book on this one yet but here's what I've done to alleviate these behaviors (for now): 1) I disabled the 1Password and PasswordState extensions within Chrome 2) I added the 'passwordstate.exe' service executable to the McAfee On-Access Low Risk Process Policy exclusions which essentially excludes this process from On-Access scanning, as well as any files/folders that process interacts with. 3) Cleared all cache and history related to PasswordState on my workstation I was watching the Security logs on the server the entire time to see if anything struck me as odd, but just normal audit behaviors. Nothing in the App log FYI. Once behavior seemed to clear up, I re-enabled the 1Password Chrome extension and validated the issues didn't return. Like I said, I'm not 100% convinced this has been averted, but I'll keep an eye on it for a while. Like I mentioned, these symptoms only happened within Chrome -- not Firefox or Safari. Thanks for the assistance for this.

Version: 7.1 (Build 7123) A few weeks back, I started getting prompts to continuously re-authenticate when trying to perform any action within the PasswordState interface (i.e. search for a password, etc). I've attached a screenshot for reference. This is occurring only within Chrome -- not within Firefox or Safari. All browsers are on the latest & greatest version. We have AD integration for our accounts + Duo for MFA, and I also have the Chrome extension enabled & configured. System details: OSX 10.10.2 Chrome Version 41.0.2272.76 (64-bit) Any thoughts on what the issue could be?