Jump to content

Search the Community

Showing results for tags 'feature'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Essentials
    • Announcements
  • Passwordstate 8.x
    • General Support
    • Feature Requests
    • Feature Requests - Completed
    • Known Issues
    • Installing Passwordstate
  • Knowledge Base
    • General FAQs
    • Password Resets
    • Remote Session Launcher
    • Mobile Client
    • Passwordstate API
    • Browser Extensions
    • Password Reset Portal
  • Passwordstate 7.x
    • General Support
    • Known Issues

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Google Plus Account


Location


Interests


Biography


Location


Interests


Occupation

Found 12 results

  1. Hi, we just bought the passwordstate enterprise edition for our company and are very satisfied. Because we are a german company i would like to ask if there are any plans for adding the possibility to change the language to for example german. This would be a great feature and would help us to find more user acceptance. Thank you. Kind regards Achim
  2. Hey guys, Just a tiny suggestion: would it be possible for you to update the PasswordState Change Log webpage to include anchor tags in each update's header? For example, if I'd like to specifically link to build 8180, it'd be great to have something like https://www.clickstudios.com.au/passwordstate-changelog.aspx#8180. The changelog has grown to considerable size, so it'd help my colleagues if they didn't have to <ctr><f> for a buildnum. It could be as simple as changing this: <h3> Passwordstate 8.1 - Build 8180 (21st November 2017)&nbsp; <img src="/images/dbschemaupdates.png" alt="Database Schema Updates in this Build" style="padding-bottom: 3px;"> </h3> ...to this: <h3> <a name="8180">Passwordstate 8.1 - Build 8180 (21st November 2017)</a>&nbsp; <img src="/images/dbschemaupdates.png" alt="Database Schema Updates in this Build" style="padding-bottom: 3px;"> </h3> Take care! :)
  3. Good morning everyone :) The past two weeks we've discussed this a bit, so I thought I'd make it a real feature suggestion. I would very much like the possibility to define one-to-many relationships for accounts to hosts (1:N). The biggest use case I can think of for this, is Linux privileged user accounts in Linux/Unix environments where a centralized IAM-platform is not available. For example, a network with many IoT devices which allow SSH for management functions, but which cannot integrate with AD or LDAP. In such a case it would be a great hassle to define privileged accounts on a 1:1 basis. If I would be able to define one Linux account, with a strong SSH keypair (or a frequently rotating strong password), that is to be used on the relevant systems as the designated privileged user, that would be ever-so-helpful. #RunOnSentence.
  4. Hi guys, Isn't it great how you can just keep on learning new things in IT? I've been working myself through all manner of interesting topics and only now I've started learning about tools such as Swagger. Imagine my mirth upon learning that I don't necessarily have to hand-code a Powershell module (or another lib for a different lang), by having Swagger CodeGen make one for me! All that's required is an OpenAPI compatible documentation of your API! (as if that's a small matter...) Either way, I'd love it if you could put this on your long-term backlog. I imagine more people could find this useful!
  5. Hi guys, I'm very happy that Passwordstate offers external log forwarding! This allows us to send our audit logs into a syslog box that cannot be tampered with. Today we discovered that Passwordstate does not buffer messages if the syslog target goes down. Funnily enough it does buffer all the logs if you've never configured Syslog before, thus barfing thousands of entries into the newly minted target. But if you've already configured Syslog and the box goes down, then you'll never receive any of the logs between the down and up of the host. Would you please consider adding buffering to the external Syslog connection? Don't rely on UDP, make it TCP with connection-testing. And if the connection fails, mark the moment where you'll need to start buffering. Cheers, Thomas
  6. Hi again! in the Administration tab, you'll find menu options like Password Lists and Password Folders. These are awesome, because it sometimes happens that somebody does lots of work, then leaves after locking all other users out of these objects. These options in the admin-section allow you to manually fix broken access permissions. Now... If only the Hosts and Hosts Folders had the same feature! We're currently in a bind because colleague X set up the auto-discovery jobs and target folders, but set them exclusively to their account. And now they're on a holiday! Yikes! I really don't want to hack these lists through MSSQL, so could you guys add a management feature to the admin-panel that allows us to fix permissions on Hosts Folders? Cheers, Thomas
  7. Hi guys! The current implementation of AD-coupled security groups works well enough for us. However, in our current use-cases even the 5-minute fastest-sync-possible may not be fast enough at times. Our sysadmins need to jump through an RBAC-portal to activate certains roles and AD-groups before working on specific cases, which means that they don't have access to their PasswordState groups 24x7. In case of a huge fire / outage /end-of-the-world even five minutes may make a difference, no? Would it be possible to change PasswordState's behaviour in such a way that it verifies the Active Directory MemberOf information for a user when he/she logs in? I realize this may lead to N-amount of hops with nested groups, but I reckon you should already have a way of resolving those anyway. So to sum it up: real-time verification as opposed to a synchronized list of groups in the local database. Cheers, Thomas
  8. Hiya, I was poking around the MSSQL database backend for PasswordState and noticed a few fields that are not stored with encryption, while they could be (ab)used to gain access to sensitive data. Or to wipe tracks should an actor gain access to the database and/or PasswordState. Obviously it's imperative that the database backend is secured to the teeth, but it's also not unlikely that the designated DBAs do not have admin-rights in PasswordState. Having access to the database may thus lead to an escalation of privileges. Most notably: Valid usernames may be harvested from the database, but I realize there's not much we can do about that. The dbo.SecurityAdmins and dbo.SecurityGroupsMembership tables are unencrypted. Could it be that the GUID field plays a role in checksumming the data, to ensure that nobody is adding access rights to their own account? Valid usernames in dbo.PrivilegedAccounts are not encrypted, giving insight into juicy targets for other platforms. Is there some method of auditing the dbo.Auditing table? What prevents a DBA from diking out a bunch of incriminating evidence? Anywho... just some thoughts, while at the office in those lost days between one holiday and the next
  9. Hi again! Another day, another RFE I was wondering whether it'd be possible for you guys to include the browser extension installers with the base PasswordState installation, similar to what you already to with the Remote Session Launcher. Not all customers will have access to the browsers' respective extension / app stores, so it'd be great if they also came with the base installer. Cheers, Thomas
  10. Hi again! Eyeing your page on the secure design and implementation of PasswordState, I noticed that it's not yet possible to integrate with HSMs: Hardware Security Modules. Right now, when installing PasswordState, we're given a password-protected ZIP file that has the encryption keys to the password database. These are a vulnerable target and will be a sought-after prize for any attacker. Instead of handling the encryption keys in such a manner, I would like to request that PasswordState be remodeled in such a way that all crypto keys can be locked away in an HSM. I've already put Thales nShield HSMs to good use in other use-cases and environments, and they've proven very valuable. Not only does an HSM ensure that your keys will never be stolen (if implemented correctly), depending on the make and model they will also ensure safe and secure backups of the keys. Many HSMs integrate nicely with Microsofts CNG API, thus providing a standard method for applications to hook into them.
  11. Hi guys, Many thanks for all your quick replies and help so far! Sorry for seemingly spamming the boards with my questions I'd like it very much, if the host discovery jobs offered a feature similar to the account discovery jobs: automatically adding the discovered objects to a specific list. For example, I'm working with something like an "Unprocessed" list for newly discovered accounts, so we can have some form of queue for our administrators. I'd like something similar for the hosts. Along other lines, the hosts menu right now only shows hostnames when they're part of a list. Hosts that are not yet in a list don't show up in the menu-bar. Hence why I also would like the option to auto-add to a list. It's not a world-shaking feature and I'm sure my wants stem from an as-of-yet-sub-optimal workflow... But heck, if you can fit it on the backlog somewhere near the bottom, that'd be great
  12. Hey again. Poking around the System Settings section of the Administration panel I saw something that deserves a spot on /r/mildlyinfuriating Please refer to the attached screenshot: the two "disable" options switched sides. If you're careless and want to disable accounts in both cases, you may be tempted to click the right-hand option both times (because the first time that's "disable"). In the long run that may lead to inadvertently deleted accounts. So yeah, please make the delete/disable pairs line up
×