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 PasswordstateAccess to PasswordsAll Passwords Exported
Auditing Data ArchivedDiscovery JobsDocuments
EmailsEmail TemplatesEmergency Access
Encryption KeysFailed APIHosts
LoginsPasswordsPassword Lists
Password ResetsPassword ValidationPrivileged Accounts
Remote SessionsReportingRestricted Features
Security AdministratorsSecurity GroupsSelf Destruct
TemplatesUser AccountsUser 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

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

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 FieldWorkspace Supplied Fields
Audience RestrictionService Provider Entity ID
‘Your Passwordstate URL’/logins/saml/default.aspxACS URL
‘Your Passwordstate URL’Service Provider Entity ID
UserID or Email or UserPrincipleNameEmail
X.509 Certificate (SHA256)Certificate
IDP Issuer URLEntity 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

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 

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 FieldAzure Active Directory Field
Audience RestrictionIdentifier (Entity ID)
‘Your Passwordstate URL’/logins/saml/default.aspxReply URL
‘Your Passwordstate URL’Sign On URL
‘Your Passwordstate URL’/logins/saml/default.aspxRelay State
UserID or Email or UserPrincipleNameUnique User Identifier
X.509 Certificate (SHA256)Certificate (Base64)
IDP Target URLLogin URL
IDP Issuer URLAzure AD Identifier
Logout URLLogout 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

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 screenWhen 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 

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 trialing 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

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 NameNumber of RecordsRendering Time
5000 Passwords5,000Less than 1 second
7500 Passwords7,5001.5 seconds
10000 Passwords10,0002 seconds
25000 Passwords25,0004 seconds
50000 Passwords50,0008 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

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

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

Hosting Your Password Reset Portal in a DMZ

We were recently asked if it was possible to install the Passwordstate Password Reset Portal in a DMZ.  A DMZ or Demilitarized zone, also known as a Perimeter Network or Screened Subnet, is usually a physically (or logically) separate network containing an organization’s external-facing services.  This is usually the Internet however large federated institutions such as Universities sometimes utilize the same for common services offered to faculty networks.

Our Password Reset Portal is a Self-Service Portal designed to enable your users to unlock or reset the password for their Active Directory Domain account.  The intent is to allow end-users to easily reset their own Active Directory password without having to contact your Help / Service Desk.  This not only means the service is available 24 hours a day, but you also unburden your IT Support staff from having to handle high volume, repetitive, transactional processes that are ultimately of low value (if the security aspect is handled appropriately).

And yes, you absolutely can install the Password Reset Portal within a DMZ so that it’s accessible to employees that are out of the office.

Verify the User is who they say they are!

This is where we cover the prior statement about the security aspect being handled appropriately. 

Most organizations struggle with the manual processes associated with verification of a user’s identity when they need their password reset!  This isn’t just an unsubstantiated statement.  The Click Studios Senior Management Team have worked in Executive and Senior IT Management positions spanning Global and Australian Enterprise Organizations, in industries such as Aerospace and Defence, Government, Law Enforcement, Mining, Oil & Gas, Banking & Finance, and Systems Integration. 

Rather than utilize manual processes for identity verification, the Password Reset Portal has the option of up to 10 different secure verification policies to choose from.  This means you can identify your users as they start the process of resetting or unlocking their AD Password.  It’s a more secure process than having an employee manually process the request, provides a faster and better user experience and is available 24 hours a day!

Install the Password Reset Portal where you need it!

The Password Reset Portal is installed via a separate installer executable and is included with the Passwordstate core product download.   It can be accessed from the screen Administration->Password Reset Portal Administration within Passwordstate.  Installation is performed through a Setup Wizard and the instructions can be located here,

The Password Reset Portal operates via a separate website and communicates back to the main Passwordstate website via an SSL tunnel.  All traffic carried via the SSL tunnel is encrypted.  All business logic including user authentication, verification of user identity, password resetting and unlocking of accounts etc. is performed by the API (Application Programming Interface) located on your Passwordstate website.

As this blog is about installation of your Password Reset Portal in your DMZ, click next and supply the information relevant to your environment and click Save.  You’ll then be prompted to run PasswordResetPortal.exe on the server you have chosen within your DMZ.  Simply follow the instructions provided by the Installation Wizard to complete the install. 

Open Port Considerations

It’s important to remember that your Website that hosts the Password Reset Portal in the DMZ must have appropriate ports open back to your Passwordstate web server.   

  • For communication from the Password Reset Portal back to you Passwordstate Instance API this is generally Port 443 unless you are using a non-standard port by default for HTTPS.  You must also have a Domain Certificate Authority installed, so that Passwordstate can communicate via LDAPS (LDAP over SSL).
  • Port 636 is required by LDAPS for communication by the Passwordstate User Interface and the API to Active Directory, allowing the reset of Passwords and unlocking of accounts.
  • Ports 135 and 49153 are required for the Passwordstate UI and Windows Service to query Event Logs on Domain Controllers for bad login attempts and account lockouts.

As usual, any suggestions or feedback are welcome via

Emergency Access Password – What is it and how do I find it?

Click Studios designed a secure Emergency Access login to Passwordstate back in the early days of Passwordstate 5.  The Emergency Access account is a separate built-in account with ‘Security Administrator’ rights that allows login to Passwordstate when other accounts are locked out, or inaccessible for any reason.  This account doesn’t allocate a license from your available license pool and is not intended for use in day to day operations.  It should be regarded as an account of last resort.

An organization would typically only use their Emergency Access account under select scenarios such as;

  • You have issues authenticating to Passwordstate due to the Authentication Option you have selected no longer working.
  • All Security Administrator accounts have been accidentally disabled or deleted, with no other accounts being able to administer all settings for Passwordstate.

To login via the Emergency Access account you must browse to the URL HTTPS://<Your Passwordstate URL>/Emergency.  You are then presented with the following login screen,

As stated in the image above, there is increased auditing associated with the Emergency Access account.  In browsing to the login screen you will trigger an audit event.  The following applies to attempted and successful logins using the Emergency Access account;

  • Browsing to the Emergency Access URL will generate an audit record.  The details for the event, including the IP Address the access was initiated from, is subsequently emailed to all Security Administrators.
  • On successful and unsuccessful login, details for the event including the IP Address the login attempt was initiated from is emailed to all Security Administrators.
  • On successful login you must specify a reason why you need access and these details are added to the auditing data.

Once you’ve logged in with this account, you will have access to the Administration area of Passwordstate.

Auditing of Emergency Access

The auditing details below relate to Click Studios internal Passwordstate Instance and show an attempted access to the Emergency Access Login Screen (for the purpose of creating the blog entry).  As this is our Production Instance please understand that I’ve redacted the account details, names of the Security Administrators and their email accounts from the screenshot below,

Setting the Emergency Access Password and Permitted IP Ranges

If you need to change the Emergency Access password navigate to Administration->Emergency Access->emergency access details.  Here you can set the Password and print it out for safe storage if required,

Whilst you can always RDP directly to your Passwordstate Server, you can further lock down the ability to login over the network, via the Emergency Access login screen, by specifying Allowed IP Ranges.  Using this feature, you can specify individual IP addresses as well as allowed IP address ranges. To set Allowed IP Ranges navigate to Administration->System Settings->allowed ip ranges and add the relevant entries under Emergency Access Allowed IP Ranges.  Remember to add only one specific address or IP ranger per line,

Recover the Emergency Access Password

If you ever lose the printed copy of the Emergency Access Password, or if it’s been reset by someone and not recorded anywhere, you can contact Click Studios and ask us to recover it for you.

In these instances we’ll need email approval from line management before proceeding.  Once we have approval, we’ll require;

  • The most recent version of your Web.config file.  This should be located in the root directory of your Passwordstate installation or C:\inetpub\passwordstate.
  • The values for EA_Password, Secret3 and Secret4 from your Passwordstate Database, located in the Passwordstate table. To extract these, you’ll need to use Microsoft’s SQL Management Studio tools to connect to your database server and execute the following query;

USE Passwordstate

SELECT EA_Password, Secret3, Secret4 FROM SystemSettings

We’ll then recover the Emergency Access Password for you using our in-house support tools;

We’ll then email the password details back to you.  Once you receive the email we suggest the first thing you do is change the Emergency Access Password, record it, print it out and store it somewhere safe!  We also encourage you to rotate your encryption keys, refer to Section 2.12 Encryption Keys here.

That’s it for this week.  Any suggestions or feedback are welcome and you can send these through to