Auditing and Graphs

Passwordstate provides comprehensive reporting to ensure you can meet the governance requirements within your organization. All reporting makes use of the built-in audit events. There are more than 110 audit events in Passwordstate, providing a rich source of information that spans multiple categories, including,

Access to Passwordstate Access to Passwords All Passwords Exported
Auditing Data Archived Discovery Jobs Documents
Emails Email Templates Emergency Access
Encryption Keys Failed API Hosts
Logins Passwords Password Lists
Password Resets Password Validation Privileged Accounts
Remote Sessions Reporting Restricted Features
Security Administrators Security Groups Self Destruct
Templates User Accounts User Identity

When reporting on audit events, you can specify all sources or be selective. For example, you could report on only audit events relating to your Windows Service or your High Availability node. These events can then be exported to Microsoft Excel for further analysis, or summarized using the built-in Auditing Graphs.

…But before we get into the details for Auditing and Graphs

If you are trying to diagnose issues around a specific Password or Account you can quickly check the Recent Activity grid for the Password List that contains that account. This will provide useful information relating to the account and why activities such as Password Resets may not have occurred. The example below is for the helpdesk account which has been temporarily locked out;


Selecting Data using Auditing Filters

To begin with navigate to Administration->Auditing and decide on the events you want to review. By default, the display grid will show all audit events that have occurred. The Auditing Filters, show in the image below, help you to selectively focus on the specific types of events you are interested in reviewing;


The Platform options shown in the green rectangle are;

  • All, as the name implies this includes audit events for all the platform categories
  • Web, this platform category includes all audit events related to your Passwordstate Website
  • Mobile, this category includes all audit events related to either your Mobile Client installation in Passwordstate up to and including Version 8, or related to the new native Mobile Apps included in Passwordstate V9. Please note that as of the release of Passwordstate V9 the original Mobile Client is deprecated and no longer included with the Installer Files.
  • API, the API category includes those audit events associated with API Calls
  • Windows Service, includes all audit events associated with AD synchronization, Password Resets, Host and Account Discovery jobs, sending emails and querying event logs
  • Browser Extension, covers Browser Extension authentication with Passwordstate, saving, retrieving and updating of passwords and the use of the password generator,
  • Instance, you can also select your Instance to focus on, either your Primary or HA instance or Both

Lastly, you can elect to include Archived Data by selecting either the No or Yes radio buttons. By selecting No you will be querying the live audit events, if you select Yes it will query the Archived Data. Now you can filter down on a number of items as per the image below;


The fields in the Green rectangle above cover;

  • Max Records, allows you to specify the maximum number of records you wish to return as part of the search. If you wish to return all records you can enter 0 in this field
  • Password List, allows you to focus on a specific Password List in the drop down list, or search for events across all Password Lists
  • Activity Type, allows you to focus on specific audit events, or report against All Activities
  • Site Location Activity, allows you to focus on events for a specific Remote Site Location. This only applies if you have deployed and have an active subscription for Remote site Locations. The default for all installations is internal. For Remote Site Locations enter the number that corresponds with the Remote Site Location you wish to report against.
  • Begin and End Date, narrows the focus to the selected date range. Simply use the calendar date pickers for the start date and end dates you wish to focus on. A blank begin date will report all events that match the selected criteria up until the specified end date. By default, the End Date is always the current days date

Then simply click on Search to narrow the focus down to those specific events. Don’t forget that you can also filter down using the standard filter boxes under the column headings in the display grid (shown in the gold rectangle).

Export and Purging Audit Records

You may want to take a copy of the selected records, so that they can be included in a report or you may want to periodically Purge specific Audit Records. The options for these are situated at the bottom of the display grid as per the image below,


The Export to Excel will produce an Excel file called AuditingReport.xls containing the contents as per the executed filter.

If you select Purge Audit Records you will be taken to the Purge Auditing Data screen which explains the process necessary to perform the purge. Please note there is no automated purge within Passwordstate. You will need a Database Administrator, or someone responsible for support and maintenance on your SQL database, to perform the activities required. The Purge Auditing Data screen is shown below,


Graphs based on Auditing Data

Auditing Graphs provide a great summary view of your audited events. Like with the Auditing section, you can define filters for the Graphs that are very similar to those on the Auditing screen.

In the example below I’ve run a simple view based on Audit Activity of Login Attempt Failed for 1 year.


The key difference to note is that the duration timeframe is retrospective from the day the graph is based. In the example above it looks back 1 year from the current date.

The Auditing and Graphing capabilities are extremely useful and enable comprehensive reporting against your governance requirements. If you have any comments or feedback we’d love to hear it via support@clickstudios.com.au.

Ignored URLs and Browser Extensions

There is no doubt that Browser Extensions make your browser-based-life easier. The ability to securely manage website logins, while enforcing a reduced attack vector through unique login credentials, should not be understated. The statistics speak for themselves,

  • A 2018 Global Password Security Report revealed 50% of users reuse the same passwords for personal and work accounts
  • A 2019 online survey by Google identified 65% of people use the same password for multiple or all accounts
  • In the first six months of 2019, data breaches exposed 4.1 billion records
  • A 2018 Data Breach Incident Report confirmed compromised passwords are responsible for 81% of hacking-related breaches
  • Globally businesses are losing $4M on average each year due to credential stuffing attacks using leaked and exposed passwords and credentials

The reuse of usernames and passwords from a compromised site leads to a significantly increased attack vector for your business. So how do Browser Extensions help to reduce this risk, and why do I have issues with some websites.

Encourage and Support the Desired Behaviour

To begin with you need to provide the tools along with the education to your users. There is significant value in encouraging and allowing staff to use Personal Password Lists. This is reflected as one of Click Studios Best Practices for Passwordstate and more information can be found here.

Enabling Personal Password Lists needs to be performed alongside a robust training and education program for staff. This training should help them understand the real world impact associated with credential theft and hacking-related breaches. They’ll need to understand why they should have unique credentials, how they generate and store unique credentials and what to be aware of so they can identify when something doesn’t look right. Don’t forget, to get buy-in you need to show your users what’s in it for them.

Create Strong Passwords Using the Passwordstate Password Generator

One of the features of the Passwordstate Browser Extension is the ability to use the defined Password Generator. This can be set globally, via Administration->System Settings->password options->
With the Password Generator on the menu Tools -> Password Generator, select the following Password Generator Policy as the default:
and prevent users from selecting a different policy by selecting the Yes radio button,


This will make the default Password Generator for Browser Extensions reflect what was set under System Settings as detailed above. Note, the user can still choose another Generator if they want. This is why the education part is so important, Click Studios provides users the choice, however the business should reinforce the security standards they have put in place and the benefits those standards provide.


Understanding the Add Site to Passwordstate Dialog

When navigating to a website, one that you don’t have any saved credentials for, on logging in you will be prompted to Add Site to Passwordstate? The dialog provides you with 3 options, Close, Ignore and Save (note I’ve removed the username for the image below),


Save is straightforward and will create the password record in the chosen Password List. Clicking Close will simply close down the Add Site to Passwordstate dialog box. The tricky option is Ignore. When you click on Ignore you are not only dismissing the Add Site to Passwordstate dialog box, you are also adding an Ignored URL for that website login screen. The end result is that you will now never be prompted to save your credentials for that website URL again – until you delete the Ignored URL record.

To delete an ignored URL, login to Passwordstate and navigate to Preferences->Preferences->browser extension->Ignored URLs, select the URL to delete and click on the Actions icon and click Delete,


It’s worth noting that clicking on Ignore isn’t the only way to prevent the dialog for Add Site to Passwordstate from appearing. Ignored URLs can be manually entered by Security Administrators under Administration->Browser Extension Settings->ignored urls. These ignored URLs are global in effect and prevent all Passwordstate Users from saving credentials for those websites via the Browser Extensions.

Report Sites that have Issues

On occasion you will find a website that our Browser Extension has an issue with, specifically in correctly mapping the user name and password fields. When you come across this, we encourage you to report the issue by clicking on Report Site Issue. This will open up the Report Site Issue page in another Tab and allow you to record the details of the issue. We encourage you to supply as much detail as possible so that our Technical Support and Development Teams can investigate and provide a fix.

As always, we welcome your feedback via support@clickstudios.com.au.

Google Workspace, SAML Authentication and Passwordstate

Last week’s blog was all about SAML2 Authentication with Microsoft Azure. Keeping to a like theme, this week we’ll concentrate on setting up SAML Authentication for Google Workspace (formerly G Suite) and Passwordstate.

Google Workspace provides email and collaboration tools similar in basic function to Microsoft 365 (formerly Office 365). In order to use SAML2 authentication, in Passwordstate with Workspace, you’ll need to specify the settings obtained within the ‘Service/App’ configured within Workspace. The following is a summary of settings that are required;

  • Specify the Certificate Type – either SHA1 or SHA256
  • Details of your X.509 Certificate
  • The IDP Target URL
  • The IDP Issuer URL
  • Audience Restriction

As with the Azure Blog, the terminology isn’t always consistent between SAML2 Providers so you should use the table below to map the Passwordstate SAML2 Authentication Settings to the information provided by Workspace,

Passwordstate Field Workspace Supplied Fields
Audience Restriction Service Provider Entity ID
‘Your Passwordstate URL’/logins/saml/default.aspx ACS URL
‘Your Passwordstate URL’ Service Provider Entity ID
UserID or Email or UserPrincipleName Email
X.509 Certificate (SHA256) Certificate
IDP Target URL SSO URL
IDP Issuer URL Entity ID

Note in the above table ‘Your Passwordstate URL’ is the URL of your Passwordstate Instance. In the examples used in this blog ‘Your Passwordstate URL’ is this time https://passwordstate8.halox.net

Create a Service/App for SAML

In these examples we’re going to configure Passwordstate for SAML Authentication and Single Sign-On with Workspace. First you’ll need to login to your Google Admin Console and click on the Apps icon as per the screen shot below,

then select SAML Apps,


and click on Add a service/App to your domain,


this will take you to Step 1 Enable SSO for SAML Application. Click on SETUP MY OWN CUSTOM APP,


Step 2 Google IdP Information will appear and prepopulate your SSO URL and Entity ID fields for you. Click on NEXT.


this will take you to Step 3 Basic information for your Custom App. Provide an Application Name, in our example Passwordstate, and click NEXT,


on Step 4 Service Provider Details, enter your ACS URL and Service Provider
Entity ID (refer to the table at the beginning of this Blog entry) and ensure Name ID, Primary Email and Name ID Format are selected as per the image below and the click NEXT,


on Step 5 Attribute Mapping click FINISH.


Next, you’ll need to turn this on for everyone by clicking on View details,


and selecting On for everyone, then clicking SAVE,


Download your Passwordstate SAML Metadata

You’ve now created the SAML settings for the Service/App Passwordstate. By clicking on DOWNLOAD METADATA you’ll have access to all the required details  that are required to configure Passwordstate’s SAML2 section,


this will open a dialog enabling you to either, 1: Download IdP metadata, or 2: Copy the SSO URL, Entity ID, and Certificate,


Configure the Passwordstate SAML2 Authentication Settings

To configure your Passwordstate SAML2 Authentication you’ll need to login to Passwordstate and navigate to Administration->System Settings->authentication options. From here you’ll need to set your Web Authentication Options to SAML2 Authentication, and under Primary Site’s SAML2 Authentication Settings enter the details as per the screen snapshot above,


Note we’ve selected to use Email Address, or EMAIL in the Workspace settings as the unique identifier. You’ll need to copy the Certificate from downloaded file or Download metadata screen, ensuring you copy the entire contents into the X.509 Certificate field (including the Begin Certificate and End Certificate lines). The IDP Target URL:, IDP Issuer URL: and Audience Restriction: are all as per the Workspace information (again use the table at the beginning to map the SAML settings). When finished click on the Save & Close button at the bottom of the screen.

Authentication via Workspace SAML

Now you should be able to log out of Passwordstate, and on browsing to your Passwordstate URL be directed to the Google Choose an account and Enter your password challenge screens. Once you’ve logged into Google Workspace Passwordstate should open up as normal.

We hope this helps with Google Workspace and authenticating to Passwordstate using SAML. Please send any comments or feedback to  support@clickstudios.com.au

SAML Authentication with Azure AD

The Click Studios Technical Support group is regularly asked if we support authentication between Passwordstate and Microsoft Azure AD. The simple answer is yes, and in order to do this you must be using SAML2 Authentication as your global authentication setting. This allows you to setup authentication to, and Single Sign-On for, Passwordstate.

In order to use SAML2 authentication in Passwordstate, you must specify a number of settings, each of which can be obtained within the ‘Application’ configured with your SAML2 Provider. The following is a summary of settings that are required;

  • Specify the Certificate Type – either SHA1 or SHA256
  • Details of your X.509 Certificate
  • The IDP Target URL
  • The IDP Issuer URL
  • Audience Restriction

As the terminology isn’t always consistent between SAML2 Providers you should use the table below to map the Passwordstate SAML2 Authentication Settings to the information provided by Azure Active Directory,

Passwordstate Field Azure Active Directory Field
Audience Restriction Identifier (Entity ID)
‘Your Passwordstate URL’/logins/saml/default.aspx Reply URL
‘Your Passwordstate URL’ Sign On URL
‘Your Passwordstate URL’/logins/saml/default.aspx Relay State
UserID or Email or UserPrincipleName Unique User Identifier
X.509 Certificate (SHA256) Certificate (Base64)
IDP Target URL Login URL
IDP Issuer URL Azure AD Identifier
Logout URL Logout URL

Note in the above table ‘Your Passwordstate URL’ is the URL of your Passwordstate Instance. In the examples used in this blog ‘Your Passwordstate URL’ is https://prbpasswordstate.halox.net

Create a Non-Gallery Application in Azure

In these examples we’re going to configure Passwordstate for SAML2 Authentication and Single Sign-On with Azure AD. First you need to login to Azure via the portal and navigate to your Azure Dashboard. From here we select Azure Services->Azure Active Directory as per the screen shot below,

Then select Enterprise applications from the menu on the left,


and click on New Application. This will present one of 2 screens depending on whether you’re using the old App Gallery or the New and Improved App Gallery,


If you’re using the old App Gallery, you’ll see the following screen and will need to click on Non-gallery application as per the image below,


If you’re using the New App Gallery, you’ll see this screen instead and will need to click on Create your own application, give it a name and select ‘integrate any other application you don’t find in the gallery’,


This will create the Enterprise Application with the name you have provided. In this example it’s called Azure Demo-Passwordstate.

Configure and Generate your SAML Single Sign-on Information

Now we need to configure Single Sign-on and generate your SAML Provider settings for use in Passwordstate. First, we click on Single sign-on,


and then click on SAML to be able to specify the settings you require,


this will open the SAML-based Sign-on screen, allowing you to configure settings, download your X.509 Certificate and provide the URLs for configuring your Passwordstate SAML2 Authentication settings,


edit 1 Basic SAML Configuration and 2 User Attributes & Claims by clicking on the pencil Edit icon, and use the basis of the information as per the table at the beginning of this blog. Then click on Download next to Certificate (Base64) under 3 SAML Signing Certificate. Please note, as stated in the image you’ll need to add your users before they are able to login. They can be added via Users and groups on the Left Hand side of the screen,


Configure the Passwordstate SAML2 Authentication Settings

To configure your Passwordstate SAML2 Authentication you’ll need to login to Passwordstate and navigate to Administration->System Settings->authentication options. From here you’ll need to set your Web Authentication Options to SAML2 Authentication, and under Primary Site’s SAML2 Authentication Settings enter the details as per the screen snapshot,


Note we’ve selected to use Email Address, or user.mail in the Azure settings as the unique identifier. You’ll need to open the X.509 Certificate you’ve downloaded previously, with something like Notepad, and copy the entire contents into the X.509 Certificate: field, making sure to include the Begin Certificate and End Certificate lines. The IDP Target URL:, IDP Issuer URL: and Audience Restriction: are all as per the Azure Enterprise Application (our example is Azure Demo-Passwordstate),
SAML-based Sign-on screen. When finished click on the Save & Close button at the bottom of the screen.

Authentication via Azure AD SAML2

Now you should be able to log out of Passwordstate, and on browsing to your Passwordstate URL be directed to the Microsoft Azure Pick an account and Enter password challenge screens. Once you’ve logged into Azure Passwordstate should open up as normal.

We hope this makes it easier to understand how to authenticate Passwordstate with Azure AD using SAML2. Please send any comments or feedback to support@clickstudios.com.au

Control Access to Local Accounts with Credential Check-In and Check-Out

Many organizations implement strict access control to privileged accounts in their Domain and on their Windows Workstations and Servers. They work through a stringent process, ensuring local and domain user accounts have the least amount of privilege possible, lessening the possibility of exploits gaining control of systems.

However, the downfall is that a good percentage of organizations keep the same Local Administrator Account and Password combination for all Workstations. The defence, when challenged on why this is done, is typically along the lines of “we only have a handful of trusted staff that use this account”. In these cases, there is typically no auditing of which staff member used it, when and on which workstation. Key users are also typically entrusted with the generic Local Administrator account so that they can assist Support Teams (when they’re overloaded) by installing and trialling software. All of these scenarios provide the potential for rootkits, keyloggers, and other suspect services being installed without your knowledge.

With Passwordstate, you can easily setup unique Local Administrator and Password combinations for each host, audit and report the access to these accounts, configure Check In and Check Out so only one person can access the account at any point in time and setup scheduled password resets to limit exposure. Enabling PowerShell Remoting is a prerequisite required for this and you should understand the implications of doing so. Microsoft provide a good summary that can be found by searching for “PowerShell Remoting Security Considerations – Microsoft Docs”.

Discover All Hosts and Local Accounts

First, you’ll need to setup a Host Discovery job, identifying all your workstations and adding them into Passwordstate. In the example below I’m identifying all of our Windows 10 Workstations using the following Host Discovery Job.

As you can see from the above image, I’ve targeted the Windows 10 Operating System on our Domain and have specified a Privileged Account with permissions to query Active Directory for this Discovery Job. I’ve also simply selected the CN=Computers (CN being Common Name) on the active directory ous tab. It’s a good idea to initially run the query in Simulation Mode to make sure it’s returning the results you were expecting. Once you’re happy with the result you can unclick Simulation Mode and run the discovery job. You can also specify the frequency of the Discovery Job on the schedule tab. I’ve added in the results of the discovery job to the Hosts tab under a folder called Halox Workstations,


Next, I’ve created a Shared Password List called Local Windows 10 Admin Accounts. This will be used to store the Local Admin Accounts for the Windows 10 Workstations that I’ve added in. In the Password List I’ve selected Enable Password Resets and set the Default Password Reset Schedule to resetting every 90 days. On the customize fields tab it’s worth checking that the Expiry Date field is checked as required as this is updated with the new Expiry Date for the Passwords.


You can also specify the Password Strength Policy and Generator Policies in accordance with your organization’s standards.

Now you can setup the Local Account Discovery job. As per the image below, this discovery job will import all Local Accounts that are members of the Local Administrator’s Group on all Windows 10 Workstations and store the password records in the Local Windows 10 Admin Accounts Password List. You will need to specify the hosts to interrogate on the hosts to be queried tab. Again, you can run this job in Simulation Mode to ensure you are targeting the right machines and verify the results before actually importing them into Passwordstate. Note, If PowerShell Remoting isn’t enabled on the remote systems then you won’t be able to query the Local Administrator accounts on the target hosts.


Schedule Password Resets for Local Accounts

Once you’re confident you are obtaining the right results you can also elect to perform an immediate Password Reset for these accounts by selecting the radio button (bottom of the image). This enables you to bring all the imported accounts under control and reference Passwordstate as the single source of truth for these Local Account credentials.

Alternatively, you can go back to the Password List that the records are being stored in, and from the List Administrator Actions… drop down select Bulk Update Passwords,


When using either the immediate Password Reset or Bulk Update Passwords the Expiry Date will be updated in accordance with the number of days specified under Default Password Reset Schedule to enable future Password Resets to occur correctly.

Enable Check Out and Check In for Local Accounts

Lastly, we’re now at the option for Check In and Check out. This is extremely useful in offering a tight granular control over access to Local Accounts across your workstation fleet. To enable this for all Local Accounts you’ll need to modify the Local Account Discovery job you’ve previously created as follows,

This will now generate a Random Password for each Local Account that is imported, perform an immediate Password Reset on the Host that the Local Account belongs to, and specify the Security Settings of each Password Record limiting access to the password via a Check Out process, immediately perform a Password Reset on Check In and automatically Check In passwords after 12 hours (in case your System Admins have forgotten to). Anyone requiring access to a Checked Out Local Amin Account password will only be able to see who has exclusive access to this credential. All events are of course audited.

You can watch our YouTube video showing the Check In and Check Out functionality here.

We hope this information helps you to understand what options are available to better control access to Local Accounts and improve on your security posture. All feedback is welcome as always via support@clickstuidios.com.au

Specifying Authentication Options

A customer recently asked us to assist in resolving an issue with authentication for some of their users. This sparked some discussion between members of our Technical Support Team as to whether most customers knew where you can set the authentication properties required for access to Passwordstate.

The end result is this blog entry, as a reminder on where authentication properties can be set, and any specific limitations or conditions that apply to those areas. For the purpose of this blog entry we’re using an AD Integrated instance of Passwordstate. If you’re using Forms-Based Authentication then some of the screens may look slightly different.

Global Authentication Options

The first area where authentication options are set controls the settings for all users. This is typically referred to as the Global or System Wide authentication options and is accessed from Administration->System Settings->authentication options as per the image below,

As stated on the screen above, the default System Wide authentication option for Passwordstate is ‘Passthrough AD Authentication’ which requires no additional input from the user.

If you wish to change this simply select the option of your choice from the Choose Authentication Option drop down list. This will change the default authentication options for all Passwordstate users. The screen provides you with options for additional settings used with Manual AD, AD Integrated, Forms Based authentication as well as settings for other options including the popular ones such as SAML, Yubikey and Duo.

Authentication Options for Specific User Groups

Next you can set specific authentication options for groups of users through User Account Policies. This is performed by creating a User Account Policy, specifying an authentication option and assigning that policy to a group of users. To create a User Account Policy, navigate to Administration->User Account Policies and click on Add to create a policy,


Give the User Account Policy a name, description and choose an authentication option at Setting ID A6,

In line with Click Studios Best Practices, we recommend that if you have ‘Passthrough AD Authentication’ selected as your System Wide setting then don’t apply an additional Two-factor Authentication option to all users. It will frustrate your users and defeats the purpose of implementing Single-Sign-on to Passwordstate. You should instead look at applying an additional 2FA for users that need access to highly privileged or sensitive accounts. It is recommended that you do this via Security Groups and not by supplying individual usernames.

Once you’ve selected the authentication options and any other settings you want to apply, click on Save and then using the Actions icon next to your new policy, click on Apply Policy to Users. An example of applying Google Authenticator in addition to Manual AD Authentication / Passthrough AD Authentication can be found here.

User Preferences – Authentication Options

Passwordstate allows users to set a number of preferences. One of the ‘preference sets’ that can be individually configured on a per user basis is authentication options. This allows each user to specify what Authentication Option they wish to use when accessing Passwordstate, and what additional authentication options they want for accessing their Password Lists. For users to set their own individual settings they need to navigate to Preferences->Preferences->authentication options,

From this screen they can choose an Authentication Option as well as configure specific settings for multiple authentication options for 2FA. You should note however that the options that appear here can be hidden and overridden by;

  • An active User Account Policy, that applies to the user, with the Setting ID A6 set as ‘Use the System Wide Authentication Settings’,
  • Specific Authentication Options have been selected to be hidden under Administration->System Settings->authentication options->
    Hide the following Authentication Options on User’s Preferences screen:

     


Additional Authentication Required for IP Ranges

Lastly, you can choose to select different authentication options based on the IP address range that access to Passwordstate is initiated from.

This is especially useful when your System Administrators need access from non-trusted IP ranges, such as needing to access Passwordstate from an externally initiated VPN or when accessing from an Internet connection.

To configure authentication options specific for unregistered IP Ranges navigate to Administration->System Settings->allowed ip ranges->Web Site Allowed IP Ranges, specify the IP ranges for allowing access to Passwordstate and then under setting If the Passwordstate web site is accessed outside of one of the IP Ranges listed above, force the user to authenticate using the following method: choose an authentication option. If there are any settings required for that authentication option you can enter those details on the Administration->System Settings->authentication options screen.


We hope this helps you understand all the areas within Passwordstate where authentication options can be set. If you have any feedback, we’d love to hear it via support@clickstudios.com.au.

Password List Performance Testing

We’re asked every now and again about potential performance impacts with regard to the size of Password Lists. While every organisation is different there are some general considerations that should be thought about when designing your Password Lists within Passwordstate. These include,

  • Logically separate your password credentials based on meaningful descriptors such division, team, function, role etc.
  • Use Folders to group like Password Lists
  • Try to apply consistent permissions within a navigation tree’s nested folders
  • Keep the Password List display grid to 50 records or less

Despite using these points when designing your Password Lists you may still end up being tempted to create a few big lists. But how big is too big?

Sample Server Specification

We recently performed some performance testing for a customer who was looking at potentially creating some really big Password Lists. For the sake of consistency during the performance testing we spun up a modest Hyper V Windows Server 2019, using 2 processors and 8 GB of RAM in our Technical Support Test Lab,

Password List Sizing’s Used

Whilst many organizations end up with Password Lists that are organized in quite a granular fashion (using the considerations at the top of this blog entry) we’ve positioned the samples on the generous side of things when performing the testing.

The performance issue you encounter with extremely large Password Lists is directly related to HTML rendering. We generated 5 Password Lists, containing 5,000, 7,500, 10,000, 25,000 and 50,000 password credentials by first creating the Password Lists in the Passwordstate UI and then using our API to add in the required number of passwords for each particular List. The Lists didn’t need to contain usable login entries as such, they just needed to contain correctly formatted password records.

Performance Results

The baseline performance testing results are tabulated below. The good news is that Password Lists will take a fair number of password records before being substantially impacted by HTML rendering,

Password List Name

Number of Records

Rendering Time

5000 Passwords

5,000

Less than 1 second

7500 Passwords

7,500

1.5 seconds

10000 Passwords

10,000

2 seconds

25000 Passwords

25,000

4 seconds

50000 Passwords

50,000

8 seconds

Based on the results above most organizations could scale-up individual Password Lists to accommodate between 5,000 to 7,500 password records if required and still have response times for rendering between 1 to 1.5 seconds. Having said this, we can’t really think why you would need to have this volume of password records in a single list if you’ve designed your Passwordstate implementation and Password Lists appropriately.

Impact on IIS Worker Process

Another point worth noting, is the impact on your IIS Worker Process. During the performance benchmarking we observed the larger Password Lists had a significant impact on the resources required for the IIS Worker Process. Running the test on the 25,000 password records list caused the CPU usage to spike to 51% and the 50,000 password records list to spike at 55% CPU usage.

We hope this information is helpful and we welcome feedback via support@clickstudios.com.au.

Some Examples of Best Practices for Passwordstate

Here at Click Studios a couple of staff from Pre-Sales and Technical Support are pulling together the first draft of our Best Practices guide for Passwordstate. The recommendations provided in the Guide are a direct result of assisting organizations around the world deploy Passwordstate successfully and streamline their privileged access management practices.

As the finished version of the Guide is still a little way off, we thought you may appreciate having a couple of the Best Practices previewed here.

Securing your Web.config File

One of the easiest ways in which you can secure your Passwordstate Instance is to encrypt both the Database Connection String and appSettings Sections of your Web.config file. This ensures that anyone having access to your Web Server’s file system will be unable to use the details of the Web.config file to access and retrieve your Password Credentials.

The process is straightforward and requires you to separately encrypt the Database Connection String and appSettings Sections of your Web.config file using aspnet_regiis.exe. The executable is usually located in the %windows%\Microsoft.NET\Framework\versionNumber folder. Once you’ve encrypted the two sections you’ll need to stop and restart the Passwordstate Service.

The example image below shows the command being executed for the AppSetting section, stopping and then restarting the Passwordstate Service,


Full instructions for performing this can be found within our documentation here or our blog entry here.

Use 2FA with SSO for highly privileged Accounts

Most organizations choose to install the AD Integrated version of Passwordstate and enable Single Sign-On (SSO) access to their Password Lists (Password Vaults).

The use of SSO is great for providing seamless entry to Passwordstate, once users have been successfully authenticated against your Domain, using their Active Directory credentials. However, for access to highly privileged and sensitive account credentials, stored within Passwordstate, we recommend you introduce an additional level of authentication.

An easy way of doing this is by enforcing 2FA, with a Smartphone App like Google Authenticator, for either your Systems Administrators or against access to Password Lists containing the highly sensitive credentials. To do this you create a User Account Policy (UAP) that specifies that users must use Google Authenticator (the example below uses Manual AD and Google Authenticator) and apply this UAP to your target list of AD accounts,


The Systems Wide Settings for Authentication Options remain set as Passthrough AD Authentication. Now anyone in your target list of users will be prompted for their Google Authenticator PIN as an additional level of authentication when browsing to your Passwordstate Website.

Full instructions for performing this can be found in our blog entry here.

Allow the use of Private Password Lists

Allowing the use of Private Password Lists for users within your organization is encouraged. Organizations that adopt and promote the use of Private Password Lists for their employees typically build a healthier cybersecurity awareness in their workforce. These employees more quickly embrace and adopt credential management practices, for both personal and business use within the organization.

You can automatically create Private Password Lists for all new user accounts as they are added to Passwordstate by enabling the option When a new User Account is added to Passwordstate, automatically create a Private Password List for the user. You can also specify the name of the Private Password List using the variables FirstName and Surname and base the new Private Password Lists on an existing or newly created Password List Template.

Once you have chosen your template, you’ll need to enforce the creation of the Private Password Lists on that template by creating a User Account Policy and targeting All Users and Security Groups,

Now each new User will have their own Private Password List and be configured as the Administrator of that List. Again Full instructions for performing this can be found in our blog entry here.

We hope you find this preview of some of our Best Practices useful and don’t forget to provide any feedback via support@clickstudios.com.au.

Click Studios Support

Click Studios has built its well-earned reputation on three Pillars. The First Pillar: Continuous development of an Enterprise grade Password Management Solution that is feature rich and scales from the smallest not-for-profit to the largest multinationals. The Second Pillar: Our solution must remain affordable for all businesses ensuring that everyone has the opportunity to protect their privileged accounts and access to data. The Third Pillar: Provide excellence in the technical support of our solution by hiring inquisitive, technically savvy, customer focused team players that are truly passionate about helping others.

Click Studios Support

The Passwordstate product suite, including the core product covered by Client Access Licenses (CALs), Enterprise and Global Licensing along with the High Availability Module are all able to be placed under maintenance. The Click Studios term for maintenance is Annual Support and Upgrade Protection. Active Annual Support and Upgrade Protection entitles customers to all minor and major releases of Passwordstate, Priority Email and Phone support covering technical questions, how to questions, general enquiries and Remote Desktop assistance if deemed necessary by our Technical Support Team.

Our subscriptions for the Password Reset Portal and Remote Site Locations are only available if you have Active Annual Support and Upgrade Protection and the duration of the subscription is bound to your support expiry date.

What is covered (in detail)?

By purchasing Annual Support and Upgrade Protection you are covered by the terms and conditions as outlined here. When you navigate to the support page on our Website, you’ll see the following displayed;


It’s important to read through the details on this page to understand what is covered and what is excluded. The following is a brief outline of what is supported and when;

  • Only the current Major version and one previous Major version and their associated add-ons are supported. This will mean that 90 days after the release of Passwordstate V9 we will only be able to support Passwordstate Version 9 and Passwordstate Version 8 (back to June 2017).
  • Email support is available from Mon-Fri, 6:00am-6:00pm UTC +09:30 (Adelaide, Australia)
  • Phone support is available from Mon-Fri, 8:30am-5:00pm UTC +09:30 (Adelaide, Australia)
  • Emails and Support Tickets generated between the support hours described above will receive a response within 2 hours. Outside of standard support hours we guarantee a 24 hour response (generally within 12 hours)
  • We are unable to cover third party applications, hardware or the use of Click Studios software in unsupported environments. This includes assistance with Load Balancers, Network configuration and assistance in maintaining your Microsoft SQL Databases.

Please note, if you have accidentally allowed your Annual Support and Upgrade Protection to lapse we’ll be unable to provide you with any assistance (even though the Technical Support Team will want to). The Technical Support Team will advise you of this and will CC in sales@Clickstudios.com.au to assist with a quote to reimplement your Annual Support and Upgrade Protection.

How to log a Support Call

When needing to log a support call you have 3 options. The easiest is of these is to Generate A Support Ticket, followed by directly emailing our Technical Support Team and lastly via calling support.

To Generate a Support Ticket simply browse to the Click Studios Website Support Page https://www.clickstudios.com.au/support.aspx and you’ll be presented with the following screen,


This page details the support hours for Email Support (including Support Tickets), the current date and time for Adelaide Australia and the international phone number if needing to call for support. It also provides the email address support@clickstudios.com.au if you need to email us directly. As indicated, you’ll need to provide us with;

  • The Passwordstate Build Number, e.g. 8973
  • The Web Server Operating System selected from the drop down list, e.g. Windows Server 2019

Once you’ve entered these and clicked on Generate Support Ticket you’ll be presented with an email as per below;


You’ll notice that the above email has prepopulated the Build Number and Server OS fields and generated a Support Ticket ID for this request. Now comes the important part, we need as much information as possible relating to your issue. This includes,

  • The Web Browsers you are using to connect to the Passwordstate web site e.g. Edge Version 85.0.564.51
  • Screenshots of any errors
  • Description of what you were doing in Passwordstate at the time
  • Instructions on how to reproduce the error

Call Support

While we prefer to accept Support Requests via Generating A Support Ticket or direct email we will of course accept phone calls.

The reality is that more than 99% of our Support Requests are in the form of Support Tickets and direct Emails, and as this medium supports the supply of diagnostic rich information, it is far more effective for both parties.

What about Trial Implementations and “Free for 5 Users”?

Click Studios understands that Support Requests may be submitted by organisations that are trialling Passwordstate and for small business that have taken up the offer of “Free for 5 Users” licensing. In these instances, Click Studios will use reasonable efforts to provide technical support on the following basis,

  • Customers with active Annual Support and Upgrade Protection will be prioritised highest in the queue for support
  • Potential Customers with active Trial licenses and are still trialling Passwordstate are prioritised next
  • Small businesses with “Free for 5 Users” licensing are prioritised last

Extended Support

Click Studios offers Extended 24 x 7 Support which is in addition to the standard support coverage. The Extended Support is for critical events where the Passwordstate Website is not accessible for all users. Customers must have attempted to restore their Passwordstate Instance system from the last known good backup before contacting Click Studios.

The Support Request process is initiated via calling the Extended Support phone number, issued after Extended Support has been purchased. Your call will then be routed to the on-call Technical Support Engineer. Please note the Technical Support Engineer does not monitor the Click Studios Ticketing system for incoming Support Requests. In these cases you should only email through information for the on-call Technical Support Engineer when requested by them.

The limitations associated with Extended Support are,

  • Any minor events or issues logged as part of the Extended Support will incur additional charges
  • Email requests received outside of standard support hours will not be processed until the next business day
  • It is not available for Trial or “Free for 5 Users” licenses
  • Click Studio reserves the right to determine which customers qualify for the Extended Support prior to accepting the order
  • Additional charges may apply in instances where upgrades have been attempted and backups have not been performed and/or instructions have not been followed

If you have any queries, or want to provide feedback, please email it through to support@clickstudios.com.au

Buy Now – Options and Information Required

You may be a new customer, having trialled Passwordstate, and are about to jump in and make your first purchase. There are a number of different ways in which you can purchase Passwordstate, so which do you choose? This week’s blog entry is a quick overview of using the BUY NOW menu option available from our Website.

Locating the BUY NOW Options?

When you browse to the Click Studios Website https://www.clickstudios.com.au/
you’ll notice the third menu item, from the left at the top of the screen, is BUY NOW. This menu provides a range of different options and information to ensure you have everything you need to complete your purchase.


Buy Now

When you select the Buy Now option you will be taken through to our Purchase Passwordstate page https://www.clickstudios.com.au/buy-now.aspx. This allows you to enter the quantities and types of licenses you require. In all the examples for this week’s blog entry we are using a fictitious company called Contoso,


In our examples Contoso are about to purchase 60 x Client Access Licenses (CALs) with Annual Support and Upgrade Protection and a Password Reset Portal Subscription for up to 100 Users. The cost for the purchase is presented to the customer and they can fine tune the quantities up and down as required before selecting Buy Now. It is important to note that outside of Australia the purchaser is responsible for any applicable sales and value-added taxes in their jurisdiction. These taxes are not factored into the prices presented on the Purchase Passwordstate screen. Our Australian customers will be presented with the GST component on this screen and it is factored into the Total Price.

On clicking Buy Now you will be directed to our Webpage that links through to our global eCommerce partner BlueSnap,


When entering your payment details you should note;

  • If you don’t see the Order Information as per above click on the + symbol in the circle. That will expand the Order Information summary. To see the full description, hover your mouse cursor over the description.
  • You’ll note that BlueSnap have automatically added the Tax for your Jurisdiction. This controlled by BlueSnap and is legally required by them. For European customers with tax exemption you will have the option to input your exemption code and BlueSnap will not apply this Tax component.

Once you’ve completed filling out your details click on submit. You will receive an email with the order details and your license keys will be emailed through within a maximum of 48 hrs (typically 12 hrs).

Get a Quote

When you select the Get A Quote option you will be taken through to our Create Passwordstate Quote page https://www.clickstudios.com.au/create-quote.aspx. This allows you to create a formal quote and have that emailed through to a nominated email account. Simply supply the Company Details and enter the quantities and types of licenses you require as per the image below,


On clicking Submit the nominated email account will receive a copy of the Quote as per below,


You’ll also note that at the bottom of the quote you are presented with a number of options to proceed with the order,


  • If you click on the Click to order Online link at Option 1 you’ll be taken through to our Webpage that links through to our global eCommerce partner BlueSnap.
  • If you click on the Click for Purchase Orders Instructions link at Option 2 you’ll be directed to https://www.clickstudios.com.au/purchase-orders.aspx
    and be presented with the details to be included on your Purchase Order,


  • If you elect to take Option 3 and provide a Direct Bank Deposit / Wire Transfer please note that IBAN (International Bank Account Number) is not used in Australia. We have followed the recommendations issued by the Commonwealth Bank of Australia on how to represent an IBAN. You can reference their information here. Please ensure you email us with the License Registration Name, typically your Company or Business Name, your contact details including First Name, Surname and email addresses of up to 4 contacts and the details of the transaction. Don’t forget to reference the quote or invoice number in the deposit / transfer description so that we can trace the payment. Once we have received payment we will generate the licenses keys and email them through.
  • Lastly, if you decide to pay by Check and are based outside of Australia it can take between 8 to 12 weeks for the Check to arrive.

We hope this helps in better understanding your purchasing options. If you have any queries or would like to provide feedback please email it through to support@clickstudios.com.au