Your Sysadmin has resigned, what do you do next?

Change within your workforce is inevitable!  Employee departure is almost a universal constant, right up there alongside death and taxes.  Employee’s move on for a range of reasons, some leave abruptly, some unfortunately have their employment terminated, some give their required number of weeks notice and others generously provide some flexibility while you search for a replacement. 

However, no matter what the circumstances, when a Systems Administrator leaves there will be disruption.  This disruption can be thought of as a continuum ranging from mild inconvenience at one extreme to utter chaos at the other. 

As they exit your employment there is a myriad of activities that need to be undertaken spanning Human Resources, Payroll, Outplacement Services, reassignment of existing workload etc.  This blog does not cover any of the other disciplines or activities outside of IT.  Rather it is focused on how you ensure the integrity of your privileged credentials, and therefore your data and systems once a Systems Administrator has left.

First Things First!

Immediately disable all personal accounts used by your Systems Administrator.  Most organisations will start this process as the individual leaves your place of employment for the last time. The accounts should include personal and elevated privilege Active Directory Accounts, Unix / Linux accounts, VPN and mobile device connections etc.

If your Passwordstate Instance is AD Integrated this will now prevent them from logging-in and accessing any privileged credentials that they had permissions to.  If you are using Forms-based authentication, or have local Passwordstate login accounts, you will need to login to Passwordstate and set the local account to disabled by selecting the Action Menu next to the user account and clicking on Toggle Status – Enable or Disabled.

Query What Accounts They Had Access To!

One of the invaluable features in Passwordstate is being able to report on what password credentials a user has been granted access to, as well as what they’ve historically accessed.  To do so, simply navigate to Administration->Password Lists and click on the Perform Bulk Processing…  drop down list underneath the Password Lists grid as per the screen shot below;

This will bring up the Bulk Password Reset screen, which I’ve broken down into multiple parts.  The first is the section located to the left-hand side of the page called Search Filter,

Simply enter the User Account of the Systems Administrator, the Site Location you wish to report against (default is All Site Locations) and options for,

  • Recommend resets based on historical user activity, or,
  • All password the user has access to.


  • Show records enabled for Reset, or,
  • Show records which are not enabled for Reset.

It’s important to note the first two are mutually exclusive, as are the second two options.  It’s also important to understand why some password records are not enabled for Reset.  In most cases these will be accounts used to login to applications or web pages where Passwordstate doesn’t have the ability to programmatically reset passwords. 

Site Locations relate to the use of the Remote Site Locations subscription module, where you can manage accounts located on disconnected networks, either firewalled on your internal network, or firewalled over the Internet.

Once you have entered your search criteria click on the Search button.  This will populate the Search Results Grid at the bottom of tReset those Accounts!

Now move over to the right-hand side of the page to Reset Schedule,

From here, you can,

  • Schedule At a specific date and time to reset the passwords for the accounts you select,
  • Add All Records to Queue – if they are accounts that are enabled for Reset, or
  • Add Selected Records to Queue – by selecting them using the check box for each account returned in the Search Results grid at the bottom of the page.  Again, this will only be available if the accounts selected are enabled for Reset.
  • Or you may want to run the Reset job immediately by clicking on Now

If you’ve selected any accounts that are disabled in AD they will still have their passwords reset to the new values.  In the event that you have records that are not enabled for Reset, you can still select them and the use the Export control shown at the bottom of the Search Results grid.  This will export the details of these accounts to a .CSV file so you can manually change these accounts.  Note the passwords for these accounts are not exported in this CSV file.

Lastly, there is a Password Reset Queue grid shown at the very bottom of the page.  This shows any currently pending scheduled Reset jobs.

So Why Do All This!

Using Passwordstate to identify accounts that your ex-Systems Administrator had historically accessed, or had permission to, is both straightforward and easy to do.  You can quickly identify and then reset those accounts to ensure there is no opportunistic or deliberate attempt to access systems.  That’s not to say your Systems Administrator may be intent on causing utter chaos, rather you have a duty to act professionally and take the actions necessary to ensure the integrity of your organization’s privileged credentials, data and systems.

As always, we welcome your feedback via

Reporting Passwords about to Expire

In previous blog entries we’ve run through setting up Scheduled Reports to alert Security Administrators and users when particular events occur.  The previous examples focused on alerting an intended audience when extremely sensitive password credentials, say for an organization’s primary bank account, were accessed.  However, you can also setup a Scheduled Report to notify an intended audience when password credentials are about to expire.  But wait…there’s more. 

You can use Passwordstate to share information, based on assigned roles and permissions and with full auditing of access to this information.  This can include information relating to,

  • Alarm/Door Codes
  • Credit Cards
  • Software Licences
  • SSL Certificates

Passwordstate provides built in templates for these, and you can create your own for things like hardware or software maintenance contracts etc.  The details on what else you can record can be located in a previous blog entry here.  Once you’ve got information and/or password credentials in Passwordstate, you can setup Scheduled Reports to notify you when they are due to expire.

Setup Report for Passwords about to Expire

Like with the previous blog examples, we’re going to use the following account for this blog (yes – it’s still a fake account).  It does however enable us to report against it,

Next, we’ll setup a Scheduled Report by navigating to Reports->Scheduled Reports as per the screenshot below,

and create a report called Passwords-Expiring-90 with the following options,

Note, I’ve elected to CC Report To one of my colleagues, Email Report As Embedded HTML, selected Do not send report if it produces no results and Selected Report Type as What passwords are expiring soon? You’ll also note under Report Description & Criteria it states to use the expiring passwords settings tab.  This is where you set the Password Lists and options you want to use.  I’ve selected the Password List called Website Logins, and the number of days in the future you want to include in the report, in this case 90 days.  You can also select if you want to include passwords that have already expired.

Then simply specify the time and frequency of the report on the Schedule tab, with options for One Time, Daily, Weekly or Monthly.  When the report has run, I receive an email as per the following screenshot,

Storing SSL Certificates and Reporting Expiry

Using the above example, being notified of passwords that are soon to expire, you can do the same for other types of information stored in Passwordstate. 

Here at Click Studios we store all our SSL Certificates, along with their expiry date in Passwordstate.  This enables us to run scheduled reports, advising what certificates are due to expire in the next 90 days.  I’ve included the redacted screenshots showing the SSL Certificate entry for our QA (Quality Assurance) environment below;

and the copy of the certificate,

and the rest is as simple as the steps in the first example.  Doing this we never get caught out with certificates expiring on us without notice!

As always, we welcome your feedback via

Improve Mobile Security

What is the single biggest threat to mobility in the workplace?  There isn’t one single threat, rather there are multiple threat categories that pose serious issue.  These range from Fake WiFi Networks, Malware Infections, Malicious Apps and Phishing Attacks. 

As more businesses embrace mobility to improve business processes, increase workplace productivity and enhance employee satisfaction, the risk transfers from traditionally IT managed infrastructure to consumer grade, largely unmanaged, mobility devices.  Add in mobile devices are used to access the multi-factor option of choice, because people are addicted to their smartphones, it’s easy to see why these devices are so desirable as an attack vector for Cyber Criminals.

Sources of Mobile Based Attack

What Cyber Criminals used to target via the desktop they are now targeting via mobile devices.  There are more vulnerabilities exposed in mobile endpoints compared to well managed IT infrastructure.  Over the last three years the number of major vulnerabilities and malware threats for mobile devices have almost tripled.  This results in increased credential theft, data leakage and fraudulent transactions.

A survey run by Enterprise Mobility Exchange reported that Fake WiFi networks were the predominate threat, followed by Malware Infections of mobile devices, Malicious Mobile Apps and Phishing Attacks.

Fake WiFi networks, often called honeypots, allow Cyber Criminals to steal credentials, browser history and perform Man-In-The-Middle attacks when users connect to them.  This is typically done by spoofing the web traffic for the websites the user visits.  Malware is often installed allowing the contents of the device to be read and enabling future theft of credentials and data.

Malware infections are typically a result of having downloaded a malicious app, downloading and opening message attachments from an email or SMS, downloading content from a website and having unpatched vulnerabilities.  Android smartphones are more vulnerable, as Google allows downloading of Apps from sources other than the official Google Play app store, and the core Operating System code is open-source. Even though Apple is a closed ecosystem they aren’t immune as the App store reviews have missed apps that were infected with Malware in the past.

Malicious Mobile Apps can be either outright malicious or introduce risk of compromise through adware, excessive permissions, or a dangerous combination of permissions.  They typically attempt to harvest account credentials or information that can be used in future attacks.  Excessive permissions can be used to intercept multi-factor authentication or send spam and phishing campaigns from your device.

Phishing attacks typically simulate well-known brands such as Banks, Retailers and Webmail, offering login portals that seek to capture specific service credentials or simply obtain email logins that are used in future credential stuffing attacks.

Make it Harder for Cyber Criminal to Exploit Your Mobile Devices

Encryption of your mobile device is critical.  Most zero-day threats require some form of jailbreak or root detection.  When your device is encrypted it acts as an additional layer of security that can help prevent zero-day threats.  By enforcing the use of a Passcode, you turn on encryption in iOS.  With Android there are some additional steps that need to be taken to ensure your device is encrypted.

Best Practices for Mobile Device Security

The following are recommended points to consider for protecting mobile devices, the sensitive credentials used from, and data contained on them:

  1. Be Clear in Your Policies, Procedures and Processes
  2. Make Strong Passwords Mandatory and conform to your Password Policies
  3. Incorporate Biometrics at the OS and Application Levels
  4. Block known Malicious Apps
  5. Encrypt Mobile Devices
  6. Prevent Public WiFi Use
  7. Budget for Mobile Security (it shouldn’t be an afterthought)

So, does Click Studios now Provide Mobile Security?

Well….no.  The point of this blog is to point out that Cyber Criminals are increasingly targeting selected users’ mobile devices.  The security on these devices tends to be less stringent than on business managed desktops and the majority of users still don’t associate the use of mobile devices with an increased risk of targeted attacks.

With the release of Passwordstate V9 we are providing native iOS and Android Apps that allow access to your Passwordstate credentials.  While these apps are secure, and have been application penetration tested, only you know the state of your mobile device cyber hygiene.  We highly recommend following Cybersecurity Practices to maintain good cyber hygiene and the use of a Mobile Device Management (MDM) or Enterprise Mobility Management (EMM) solution for protection and management of your mobility devices.

And don’t forget, when it comes to generating strong passwords that meet your Password Policies, storing them securely and sharing them amongst your team, you can rely on Passwordstate,   the web-based solution for Enterprise Password Management used by more than 29,000 Customers and 370,000 Security & IT Professionals globally.

As always, we welcome your feedback via

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