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 for
links 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

Second Sneak Peek at Passwordstate Version 9

The features, optimization and stability for Passwordstate V9 is coming along a treat. This week’s blog aims to tease you with a couple more features designed to make your Passwordstate related work-life easier.

Settings Search Functionality

The V9 design team has looked at a number of features aimed at making the administration of Passwordstate even easier. One of these relates to finding where a particular setting is located. This is especially useful when trying to remember where the setting is located on one of many tabs under System Settings or Feature Access. This Search feature has been incorporated in the following locations;

Administration->Passwordstate Administration->Feature Access

Administration->Passwordstate Administration->System Settings

Administration->Password Reset Portal Administration->System Settings

The Search Settings input field is located directly above the tabs and any criteria entered is dynamically searched for across all tabs:

In the example below, I’m searching Passwordstate Administration->System Settings for all settings related to “Password Lists”. The drop down list returns all the Tabs and Settings relating to the search criteria,

When you click on one of these entries you’re taken to that tab and the relevant section is highlighted as per the image below.

If this wasn’t the setting you were looking for, simply click back on the Search Settings field as the Search Results are remembered, and choose another result to navigate to that Setting.

SAML Verification Policy for Password Reset Portal

With Passwordstate V9 we’ve introduced SAML as an additional Verification Policy for our Password Reset Portal. SAML (Security Assertion Markup Language) has become an increasingly popular choice being an open standard for exchanging authentication and authorization data between the identity provider and the service provider.

As with all Verification Policies, it is used to correctly identify a user prior to allowing them to either reset their password or unlock their Active Directory account.

…and Introducing our Mobile App

Click Studios will also be releasing its first true native app for Android and iOS devices with V9. This has been designed from the ground up, is Secure by Design and is a complimentary offering to our existing Mobile Client.

With Biometrics Support for application access, an offline mode allowing access to an encrypted cache of credentials the user would normally have access to, all with full auditing of access that is synced back to your Passwordstate instance.

We’ve optimized the performance of the App, with access to tens of thousands of passwords almost instantaneously. Users can also manually refresh their encrypted cache whenever they want.

Again, we hope you’re as excited about these features as we are, and as always we welcome your feedback via

Encryption Keys Explained

Passwordstate utilises a number of techniques to ensure the security of your password credentials.

One of these is implemented automatically during installation, when two unique encryption keys are created. These encryption keys use a 256 Bit AES (Advanced Encryption Standard) Encryption, first adopted by the U.S. government and now used worldwide. The keys provide the encryption of passwords as well as the HMAC-SHA512 hash used to ensure the integrity of the database.

These encryption keys are split into 4 secrets that are independently stored in different locations. The reason for this is it would require more than one of your Windows Servers to be compromised, to obtain your encryption keys, and access your privileged account credentials.

Whilst not covered in this blog, it is highly recommended that you follow Click Studios best practice approach to securing your Passwordstate instance, by encrypting your Web.config file. You can find the details on how to do this here.

Split Secrets file locations:

As mentioned above, the two encryption keys are split into 4 secrets, with 2 of the split secrets stored on your Passwordstate Server in the Web.config file. The other 2 split secrets are stored within the Passwordstate database itself.

The Web.config file is located by default in the root directory of your Passwordstate installation or C:\inetpub\passwordstate. It contains the first 2 secrets (Secret1 and Secret2) under the <appSettings> section. An example is show below;

Your Database for Passwordstate contains the remaining 2 secrets (Secret3 and Secret4) 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

Note: If you ever lose or forget your Emergency Access Password you can request Click Studios to generate a new one for you. To do this email us and provide a copy of your Web.config file (so we can access your Secret1 and Secret2) as well as the details from the SQL query above. We’ll then recreate an Emergency Access Password for you, and suggest that once you have access again, that you change this and rotate your encryption keys

Exporting your Encryption Keys:

It is extremely important to export the full set of your Encryption keys and store these safely outside of Passwordstate. In the event of a disaster, and you are unable to locate a copy of your Web.config file, Click Studios will be unable to help you rebuild your Passwordstate environment.

When you export your encryption keys, they are written to a password protected Zip file. To do this navigate to Administration->Encryption Keys and click on Export Keys;

You are then presented with an information screen and a button to Export the Keys;

At this stage you’ll need to specify a password for the Zip file that is about to be created and then click on Export Keys;

You will then be presented with a Save As dialog box. Select the folder you wish to save the Password protected Zip file to. Note: the file name includes the date and time the export was performed;

You should also note that the exporting of encryption keys is automatically logged as an auditable event.

Restoring your Passwordstate Server:

You MUST have a copy of both your Web.config file and your Passwordstate database to be able to restore your Passwordstate instance in the event of a disaster. Without these two Click Studios will not be able to assist you in recovering your password credentials.

In the event you need to build a new Database Server or Web Server then please follow the links below for detailed instructions;

Moving Passwordstate to a new Database Server

Moving Passwordstate to a new Web Server


As always, we welcome your feedback via


Reporting When a Sensitive Password has been Viewed

As discussed in last week’s blog, Passwordstate is designed to keep Security Administrators and users informed when different events take place. Building on from that, we’ll now setup a Scheduled Report that alerts an intended audience of a Password record being viewed within a preset timeframe.

You could look at using this approach for very sensitive password credentials where you want to closely monitor when they are being used and by whom.

Password Record being Reported:

We’re going to use the following account for this blog (don’t worry it’s a fake account). It does however provide an account to report against. We’ve specifically set up a description field that’s meaningful as per the screenshot below;

Setting up the Report:

Next, we’ll setup a Scheduled Report which runs once every 5 minutes.  This report will only generate and send an email if the password for ClickStudiosAccount has been viewed. If no one has viewed the password record then you won’t get an email – so no false positive emails. Note you can schedule the duration for any period of time you like.

First you’ll need to navigate to Reports->Scheduled Reports and click on Add Report as show below;

When creating the report, on the report settings tab give it a Report Name and a Report Description (if you wish), but importantly make sure you CC in a user or a mailbox of your choice in the CC Report To field.  The report will be sent to the person creating the Scheduled Report by default but it will also CC in the mailbox specified.  Ensure you tick the option to not send the report if no results are produced, and choose the report type as Custom Auditing Report:

Next, on the schedule tab, select the frequency of One Time, click on the Generate report and specify a frequency of 5 Minutes as per the screen shot below;

and finally, on the auditing settings tab, select the Password List where the password is located, the Activity Type as Password Viewed, Query Previous for 5 minutes (of auditing activity), and enter the unique value you set in the Description field of the Password record, then click on Save Report;

This report will now run every 5 minutes, and on finding any activities matching the type of Password Viewed will email the person that setup the Scheduled Report as well as the email addresses specified on the CC line.

As always, we welcome your feedback via

Passwordstate Email Notifications Explained

Passwordstate is designed to keep Security Administrators and users informed when different events take place. This is achieved through a combination of audit records, real-time monitoring and email notifications.

With over 50 different types of email notifications, Administrators and employees can be alerted to specific events happening within Passwordstate.  This can range from a simple event, such as a user copying a password to their clipboard, to License warnings being sent to all Security Administrators.  In order to use the Email Notifications, you’ll need to configure your email server settings under Administration->System Settings->Email Alerts and Options.

By default, all Email Notifications are enabled. If you’re not careful this can result in Passwordstate “Spamming” your users.  At Click Studios we understand how frustrating this can be and have provided the ability for you to control which emails your employees receive. This can be configured at the Security Administrator level, allowing control over which emails other users in the system receive.  It can also be controlled by users within their own preferences.

Controlling your own Emails:

To control your own individual Email Notifications, navigate to Preferences->Email Notifications as per the screen shot below:

Now select the Actions Menu for the notification you don’t want to receive, click it and select Toggle status – Enabled or Disabled. You’ll see the Enabled icon change from a green tick to a red cross. To change it back simply repeat the process again and you’ll see it change back to a green tick in the Enabled column.

Once disabled you’ll no longer receive these notifications. Note that if you can’t toggle the Enabled or Disabled status then your Security Administrator has put in place settings that override your preferences.

Control which Emails are sent to specific users in the system:

As a Security Administrator you can use Email Notification Groups to specify which email notifications certain users receive, or don’t receive. This allows you to have certain notifications enabled for Security Administrators but disabled for standard user accounts in Passwordstate.

It is important to note that any Email Notification permissions you apply here for users will override their personal settings as set under their Preferences. It is also important to note that If you have more than one Notification Group created for a user, any disabled Email Notification will over-ride its enabled counterpart in the other Notification Groups.

To create an Email Notification Group, navigate to Administration->Email Notification Groups and click Add:

Give your Notification Group a meaningful name and description (as per the example below) and click Save:

Now from the Actions Menu, select View Notifications and disable the templates of your choice.  In this example, I’ll be disabling the Copy to Clipboard Notification only:

Navigate to the Password
Copied To Clipboard Notification Group, click on the Actions Menu and select Toggle status – Enabled or Disabled. You will see the Enabled icon change from a green tick to a red cross.

Then click on Return to Notification Groups. Next, we need to apply this to some users. In our example we’re applying it to a Security Group called IT Staff, and all the members in this group will be assigned to this Notification Group. Select the Actions Menu and click on View Permissions:

Then we assign the permission to the IT Staff Security Group by clicking on Security Group, searching for IT, selecting the Group from the Left Hand pane and clicking on >> then clicking Save.

With this Notification Group now active, all users contained in the IT Staff Security Group will no longer receive the Copy to Clipboard emails.

Disabling Emails globally:

Security Administrators can disable Email Templates at a global level preventing them from being used in Passwordstate.  This will disable Email Notifications even if users have them enabled under their own Preferences. It will also override any inclusions specified as part of an Email Notification Group.

To globally disable an Email Template navigate to Administration->Email Templates, choose the Email Template you wish to disable, click on the Actions Menu and select Toggle status – Enabled or Disabled.

Once you disable the email from here it cannot be sent to any user.

As always, we welcome your feedback via

Remote Sessions Without Knowing the Password

A key feature of Passwordstate is being able to automatically authenticate to remote hosts, without the need for specifying your authentication credentials manually. This feature can be extremely useful when utilising contract staff to assist in supporting large fleets of servers and network infrastructure. It can be used in situations where remote 3rd Party access is required by application vendors to ensure your expensive software is up to date and functioning correctly. In this scenario, you can configure your system so the contractor doesn’t even know the password they are connecting in with.

Remote sessions are automatically audited enabling you to report on who launched a Remote Session, to which Host, from what IP Address, and using which specific authentication credentials. This can be taken to the next level by using our browser based launcher and specifying which contractors, vendors or support staff have their Remote Sessions recorded. This allows you to maintain a record of what actions were undertaken during each remote session.

How do you setup for establishing Remote Sessions without the user “needing to know” or having to remember complex credentials?

Setting up the Remote Session Launchers

If you are not familiar with how to set up the Remote Session Launchers, please refer to the following information,

Add an account with permissions to connect to Hosts

First, create a new Password List and give it a meaningful name. In this example I’ve created a Password List called Remote Session Launcher Accounts under a folder called Remote Access in the root of the Passwords tab. Next add a new Password Record, specifying an account with permission to connect into machines on your network.  The following example uses an Active Directory account which can connect to any Windows Server or Desktop.  Note, do not grant contractors, vendors or support staff permissions to see or use this Password Record!

Create a Remote Session Credential and grant access to it

Next, you’ll need to create a Remote Session Credential. To do this navigate to Hosts->Hosts Home->Remote Session Credentials and Add Credential to create a new Remote Session Credential, ensuring it’s linked to the existing Password Record you’ve created above:

Next, you need to grant your contractors, vendors or support staff access to the Remote Session Credential you have just created by selecting the action icon and clicking on View Permissions

then click on the Grant New Permissions and add the appropriate account (as per the example below) and click save

Granting access to a Folder containing the Hosts

Now you can grant access to the Folder containing the machines you want the contractors, vendors or support staff to have access to.  Once done the Folder and the machines will be visible in the Host tab when they log into Passwordstate.

Now those users can simply navigate to the Hosts tab, select the host they need to establish a remote session to and click on the Auto Launch button.

This will establish the connection for them without their ever needing to know the password credentials!

As always, we welcome your feedback via

Protecting your Passwordstate Website when exposing it to the Internet

One of the great advantages of Passwordstate is being able to securely provide authorized employees with access to your password credentials whilst they’re out of the office. This requires your Passwordstate instance to have a connection to the internet which could pose a number of complications and well as potentially increase your organizations attack vector.

How do you make Passwordstate more accessible without dramatically increasing the risk to your organization?

Prerequisites for accessing Passwordstate from outside your Network

Before you begin there are a number of prerequisites that will need to be in place.

First, you’ll need to ensure you have an external DNS entry which directs all HTTPS traffic to your company IP Address.

Next, you’ll need an open port on your firewall which will be used to direct all incoming HTTPS traffic to your Passwordstate webserver. This port is the same one you will have configured for Passwordstate in Internet Information Server (IIS).

It is highly recommended that you purchase a signed SSL certificate from an Online Certificate Authority and assign it to your Passwordstate website in IIS. Whilst Click Studios provides and installs a self-signed SSL certificate with Passwordstate it is not recommended for use over the internet. There are many online companies that provide CA-signed SSL Certificates. The key thing to remember is to purchase it from a trusted source and ensure it matches the URL of your Passwordstate website.

Considerations for Securing Passwordstate when exposed to the Internet

A lot of our customers elect to have their Passwordstate instance accessible over the internet. When planning this you should consider the options listed below. As always, we’d recommend following your own internal risk assessment process as part of a Change Management Plan, to determine if there is any associated residual risk or compensating controls required, for your environment.

  • If you would prefer your employees not to have to use Two-factor Authentication whilst inside your corporate network you can use our Allowed IP Ranges feature. This is located under Administration->System Settings->allowed ip ranges and allows you to specify your internal IP ranges;

Once set, along with the Two-factor Authentication, any access from any IP range not matching your allowed IP ranges will be prompted for the Two-factor Authentication option you have set. Now access from the internet will be differentiated from internal corporate access and ensure that additional authentication is required.

  • As part of good Systems Administration practice, you should look at removing older protocols on your webserver. Passwordstate uses the most secure protocol currently supported by Microsoft IIS, TLS (Transport Layer Security) 1.2. The removal of any older, less secure protocols, will help protect your webserver. There are many toolsets available to assist with this, just search for “enable or disable windows protocols” and pick one that works for your organization.
  • The backups feature in Passwordstate requires an account on your webserver with permissions to upgrade the install files. Some customers make this account a member of the Local Administrators group on the Server, but you can give it less permissions by following the guide under Help->Security Administrators Manual->Passwordstate Administration->Backups and Upgrades->Non Local Administrator Rights for the Backup Account on the Web Server.
  • Under Administration->System Settings->Authentication Options->Web Authentication Options we have 2 settings that apply to Brute Force attacks,

    The fist setting relates to the number of failed login attempts before the active session is locked out. By default, this value is set to 5 however you can reduce this value in accordance with your IT Security Policy. Lowering this value will slow down automated attempts at guessing a login for your website.

The second setting relates to the delay in seconds before returning a message of “Incorrect Username or Password”. If you find that entering a false username takes a shorter amount of time to produce the message, compared to entering a false password, then you can increase this value. This will delay the message by the stated number of seconds, which will help to confuse the attacker knowing which information they have wrong.

  • Click Studios Best Practice approach for securing your Passwordstate instances involves securing your Web.config file. There are two parts to this, encrypting your Database Connection string and encrypting your appSetting Section. Further details on how to do this can be obtained from the following blog entry:
  • You could consider using a Managed Service Account Consider to communicate with the Passwordstate database server, instead of a SQL Login. Managed Service Accounts have the benefit of being locked down, do not permit interactive logins and are able to automatically negotiate password updates with minimal administration overhead. You’ll find information on how to configure this under Section 14 of our Installation Instructions here:

As always, we welcome your feedback via

Diagnose and Fix Passthrough Authentication Issues

Passwordstate has a couple of base authentication methods, Active Directory Integrated and Forms Based Authentication. When you setup Passwordstate for the first time you can choose which of these authentication options you want to use. By default, the Active Directory Integrated version of Passwordstate is installed.

With Active Directory Integration you can take advantage of Single Sign-On (SSO). SSO is an authentication scheme that allows logging in with a single username and password to access multiple computer applications and resources. It uses your Active Directory credentials to automatically authenticate you to your Passwordstate website, without needing to re-enter your username and password.

But what if that isn’t working? How do you stop Passwordstate from prompting for your credentials each time you browse to Passwordstate? What if you can’t select Passthrough AD Authentication in your System Settings?

Check your Internet Information Server Authentication Settings

Passwordstate requires users to enter their Active Directory username and password to authenticate by default. During installation we also set the Internet Information Server (IIS) to Anonymous Authentication. This setting needs to be disabled to allow your Windows clients to use SSO. To do this you’ll need to open IIS on your webserver, select your Passwordstate website and double click Authentication,

Now right click Anonymous Authentication and select disable. The results should look like the screen image below,

Now you can make the required changes in your Passwordstate Instance.

Choosing Passthrough AD Authentication

Logon to your Passwordstate instance and navigate to Administration TAB->System Settings->Authentication Options->Web Authentication Options and select Passthrough AD Authentication from the Choose Authentication Options drop down list as per the screenshot below

Once this has been set you can logoff and try browsing back to your Passwordstate instance. You should now be automatically logged in with SSO from your Windows client. Unfortunately, Linux and Mac clients will continue to prompt for the username and password credentials.

My Browser Is Still Prompting for Domain Credentials

You’ve now successfully configured your system to allow SSO. So why could you still be receiving prompts to enter your domain credentials? There are a number of reasons why you could continue to receive these prompts to enter your domain credentials.

First, check that you are currently logged on using a Domain Account and not a Local Account. You should also check that you are using DNS for name resolution and not a hosts file.

Next you can confirm if your Passwordstate website is being detected as being in the ‘Local Internet’ Security Zone. Security Zones are a legacy of Internet Explorer but appear to be still used by modern browsers. To confirm if Passwordstate is in the correct Security Zone, open Control Panel->Internet Options->Security Tab and select Local intranet and click on Sites (screen shot below;

Next click on Advanced,

And confirm your Passwordstate website is listed under the Websites: listing. The example below is for Click Studios Passwordstate instances. If your Passwordstate instance is not shown here you should add the URL of the site to a group policy which forces your browser to detect the site is in the Local Intranet zone.
Alternatively, each user can add the URL in the Add this website to the zone: and click the Add button.

For the Firefox browser, open Firefox and type about:config in the URL bar. In the Search dialog box type network:automatic and double click the network.automatic-ntlm-auth.trusted-uris result.
You’ll then need to enter your Passwordstate URL (screenshot below as reference),

Now restart your browser and SSO should be working.

Lastly, some customers SSO for Passwordstate has been affected by the order of the authentication providers in IIS for Windows Authentication. You can try moving the NTLM Provider to the top. To do this open IIS on your web server, select your Passwordstate website and double click Authentication. Select Windows Authentication, click on Providers… select NTLM and click on Move Up.

Click on OK and then restart IIS or reboot the Webserver and your SSO for Passwordstate should now be working.

As always, we welcome your feedback via