When asked about recommendations for hardening Passwordstate we’ve never really had a single point of reference for customers.  This blog has pulled together the responses previously sent to a number of customers and consolidated it for the first time.  Customers should understand that not all of these recommendations may be appropriate for they way in which they use Passwordstate. 

Each of the suggestions should be considered, and if applicable to your business, assessed formally via an internal risk assessment and approved via a change submission before being implemented. 

Encrypt Your Web.config Files!

Yes, this isn’t performed within the Passwordstate UI, however it is a fundamental best practice approach for securing your Passwordstate instance.  It ensures that should anyone have access to your Web Server’s file system they can’t use the details of the Web.config file to access and retrieve your Password Credentials.

The process of encrypting your Web.config is straight forward and details on how to perform this encryption can be found in our General Installation Instructions.  Theses can be found on our website under Support->Documentation->Installation Instructions,

You should encrypt the Database Connection String and appSettings section of your core Passwordstate Web.config file.  If you’re using our App Sever or HA (High Availability) Module you should encrypt the Database Connection String and appSettings section in the Web.config files for those as well.  If you’re using our Password Reset Portal subscription, you’ll only need to encrypt its appSettings section.

While the detailed instruction for each can be found in the corresponding Installation Instructions document, the approach is easy.  All you’ll need to do is open a Command Prompt with administrator privileges on each of the webservers running the core Passwordstate or optional App Server, HA or Password Reset Portal modules,

• navigate to C:\Windows\Microsoft.NET\Framework64\v4.0.30319,
• type in aspnet_regiis.exe -pef “connectionStrings” “c:\inetpub\passwordstate” and press enter.

This will encrypt your Database Connection String.  You should then encrypt your appSettings sectionby,

• typing aspnet_regiis.exe -pef “appSettings” “c:\inetpub\passwordstate” and pressing enter.

You’d also do this for each App Server, HA Server and the Password Reset Portal Server.  Note you’ll be changing the location of c:\inetpub\passwordstate to the correct locations on each of those webservers.  After each one you’ll need to stop and restart the relevant Windows Service. 

2FA for logging into Passwordstate

Using 2FA (Two-Factor Authentication) allows you to implement an additional level of protection when accessing credentials and data stored within Passwordstate.  You can use this as part of the primary authentication for all users, or in conjunction with SSO (Single Sign-On) for select users.

Click Studios recommends that if you are using SSO (Passthrough AD Authentication) selected as your System Wide Authentication option then don’t apply an additional 2FA option to all users.  It will frustrate them and defeats the purpose of implementing SSO to Passwordstate.  You should instead look at applying an additional 2FA for users that need access to highly privileged or sensitive accounts.

In these cases, you can implement the additional 2FA as part of a User Account Policy applied to specific Security Groups.  Just consider the implications as they relate to inappropriate access to highly privileged or sensitive accounts and restrict that access accordingly.

Use 2FA for Emergency Access

Following on from the concept of applying an additional 2FA for users that need access to highly privileged or sensitive accounts, look at configuring this for access to your Emergency Access account.

The Emergency Access account is highly audited and access to it can be restricted to a specified list of Security Administrators under Administration->Security Administrators.  You can configure the requirement for 2FA with OTP (One-Time Password) to further protect the Emergency Access account and subsequent access to your Passwordstate configuration.

Define Allowed IP Ranges

You can specify the IP ranges that Passwordstate is accessible from, that the Emergency Access account can be used from and where the API (Application Programming Interface) can be initiated from.  These are configured under Administration->System Settings->allowed ip ranges,  

You can also state the behaviour when Passwordstate is tried to be accessed outside of the stated Allowed IP Ranges.  This can range from denying access to additional methods of authentication.

Ensure Brute Force Detection is Enabled

Brute Force Detection works by monitoring for failed login attempts from the same IP Address and username combination.  Once these reach a predetermined number of failed login attempts the corresponding IP and Username is blocked from trying to login to Passwordstate. 

You can configure the maximum number of failed attempts under Administration->System Settings->authentication options->Web Authentication Options,

You can also delay the error message response to make it harder for an attacker to determine if the error is related to an incorrect username or password.

Use Feature Access to Restrict Access (to Features)

Using Feature Access allows you to grant or deny access to multiple features and menus.  This would ideally be done by specifying Security Groups, however you can also set this on individual user accounts.  The options are extensive as highlighted in the image below,

To define access to any of the features simply navigate to Administration->Feature Access and select the tab you want to set access for.  The image above shows the mobile tab where you can set permissions for users allowed to use the native iOS and Android mobile apps.

Specify the Functional Roles Used

Introduced in Passwordstate V9 Build 9493, Authorized Web Servers for the core Passwordstate product and any instances of the App Server, can have specific Functional Roles defined.  There are 7 main roles that can be defined, allowing customers to offload intensive processing associated with these roles to another webserver in your farm,

Click Studios recommends that customers deselect any Functional Roles not required for their Primary, High Availability and App Server instances.

Consider Security Administrators and the Roles they Hold

This one requires careful consideration before enacting.  In large organizations with a correspondingly bigger IT department, you can have the luxury of segregating the Administrative Roles within Passwordstate to multiple Security Administrators.  This ensures that no one individual has the ability to change all areas within Passwordstate.  In smaller organizations you may be forced, out of necessity, to provide more roles to fewer or even 1 Security Administrator.

To define the Administrative Roles within Passwordstate to a Security Administrator simple navigate to Administration->Security Administrators, click on the Administrator and select the roles you want to grant them.

Note, a Security Administrator cannot make changes to their own account, or a security group they are a member of.  Any changes need to be performed by another of the Security Administrators defined in Passwordstate.

Consider Using a Managed Service Account

This relates to database connectivity for Passwordstate.  Both Managed Service Accounts (MSA) and Group Managed Service Accounts (gMSA) effectively use an Active Directory account for service-related tasks while easily keeping that account’s password secure. 

MSA accounts cannot be used to log into a machine, have rotating passwords that are managed by the domain, and cannot be locked out.  Group Managed Service Accounts provide an even higher security option for non-interactive applications/services/processes/tasks that run automatically but need a security credential.

By using and MSA or gMSA you have no ability to know the password that is used for database connectivity as it isn’t stored anywhere within Passwordstate.  You can find instructions on how to configure Passwordstate to use a MSA in our General Installation Instructions here,

Privileged Account Credential Password Visibility

You have a couple of options relating to restricting the visibility of Privileged Account Credentials, used for Active Directory Account lookups, Host and Account Discovery, and Password Resets.  You can hide the value of the password field from all Privileged Account Credentials.  This removes the Password Field and provides on screen information stating it is saved to database,

You can also set visibility of only the Privileged Account Credentials that you have been explicitly granted access to,

Both of these settings are configured under Administration->System Settings->miscellaneous as per the image below,

Hardening the Operating System and IIS

Click Studios would also recommend following established processes to harden your Passwordstate webserver OS and IIS.  The best approach for doing so is to follow Microsoft’s recommendations rather than trying to develop your own. 

The following is offered as a starting point in determining what is appropriate for your organization https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-security-configuration-framework/windows-security-baselines

You can choose some or all of the suggested options in this blog to harden your Passwordstate instance.  The key as always, is to understand what you are doing, the implications of doing it, the benefits of taking that configuration option and that the change mitigates or removes the risk you are trying to address.

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

One of the new major features in our Browser Extensions for Passwordstate is the ability to easily map website input field IDs to fields within a Password Record.  This allows the Browser Extension to know exactly which input fields on a website’s login page need to be automatically form-filled by fields within your Password Record.  It effectively removes the guess work, on the part of the Browser Extension, when dealing with websites that have similar input fields.

In this week’s blog I’m going to work through a step by step approach to mapping the Username and Password input fields to a Password Record.  However, before we get started, I’ll make a couple of statements up front, those being;

• You must be on Passwordstate 9.5 – Build 9583 or later, with the latest Browser Extension installed,
• Don’t do this for every set of credentials you form-fill with our Browser Extensions.  Save it for the websites that need it,
• This blog works on the assumption the Password Record already exists,
• I have 2 Password Records for this website, and,
• I’m deliberately redacting the name of the website used for the examples.  There is no inference the company owning the website has produced an inferior or poorly designed site.  It’s simply one of many websites we use for testing our functionality against.

Form-Filling Incorrect Fields

When I navigate to the website used in our example the issue becomes evident.  The Browser Extension has either detected the incorrect website field IDs to form-fill, or the Password Record has historically referenced field IDs that have changed over time.  The latter is more common than you’d think and is usually the result of the owner/developer continuing to evolve their website. 

At this stage it doesn’t really matter what the underlying cause was as the process I’m going to use will fix it. 

As stated at the beginning of this blog there are 2 Password Records for this website.  This means I’ll need to select the correct one to perform the field mapping I require.  To do this I click on the Browser Extension icon, then click on Show Matching Logins.  This shows the two sets of credentials, or two Password Records, for the website.  In the example I’m selecting the bottom one that I want to automatically form-fill the Your email and Your password fields, 

When I hover my mouse cursor over that record, a right pointing arrow appears on the right hand side, and clicking on this brings up the Password Record details (image below).  What I want to do is navigate to the Password Record in Passwordstate by clicking on the link symbol shown,

Clear Existing Mappings

This will take me through to my Passwordstate instance that the Browser Extension is authenticating against.  I’ll need to login to Passwordstate as normal (as I don’t have Single Sign-On configured in this environment) and the Password Record will be opened for me.  From here I’ll select the website fields tab and clear the UserName Field ID and Password Field ID and then click Save.

Note, this step isn’t really necessary, but it’s a good method of showing where the field IDs are kept and how to clear them. 

Now Map The Correct Fields

I’m now going to navigate back to the website in the example and select the Password Record again from the Browser Extension icon.  Then I’ll select the right pointing arrow on the right hand side, and click on it to bring up the Password Record details.  Now I click on the Map Website Fields button at the bottom of the Password Record,

I’m now presented with the Passwordstate Website Field Mapper dialog.  This allows me to map the Website Fields to my Passwordstate Fields in the Password Record.  I’ll start by mapping the correct field for Username.  To do this ensure I’ve selected Username from the Passwordstate Field drop down box.  Next, I click on the Pick Field button and then click my mouse pointer in the input field for Your email (your website will most likely be different to these – as this is my example).

The Website Field will now show the name of that input field, in this example it’s called email.

I’ll now do the same thing for the Password Field.  I’ve selected Password from the Passwordstate Field drop down box.  Then clicked the Pick Field button and this time clicked the mouse pointer in the input field for Your password (again this is an example).

The Website Field will now show the name of that input field, in this example it’s called secret.  Then I click the Save button.

It really is as easy as those couple of steps.  Now I simply refresh the login page for that website and as you can see the Browser Extension has correctly mapped the Your email and Your password input fields.  If there was only one Password Record for this site then the two fields would have automatically form-filled correctly.

Mapping the website input fields to the fields in your Password Record enables you to successfully auto form-fill the login details for most difficult sites.  The next time you have an issue why don’t you give it a try.

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

We receive quite a few support calls from customers wanting to understand the differences in our permission models.  To that end we’ve provided examples of the Standard, Advanced and Advanced Permission with Disabled Inheritance in this week’s blog.  Please note that all user account names have been redacted in the images used.

Standard Permission Model

The Standard Permission Model is probably the easiest to understand for those new to Passwordstate.  It works by you applying the required permissions to a Password List, and the direct folder hierarchy or folder path required to access that Password List, inheriting those permissions. Think of it as a bottom-up application of permissions. 

In our example, the Standard Folder Permission Model is the default setting in Passwordstate.  You can confirm the permission model via two different ways.  The folder icon has no indicators next to it – all you can see is the folder.  This is the quick visual indicator that the folder is using the Standard Permission Model.  The second way is by clicking on the folder in the navigation pane and the Folder Properties on the right hand side of the screen will show the Permission Model in use,

We’ve assigned the permissions on the Password List SharePoint Accounts, having added 2 Users and a Security Group with Admin permission.  This is done by selecting the Password List, right clicking on it, selecting View Permissions, clinking on Grant New Permissions, selecting the intended recipients or groups, adding them to the Administrator Permissions box and clicking Save, 

Now if we look at the Folder Permissions on the Business Systems folder you can see the 2 Users and Security Group with Admin permission have had those permissions applied at that folder level.  This shows that the folder has inherited those permissions from the nested Password List, in this case the SharePoint Accounts Password List.  You’ll also note there are additional Modify permissions on the folder.  These have been inherited from a different Password List in the Business Systems Folder.

Advanced Permission Model

Next, we have the Advanced Permission Model.  This works by you applying the required permissions to a top level folder, and all objects beneath that folder, including nested folders and Password Lists, have the same permissions propagated down to them. Think of this as a top-down application of permissions. 

Again, using our example, you can confirm the permission model via two different ways.  The folder icon has a downward pointing blue arrow next to it.  This is the quick visual indicator that the folder is using the Advanced Permission Model.  The second way is by again clicking on the folder in the navigation pane and the Folder Properties on the right hand side of the screen will show that the Permission Model in use is the Advanced Model,

To confirm this, we’ll check the permissions on the Password List Web Sites.  This Password List is located in a nested folder called Halox.  This means the Advanced Permission Model will have propagated the permissions down to both the nested folder Halox and the Password List Web Sites.

The folder Customers has just 2 Users with permissions set to Admin.  To view this, we’ve selected the Password List Web Sites, right clicked on it and selected View Permissions.  You’ll note that the Grant New Permissions option is greyed out.  This is correct as the permissions on the Password List have been propagated down to it from the top level folder Customers,

Next, we’ll confirm the permissions on the Password List Web Sites (image above) match the permissions set on the Customers and Halox folders.  To do this we’ve selected the folder Customers, right clicked on it and selected View Permissions.  Again note, at the Customers folder level the Grant New Permissions option is available as this is the top level folder.  However, when you select the Halox folder the Grant New Permissions option isn’t available.  This is because the permissions on Halox are propagated down from the Customers folder,

Advanced Permission with Disabled Inheritance

The last Permission model we’ll discuss in this blog is a variation of the Advanced Permission Model.  This model blocks inheritance of permissions from any folder above, set’s the permissions for a specific folder and propagates these permissions to any nested folders and password lists.  We typically refer to this model as the Advanced Permission with Disabled Inheritance and it effectively replaces the old Manual Permissions model used in Passwordstate Version 8.

To confirm the permission model for Advanced Permission with Disabled Inheritance you can look for the quick visual indicator next to the folder icon.  This indicator is a downward pointing blue arrow followed by a red cross.  If you click on the folder in the navigation pane the Folder Properties on the right hand side of the screen will show that the Permission Model in use is the Advanced Model with extra detail stating disabling inheritance of permissions from any parent level folders.

For this example, we’re going to build on the Advanced Permissions Model shown earlier in this blog.  In that example permissions were set at the Customers folder and propagated down to all nested folders and Password Lists.  Now, at the Allsand folder, we want to disable inheritance of permissions from Customers and instead set new permissions for the Allsand folder.  These will then be propagated down to all nested objects under Allsand including the Workstation Accounts Password List,

To set Disable Inheritance of any permissions from upper-level folders we right click on the Allsand folder, select Edit Properties and set the Disable Inheritance option to Yes and then click on Save,

We have then set two different User Accounts to have Admin permission on Allsand and these are propagated down to all nested objects, in this case the Workstation Accounts Password List.

Now we’ll confirm the permissions on the Password List Workstation Accounts (image below) match the permissions set on the Allsand folder.  To do this we’ve selected Workstation Accounts, right clicked on it and selected View Permissions.

Take Care When Changing Permission Models

The ability to convert between permission models is protected under Administration->Feature Access->folder options->Convert Folder Permission Models.  You can both restrict this Administration functionality to specific Security Administrators and only these individuals can specify which Users and Security Groups can covert folders between different permission models.

When converting Folder Permission Models take the time to read through the information presented.  Implications with the move to the new permission model will be presented to you and it is important that you understand what those implications mean, i.e., overwriting existing Standard Permissions (bottom-up approach) with Advanced Permissions (top-down approach).

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Let’s start this week’s blog with an admission.  I am not a SQL Database Administrator and I have no desire to become one.  In my professional opinion being a DBA requires a special way of looking at the world and that extends to how your databases are structured, managed and monitored.

This blog is not aimed at educating DBAs, rather it offers the options for replication that can make Passwordstate Administrators lives easier.  We’re also starting this blog from the perspective of what is achievable versus looking at business requirements, risk appetite and budget.  You could think of this as a bottom-up approach versus the top-down approach referenced in https://blog.clickstudios.com.au/ha-auditing-records-and-syslog-servers/.   

HA Options Available

As per our previous blog (link above), when implementing Passwordstate HA you require our HA license, even if you use Virtual Server Replication technologies for your implementation.  The image below is again a simple logical view of the 2 types of HA that Passwordstate could be implemented with using a bottom-up approach.  In both of the diagrams the databases are installed on the webservers to maintain simplicity.

Passwordstate HA with SQL Standard and SQL Express:  The design on the left hand side has been created with the decision not to use SQL Server Standard Edition on the HA Server.  Instead, SQL Server Express (at no cost) has been selected. 

This will only support an Active / Passive HA implementation, with the Primary instance of Passwordstate being the Publisher and using SQL Standard.  The Passive Secondary instance is the Subscriber and is using SQL Express.  Using this model your only supported form of SQL replication between the Publisher and the Subscriber is Transactional.

Passwordstate HA with SQL Standard:  The design on the right hand side has been created with SQL Server Standard Edition used for both the Primary instance and the Secondary instance.  This now provides us some options. 

This will support an Active / Passive HA implementation, or an Active / Active HA implementation. You could setup Transactional replication the same as on the Left Hand Side, or you could setup a Basic Availability Group.  Using a Basic Availability Group, you specify both a Primary Replica and Secondary Replica on your Primary instance.  Both the Primary and Secondary Replicas have a copy of the Passwordstate database. 

A Secondary Replica, also containing a copy of the database, is setup on your Secondary instance.  The Basic Availability Group handles replication between all databases and enables automatic failover of the databases using a SQL Listener, an Active Directory object created when you setup a Basic Availability Group.

Benefits of Basic Availability Groups

So, what are the advantages of using Basic Availability Groups?  An immediate advantage is that you now have an Active / Active implementation of Passwordstate HA at the Database Level.  Add a load balancer, placed in front of both of your webservers, and you can then distribute the load for a single URL between the two webservers.  This will also enable automatic failover at the webserver level in the event one of them becomes unavailable. 

Basic Availability Groups also handle database schema changes natively whereas Transactional replication requires a hands-on approach during upgrades to ensure schema changes are processed.  By using Basic Availability Groups your Passwordstate Upgrades will become that much easier.

Supplemental Information

Basic Availability Groups in SQL Server Standard edition was introduced in SQL Server 2016.  For information on how to configure either Transactional Replication or Setup Basic Availability Groups, please navigate to Support->Documentation on our website and select the documents you require.

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Our Browser Extensions for Passwordstate enable the secure storing of website credentials in your Passwordstate instance.  The credentials can then be used to automatically form-fill credential input fields, such as the Username and Password fields, when you next visit a website that you have credentials for.

With the release of Passwordstate Build 9583 we’ve updated and improved our Browser Extensions for all Chromium based browsers, including Google Chrome, Microsoft Edge, the Brave Browser and Mozilla’s Firefox.

Confirming Your Passwordstate URL – Is It New?

Well no, but it is a really important concept!  You are asked to confirm your Passwordstate website URL is correct as mitigation against a phishing style attack, where you could be asked to click on a link to login to an imitation of your Passwordstate environment.  If this should ever happen the results could be catastrophic and range from harvesting your credentials to outright compromise of your systems.  Take the time to confirm the URL matches the URL for your Passwordstate instance and only then click on Confirm,

Map Website Fields

The new Browser Extension have greatly improved input field detection.  However, with some difficult sites they may still be unable to determine which are the Username and Password fields.  This can be the case with websites that have multiple input fields, or even duplicates of input fields, on the same page.

In these cases, you can map the Website Fields to the Passwordstate Fields.  To do this, simply navigate to the website and click on your Browser Extension icon, click on Show Matching Logins, then click on the arrow to the right of the credentials you are selecting.  At the bottom of the retrieved credentials you’ll see the Map Website Fields button.

When you click on the Map Website Fields button the Passwordstate Website Field Mapper dialog will appear,

From here it’s a straight forward process of,

1. Selecting the type of Passwordstate Field to map,
2. Click on the Pick Field button,
3. Move the mouse cursor to the input field, in this case the Password input field on the website and click in it to select it.

You’d then need to repeat this process for all required input fields, and once complete, click on Save.  This will write the unique website field IDs into your Password Record in Passwordstate and correctly populate those fields each time you navigate to that website.  This then leads us to the next new feature…

Form-Filling More Than 2 Input Fields

You now have the ability to automatically form-fill more than just 2 input fields.  This can be especially useful in situations where sites require a Username, Password and OTP code.  Note, your Security Administrators can turn off the setting allowing the automatic form-filling of OTP Codes.

Additionally, you can configure up to a total of 13 input fields by using the Username, Password, OTP (enabled at the Password List Level) and the Generic Fields one through ten. 

The image below is a composite image, showing the two input screens for a WordPress website that has 2FA (Two Factor Authentication) enabled.  The first screen is automatically form-filled for the Username and Password fields.  On clicking the Log In button the screen prompting for the Authentication Code is displayed and this is also automatically form-filled.  The user then simply clicks the Log In button a second time to complete the login process,

The corresponding Browser Extension record for this example looks like this,

In order to utilise form-filling of more than 2 input fields you’ll need to map the website’s input fields to fields in your Password Record as outlined in the Map Website Fields section above.

Specifying Your URL Matching Option

Another improvement, for improving the accuracy of form-filling input fields on difficult websites, is by specifying the type of URL matching to use.  URL Matching options are specific to each Password Record and are typically required when input fields are located on different webpages with different URLs.  For example, one URL that prompts for Username and a different URL for Password. 

There are 3 URL Matching options that can be selected from, Starts With, Host Name and Base Domain with the default being Starts With,

Clear Existing Website Field IDs

Lastly, if you find you are having problems with multiple Password Records automatically form-filling correctly because of incorrect or previously set Field IDs, you can clear the website Field IDs for all Password Records in a Password List.  This will not affect the credentials for those websites, only the associated Field IDs that have been recorded and stored on the website fields tab for each Password Record.

To clear all the website Field IDs, for all Password Records in a Password List, simply login to Passwordstate, navigate to the Password List you want to perform the action against and click on List Administrator Actions…, then click on Clear Web Site Field ID Values,

Note, your Security Administrator has the ability to clear all Username and Password Field IDs for all Shared Password Lists within Passwordstate.  However, they can’t clear the Password Field IDs for any Private Password Lists.

These improvements to the Browser Extensions should make significant improvements in automatically form-filling your credentials for websites.

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Passwordstate has comprehensive auditing, with over 120 different Audit Events.  These events detail when password credentials and other information has been accessed, by whom, when and much more.  For a comprehensive list of events please refer to https://www.clickstudios.com.au/about/compliance-reporting.aspx.

When you scale out your Passwordstate implementation to include High Availability, in either an Active / Passive or Active / Active design, the storing of Auditing information subtly changes.  Add to this, requirements for Syslog or SIEM (Security Information and Event Management) integration and knowing where auditing is stored and being accessed from can become a little confusing for those new to Passwordstate.

Passwordstate High Availability

Passwordstate supports 2 types of HA (High Availability), Active / Passive and Active / Active.  Both have their use cases and the type of HA implementation you decide on will very much depend on your organization’s business requirements, risk appetite and budget.  When implementing Passwordstate HA you’ll require our HA license, even if you intend on using Virtual Server Replication technologies for your implementation.

The image below is a simple logical view of the 2 types of HA that Passwordstate can be implemented with.  In both of the diagrams the databases are installed on the webservers to maintain simplicity.

Active / Passive Implementations:  This design on the left hand side provides an Active Primary instance of Passwordstate and a Passive Secondary instance.  Your users are serviced from the Primary instance and your secondary instance is effectively on standby.  Replication of SQL data occurs from your Primary instance to the database on the Secondary instance.  Any auditing data from your Secondary instance is posted back to your Primary instances API every few minutes and subsequently inserted into the Primary’s database.

In the event your Primary instance is unavailable, you would normally point users to the Secondary instance where they can access their data as read only.  No credentials can be changed by users while using the Secondary instance.  All access to credentials is logged into a local audit database, and once the Primary Instance resumes normal operation, these audit entries are synchronized back with the Primary instance.

Active / Active Implementations:  This design provides an Active Primary instance of Passwordstate and an Active Secondary instance.  Your users are serviced from either the Primary instance or your Secondary instance.  Both instances support full read & write operations.  Your users are typically directed to an appropriate instance via a load balancer.  Replication of SQL data occurs both ways, i.e., data initially written to your Primary instance is replicated to the database on the Secondary instance and data initially written to the Secondary instance is replicated to your Primary instance. 

In the event your Primary or Secondary instance is unavailable, your load balancers should be configured to direct all Passwordstate traffic to the instance that remains operating.  All access to credentials is logged as normal.  If the Primary instance isn’t available the Secondary instance will synchronize its database and auditing data back to the Primary Instance once it resumes normal operation.  When both instances are running normally the Secondary instance will synchronize its database and auditing data back to the Primary Instance on a regular basis.

Syslog and SIEM Integration

Passwordstate provides the ability to feed your audit entries directly into your Syslog or SIEM solution.  It does this via specifying the Server details including name, port number, date format and specifying the type of protocol to use. 

The setting can be configured under Administration->System Settings-proxy and syslog servers as shown below,

Once configured all audit entries are initially sent from your Primary instance.  In a HA environment, regardless of your configuration (Active / Passive or Active / Active), the audit entries are sent only from your Primary instance.  This has all the audit events for your Primary and Secondary instances as described earlier.

After the initial forwarding of all audit entries, the Passwordstate Windows Service on your Primary instance will monitor for new audit entries and send these through to your Syslog server every couple of minutes.

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Passwordstate has 2 first-in-class Remote Access Solutions, a Browser Based Launcher and a Client Based Launcher.  These are included with all current versions of the core Passwordstate product and at no additional cost.

The key advantage for these built-in launchers is the use of Remote Session Credentials.  This enables automatic authentication to your remote hosts, removing the need for users to have to manually enter credentials. This feature is especially useful for enabling contractors or vendors accounts to be configured for authenticating to hosts without having to have access to the password record.

Both the Browser Based and Client Based launchers operate the same way in relation to protecting your credentials through encryption.  When credentials are retrieved from Passwordstate they are encrypted, sent to the Remote Session Launcher utility/gateway, decrypted and passed to the remote client.

First Time Installation and Manuals

To access the installation instructions, and install either the Client Based Launcher or Browser Based Gateway, simply navigate to Help->Remote Session Management.  From there you’re presented with the option to Install/Configure either the Launcher or the Browser Based Gateway,

and, just to point out what some people may think is obvious, when you’re Installing and configuring the Client Based Launcher… the PowerShell and .Net Framework requirements need to be on the Client PC, and the installer itself needs to be run on each Client PC that will use the Launcher,

Browser Based Launcher

Once installed, the Browser Based Launcher settings, including the Gateway settings and the installer for the Browser Based Gateway are located under Administration->Remote Session->Management,

The screen above includes a high level description of the features found in this Remote Session Launcher.  Providing greater detail on these, the Pros associated with this Launcher are;

Operating System Independence:  As the Browser Based Launcher runs from within your browser you largely have operating system independence.  This makes it not only quick to deploy but also extremely versatile, as there is no client software and associated compatibility issues, required to be installed on each user’s personal computer. 

Supports RDP and SSH Sessions:  RDP (Remote Desktop Protocol) is the most commonly used protocol for connection through to Windows based servers and PCs.  RDP clients also exist for Linux, Unix, macOS, iOS and Android operating systems.  SSH (Secure Shell Protocol) is a commonly used protocol for operating network services securely over an unsecured network.  It was designed for Unix style operating systems as a replacement for Telnet and unsecured remote Unix shell protocols.  Through RDP and SSH support the majority of an organizations computing and infrastructure fleet can typically be accommodated. 

Session Recording and Playback: This is a significant feature allowing for the recording and playback of initiated RDP and SSH sessions to remote hosts.  The feature is configurable on a per host basis and recorded sessions can be retained indefinitely or automatically purged after a preconfigured number of days.  The recorded sessions capture what is presented to the screen, allowing you to review what commands are typed/opened and the resultant screen updates.

The only real downside for the Browser Based Launcher is that it its support is limited to RDP and SSH sessions, and, that recordings of sessions are produced in a proprietary and highly compressed format which can only be reviewed within the Passwordstate UI (User Interface).

Client Based Launcher

Again, once you’ve installed the Client Based Launcher on each PC, and have setup the appropriate Remote Session Credentials you can start using the Client Based Launcher,

The screen above includes a high level description of the features found in this Remote Session Launcher.  Providing greater detail on these, the Pros associated with this Launcher are;

Support for select 3^rd Party Software:  This enables you to continue to use existing investments in products, training and processes in software such as VNC (Virtual Network Computing), Teamviewer and others.  This is offered in Passwordstate for those organizations that heavily use those select 3^rd party solutions for other use cases, such as shadowing users when providing training, or for Help Desk Support.  It enables your support teams to use a consistent tool set for all use cases and maximize the return on investment associated with that software.

Local Initiation:  Each launcher is initiated from the client PC.  This can be important in situations where existing 3^rd party toolsets have already been installed on those PCs and/or support devices are operated in a high mobility environment (such as work from home/work from office arrangements).

The two downsides associated with this Launcher is that software needs to be deployed to each PC requiring it.  While this isn’t an issue if you’re already deploying the select 3rd Party Software for other purposes, it may be an issue if you’ve just getting around to purchasing it now (you should seriously consider the free Browser Based Option).  The second downside is there is no centralised Passwordstate Session Recording option available.

What’s Our Recommendation?

Firstly, every organization should match the capabilities offered with Passwordstate to their own requirements.  This is really the only way to ensure that capabilities that you plan to rollout match the requirement and use cases within your organization. 

Secondly, and from a purely biased point of view, the Browser Based Launcher option is hard to beat.  No cost or deployment hassles, support for RDP and SSH protocol, and the ability to setup Session Recording for playback later make this our own go to for a Remote Session Launcher (and I did say it was a biased view).  

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

In this week’s blog we’re looking at a scenario where a previous Passwordstate Administrator has left and you’re now in the driving seat.  One of the first tasks you’ve been given by your “overlords” is to find out how far behind your install is and plan what needs to be upgraded.

Being new to Passwordstate, and never having been involved in the upgrade process before, you’re probably thinking “It’s time to find a new job”.  But there’s no need to panic!  Before you start taking drastic steps like planning to move on, let’s work through a high level process aimed at giving you the information you need.  This includes;

• What version am I running?
• What is the latest version available?
• How do I find what options are installed?
• Where do you obtain instructions on the upgrade process?
• Are there any dependencies?
• Where do I get the source files from?

Once you’ve covered off on the above, you’ll be ready to make informed decisions on what needs to be upgraded, when, and apply the upgrades to all required components.

What Version AM I Running & What Is Available?

First things first.  We’re going to assume you’ve been setup as a Passwordstate Security Administrator and granted access to most of the Roles/Features listed on the left side of the screen below.  When you navigate to Administration->Passwordstate Administration you’ll see the About information relating to your core Passwordstate instance,

Note, even through you are shown the Password Reset Portal and Remote Site Locations API Build Numbers, this does not mean you are licensed for these modules or that they are installed.  To check if you have these installed or if they need to be upgraded is covered later in this blog. 

Next, you’ll navigate to the Click Studios website https://www.clickstudios.com.au and under Download->Change Log – V9 you’ll find details on the latest build of Passwordstate.  While Click Studios recommends always being on the latest build of Passwordstate we do recognize that you’ve got other tasks and duties to perform.  We encourage all customers to review the details associated with each build and, in accordance with internal risk and change management practices, decide when to upgrade. 

Note: Each Build incorporates all previous updates and fixes for that Major Version, i.e., Version 8 or V9.  While the image above is focused on V9 you can also confirm the details for Version 8 under Download->Change Log – V8.

Once you’ve decided that you do want to plan out the upgrade you can download the appropriate CSIP (Common Software Installation Process) package from our website located here https://www.clickstudios.com.au/passwordstate-checksums.aspx.  On this page you’ll always find two packages, show by the Red Circles 1 & 2,

Red Circle 1 – or the top entry will always show the latest build of Passwordstate for the current Major Version.  In our example this is the latest build (at the time of this blog) for V9.  Red Circle 2 will always show the last build available for the previous Major Version of Passwordstate, in this case, Version 8.  Underneath the two is the link to the Upgrade Instructions. 

Don’t forget, check the downloaded package’s checksum with the published checksum value shown on the page.  The values published and the checksum of the download package change with every new build.

How Do I Find What Options Are Installed?

To start with we’d recommend looking at what options you are licensed to run.  You can check these details by navigating to Administration->License Information as per the image below,

The two core license types are Client Access Licenses and Annual Support (although a very small number customers may not have Annual Support).  The optional modules of High Availability, Password Reset Portal and Remote Site Locations will only have entries under Registration Name, Expires, License Count and Registration Key if you have either a valid or Trial license applied. 

Once you’ll established what license options you’ve got you can also confirm if and where the AppServer, Browser Based Gateway and/or Self Destruct Website are installed.

For the AppServer, navigate to Administration->Authorized Web Servers.  From here you’ll see the NetBIOS names for your Primary, High Availability and AppServer webservers.  If you need to obtain the IP address for any NetBIOS names you can use the nbtstat (NetBIOS over TCP/IP) command.

To confirm if you have the Self Destruct Push Pull website installed externally from the core website (its default installation) navigate to Administration->System Settings->self destruct messages->Self Destruct Settings and check for an entry under Separate Site URL,

Again, if you need to obtain the IP address for the supplied URL you can perform a DNS lookup of that URL by using the nslookup command.  Lastly, to confirm if you’ve installed the Browser Based Gateway on a separate server navigate to Administration->Remote Session Management->Browser Base Gateway Settings,

And under Configure Remote Session Gateway->Gateway URL you’ll see the URL of the server where it’s installed.  Again, you can use the nslookup command to locate your IP address.

Where Do You Obtain Instructions and Check Dependencies?

This part is really easy.  You have three options available for accessing the Upgrade Instructions.  These are;

1. Accessed from our website documentation page https://www.clickstudios.com.au/documentation/

2. Accessed from the website Checksums page https://www.clickstudios.com.au/passwordstate-checksums.aspx (the link is the same as that used for the documentation page above)

3. Documentation is included in the CSIP Package you download.  Once extracted, the PDF is located in Passwordstate\Upgrade Instructions.  This is simply a local copy of the same Upgrade Instructions available from our website.

And lastly, regardless of how you’ve accessed the Upgrade Instructions, the Upgrade Dependency Matrix, covering all modules is located in Section 12 of the document,

Where Do I Get The Source Files From?

The only location you should ever obtain your source files from is https://www.clickstudios.com.au/passwordstate-checksums.aspx.  Never obtain Passwordstate source files from a 3^rd Party Systems Integrator, Authorized Reseller or other person etc. 

When downloading from the Checksums page you will be downloading from the Click Studios Content Delivery Network.  This is a geographically distributed group of servers that provide fast delivery of our CSIP packages. 

Each build of Passwordstate includes the latest source files for all modules.  These are located in the Install path of your Passwordstate webserver under \inetpub\Passwordstate\downloads.

By following the high level processes in this blog you can,

• Identify your current installed version of Passwordstate,
• Confirm what you’re licensed for, have installed, and where,
• Find the latest build available and the changes it contains,
• Understand what components require updates, and,
• Obtain the latest source files and instructions. 

From there you can plan out the upgrade(s), submit change requests and seek the approvals to move forward.

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Passwordstate uses the concepts of Security Administrators and Password List Administrators.  Both roles are specific in what they allow the user to do within Passwordstate and in relation to accessing Password Records.  The two named roles are sometimes used interchangeably by customers new to Passwordstate. 

While it is quite possible, even probable, that a Security Administrator will be a Password List Administrator of some Password Lists, most Password List Administrators will not be assigned Security Administrator roles.  What are the differences and what do they allow?

What is a Security Administrator!

A Security Administrator is a User Account within Passwordstate, that has been granted access to one, many or all of the roles or features shown under the Administration Tab.  Security Administrators in large organizations typically have access to one or multiple roles but not all.  This allows better segregation of administrative duties and ensures separation of elevated privilege responsibilities.  Conversely, Security Administrators in smaller organizations typically have access to all roles as there are less staff to apportion them to. 

Security Administrators cannot modify their own assigned roles.  This is a built-in feature intended to prevent Security Administrators assigning additional elevated privilege roles to their account.  To modify, including adding or removing roles or access to the features, requires another Security Administrator to do it for them.  For this reason, Click Studios recommendation is there is a minimum of 2 Security Administrators assigned within Passwordstate.

Security Administrators cannot manage permissions or settings on Private Password Lists owned by other accounts.  Using the Password Lists feature they can only see that a Password List exists and who owns it.

They cannot grant themselves access to, or modify their own permissions on Shared Password Lists they don’t already have access to.  In this case when clicking on Shared Password Lists, all passwords will be hidden and some features will be disabled for them.  Note: Under System Settings you can elect to grant Security Administrators Admin Rights to new Shared Password Lists as they are created.

What is a Password List Administrator?

A Password List Administrator is the owner of a Password List.  By default, they have administrative rights to their Password List and are the only account with permission to grant additional users rights to the Shared Password List (Private Password Lists cannot have access granted to other users).

Can you have Multiple Password List Administrators?

For Private Password Lists the answer is no.  There can only be one Password List Administrator for a Private Password List.  Having said that, you can add multiple Password List Administrators to a Shared Password List, however, there is only one owner that originally created the Shared Password List.

Shouldn’t Security Administrators Access Everything?

In short no!  Passwordstate in its default configuration does not allow Security Administrators access to everything.  The founding principle for Passwordstate is to grant access to password records using RBAC (Role Based Access Control).  All users should only be provided with access to the Password Records they need to be able to perform their duties.  This means Security Administrators cannot by default grant themselves access to, or modify their own permissions on Shared Password Lists.

The analogy I like to use here is based on Segregation of Duties (SOD).  This is a basic building block of sustainable risk management and internal control for a business.  In this analogy, a person raising a Purchase Order for goods should not also be the person receiving the goods and then paying the invoice for those goods.  If the same person raises the order, receipts the goods and then pays the invoice, the end to end transaction is open to a lack of appropriate authorization, potential errors, and at worst fraud.

Likewise, Security Administrators responsible for the effective running of your Passwordstate instance, should not also need access to password records allowing access to all Employee Records in your Human Resources System, or, the credentials for the organization’s primary banking account.  In 99.9% of organizations your Security Administrators role won’t include Passwordstate Management, reviews of HR records direct from the database and shuffling funds in and out of the business bank account.  

Relevant Configuration Options

Security Administrators can, if granted access to the Systems Settings role/feature, configure the following under Administration->System Settings->password list options,

• When administering Password List permissions from within the ‘Administration’ area, prevent Security Administrators from granting themselves permissions to passwords – either via their own account, or security groups which they are a member of (Yes/No)

• When searching for users in order to grant them access to Password Lists, only show users who are in the same Security Groups as the person granting the access (Yes/No)

• When a new Shared Password List is created, apply the following permission to the user who created the list (List Administrator/Modify/View)

• When new Shared Password Lists are created, grant Security Administrators with the selected role below admin rights to the Password List (Do Not Provide Admin Access/All Security Administrators/Password Lists)

We hope this explains the differences between Security Administrators and Password List Administrators and what they can do.  If you’d like to share your feedback please send it through to support@clickstudios.com.au.