Some Examples of Best Practices for Passwordstate

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

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

Securing your Web.config File

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

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

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

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

Use 2FA with SSO for highly privileged Accounts

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

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

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

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

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

Allow the use of Private Password Lists

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

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

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

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

We hope you find this preview of some of our Best Practices useful and don’t forget to provide any feedback via

Hosting Your Password Reset Portal in a DMZ

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

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

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

Verify the User is who they say they are!

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

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

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

Install the Password Reset Portal where you need it!

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

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

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

Open Port Considerations

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

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

As usual, any suggestions or feedback are welcome via

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

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

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

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

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

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

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

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

Auditing of Emergency Access

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

Setting the Emergency Access Password and Permitted IP Ranges

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

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

Recover the Emergency Access Password

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

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

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

USE Passwordstate

SELECT EA_Password, Secret3, Secret4 FROM SystemSettings

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

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

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

What Else Can I Record with Passwordstate

Most existing customers will have a good idea of the benefits that Passwordstate provides.  The core product, an on-premise web-based solution for Enterprise Password Management, provides enormous flexibility for individuals and teams accessing and sharing sensitive password resources.

However, in this week’s blog we want to draw to your attention some other use cases, where Passwordstate’s ability to share information, based on assigned roles and permissions along with audited access, can provide even greater value to your organization.

So what else can I Record?

Passwordstate has a number of default templates, not related to Passwords, that can be used through the Add Shared Password List Wizard.  The key one’s being,

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

By using the Add Shared Password List Wizard and selecting one of the above templates you are in effect creating a List of critical details relating to that topic instead of a Password List.  The example below is the Click Studios Door PIN Codes which lists all the PIN codes for access to different sections of the Click Studios office,

The details in each List consist of Standard and Generic fields, with all Generic fields being able to be renamed to fit in with an organization’s terminology and naming conventions.  You can easily add additional fields to suit your particular requirements.  Note you can select the Hide Column from the List view, so the hidden details are only revealed when you click on the record.  This ensures access to all of the data for that record is logged when a user reviews it.  You should also consider ticking the Encrypt check box to prevent Database Administrators from seeing critical sensitive data stored within the database.

This List can then be provided to applicable users and Security Groups via Password List Permission->Grant New Permissions.

Default fields provided by each of the Templates

By default, Passwordstate provides the following predefined fields for each of the different Lists that you’ve created, 

  • Alarm/Door Codes: Title, Description, Building, Security Code
  • Credit Cards: Title, Description, Card Type, Card Number, CVV, Expiry Date
  • Software Licences: Title, Description, Software Name, Software Version, Software Owner, Expiry Date
  • SSL Certificates: Title, Description, Expiry Date

Build your own Lists

You can also build your own Lists, to suit other purposes.  The example below is our List containing Hardware Maintenance Contract details, including Authorization codes which are hidden and uploaded documents outlining all the device serial numbers, that are covered by maintenance,

Any information that needs strict control and audited access by authorised users can be setup with these Lists.

As always, we welcome your feedback via

How to use your Phone for Google Authenticator and Passwordstate

We often receive support requests asking how to enable Two-Factor Authentication (2FA) in addition to AD Authentication.  This is a straight forward process and the 2FA options can be used with Single-Sign-On (SSO), Manual AD Authentication and even with Local Passwordstate Accounts.


There are a couple of approaches that can be used to set this up.  For the examples in this week’s blog I’m going to be using the Google Authenticator App from an iPhone and a Local Passwordstate Account.  These examples will work equally well with AD Accounts, the only difference being the required Authentication Options under Administration->System Settings->authentication options->Choose Authentication Option

I normally choose SSO (Passthrough AD Authentication) for the System Wide Authentication setting, as I quickly jump in and out of my Passwordstate Sandpit environment.  For the purpose of doing this blog I’ve dropped back to Manual AD Authentication as I’m logging into Passwordstate with 2 accounts from the same computer. 

Create a User Account Policy for 2FA with Google Authentication

Using a User Account Policy is a great way to both test the 2FA configuration as well as making it easier to rollout across your intended users. 

Navigate to Administration->User Account Policies and click Add to create a new Policy.  Give the policy a name and description and select the Authentication method you want to assign at A6.  In the example blow I’ve used Manual AD and Google Authenticator, then click Save at the bottom of the page,

Apply the User Account Policy to Users

Next, you’ll need to apply the newly created User Account Policy to Users.  Select the Action button next to the Policy Name, click and select Apply Policy to Users,

Now select the users you want to apply this User Account Policy to.  In the below example I’m using a single account for testing purposes.  Once you happy it’s working you can go back in and apply it to Security Groups as required

Now when I log into Passwordstate for the first time after the policy has been applied, I’ll be presented with a normal login screen,

And on clicking on logon will be presented with,

I now need to use the Google Authenticator App and select the + symbol to add an Authenticator, pick Scan barcode and place the QR code that is presented above within the onscreen frame.  This will then setup the Authenticator and present back the PIN code that needs to be entered.

Simply enter this in the Google Verification Code and click Login.

Once you’re happy you can Apply the User Account Policy to the required Security Groups to rollout the policy.

Using SSO with 2FA & Google Authentication

As stated at the beginning you can use 2FA with both SSO (Passthrough AD Authentication) and Manual AD Authentication.  The only differences being that with SSO you only need to ensure your System Wide Settings under Administration->System Settings->authentication options->Choose Authentication Option is set to Passthrough AD Authentication, and the Authentication Option you specify at Setting A6 in your User Account Policy is set to just Google Authenticator as per the below image;

This will in effect Prompt for your Google Authenticator credentials during the Passthrough Process.  It is highly recommended that you don’t roll this configuration out to all users as it defeats the purpose of having SSO.  Rather you should reserve it for those users that have access to highly privileged password credentials or those accounts associated with considerable impact if the credentials were stolen or misused.

As always, we welcome your feedback via

RDP and SSH Sessions to Remote Hosts

Click Studios introduced the Browser Based Remote Session Launcher back in Passwordstate 8.2 – Build 8275 (March 2018).  When combined with our Remote Site Locations module customers have the ability to use our first-in-class Browser Based Remote Access solution, over RDP and SSH, to connect to machines located on a remote network.

The primary functionality provided by the Remote Site Locations Module, is to allow your existing Passwordstate Instance provide Privileged Account Management (PAM), for networks firewalled on either your internal network or over the Internet. 

However, when using the Remote Site Locations module with the Browser Based Remote Session Launcher, customers have the ability to establish RDP and SSH sessions to systems hosted on the remote network.  This offers a significant advantage for larger customers and Managed Service Providers, in that it provides a zero-additional-cost remote access solution, for connecting to remote hosts with full auditing, session recording and requires no client agent deployments.

Requirements and Architecture

As outlined above your Passwordstate instance will require the Remote Site Locations module with a current subscription for the number of remote sites that you wish to manage.  Pricing for the Remote Site Locations modules can be found here.  Please ensure you contact to ensure your price for the subscription is co-termed with your existing Annual Support and Upgrade Protection expiry date.

The architecture required for deployments is straightforward.  In the example below we have a fictitious customer with a requirement for PAM on a remote firewalled network, with access to that network via the internet.  In this example they already have a Passwordstate Instance and would require;

  • A Remote Site Locations module subscription for 1 site, co-termed to their Passwordstate Annual Support and Upgrade Protection expiry date,
  • Installation of the Remote Site Locations agent on a server at the remote site,
  • Installation of the Browser Based Gateway on the same server as the Remote Site Locations agent,
  • A functioning external DNS record which can redirect traffic to the Remote Site firewall,
  • One open port on the firewall and ability to forward HTTPS traffic to the Server that has the Remote Site Locations agent and Browser Based Gateway installed on it.

In the diagram below we have installed both the Remote Site Locations agent and the Browser Based Gateway at the remote site, opened up a single port 7273 on the remote firewall to enable communication between the Passwordstate Instance and the Remote Site Agent.

Full instructions for the installation of both the Remote Site Agent and the Browser Based Gateway can be found in the Passwordstate Remote Site Agent Manual located here.


The Browser Based Remote Session Launcher is not intended to be a feature for feature competitor with the likes of TeamViewer, AnyDesk or LogMeIn.  Rather it is functionality that is included within the Passwordstate Core and Remote Site Locations offerings.

By using the solution outlined above, you can achieve the following benefits and potential cost savings;

  • Remote hosts do not require to have an agent installed on them,
  • Encryption of traffic, between your Passwordstate Instance and the Remote Site agent, using advanced InTransit Encryption keys (no possibility of a data breach),
  • Secure RDP and SSH sessions to any host located on the remote network,
  • Only one port is required to be opened on the remote firewall, restricted to traffic between the Passwordstate Instance and the Remote Site agent’s IP addresses,
  • Native integration between the PAM functionality provided by Passwordstate and this Remote Access Solution e.g.  control who can access what remote systems, audit these accesses, restrict and even hide the password credentials for the remote systems etc.,
  • Retain full control over the use of remote access and the required remote system credentials,
  • Full auditing on who launched a Remote Session, to which Host, from what IP Address, and using which specific authentication credentials,
  • Session recording and playback to enable investigation into any suspicious activity during remote access,
  • Make potentially substantial savings by removing the cost of your existing Remote Access solution.

It should be pointed out that this functionality is intended for System Administrators managing remote systems.  The solution does not provide Screen Sharing, so it is not suitable for situations where you are either watching or showing end users how to use end devices or applications.

As always, your feedback is welcome via

Password Protection for Cloud Accounting

Passwordstate is trusted by more than 29,000 Customers and 370,000 Security & IT Professionals around the world, with an install base spanning from the largest of enterprises, including many Fortune 500 companies, to the smallest of IT shops.  This week’s Blog references some content from an article published by David Walker for CPA’s online magazine INTHEBLACK in late 2019.  The article can be viewed here.

The Importance of Aligning to Industry Standards

Strong password protection is an essential element of an organisation’s Cyber Security controls.  This not only includes implementing a capability like Passwordstate but also extends to ensuring there is an understanding by employees on why it needs to be used, how it should be used and in the ongoing review of who has access to and is using your privileged accounts. 

Whilst there are a number of Standards that can be adopted, I’ve used the NIST Cybersecurity Framework Version 1.1 for this blog.  Using the NIST Framework, you may have;

  • Identified the importance of your privileged accounts in the support of critical business functions, and,
  • Protected these privileged accounts through the implementation of Passwordstate.

However, the story doesn’t end there.  You still need to implement ongoing user awareness and training on the importance of managing your password credentials.  This needs to be supported by appropriate policies and procedures, and Detecting any anomalies or unusual events in the audited access of those accounts. 

Following Good Password Practices

Once you’ve got Passwordstate installed and have imported your privileged accounts there are a number of good practices that should be followed.  These practices are especially important in organisations that have a Cloud First Strategy e.g. acquire Cloud Based services such as Cloud based Accounting in preference to locally hosted capabilities.

  • Use unique passwords
  • Only manage these passwords within Passwordstate

Use Unique Passwords

The single biggest cause of password credentials being hacked relates to daisy chaining passwords.  This is where a common username, such as your email address, is used across multiple web front-ended systems and the user chooses to use the same password for each of these systems.  All it requires is for one of these sets of password credentials to be compromised and all sets using the common username and password are now at risk of being compromised.

To prevent this all passwords should be unique.  Passwordstate provides the ability to specify a password generator policy that is used to generate all passwords for an account.  Administrators can enable a setting forcing the use of a Password Generator and by defining a Password Strength Policy.  The default Password Generator and Strength Policies can be set at a global level, or for each Password List.

Only Manage Passwords within Passwordstate

It should go without saying, to ensure your password credentials are known, accurate and secure, you need to manage them.  If your passwords are manipulated outside of Passwordstate then you cannot easily confirm what they are and who they are being used by.

To ensure your password credentials aren’t being changed outside of Passwordstate you should review accounts that fail their Heartbeat Validation.  This option is available for on-premise systems and uses a Heartbeat Validation check to confirm the password recorded in Passwordstate matches against the account on the target system.

For web front-ended systems, you should use Passwordstate’s Browser Extensions and store your credentials within an appropriate Password List.  Browser Extensions allow you to generate new passwords based on your defined Password Generator and Strength Policy.  If the password stored within Passwordstate doesn’t match the password required for that system you can confirm the last person that legitimately accessed the password credentials from the auditing table or by running a report.

Reset your Passwords Regularly

Passwordstate makes it very easy to reset your Passwords regularly by taking the option to enable password resets on a Password List’s Properties.  You can also set a default password reset schedule and new expiry dates for the Passwords.

Again, for web front-ended systems, you should setup a scheduled report to confirm what web-based password credentials need to reset.  To do this you would create a report, based on what passwords are expiring soon, and schedule it to run periodically.  You can specify the Password Lists you want to report against, as well as the length of time before those passwords expire.

2FA (two-factor authentication)

2FA is a great way to apply an additional level of protection.  It requires an additional level of authentication apart from the username and password combination to securely authenticate a user.  Passwordstate supports a range of popular 2FA options including Google Authenticator, RSA SecurID, Duo 2FA and many others outlined here.

As always, your feedback is welcome via

How to Change your Passwordstate URL

At installation time some customers elect to customize aspects of their Passwordstate installation.  By default, Passwordstate will use the Host Name of the Webserver that it is being installed on.  Alternatively, you can specify a custom URL (Uniform Resource Locator) to make it easier for users to remember the system (in case they haven’t book marked it in their favourites) or simply if you want to brand your installation.

Creating an appropriate DNS Record

In order to be able to use a custom URL you will need to create a CNAME DNS entry.  You should never try to use host files for name resolution as they do not work with Windows Authentication in Microsoft IIS (Internet Information Services).

In the following example I will be creating a custom URL for my “Sandpit” Passwordstate Instance.  This instance is used for testing out new releases, producing the blog entries and basically familiarising myself with the functionality, new and existing, in Passwordstate.  First, connect to your Windows Server hosting your DNS settings and start DNS Manager;

under Forward Lookup Zones select your Domain and create a CNAME (Canonical Name Record or Alias) as per the image below.  Note your Alias name and Fully Qualified domain name (FQDN) will be different to prbpasswordstate, and the taget host is your Passwordstate web server;

Modify your IIS Bindings

Next, you’ll need to modify the bindings in IIS to match the URL that was set in DNS Manager.  To do this login to the Webserver that your Passwordstate instance is hosted on and start Internet Information Services (IIS) Manager;

Under your Webserver, navigate to Sites and select Passwordstate from the Left-Hand pane.  In the Right-Hand pane click on Bindings… as per the image below;

When you click on edit to supply the details it’s worthwhile ensuring you use port 443 as you’ll no longer need to append the port number to the end of your URL (your Web Browser automatically adds 443 silently to your URL making it easier to remember).

Generate a new Certificate

Next, you’ll need to create a new Certificate and there are a number of options for this;

  • The Self-Signed Certificate that Passwordstate installs 
  • An internal Certificate Authority
  • A purchased Wildcard Certificate from a Certificate Authority (best option)

If you elect not to use a purchased SSL Certificate from a Certificate Authority you can still generate a more secure certificate to use on your Passwordstate website.  This will be generated by using an Internal Certificate Authority.  Please see this forum post on how to first setup an Internal Certificate Authority.  Once done you can then follow these instructions on how to generate a new Certificate from your Internal Certificate Authority.

Creating a new Self-Signed Certificate is straight forward.  On your Webserver, Run PowerShell ISE as an Administrator and ensure your PowerShell version is at least V 4.0.  To confirm what version you are running type $host into the console and you should see a response similar to below;

Next copy the following code into your Powershell ISE console, changing the URL in the second line to be your new URL (in my example it’s and run the script.  it will create a new Self-Signed certificate for you;

# Begin script
$URL = “”

$PowershellVersion = $host.version.Major
 # Create the SSL Certificate, using different commands depending on which version of Powershell is installed.  Preferably Powershell 5, as this allows us to set a longer expiry date on the certificate
    if ($PowershellVersion -eq ‘4’)
        $cert = New-SelfSignedCertificate -DnsName $URL -CertStoreLocation Cert:\LocalMachine\My    
    if ($PowershellVersion -eq ‘5’)
        $StartDate = ’01/01/’ + (Get-Date).Year
        $EndDate = ’01/01/’ + (Get-Date).AddYears(5).Year
        $cert = New-SelfSignedCertificate -DnsName $URL -CertStoreLocation Cert:\LocalMachine\My -FriendlyName $URL -NotBefore $StartDate -NotAfter $EndDate
    $rootStore = New-Object System.Security.Cryptography.X509Certificates.X509Store -ArgumentList Root, LocalMachine

Now navigate back to IIS, go to the bindings… for the site, double-click on the https binding, and select the new SSL certificate you’ve just created from the drop-down list and click OK;

Modify Passwordstate Base URL

Lastly, you’ll need to specify the new base URL to reflect the new custom URL that you’ve set.  To do this open your Passwordstate instance and navigate to Administration->System Settings->Miscellaneous Tab and update your Base URL as per the image below;

Note that this URL is used forlinks in the emails, permalinks etc.

That’s it for this week and as always, your feedback is welcome via

Passwordstate One-Time Password Authenticator

A One-Time Password (OTP) is a password that is valid for only one login session or access transaction.  OTPs, used as part of 2FA (Two-Factor Authentication), offer an advantage in that they’re not vulnerable to replay attacks.  This means a potential intruder, who manages to record an OTP already used, will not be able to abuse it as it’s no longer valid.

Passwordstate utilizes the TOTP standard, where time is an important part of the password algorithm in addition to the Issuer and Secret keys.

Setup One-Time Password Authenticator

First, I’ve created a Shared Password List based on the One-Time Password Authenticator template by right clicking on a folder, in this case our Windows Team, and progressing through the Add Shared Password List Wizard

Next, I’ve created a Password Record for logging into Gmail for one of our staff members,

You’ll note, that by using the One-Time Password Authenticator template, the highlighted section above is automatically added to the Password Record.  In the event that you want to add the One-Time Password Authenticator to an existing record, in an existing Password List, simply go to that Password List, click on List Administrator Actions… and select Edit Password List Properties,

Then under Password List Settings, click on Enable One-Time Password Generation, and click Save & Close

Now you can configure the One-Time Password Authenticator.  You can do this via either a QR code provided by your Issuer, or by entering the Issuer details manually.  To enter a QR Code simply click on the icon of a QR code and either browse to the location of your QR Code by clicking on the select button, or, drag the QR Code over the Drop Image Here

Alternatively, you can add the details manually.  To do this you must provide both the Issuer and Secret as provided by your Issuer.  Make sure to cut and paste the Issuer and Secret into the correct fields;

You’ll notice that every time you now access that Password Record a new One-Time Password is generated for you, and refreshed based on your Valid Period (specified in seconds).

That’s all there is to it!  As always, your feedback is welcome via

Update to Remote Session Launchers

Passwordstate has two first-in-class Remote Access Solutions, typically referred to as Remote Session Launchers, a Browser Based Launcher and a Client Based Launcher.  The Remote Session Launchers are provided as part of the core Passwordstate product, with source files located in your Passwordstate install directory.  Details on the differences between the two launchers can be found here.

As of Passwordstate build 8844 we’ve introduced an Automated installation for the Remote Session Launcher Gateway.  For detailed instructions please refer to the Remote Session Launcher Install Guide.

Overview and Automated Installation Changes

Let’s talk about whether this is an automated or semi-automated installer first.  As long as you’re performing the installation on your Passwordstate Server, and are using the default installation directory, then it’s fully automated.  In the event you wish to install the Gateway on another server, or wish to change default settings, then you’ll need to perform some steps outside of this process (it then becomes a semi-automated installation).  For the steps associated with a semi-automated install please refer to the Remote Session Launcher Install Guide above.

Source files for the “Browser Based Gateway” are included with your Passwordstate installation.  They are downloaded by default and are typically located in c:\inetpub\passwordstate\hosts\gateway

Once the installation is completed all SSH and RDP sessions will be tunnelled through the Gateway, and you won’t be required to perform any client installs.  All future RDP and SSH sessions will be initiated through your HTML5 browser, from any device that can access your Passwordstate Website.

During the Installation the following changes will be performed (based on a default install on your Passwordstate Server);

  • Creates a logfile in the same directory where you execute the PowerShell script
  • Downloads OpenJDK 13 (approximately 200 MB) from Azul Systems and extracts this to C:\Program Files (x86)
  • Appends the file path C:\Program Files (x86)\OpenJDK\bin to the PATH Environment Variable
  • Adds a new Environment Variable called JAVA_HOME set to C:\Program Files (x86)\OpenJDK
  • Automatically exports your certificate from your https binding in IIS
  • Installs a Windows Service called Passwordstate-Gateway
  • Removes all temporary source files that were created during the installation

Download and Extract Files

As a general rule we’d recommend that you always grab the latest version of the source files.  These can be obtained in a ZIP file here and should be saved to a temporary folder on your Passwordstate server.  Once you’ve saved the file, you’ll need to extract the two files 7za.exe and Install-Gateway-Internal.ps1 as per the image below; 

Running the PowerShell Script

Once this has been done, you’ll need to open a GUI that can run PowerShell scripts (files ending with an extension of .ps1).  For the purpose of this blog I’m using Microsoft’s ISE (Integrated Scripting Environment).  It’s important to start ISE with Run as administrator to ensure adequate privileges as per the image below;

Once ISE has loaded, you’ll need to open the extracted PowerShell script Install-Gateway-Internal.ps1 and then either press F5 or click the Run button shown;

This will install the Remote Session Launcher Gateway and you should see the successful completion messages as per the image below;

It’s as simple as that!  All RDP and SSH sessions will now be initiated through your HTML5 browser!

As always, your feedback is welcome via