Troubleshooting AD Password Resets Performed via the Portal

The intent of our Password Reset Portal, is to remove unnecessary interaction by Help Desk staff and Systems Administrators when users need to reset their Active Directory Users Accounts.  The portal is aimed at making users self-sufficient at the process, ensuring they can reset the account when they need to, and allow support staff to focus on higher value tasks.

Error: Password Doesn’t Match the Policy

But what happens when the process doesn’t seem to be working?  We recently assisted a customer with a scenario where the users couldn’t seem to match the Password Policy no matter how often they tried.  They attempted to troubleshoot this by generating a password in Passwordstate however this wasn’t being accepted either.  So where do you start to troubleshoot AD Password Resets performed via the Password Reset Portal? 

To start off with let’s use an example of a Password Policy and Failed Reset Message.  This is configured under Administration->Password Reset Portal Administration->Password Policies,

Note: You can set the Failed Reset Message wording so that it’s consistent with the language used within your organization.

Password Reset Portal Process

At a high level, the process that is used within the Password Reset Portal is;

  1. When a user resets their AD password, the characteristics of that password must adhere to the Password Policy that has been defined.  For the sake of this blog the Password Policy is the Default Policy and is the same for all fields as we’ve set in the previous image.  Again, this is set by navigating to Administration->Password Reset Portal Administration->Password Policies,
  2. As the user types in the new password, the Portal page will report on what characteristics are required to set a password.  These must match the policy and feedback is provided live as they type in the new password,
  3. Once all requirements are satisfied the Password Reset Portal will attempt to reach out to Active Directory to reset the password.  At this stage, if your Domain Password Requirements as specified in your Domain Group Policy have further complexities, then the user’s new password will be evaluated against these further complexities.

If the Password Reset is rejected with the Failed Reset Message in the image above, then it is most likely the error you are seeing is coming from your Domain and not the Password Reset Portal.

Settings that Impact on Portal Resets

There are a number of settings that can impact on the Password Reset Portal successfully resetting a user’s password. 

The first is located in a group policy setting.  Open your Group Policy Editor and navigate to Local Computer Policy->Computer Configuration->Windows Settings->Security Settings->Account Policies->Password Policy and look for a Policy setting stating the Minimum password age

The Minimum password age of 1 day is the default setting.  It is used to prevent repeated resets until a favourite password can be cycled back in again.  You’ll need to consider the risks associated in changing this default, and if acceptable you can relax this setting and enable multiple password resets per day by changing the Security Setting to ‘0’,

The next setting that can impact on successfully resetting the password is if your permissions associated with impersonation aren’t correct.  To check this, you’ll need to launch the Local Security Policy editor by running secpol.msc.  From there you’ll need to navigate to Security Settings->Local Policies->User Rights Assignment and review the permissions that are set for Impersonate a client after authentication.  These should be set to the following as per the screenshot below.

  • Local Service
  • Network Service
  • Administrators
  • IIS_Iusers
  • Service

And lastly, it’s possible that you may have a fine grain policy set in Group Policy, that takes precedence over your Standard Password Group Policy. 

This may have been set with a Minimum password age set to something greater than 1, or, may have stricter password complexity requirements.  To check if you have a fine grain policy set up you’ll need to logon to one of your Active Directory Domain Controllers, open the Active Directory Administrative Centre and navigate to System->Password Settings Container as per the image below,

If there is a policy show in the area outlined by the green box above then please check the settings.  If you’re unsure you may want to refer to the person that is applying the policy.

Privileged Account Credential Permissions

One final thing you can check is to confirm the Privileged Account Credential, that you have specified for the Password Reset Portal, has sufficient permissions to reset the AD Accounts.  The Privileged Account Credential is set under Administration->Password Reset Portal Administration-> Privileged Account Credentials

This should be a member of the Account Operators Security Group.  If it isn’t working you can temporarily test with as a member of the Domain Admins Security Group.

Got feedback you want to share?  Email it through to

Stopping and Restarting your Passwordstate Instance

We’ve recently had a number of enquiries around the best way of Stopping and Restarting Passwordstate.  Most of these enquiries have been related to businesses getting ready to test their Annual DR (Disaster Recovery) and BCP (Business Continuity Plans).

With this scenario in mind, we’ll establish for the sake of the blog entry, that we’re talking about a Passwordstate Primary Instance with HA (High Availability) instance in an Active / Passive configuration.  It is assumed that the HA instance is on a separate network with associated infrastructure enabling it to be contactable as required.

The image above represents a simplified logical view for this blog entry.  The webserver and database servers are installed on separate Windows Servers and all members in the example are connected over a traditional diverse pathed ethernet networks.  The Passwordstate webservers site behind a load balancer.

What Needs to Be Stopped?

The premise for this blog is you want to ensure your High Availability Instance is running and can be pointed to in the event your Primary instance is non-functional.  In order to test this, you need to effectively stop your Primary instance and then test your HA instance is functioning.  But how do you do this?

You could simply shutdown the Primary instance webserver.  Or you could follow shutdown the Primary Instance Passwordstate Windows Service and IIS (Internet Information Services) Site.  The Passwordstate Windows Service is used to perform all background tasks for the website, which typically includes;

  • Sending email notifications,
  • Sending out scheduled reports,
  • Performing scheduled password resets, heartbeats and discovery jobs,
  • Checking for new builds online,
  • Removing expiring access to passwords, and,
  • Sending auditing data from you HA server to your primary server (in Active/Passive HA configuration)

However, simply shutting down the Passwordstate Windows Service is not enough.  This will only stop the scheduled actions listed above. You’ll also need to Stop the Passwordstate IIS Site to prevent people form being able to login to Passwordstate and access Credentials via the API or via our Browser Extensions.

How do I stop the Windows Service and IIS Site?

There are a couple of ways of stopping the Passwordstate Windows Service.  The first is via Windows Services App.  Simply start the Services App, Search down the list of services for Passwordstate Service, right click on the service and select Stop as per the image below; 

Alternatively, you could fire up the Windows CMD Shell as an Administrator and type in Net Stop “Passwordstate Service” and hit enter as per the image below;

Next, you’ll need to stop the Passwordstate IIS website.  To do this you’ll need to start the Internet Information Services (IIS Manager) App on your webserver.  Expand the sites folder, select Passwordstate and click on Stop under Manage Website as per the image below;

This instance of Passwordstate is now effectively stopped and will not service logins, credential access via API or Browser Extensions and no scheduled background actions will run.

How do my Load balancers monitor the availability of Passwordstate?

If you were using a High Availability instance of Passwordstate, that is running in Active/Active mode, then it’s possible that you have a load balancer in front of both of your sites.  Typically, your load balancer should automatically fail over to a working site, if one of them became unavailable.

Passwordstate has a dedicated page that your load balancers can monitor, to confirm if it is running successfully, and this page is called “keepalive”.  This is designed to provide a return code of 200 if a Passwordstate instance is up and running.  The keepalive page your load balancer should periodically check is <your Passwordstate URL> with ‘/keepalive’ appended to the URL.

You may be tempted to use your normal Passwordstate login URL but you shouldn’t.  The reason for this is you may have Anonymous Authentication disabled for your Passwordstate login page.  If so ten this may return results that your load balancer may interpret as a failure triggering a failover when it isn’t required.  Many Load Balancers don’t like pages that redirect and your primary URL will redirect to different login pages, depending on the type of authentication you have set.

The Keep Alive page is always set to use Anonymous Authentication and it will never redirect.

How to restart the Windows Service and IIS Site?

Once you’ve finished your testing simply start the Internet Information Services (IIS Manager) App on your webserver, expand the sites folder, select Passwordstate and click on Start under Manage Website as per the image below;

Then start either the Services App searching for the Passwordstate Service, right click on the service and select Start as per the image below;

Or fire up the Windows CMD Shell as an Administrator and type in Net Start “Passwordstate Service” and hit enter as per the image below;

That’s all there is to it.  As outlined above you have a number of methods of effectively shutting down a Passwordstate instance for DR and BCP testing.

If you have feedback and are unsure where to send it?  Send it through to

Browser Extensions, Options when Saving and Ignored URLs

Back in November 2020 we published a Blog article called Ignored URLs and Browser Extensions.  The focus of that article was on how to promote strong password generation, encourage users to use Passwordstate and understand the options presented when saving a password record.  You can find the previous article here

Since then, we’ve updated the Browser Extensions, the dialogs and the buttons that are presented.  This blog article is about the changes that we’ve made since the previous article above.

Changes to 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 image below shows the new Browser Extension dialog on the Left (Green Arrows) and the old Browser Extension on the Right (Red Arrows).

The first obvious change is the old CloseIgnore and Save options (Right, Red Arrows) have been replaced with Later, Never and Save options (Left, Green Arrows).  Note, I’ve removed the username from the images of both Extensions.

The reasoning behind the changed labels on the buttons was to make it clear what action was taken when clicking on each button;

  • Later (was Close):  This will simply close the Add Site to Passwordstate dialog and take no further action.  When you next login to that site you’ll be prompted once again to Add Site to Passwordstate.
  • Never (was Ignore): This was the button wording that confused many customers.  When clicking Ignore in the old Browser Extension, you weren’t telling the Browser Extension to ignore the add request this time.  You were telling Passwordstate to create an Ignored URL for that website and never prompt to add a record for that websiteever again!  This wording has been changed to Never to make it clear you never want to save the credentials for that site (which creates an Ignored URL entry).
  • Save (was Save):  You get the idea here.

Update Password Dialog

Once you’ve added the record, it’s a good idea to periodically change the passwords for your websites.  When you change the password on the website the Browser Extension will prompt you to Update Password as per the image below;

You have two options presented, Later and Update;

  • Later:  Again, this will simply close the Update Password dialog and take no further action.
  • Update: This will update the password record with the new password.

Don’t forget, the Generate Password screen from the Browser Extension is a great way of generating complex passwords for your website logins.  And you don’t need to remember them when using the Browser Extension.

Visual Indicator for Ignored URLs

First of all, lets cover off on the colors that the Browser Extension could be showing.  The image below is a composite image showing these colors;

  • Red Icon:  This means the Browser Extension isn’t logged into your Passwordstate Instance and you cannot access Password Records.
  • Blue Icon: This means the website you are currently visiting has an Ignored URL.
  • Black Icon: This means the website you are currently visiting is accessible by Passwordstate.  You can save credentials for this site to your Password List.  If the icon has a red badge with number in it, then there is already a password record that you can access for this website.  Any more than 3 password records will be displayed as 3+ in the badge.

Taking this further you can see that the website I have navigated to has turned the Browser Extension icon blue, and by clicking on the Browser Extension you can see there are 4 Ignored URLs that apply to the website.

If you have inadvertently set an Ignored URL, typically by clicking on the Ignore button, you can click on the arrow on the Right Hand Side of the Ignored URLs and then click on the X next to the URL you wish to remove as per the image below;

This will now allow you to save a password record for the site as normal.  Note you can only delete personally set Ignored URLs, not global Ignored URLs.  Alternatively, you can remove any personal Ignored URLs from within the Passwordstate UI by navigating to Preferences Menu->Preferences->browser extension->ignored URLs.

If you have feedback and are unsure where to send it?  Send it through to

Requesting Access to Passwords

If you’ve ever found yourself needing to either, request access to password credentials, or, needing to approve a request, then we’ve got you covered.  Passwordstate includes a simple workflow, included as part of the core software, that handles this very scenario.

In this Blog entry we’re using an example for one of our employee’s Abagail, who’s filling in for a System Administrator who’s responsible for our internal SharePoint support.  Abagail by default has limited access to the Password Records in the SharePoint Accounts Password List.  In fact, the only access she has is View access on one Password Record and that relates to demonstrations of Passwordstate as shown below;

Abagail has provided backup support for SharePoint in a previous life (and she’s really good at it).  But before we run through the example of her requesting and being granted access to the Password records we should first run through the workflow at a high level.

Overview of Supported Workflow

The Seek Access to Passwords workflow is a simple workflow built around the specific tasks of;

  • requesting access to either a Password List (including all Password Records it contains) or,
  • requesting access to a single Password Record, and,
  • approving or denying the request.  

In line with this, and at a high level, the process is;

  • User requests access to a Password List or Password Record,
  • They select the type of access and the start and end date/time,
  • They can provide an optional reason for the request,
  • The submitted request is routed to the Administrators of the Password List,
  • The Administrators Approve or Deny the request,
  • If Approved the System grants the requested access for the duration requested

The Administrators of the Password List can be anyone with Administrator Permissions on the Password List and, if set under Administration->System Settings->email alerts & options, Security Administrators or Security Administrators with the specified role of Password Lists.

Request Access to a Password or Password List

Let’s get started.  As stated earlier, Abagail doesn’t have the required access for all Password Records in the SharePoint Accounts Password List.  To request access, she clicks on the Passwords icon in the menu at the extreme left and selects the option for Request Access to Passwords as per the image below; 

This brings up the Request Access to Passwords screen.  From here, Abagail types the search criteria of SharePoint Accounts in the Password List Search Filter box and clicks on the Search button.  This will display all matching records in the display grid.  As she needs access to the Password List and all corresponding Password Records, she selects the top response in the display grid by clicking on the Action Icon and selects Request Access to Password List (image below);

Now the dialog box for Request Access to Password List opens.  Here Abagail selects the Access Type required, in this case View, the Start Date and Time, in this case we’ve left it blank (meaning As Soon As Possible), the Expiration Date and Time, in this case the date and time she stops providing backup support and a Reason to provide context on the request for the Approver.  Once this information is filled out, she clicks the Submit button (image below);

On clicking the Submit button Abagail is presented with an Access Request Sent box and clicks on the Close button (image below);

How to Approve the Request

The Request is emailed through to all Administrators of the Password List and/or Security Administrators or Additional Approvers as per the settings outlined under;

  • Administration->System Settings->email alerts & options.
  • Administration->Feature Access->password list options->specify additional ‘Approvers’ of Access Requests for Password Lists and Password records

A notification is also sent to the Notifications area for those Password List Administrators as per above. 

To review the request, a Password List Administrator or Security Administrator clicks on the Passwords icon in the menu at the extreme left and selects the option for Pending Access Requests as per the image below;

This brings up the Pending Access Requests Screen.  Here all pending requests and their details are displayed.  To select a request simply click on the corresponding user name in the User Requesting Access column (image blow);

This will bring up the Process Access Request screen.  This duplicates the information in the same format as entered by Abagail.  The Approver can select to Approve Request, Deny Request or Cancel to return to the previous screen.  In this example the Approver will approve the request by clicking on that corresponding button (image below);

The Approver will now be taken back to the Pending Access Requests screen to approve any further requests.

What Happens Behind the Scenes?

Passwordstate will now process the approved access type, for the requested object.  In this example it means it will set Abagail’s permissions to View at the Password List level (so she has that access on all records in the List).  Abagail will be emailed advising her that her request has been processed.  When Abagail logins in next she will see she now has access to all the Password Records in the List (image below);

As an Expiration Date and Time were also set, a job will be queued to remove the View permission from the Password List at the time specified.  This is the same for Password Access Requests with a specified Start Date and Time.

As stated at the beginning, the workflow is simple and geared toward handling the Approval, setting and removal of permissions as required.

If you have feedback and are unsure where to send it?  Send it through to

Importing Passwords with Build 9400

Please Note: This blog article applies to Passwordstate Build 9400 or higher.

In October 2021 we published a blog entry that walked you through the process of Importing Passwords via a CSV (Comma-separated Values) file.  This blog entry is located here and the approach was based on generating an appropriate .CSV Template, matching the default fields for a specific Password List, ready for you to then populate with the passwords and import them.

With the release of Passwordstate V9 Build 9400 we’ve streamlined the methods of importing not only from CSV files but also importing Passwords from the following systems;

  • CSV file into a Single Password List
  • CSV file into a Multiple Password Lists
  • KeePass
  • LastPass
  • Thycotic Secret Server
  • Password Manager Pro

We’ve also changed the locations where the import capability can be driven from.

Where’s the Import Passwords List Administrator Action Gone?

Prior to Build 9400 the Import Passwords Administrator Action was found by clicking on the Administrator Actions drop down list located under the Password Records display grid.  This ensured that any .CSV file that was generated for importing passwords included the correct fields for that Password List.

Now with Build 9400, the Import Passwords Administrator Action has been removed.  Instead, the new Import Passwords wizard is found under Tools->Import Passwords as shown below;

When clicking on this you will be taken to the Import Passwords Wizard enabling you to confirm the type of Password Records, originating system and password record format to be imported;

Example of importing via a .CSV file

The first example we will use is the new version of importing via a .CSV file to a single Password List.  In preparation for this I’ve deleted all the previous Password Records in the Performance Portal Password List (by toggling the Visibility of Delete Checkboxes, selecting all the Password Records and using the Bulk Delete Selected Passwords action).

Then I’ve navigated to Tools->Import Passwords and selected CSV file into Single Password List.  This should automatically take you to the next step in the wizard called Instructions.  If it doesn’t then click on the Next button,

On this tab of the Import Passwords wizard, you need to select the Password List you’ll be importing the passwords to.  This not only provides the name and location of the Password List but also the fields used within the Password List,

Once you’ve selected the target Password List, the fields within that Password List will be displayed and you’ll be prompted to generate the appropriate template by clicking on the Generate CSV Template button.  Once you’ve done that click Next.

You now have access to a .CSV Template that has the correct fields and can be populated with the required Password Records.  Once you complete populating the template, you’ll need to upload it by clicking on Select and then choosing the file using the file explorer pop up window.  In the example below I’m selecting results.csv.  Then click on Import Passwords,

You’ll now be taken to Results tab, which will display the number of records successfully added to Passwordstate.  Click Finish to close the Import Passwords wizard.

Importing from Other Systems

As stated at the beginning of this blog, Passwordstate now includes the ability within the core product to Import Records from multiple other systems, including;

  • KeePass
  • LastPass
  • Thycotic Secret Server
  • Password Manager Pro

The process for these is quite similar to the .CSV option explained above with the exception that;

  • For KeePass and LastPass you will be presented with a link to instructions on how to export the password records from those systems.  This documentation is supplied with Build 9400 and is located in the following folder on your Web Server C:\inetpub\Passwordstate\help\manuals.  Once you have exported the records the import of data is the same as for the .CSV example in this Blog.
  • For Secret Server, you will be also be presented with a link for instructions on how to export the password records into an .XML file and have access to a Spreadsheet showing the Field Mappings between the exported XML data and the Passwordstate Password List fields.  Please note the Field Mapping spreadsheet is for information purposes only.  You do not need to manipulate the XML data from the export and can directly import the data is the same way as for the .CSV example.
  • For Password Manager Pro, again you are presented with the instructions link showing how to export the password records to a .CSV file.  Once this has been done, open the file and check to see if the column called Resource Name has a prefix of ‘#’.  If it does have the prefix then edit it to remove the ‘#’’and save the file.  Again, you can simply import the data in the same as for the .CSV example.

If the Other Systems End Up Changing?

In each of the sets of instructions we advise what version of the other systems we’ve based out import wizard on.  The vendors responsible for these systems may change the underlying field definitions from time to time which may cause an issue with the Import Passwords wizard. 

If you find that this does occur, please raise a support ticket with us at and provide a sanitised copy of the export so we can make any updates as required.

If you have feedback and are unsure where to send it?  Send it through to

Browser Based Remote Session Settings

There are a lot of specialist Remote Access Solutions available in the market.  Many of these offer substantial toolsets with the complexity to match.  If your requirements are simpler, for example you simply need a secure method of accessing your managed infrastructure using a least privileged approach, then sometimes the costly and complex Remote Access Solutions are overkill for your needs.

The Click Studios Browser Based Remote Session launcher is provided as part of the core Passwordstate solution. It’s not intended to be a feature for feature competitor with the likes of TeamViewer, AnyDesk or LogMeIn.  Rather it provides a simple, secure and cost effective solution that is audited, only provides access to authorized users and supports session recordings.

What’s Required?

To be able to use the Browser Based Remote Session Launcher and remote into your devices you’ll need to ensure you have;

  • installed the Browser Based Gateway on either your Passwordstate Web Server or a separate server,
  • configured your Browser Based Gateway settings as appropriate,
  • defined Remote Sessions Credentials for the hosts you want to remote into, and,
  • added Hosts, and their associated properties, to the Hosts Tab.

Your Passwordstate V9 Build 9381 contains all the source files and instructions on how to install the Browser Based Gateway.  To access the instructions, navigate to Administration->Remote Session Management and click on Install Browser Based Gateway.

Browser Based Gateway Settings

To configure your Browser Based Gateway Settings you need to navigate to Administration->Remote Session Management and click on Browser Based Gateway Settings.  This will take you to the Configure Remote Session Gateway screen,

From here you can set the specific settings for the following;

Gateway URL:  This is only required if you’ve decided to install the Browser Based Gateway on a different server to where your Passwordstate Webserver is hosted.  The format you need to use for the URL is a FQDN (Fully Qualified Domain Name).

Port Number:  Specify the Port Number that the Gateway will listen on.

Folder for Recorded Sessions: The folder for recorded sessions can either be the default folder, a different disk/folder on the Passwordstate Webserver or a defined share on another server using //<servername>/<sharename>. 

When to Purge older Recordings: You can specify the number of days before older session recordings are deleted or disable deleting session recordings.

Specify Account if using a Network Share: This is used for purging sessions stored on a defined share.  If you are not storing recorded sessions on a defined share you do not need to supply any details here.

Once you have supplied the required details ensure you have clicked on the Save button.

Remote Session Credentials

Remote Session Credentials act in a similar way to Privileged Account Credentials.  They are in effect a privileged credential that is used to login to the remote hosts.  For example, this could be either a Domain Administrator account for Windows Based Servers or the Root account on Unix Based systems.  Ultimately your organization will determine what level of privileges are required for Systems Administration and apply those to the specified accounts.

For example, the Remote Session Credential used for remoting into the Windows Servers in our Demo Environment has;

  • a description of RDP.  This is just a description to provide a level of understanding on the method of remoting in and or and the target devices, and,
  • the credential used to remote into the remote devices. 

When I select the RDP entry it provides the options below (again as an example);

Note, we have only used the Description, Connection Type and Link To Credential.  The Description and Connection Types are straightforward, remembering that only RDP and SSH Connection Types are used for the Browser Based Launcher.  The Link to Credential is the path in Passwordstate for the credential being used.  In this case the credential is imported from Active Directory and is stored in the Active Directory Accounts Password List under the Infrastructure folder located in the Root of Passwords Home.

The other options that are provided include;

Include Host Name Match:  You can apply the Remote Session Credential based on individual hosts or query results.  As an example, you could apply it to all Windows based Servers matching a naming Standard of Win*.  The query results tab allows you to fine tune your query and is especially useful when using multiple queries separated by a comma.

Exclude Host Name Match:  This works the same as the above but excludes hosts based on the results.

Site Location: This is only used for differentiating between internal and a Remote Site when a Remote Sites Locations Module subscription is used.

Host Type(s): Allows you to target specific Host Types.  You can select one or more Host Types from the drop down list.

Operating System(s): Allows you to target specific Host Types.  You can select one or more Host Types from the drop down list.

Again, once you have supplied the required details ensure you have clicked on the Save button.  You can then add permissions to use this Remote Session Credential to Users and Security Groups by clicking on the Action icon next to the Credential, selecting View Permissions and then clicking on Grant New Permissions and selecting the appropriate Users or Security Groups.  

Host Properties

Your Host Properties are selected under the Hosts Tab.  Select the Host that has previously been setup and enter the required details,

The required fields are Host Name, Host Type, Operating System.  The fields for Host Type and Operating System are used with the Query Properties for the Remote Site Credentials.  You only need to enter details for the mandatory fields with the red asterisk (*).  The other fields are for documentation.  Note: you can only select and use Session Recording with the Browser Based Launcher not the Client Based Launcher.

In the red box above, the Connection Types other than RDP and SSH are used for the Client Based Launcher as is the Additional Parameters field.

By ensuring you have configured your Browser Based Gateway settings, defined a Remote Sessions Credential and have added a Hosts and associated properties to the Hosts Tab you’re on your way to using a simple, secure and cost effective solution for remote access.

If you have feedback and are unsure where to send it?  Send it through to

Customizing Email Templates

Passwordstate uses emails to communicate events to Systems Administrators and Users.  The events range from failed logins to account status changes and information regarding password access, expiry and when credentials are copied to the clipboard.

Almost all emails are supplied in template form and can be individually customised to conform to an organizations style, culture and internal language.  Only system dependant emails, such as those used to alert for Annual Support and Upgrade Protection expiry, are fixed and unable to be modified.    

Where are Email Templates Located?

All Email Templates for the core Passwordstate product are located under Administration->Passwordstate Administration->Email Templates.  From here you can;

  • Enable or disable individual templates,
  • Modify the contents of a template, including previewing and testing the template,
  • Enter additional recipients for selected emails,
  • Restore the template back to its default wording, and,
  • Enable or disable all templates.

Customers with subscriptions for the Password Reset Portal Module can modify the email templates associated with Verification Policies under Administration->Password Reset Portal Administration->Verification Policies.  From here you can;

  • Modify the 3 enrolment email templates for each Verification Policy,
  • Any email that is sent as part of the Verification Policy being used, and,
  • Preview each email template.

and under Administration->Password Reset Portal Administration->System Settings->password expiry reminder template, you can;

  • Select the number of days to alert before a password reset is required, and,
  • Modify the contents of the template, including previewing it.

Passwordstate Email Templates

Each of the core Passwordstate Email Templates located under Administration->Passwordstate Administration->Email Templates includes a description.  This description states who the email is designed to be sent to.  These are typically either Password List Administrators, Users, Security Administrators, or Creators of Self Destruct Messages,

To modify a template, simply click on the name of the template (in this example we’re using the Access Request Template) and enter the customized text then click Save.

Note you can also click on Preview to see what the email will look like as well as testing the result with Test Email.

Password Reset Portal Email Templates

As stated earlier in this blog entry, customers with a subscription for the Password Reset Portal Module also have Email Templates that can be customized.  To modify the wording used in the Password Expiry Reminder email navigate to Administration->Password Reset Portal Administration->System Settings->password expiry reminder template,

From here you can modify the Email Subject and email body.  Again, you can click on Preview to check the formatting is what you’ve intended before clicking Save.

Next, for each of the Verification Policies you are using, use you can modify the 3 enrolment email templates and any emails sent when using the verification policy.  Simply navigate to Administration->Password Reset Portal Administration->Verification Policies, and click on the name of the policy you want to modify (in this example Email Temporary Pin Code),

From here you can modify the wording for each of the 3 enrollment emails as well as the email used to send the temporary pin.  Please note verifications policies that don’t use email, in the verification process of a user’s identity, will not be shown here as an additional email option.

Again, simply change the wording as required for each of the email templates, preview the results as appropriate and don’t forget to click Save when you’re finished!

By customizing the Email Templates to match the language and style of communication used in your organization you can reduce confusion and maintain consistency of in-house style.

If you have feedback and are unsure where to send it?  Send it through to

Customizing the Passwordstate UI

Passwordstate has a substantial amount of flexibility with multiple configuration options.  It provides many options for storing, securing, sharing, displaying and using password credentials and associated information. This flexibility enables your Security Administrators to tailor your installation of Passwordstate to best match your organizational requirements.

While this flexibility can be invaluable it can sometimes also result in information overload for your users.  To maximize the usage of Passwordstate across your user base you should consider streamlining the UI (User Interface). The intent being to provide a simplified, functional interface that doesn’t distract or overwhelm your users.  

What Can be Simplified?

There are logically 4 categories of settings that can be used to simplify the UI for users.  These categories can be thought of as;

  • Passwordstate Build and Notifications
  • Unused Menu Groups and Items
  • Access to Hosts
  • User Account Policies

Passwordstate Build and Notifications

This category relates to displaying the build of Passwordstate being used and access to the Notifications Area.  The current Passwordstate Build is normally displayed in two separate areas, the Administration Area (Red Dot 1) and in the Passwordstate Title Logo (Red Dot 2) as per the image below;

The Notifications Area (Red Dot 3) displays notifications such any New Builds that are available, and alerts for,

  • Maintenance renewal reminders
  • Password Reset reminders for Forms-based and Local logins
  • Pending Access Requests requiring review, approval or deny
  • Days remaining for trial license
  • Reminder for Encryption Key Rotation
  • Windows Service unavailable on primary server
  • Ad Blocker detected for the Passwordstate website
  • Health Check based on errors in Error Console, excessive queued emails and excessive Auditing Records

The settings for Passwordstate Build and Notifications are contained in two separate areas.  The first relating to the Passwordstate Build (Red Dots 1 and 2) is controlled by;

  • For Red Dot 1, access to the Administration Tab is only provided for Security Administrators.  This doesn’t affect standard users.
  • For Red Dot 2, visibility of the Build Number at the end of the Passwordstate Title Logo is set under Administration->System Settings->branding Show Passwordstate Build Number.  This allows you to Show the Build Number at the top of the screen to All Users or Only Security Administrators.  Simply click on Only Security Administrators and your users will not see the build number when they login to Passwordstate.

Visibility of the Notifications Area is role dependent.  Users will have access to any notifications of a functional nature, including;

  1. Password Reset reminders for their login,
  2. Any Pending Access Requests requiring their review, approval or deny, and,
  3. If they have an Ad Blocker that is detected for the Passwordstate website.

All other notifications are only displayed for Security Administrators with the exception of advertising a new Passwordstate Build is available.  To ensure this is turned off for all standard users navigate to Administration->System Settings->check for updates and under Show new build alerts for make sure Only Security Administrators has been selected.

Unused Menu Groups and Items

Most users will never need all of the Menu Items located on the left-hand side of the screen.  These can be either hidden, or disabled and when doing this we strongly recommend you base the changes on Security Groups as opposed to manually entering user accounts.

For our example, if a user is never going to use the Reports->Auditing option you can remove this Menu item by navigating to Administration->Feature Access->menu access, ensuring If a user doesn’t have access to a Menu has Hide it from them selected and then Set Permissions to not include that user (again based on a Security Group wherever possible),

This will remove the Menu item Reports->Auditing as per the image below (normally shown where the red arrow is),

Alternatively, if the users don’t require any of the menu items for a specific group, say Reports, then you can hide the entire group by using the Set Permissions next to the Menu Group.  This can be done for all Menus Groups except Passwords.

Access to HOSTS

Generally speaking, the Hosts Tab is only used by staff or contractors in an IT Department.  It is used to enable remote access into network devices, servers and other PCs.  By default, all users have access to the Hosts Tab,

As most of your users will be unlikely to need the Hosts Tab you can remove it by navigating to Administration->Feature Access->Hosts and clicking on the Hosts Tab Permissions button,

From here it’s the standard Passwordstate permissions screen and you simply need to search for the groups that should have permission and add them using the >> button.  You can also select the All Users and Security Groups and remove that from the Applied Permissions screen using the << button.

User Account Policies

Our recent Blog entry talks about how useful User Account Policies are for controlling settings for different groups of users.  We’re not going to go back over the same material but simply highlight the settings and values you can consider for simplifying the UI for your users.

Add UAP TabSetting IDSettingValue
User preferencesA14Show the Permission Model icon indicators next to Folders and Password Lists in the Passwords Navigation TreeNo
Password List Screen OptionsB4Make the Recent Activity Grid visible to the user This is all the Auditing data for the selected Password ListFalse
 B6Make the Pie Charts visible to the user Pie Charts on the right-hand side of the pageFalse
Home Page Screen OptionsC1Dashboard Layout Settings Use the icon to the right to organise Zones and Panels. Do not try to modify the data in this textbox manuallyTick Zone 1 and Zone 2
 C2Show the Password Statistics Chart Show or hide the chart which represents Auditing data, displayed at the bottom of the pageFalse

And when you put it all together…

Using one of our internal users as a test case you can go from this,

To this,

Hopefully this helps demonstrate how you can simplify the User Interface and not distract or overwhelm your users with information and options they may not require. 

If you have feedback and are unsure where to send it?  Send it through to

Develop User Account Policies

One of the many strengths of Passwordstate is that it uses RBAC, or Role Based Access Control to assign granular permissions to objects stored within the system.  RBAC restricts access based on a person’s role and is one of the main methods for advanced access control.  In Passwordstate this means that users can only access the credentials, hosts and information that’s related to their job and that they’ve been assigned access to.  Access can be based on their need to view, create, or modify credentials or stored information.  Using RBAC helps in securing your company’s credentials and subsequently the access to sensitive information.

What’s needed to assign Granular Permissions?

The majority of Passwordstate implementations are Active Directory Integrated.  This means that Passwordstate has been installed so that it can readily integrate with and utilise/synchronise User Accounts and Security Groups setup in Microsoft’s Active Directory.  This allows you to fast track the appropriate Accounts and Security Groups rather than creating them from scratch (if you are using Forms Based Authentication). 

The choice to setup your system as Active Directory Integrated or to use Forms Based Authentication is performed on initial setup under System Settings;

But don’t be concerned if you’ve setup Forms Based Authentication, we supply documentation on our website that guides you through the migration from Forms Based to Active Directory Integrated (and AD to Forms Based).  Navigate to and follow the appropriate documentation as indicated below;

How do you assign these Granular Permissions?

First, you’ll need to ensure the Security Groups and User accounts have been imported into Passwordstate and that you have a folder hierarchy that looks similar to your organizational structure.  For reference, a blog on setting up a folder structure matching a fictious organizational structure is located here

Next, you’ll need to ensure you’ve added the required Security Groups from AD that contain the users you want to assign permissions for.  While the image below has a lot of arrows it is straight forward.  Navigate to Administration->Security Groups and click on the Add AD Security Group located beneath the display grid on the Left-Hand Side.  This will take you to the screen below.  Now search for the Security Group Name you’re after, Select the Name in the Security Groups Search Results and then click Save;

You can of course do the same thing with User Accounts, but you’re better off assigning permissions based on Security Groups as a general rule.

You can now assign permissions for this Security Group on Folders and Password Lists.  The example here is the Security Group Server Administrators has been granted Modify Permissions on the Password List SharePoint Accounts,

So…What Are User Account Policies?

User Account Policies allow you to manage specific sets of settings for groups of users.  The settings relate to various user settings normally set under a User’s ‘Preferences’ area, and ‘Screen Options’ for Password Lists and Folders.  When a User Account Policy is applied to a User (in this context as a member of a Security Group) it disables their ability to modify the settings under ‘Preferences’ themselves.

There are 34 different settings that can be applied to a User Account Policy.  While a lot of the options control cosmetic settings, such as Specifying the Base Color or Show Header row on all Passwords Grids the keys ones of interest for this blog are;

  • Mask Password Visibility on Add/View/Edit Pages
  • Auto Generate New Password When Adding a New Record
  • Specify which Authentication option will apply to the user’s account
  • In the Passwords Navigation Tree, Use Load On Demand Feature
  • Show the Permission Model icon indicators next to Folders and Password Lists in the Passwords Navigation Tree
  • Make the Recent Activity Grid visible to the user
  • Set the Mobile default home page to Password List Search or Password Search

These settings are particularly useful for different groups of users.  For example, you could mandate that all members of Server Administrators, that by virtue of their role have access to highly privileged accounts, can’t just use SSO (Single Sign-On).  Instead, the User Account Policy for the Security Group Server Administrators ensures that in addition to SSO they must use Google Authenticator as a second method of authentication when logging into Passwordstate.

To setup User Account Policies, navigate to Administration->User Account Policies and click on Add.  This will take you to the Add User Account Policy screen

From here you’ll need to provide a Policy Name and Policy Description, and change the required settings across the following areas;

  • User Preferences
  • Password List Screen Options
  • Home Page Screen Options
  • Mobile Access Options, and,
  • Password List Options.

Once you made all your changes click Save at the bottom of the Screen.

Apply the User Account Policy to your Security Group

Now we’ve created a User Account Policy, in this case Google Authenticator, we can apply it to the Server Administrators Security Group.  Select the Action menu next to the User Account Policy and click Apply Policy to Users.  This will bring up the User Account Policy Permissions screen.  It’s then a matter of searching for the Security Group, selecting it with the >> button and clicking Save

Now when all Server Administrators browse to your Passwordstate URL they will be prompted to enter their Google Authenticator OTP even though the global authentication settings under Administration->System Settings->authentication options->Web Authentication Options are set to Passthrough AD Authentication.

User Account Policies Are Additive

When developing your User Account Policies, you can do so in a couple of ways.  You could go ‘all out’ and have one policy for the primary Security Group that caters for all the settings you want to take effect.  Or you can take the ‘incremental’ approach and have policies with only a few settings in them.    

The latter approach of incremental policies is effective in that you can reuse those policies time and again for different Security Groups.  And when the policies are applied at logon they are additive.  By this we mean that the all of the applicable policies are applied to the user.  You just need to remember that if you have the same setting in multiple policies, but each policy has a different value, the last of those policies takes priority.  Polices are applied top to bottom with those lower in the policy grid taking precedence over those higher in the grid. 

User Account Policies are an extremely useful tool when catering for different settings for different groups of users.  All that is required is some thought and testing to achieve the results you want.

Got feedback? We’d love to hear it via

Password Reset Portal Verification Policies

One of the additional Passwordstate modules that can be implemented is our Password Reset Portal.  This is an annual subscription based module that allows your users to unlock, or reset the password for their Active Directory account.  It’s specifically designed to help empower your staff, allowing them to reset or unlock their account when they need to, not just during your Service Desk hours. 

A typical organization experiences between 30% to 50% of Service Desk calls related to Password Resets!  This represents an unnecessary distraction for your support staff, having to deal with highly repetitive low value activities.  And by manually servicing these requests you’re wasting your already tight budgets on activities that are unnecessary.  So why would you want to do this?

Are Users Really Who They Claim to Be?

One plausible line of thought is security.  Or more importantly, is the user wanting to change their password / reset their account the actual user that owns that account?  That’s a really good line of thought! 

But how many organizations really have a process that verifies the identity of user?  I can tell you from experience, that a high percentage of organizations rely on something like the approaches below (one or more, and progressing top to bottom);

  1. Ask the Service Centre to confirm your identity (when you’re on the phone requesting the reset)
  2. Ask them predefined questions like what’s your Mother’s Maiden Name? What School did you go to? etc.
  3. Ask them for their HR issued employee ID
  4. Call them back on a listed phone number (or even better, one that’s not listed)
  5. Get the user’s line Manager to confirm their request (by phone or email)

Can you see the major problems here?  The first, depending on how far down the list the organization goes, is there is little understanding of the value of Internal Customer ServiceThe second is none of these approaches actually verifies the user is who they say they are!

To be close to 100% sure, that they are who they say they are, you need a 2FA (two-factor authentication) style process.  This could be a manual process, if you’re not concerned about the customer service angle.  Or, it could be an automated process that uses more than their User Name and Password and doesn’t use information that can be easily discovered via social channels.

Verify Who You Are!

Passwordstate’s Password Reset Portal uses the concept of Verification Policies to securely “identify” your users. Verification Policies are used when a user first enrolls to use the portal, and also when resetting their AD password or unlocking their account.  The principle is based on the 2-factor authentication discussed above.  To access the Verification Policies, you’ll need to install the Password Reset Portal, be licensed for use with either a valid subscription key or a trial license and navigate to Administration->Password Reset Portal Administration->Verification Policies.

Click Studios provides 9 different policies, each based on an industry standard 2FA authentication method, and you can apply different policies to different sets of users.  More detail is available here and the summary of the authentications options is show below:

  • Duo Push Authentication
  • Email Temporary Pin Code
  • Google Authenticator
  • One-Time Password (based on the TOTP and HOTP standards)
  • PIN Number (with configurable length)
  • Questions and Answers
  • RADIUS Authentication
  • RSA SecurID Authentication
  • SAML 2 Authentication

Let’s use an Example!

So let’s use an example.  We have a fictitious employee with a User Account of bdick (based on the lead singer of one of the best bands in the world).  This user has previously been enrolled to use the Email Temporary PIN Code Verification Policy.

 A personal email address has been specified for sending the email containing the Temporary PIN Code,

When this user accidentally locks out their AD account or needs to reset their AD Password they simply browse to the URL of your Password Reset Portal.  This URL is configured under Administration->Password Reset Portal Administration->System Settings->miscellaneous.  On browsing to this URL they are presented with Step 1: Identify,

The user needs to enter their Username and then click on NEXT.  The Temporary Pin Code is then emailed through to their nominated email address, 

Note the Temporary Pin Code is 5 characters long and only valid for 3 minutes in this example.  Both of these settings are configurable in the Verification Policy under Email Temporary Pin Code Settings, Pin Code Length and Pin Code Expires in Minute(s). The screen now changes to Step 2: Verify.  Here the user enters the Temporary Pin Code from the email in the Temp Pin Number field and then clicks NEXT.  Note the users is advised that the Pin expires in the amount of time as specified in the email, in this case 3 minutes.

Once they have been verified they are taken to Step 3: Reset Password.  Here they are provided with the ability to set a New Password, Confirm Password and then RESET their AD password,    

Once the password has been reset the user is prompted with a Password Reset Complete screen.

What if users are in multiple Verification Policies?

If you apply Verification Policies based on Security Group membership and users are in multiple Security Groups you may find the intended Verification Policy is not applying correctly.  This is because policies higher in the policy grid are being ignored and a lower Verification Policy in the grid has precedence. 

To diagnose this, click on the Users in Multiple Policies to identify which policies are applying to them.  You then need to reorder the correct Verification Policy to be lower in the grid.  This can be done by dragging that policy lower in the grid using the order handle.

By implementing the Passwordstate Password Reset Portal, you improve your customer service and more importantly introduce a repeatable and fool proof two-factor authentication system that verifies the user is who they say they are.  Improving customer service and the security associated with password resets while reducing costs!  That has to be considered a win-win!   Got feedback? We’d love to hear it via