# Supported Features

Before you get into exploring Psono as a potential password manager, you may be wondering if it supports some basic features needed to fulfill your requirements. The following table shows what is supported in Psono.

If you are looking more for features for users, then you can find them here in our Features for Users

# Features for administrators

Features Supported Notes
Healthcheck Yes An API endpoint to monitor the health of your installation, including DB connectivity, time sync and various other
Prevent old passwords Yes Old passwords can be blocked without compromises for the "never send the password to the server"
Restrict 2FA methods Yes If administrators only want to allow particular 2FA methods, then they can restrict them.
Search by email address Yes By default the server does not allow to search users by their email address, but in a corporate environment administrators can enable this.
Search by partial usernames Yes By default the server does not allow to search users by parts of their username, but in a corporate environment administrators can enable this.
Admin dashboard Yes Psono offers with the "Admin Client" a nice web based dashboard to manage users and their accounts.
Console commands Yes Allows to automated processes like user generation or promotion of users with scripts.
Broad OS support Yes Psono can run on any system that can provide a docker environment, e.g. AWS, Azure, GCE, Mac, Windows, Debian, Ubuntu, CentOS, Fedora, RHEL, SUSE, Oracle Linux
Vertical scalability Yes Psono architecture allows vertical scalability and is only limited by the amount of write operations a single Postgres can handle (which is a lot with the right hardware).
High availability Yes Psono architecture allows a full redundant setup for secrets and filestorage.
Site affine filestorage Yes Allowing setups with dedicated storage for remote offices, or "external" users.
Multiple storage backends Yes The fileserver supports various storage provider (local storage, Google Cloud Storage, AWS, Azure, ...) for client side encrypted files
Central security reports Yes Central security reports you to audit the passwords of your users, check if they have been breached and if they follow password policies with length or complexity requirements without access to the actual passwords.

# Features exclusively in the Enterprise Edition

Features Supported Notes
LDAP Authentication* Yes Allows to login with their LDAP credentials
SAML Authentication** Yes Allows to login with SAML SSO
OIDC Authentication** Yes Allows to login with OpenId Connect SSO
LDAP Groups* Yes Adds users automatically groups based on their LDAP groups
SAML Groups** Yes Adds users automatically groups based on their SAML groups
OIDC Groups** Yes Adds users automatically groups based on their OpenId Connect groups
Audit Logging Yes Once enabled the server will log all events. Administrators can control what they are interested with white and blacklists.
2FA Enforcement Yes Users can be forced to provide a second factor before they can use Psono.
Disable Export Yes Users can be denied the possibility to export their passwords.
Disable API Keys Yes API keys bypass external authentication and therefore can be disabled if required.
Disable Emergency Codes Yes Emergency codes can violate company policies, as they bypass external authentication
Disable Recovery Codes Yes Recovery codes can be disabled if policies require or external authentication providers are in place
Disable File Repositories Yes File repositories allow users to share files through external services and therefore can be disabled
Disable Link Shares Yes Link shares allow users to share passwords and files with anonymous users via link and can be disabled
Enforce central security reports Yes Enforces that all security reports have to be sent to the server
Recurring security reports Yes Allows administrators to specify an interval in which they want to tell users to generate new security reports

* LDAP comes with some requirements, e.g. that the server needs to be able to provide the users plaintext password to the LDAP server or that the server needs a way to re-encrypt the users secrets when the user is changing his password on the LDAP server. Using this feature therefore necessarily will tell the client to send the plaintext password. (A warning is displayed to the user before that happens, to prevent any misuse of that feature.) and the server will store the users secrets (not his password) encrypted in the database to be able to re-encrypt them if necessary.

** SAML & OIDC come with some requirements, e.g. that the server needs a way to to access the users secrets in order to be able to provide the client with a random "fake password" that it then can use to decrypt the normal secrets.

TIP

If you are interested in a feature that is not listed, then let us know.