Migrating Passwordstate to a New Domain Part 2

November 11, 2022 by

A few weeks ago, we published a blog article on Moving the Passwordstate instance to a new Domain that has a Domain Trust.  That was the first permutation and this week’s blog covers off on the second permutation, moving a Passwordstate instance to a new Domain without a Domain Trust.

The images used in this blog are taken from Builds 9630 (also used in Part 1) and 9653.

Prerequisites – The Same As In Part 1

Again, your instance of Passwordstate will need to be on Version 8 or 9, the same as the first part in this series.

And again, make sure you have the following,

  • A recent successful backup of Passwordstate including the database.  Confirmed by navigating to Administration->Backups
  • your Emergency Access password in case you need it.  To get this navigate to Administration->Emergency Access

Tasks on the Old Passwordstate Website

Now we’ll perform the required tasks on the Old Passwordstate instance prior to the move.  We’ll need to setup a new Privileged Account Credential that uses an AD Account with permissions to read AD accounts and security groups in the new Domain.  To do this navigate to Administration->Privileged Account Credentials,

And, we’ll add in the new Domain name under Active Directory Domains.  To do this navigate to Administration->Active Directory Domains, and specify the newly created Privileged Account Credential at the Account with Read Access.

Next, we’ll add in the new Authorized Web Server under Administration->Authorized Web Servers,

If you have specified any IP Address Ranges in Allowed IP Ranges then these should be recorded for later and deleted (for now).  To do this navigate to Administration->System Settings->Allowed IP Ranges, and delete all listed networks.  The only network range you should retain is for the New Domain,

You’ll now need to create an Account in Passwordstate that will be used to login on the new Domain.  This is done by navigating to Administration->User Accounts.  Again, if using Client Access Licenses and are running short you can temporarily toggle one of the existing user accounts to disabled,

Once done, you’ll need to add all the Roles for the new Account you’ve just created under Administration->Security Administrators,

Next, you’ll need to stop the Passwordstate website in IIS to prevent any users from logging in to Passwordstate.

Domain Move and Then Test Login

You’re now ready to move your Passwordstate instance to the new Domain.  The instructions for this can be found on our website here,

Please Note: the order shown here is the reverse of that shown in Part 1 of this series.  It is important to perform the instructions in the order listed,

  1. First (Red Circle 1), perform the database backup and move using the instructions in the document Moving Passwordstate To A New Database Server
  2. Then (Red Circle 2), perform the webserver move to the new Domain following the instructions in the document Moving Passwordstate To A New Web Server,

Now you’ll need to login from a PC in the new Domain and browse to the Passwordstate URL for the instance you just moved.  If this is successful then you’re ready to continue.

Tasks Post Move To New Domain

If the login with the new account was successfully, you’ll need to set the new Domain as the Default and then delete the old Domain.  To do this navigate to Administration->Active Directory Domains, click on the Actions icon next to your new Domain and then select Toggle Default Status.  This will change the current Domain to the default.  You can then delete the old Domain from the Actions icon.

Now navigate to Administration->System Settings->Miscellaneous and update the Base URL field to match your new Passwordstate URL,

You can now start creating the Domain’s Accounts and granting access to the existing Data in Passwordstate.  To do this navigate to Administration->User Accounts.  Here you could either add them one at a time, or alternatively use the Add from AD button, 

Then search and select Users or Security Groups (and their members) to add,

Once you have your User Accounts created, and you’re still on the User Accounts screen, click on the Clone User Permissions button.  This is used to clone permissions between the old Domain’s accounts and the New Domain’s Accounts.  You can do this one at a time like below,

Or by clicking on the Clone Multiple Users button, you can generate a CSV file that can be populated and uploaded.

Next, you’ll need to add the appropriate Security Groups if you’re applying permissions based on AD Security Group membership.  This is not required for Local Groups.  To do this navigate to Administration->Security Groups and click on Add AD Security Group,

Once you’ve added your Security Groups you can Clone Permissions between the old Domain’s Security Groups and the new Domain’s Security Groups,

Final Configuration Changes (If Required)

There are a number of other settings that may need to be changed, depending on your use of them,

  1. If you update passwords in Active Directory, you’ll need a Privileged Account Credential associated with the Domain.  This is configured under Administration->Active Directory Domains,
  2. If you are using any Password Reset features and / or scripts you’ll need to update each of their Privileged Account Credentials with the new Domain Account.  This is configured under Administration->Privileged Account Credentials,
  3. If you are using our Backup feature, you’ll need to update the settings under Administration->Backups.  Full instructions on the required permissions are documented under Help->Security Administrators Manual->Backups,
  4. Navigate to Administration->System Settings->Allowed IP Ranges, and add back in any network ranges that you removed prior to the Passwordstate migration,
  5. Review you and change your email server settings if required.  This is performed under Administration->System Settings->Email Alerts & Options.

Now Test, And Test Again

Finally Restart the Passwordstate Windows Service to ensure that unattended processing of tasks will occur as normal.  To do this start the Microsoft Services Desktop Application on your Passwordstate webserver, select the Passwordstate Service, right click on it and select Restart,

You’ve now effectively migrated your entire Passwordstate instance, inclusive of website, database and data structure to the new Domain, and cloned permissions from each of the old accounts to the corresponding new account.

Now you need to test and make sure all those users can still see and access all the credentials that have been granted permission to.  Only when you’re comfortable, that all data is accessing by those that should have it, should you delete the old Passwordstate User Accounts, Security Groups in your new instance and then remove the old Passwordstate instance.

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Filed Under: Hints & Tips

Can you setup a Test Instance with Production Data

November 2, 2022 by

Did you know that Click Studios allows you to use your Passwordstate Production License Keys for One (1) non-production instance for Development, Staging or Quality Assurance (QA) purposes?  This information is included under section 3.5 Number of Instances in our EULA (End User License Agreement).  You can obtain the most up to date version of the EULA here,

The relevant section is reproduced below,

Unless otherwise specified you may install one (1) Passwordstate Instance on systems owned or operated by you or one of your Authorized Users. We allow you to deploy (1) non-production instance for development, staging or QA purposes. No other Passwordstate Instances are permitted, unless Multiple License Sets, the Global License, or the High Availability license options are purchased.

But you may be wondering, how exactly do I get a copy of my production data into a development instance?  Well, let’s read on.

Creating your Test Instance

First, you’ll need to decide on what you’re hoping to achieve with this second non-production instance.  For the purpose of this blog, we’re setting up a QA Server that matches our production instance.  This means it is identical except for its Netbios name, URL for accessing, IP address and DNS entry.

Once we’ve setup our server(s) at the physical / operating system level we’re ready to migrate a copy of our existing Passwordstate instance to our new QA server.  Note If your Production instance has the webserver and database on different servers then ideally you would replicate this setup for your QA Server.

The steps you need to follow can be obtained from our website here,

It is important to follow the instructions in the order show above by the Red Circles 1 and 2, e.g., Perform the instructions from Red Circle 1 first and then those from Red Circle 2.  You should also ensure you have a backup before beginning the process (just good practice).

Once we’ve followed the instructions, we now have a copy of our production data on our new QA instance.

Important Things to Change

As we’ve now got a replica of our Production Passwordstate instance, with its associated Password Records and Reset jobs, it’s a good idea to prevent the QA instance performing unattended updates on your production data.  To do this,

Start the Microsoft Services Desktop Application on your Passwordstate webserver, select the Passwordstate Service, right click on it and select Stop,

you should also set the Properties, Startup type to Disabled as per below and click OK.

This will prevent the Passwordstate Service from starting when you reboot or start the webserver.  A full list of the events managed by the Passwordstate Service are;

  • Scheduled Password Resets, Discoveries and Heartbeats
  • Scheduled Backups
  • Sending Email Notifications
  • Checking for new Builds
  • Sending Audit Log data to Syslog Server
  • Synchronizing AD Security Groups
  • Sending Scheduled Reports
  • Archiving Auditing data
  • Removing Time Based Permissions

You should also review the Users and Security Administrators that have access to the QA Instance and adjust these as necessary.  Longer term it would probably pay to remove critical Password Records from this instance as well. 

As you can see, the process of populating a test Passwordstate instance with production data is straightforward and permitted under our EULA.

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Filed Under: General Post

Migrating Passwordstate to a New Domain Part 1

October 30, 2022 by

Click Studios Technical Support deals with support calls ranging from ‘How do I create a new Password List?’  to ‘How do I recover my Passwordstate instance after a DR event?’ and everything in between.  A recent theme in support calls relates to moving a Passwordstate instance to a new AD Domain.

There are 2 permutations that we’ll need to cover off on this topic.  Moving the Passwordstate instance to a new Domain that has a Domain Trust is covered in this blog.  A future blog will cover moving the Passwordstate instance to a new Domain without a Domain Trust.

In layman’s terms when you have multiple Domains, you will not automatically have all resources in one Domain directly available to all other Domains. To enable resources in one Domain to be used in another Domain a trust in Active Directory needs to be established.  This provides secure authentication and communication between the Domains and enables you to grant access to the resource to users, groups, and computers across the different Domains.

Prerequisites

To be able to perform the following your instance of Passwordstate will need to be on Version 8 or 9.  The functionality is not support on previous versions of Passwordstate.

Firstly, make sure you have a recent successful backup of Passwordstate including the database.  If you are using the built in Backup feature this can be confirmed by navigating to Administration->Backups,

Next, it’s good practice to make sure you have your Emergency Access password in case you need it.  To get this navigate to Administration -> Emergency Access,

Don’t worry about the Emergency Access Password shown above (it’s not the real one).

On Your Old Passwordstate Website

Now let’s perform some tasks on the Old Passwordstate Webserver prior to the move.  To begin with we’ll setup a new Privileged Account Credential that uses an AD Account with permissions in the new Domain.  This will be used to read AD Accounts and Security Groups.  To do this navigate to Administration->Privileged Account Credentials,

We’ll also add in the new Domain name under Active Directory Domains.  This will enable the correct Privileged Account Credential to be used for this Domain.  To do this navigate to Administration-> Active Directory Domains,

Ensure the newly created Privileged Account Credential is selected at the Account with Read Access.

We now need to create an Account in Passwordstate that will be used to login from the new Domain.  This is done by navigating to Administration->User Accounts.  Note, if using Client Access Licenses and are running short of available licenses you could either buy some more (subtle hint) or temporarily toggle one of the existing user accounts to disabled (disabled accounts don’t count toward your licensed level),

Now you’ll need to add all the Roles for the new Account you’ve just created.  To do this navigate to Administration->Security Administrators, search for the new Account and tick the top level check box called Passwordstate Administration under Select Roles,

Login Test & Domain Move

Before we go any further, we’ll need to test that you can login correctly with the new Account you’ve created.  If this is successful then you’re ready to start the move of your Passwordstate instance to the new Domain.  The instructions for this can be found on our website here,

It is important to perform the instructions in the order listed,

  1. First (Red Circle 1), perform the webserver move to the new Domain following the instructions in the document Moving Passwordstate To A New Web Server,
  2. Then (Red Circle 2), perform the database move using the instructions in the document Moving Passwordstate To A New Database Server.

Once you have completed this you’ll need to login again using the new Account you created.  This may prompt you to upgrade the database.  If it does, please click Next to allow this to occur.

New Accounts & Access To Existing Data

You can now start the process of creating the new Domain’s Accounts and granting access to the existing Data in Passwordstate.  Once again, if using Client Access Licenses and are running short of available licenses you can temporarily toggle some of the existing user accounts to disabled (as disabled accounts don’t count toward your licensed level).

When creating the new Domain Accounts, you could either add them one at a time, or alternatively use the Add from AD button, 

This is found under Administration->User Accounts.  This will allow you to search and select Users or Security Groups (and their members) to add,

Once you have added them, and while still on the User Accounts screen, click on the Clone User Permissions button.  This is used to clone permissions between the old Domains account s and the New Domain Accounts.  You can do this one at a time like below,

Or by clicking on the Clone Multiple Users button, you can generate a CSV file that can be populated and uploaded.

When Cloning User Permissions, either individually or in bulk, the following settings are cloned,

  • Any Blocked Email Notification settings
  • Any memberships to Email Notification Groups
  • Any Favorite Passwords
  • Any of the ‘Features’ permissions for what menus the user is allowed access to at the bottom of the screen
  • Any Grid Settings – which columns to see, width, etc.
  • Any permissions to Password Lists (auditing records are added)
  • Any Password Permissions (auditing records are added)
  • Any permissions to Password Lists Templates (auditing records are added)
  • Any Security Admin Roles (auditing records are added)
  • Any membership to Local Security Groups (auditing records are added)
  • The expand/collapse status of the Password Lists Navigation Tree
  • Any User Account Policy permissions
  • Any Scheduled Reports

Now you’ll need to add the appropriate Security Groups if you’re applying permissions based on AD Security Group membership.  You do not need to do this for Local Groups.  To do this navigate to Administration->Security Groups and click on Add AD Security Group,

Once you’ve added the appropriate Security Groups you can then Clone Permissions between the old Domains Security Groups and the new Domain’s Security Groups,

When you Clone Security Group Permissions, the following settings are cloned,

  • Any memberships to Email Notification Groups
  • Any of the ‘Features’ permissions for what menus the user is allowed access to at the bottom of the screen
  • Any permissions to Password Lists (auditing records are added)
  • Any Password Permissions (auditing records are added)
  • Any permissions to Password Lists Templates (auditing records are added)
  • Any Security Admin Roles (auditing records are added)
  • Any User Account Policy permissions

Now Test, Test and Test

By following the above you’ve effectively migrated your entire Passwordstate instance, inclusive of website, database and data structure.  You’ve then added the new Domain Accounts and cloned the permissions from each of the old accounts to their corresponding new account.

Now you need to test and make sure all those users can still see and access all the credentials that have been granted permission to.  Only when you’re comfortable, that all data is accessing by those that should have it, should you delete the old Passwordstate instance.

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Filed Under: Hints & Tips

Passwordstate User Preferences

October 25, 2022 by

Passwordstate provides individual users the ability to customize some aspects of the UI (User Interface) and how the software operates.  This is offered so that frequent users can tailor the use, look and feel to better match their own preferences.

This week’s blog runs you through what can be set, and if these settings are overridden by global settings, that your Security Administrator may have put in place in accordance with organizational policies.

To access your Preferences, go to the Main Navigation Menu on the Left Hand side of the screen, click on the Person icon and then select Preferences.

Passwords Tab

Under Preferences is the first tab, Passwords Tab.  From here you can set individual preferences for;

  1. How the Passwords Navigation Tree is handled.  This includes showing it collapsed or remembering what Nodes,or Password Lists and Folders, were expanded.  If all Password Lists / Folders were shown or hidden,
  2. Limiting the number of Nodes shown, or showing all of them,
  3. If you want to show the Permission Model icons next to the Nodes in the Passwords Navigation Tree,
  4. Preferences for the type of Remote Session Launcher, if used from any Hosts in the Passwords Tab.
  5. If you wish to use the Load On Demand feature for faster loading of Nodes in the Passwords Navigation Tree.

It also provides reference to some of the impacts associated with the Load On Demand feature that users need to be aware of.

Hosts Tab

The next tab is the Hosts Tab,

and you guessed it, on this tab you can set your individual preferences for;

  1. Limiting the number of displayed Nodes, this time Folders and Host Records, in the Hosts Navigation Tree,
  2. If you wish to use the Load On Demand feature for faster loading of Nodes in the Hosts Navigation Tree, and,
  3. Settings associated with using the Browser Based Remote Session launcher.

With the Browser Based Remote Session launcher, you can select a number of session based performance settings,

As well as specifying a different Keyboard layout for RDP sessions.  For SSH Sessions, you can specify the font size as well as Background Color and Font Color.

Miscellaneous Tab

The Miscellaneous Tab handles all preferences that are not aligned to specific groups of functionality,

This includes,

  1. If you want the password field, in Add / View and Edit pages, visible or masked by default,
  2. Auto Generating New Passwords when adding a new Password Record,
  3. Setting Search Criteria Stickiness across Password Screens,
  4. The Position of the Actions Toolbar,
  5. Sorting order on all Password List screens,
  6. Sorting order for Search Results and Favorite Passwords from the Passwords Home screen,
  7. Base settings from selected Template for new Shared Password Lists,
  8. Base permissions from selected Template for new Shared Password Lists, and,
  9. The Date Format you prefer.

Color Theme

The Color Theme tab simply allows you the option of either using the System Wide color theme or you can choose to set your own by clicking on Choose My Own,

If selecting Choose My Own you can then select the Base Color you wish to use throughout Passwordstate.

Authentication Options

The Authentication Tab provides the largest selection of options, all related to you authenticating with Passwordstate.  The options can be used for accessing the Passwordstate website, and as secondary authentication when accessing a Password List. 

Once you have selected the type of Web Authentication Option you wish to use you will need to ensure you’ve configured the corresponding authentication type.  Note I’ve selected Manual Login and Google Authenticator as my preference.

This first image shows the sections for ScramblePad Pin Number and One-Time Password Settings,

This second image shows the sections for YubiKey Authentication Settings and RADIUS Username, SecurID User ID, and Duo Security Username,

This third image shows the sections for Email Temporary Pin Code and Google Authenticator.  Here you can see I’ve gone through the process of enrolling, have scanned the generated QR code into my App (I’m actually using our Passwordstate Mobile App for this) and have saved the corresponding Secret Key,

Mobile Access Options

Next is the Mobile Access Options Tab.  Here you create the Master Password for your native iOS or Android Mobile App and generate the required QR code.  This is needed when setting up your Mobile App to sync with your Passwordstate Instance,

Browser Extension

The Browser Extension Tab controls the preferences for Automatic logout from the extension and any personal Ignored URLs,

Automatic logout of the Browser Extension can be set for,

  • When you close the browser, and,
  • When your computer has been idle for the specified number of minutes.

You can also clear the clipboard after a specified number of seconds, when performing the Copy to Clipboard from within the UI or from the Browser Extension.   

API

If you wish to use a One-Time Password code when using the Windows Integrated API (Application Programming Interface), you can set this on the API Tab,  

Preferences Overridden by Global Settings

Your Passwordstate Security Administrator can use a feature called User Account Policies, which may override the majority of the settings you can specify under your Preferences.  If this has been done then those settings on an individuals Preferences screen will be disabled.

Browser Extension settings, including logging out on browser closure, ignored URLs and permission to use the Extension can be set by your Security Administrator.  As can permission to use the native iOS and Android Mobile Apps.  If you don’t have permission to use you will not be able to fill out the details for your QR Code and enrolment.

If you believe you should be able to set your own Preferences, or have issues with enabling the Browser Extension or native Mobile Apps please speak with your Security Administrator in the first instance.  Further details on how to configure each of the preferences can be found on our website’s documentation page here,

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Filed Under: General Post

Adding Corporate Bad Passwords

October 14, 2022 by

Passwordstate uses a number of approaches to prevent users from selecting easy to guess words for their Password.  It does this by referencing a list of words that you want to prohibit from being used.  The options, for where to reference the list of words you want blocked from being used, is Located under Administration->Bad Passwords. 

From here you can,

  1. Select the approach for referencing a Bad Passwords Database.  This can be based on either a Custom Database, where you populate the Bad Passwords, or by referencing a list of known bad passwords by using the Have I Been Pwned API.  You can even select an option for using Both if you are you are running Passwordstate V9 Build 9000 or above.
  2. You can Add, Import and Export your Custom Database containing both the default Bad Passwords that ship from Click Studios as well as any words that you have added to it.

Before we get into the main body of this blog article, we must mention the https://haveibeenpwned.com/ website, and the API that Click Studios references, is courtesy of Troy Hunt and the excellent work he’s done in providing details on credentials caught up in data breaches.  He provides this information as a free resource for everybody.

Include Words from Your Corporate Dictionary

A corporate dictionary, sometimes referred to as a corporate glossary, contains words, terms and their meanings.  They are typically used to assist employees in being able to speak the same business language.  For example, the Oil and Gas industry uses certain words to name and describe geology, products, processes, outputs etc. that relates to that industry.  The Corporate Dictionary is available as a resource that can be referenced to ensure that employees, colleagues and even industry partners can accurately understand what is being discussed.

Unfortunately, these resources are sometimes referenced as a source of passwords.  As an example, people outside of the Oil and Gas or Legal  industries may rarely come across a word such as sequestration.  Excellent, I should use that as my password! Nuh-uh! Those cybercriminals that are targeting your organization will already have done some easy preparation and likely downloaded a list of Oil and Gas terms for use in a Brute Force Dictionary Attack.  You could send out an email and ask all employees not to use the words in the corporate dictionary – but you and I both know that doesn’t work!

So… let’s stop those words from being used as passwords by adding them in to the Bad Passwords Custom Database.  You could add each word individually by clicking on Add, located underneath the Custom Database display grid.  This will open the Add New Bad Password screen allowing you to add a word and then click Save,

Alternatively, you can click on Import, again located beneath the Custom Database display grid.  This will open the Import Bad Passwords screen,

From here simply click on Generate CSV Template.  This will create and download a simple template to your computer.  As shown in the image above, the CSV File Format includes one Field with a heading of BadPassword and the size of the field is a maximum of 255 characters. 

I’ve opened the template in Microsoft Excel, populated it with a selection of words from an Oil and Gas companies corporate dictionary (using a sample found via a Google Search), and I now have a selection of words I want to prevent being used as Passwords.  I’ve then saved this file as badpasswords_OAG.csv,

Now, all I need to do is click on the Select button, pick the file using File Explorer and then click on Submit as per the image below,

This will import the contents of the CSV file and add those records to the Custom Bad Passwords database.  The Import Process will, as a confirmation, show the Import Successful screen and the number of records that were imported.  Click Continue to return to the Bad Passwords Screen,

Confirmation

Now, back on the Bad Passwords screen you can see confirmation in the image below that the required words have been loaded and will be prohibited from being used as passwords.

And…One Last Fine Tune

You can also prevent those words in the Custom Database from being used as part of a Password.  To do this you’ll need to navigate to Administration->System Settings->miscellaneous and select Yes for Use regular expressions when matching ’Bad Passwords’.  As an example, this will ensure that users can’t fool the system by trying a known bad password with ‘01’ appended to it.

By adding in words from your organization’s Corporate Dictionary you strengthen your Password policies and remove yet another potential attack vector through Brute Force Dictionary Attacks consisting of easy to guess ‘bad passwords’.

If you’d like to share your feedback please send it through to support@clickstudios.com.au

Filed Under: General Post

Browser Extension Authentication Step By Step

October 6, 2022 by

As part of our continual focus on improving security, we’ve recently reviewed the process used by our Browser Extensions when accessing Passwordstate.  The result being we’ve changed how the extensions authenticate back against your Passwordstate instance.

The changes were introduced in Build 9611, and post upgrading, all browser extensions are required to reauthenticate with your Passwordstate instance.  This will be indicated by the Passwordstate Browser Extension icon having turned red as per the image below.

The reauthentication process will only need to be performed from your Browser Extension under the following situations,

  1. After your first upgrade to Build 9611 or a later version,
  2. Every time you add the Browser Extension to your web browser,
  3. If you logout of your Browser Extension and then browse to a different Passwordstate instance.

When your Browser Extensions are updated through the relevant store, e.g., Google Chrome Store, you won’t have to reauthenticate.  However, if you delete the Browser Extension and then re-add it you will need to reauthenticate. 

Authentication Steps

The process of reauthenticating the Browser Extension with your Passwordstate instance is straight forward.  The biggest gotcha you’re likely to encounter is if you do not confirm the Passwordstate URL within 25 seconds. If this happens, simply refresh Passwordstate whilst logged in to kick off the process again.

To start the process of authentication, click on the red Browser Extension icon located in the Browser Toolbar as shown by the red circle 1 in the image above.  This will display the dialog stating Please browse to your Passwordstate website so this extension can be configured.

You will then need to login to your Passwordstate instance as shown by the red circle 2 in the image below.  Make sure you have selected the correct login type for your account from the drop down list, then enter your Username, Password and click on the Logon button,

Once you have logged in to Passwordstate you will see the normal User Interface based on your assigned permissions.  In these images the UI is showing the Administration tab as my account is setup as a Security Administrator.

A new dialog will now appear beneath the Passwordstate Browser Extension.  The dialog will state Please click on the Passwordstate Browser Extension icon above to authenticate with the extension.  You will need to click on the red Browser Extension icon as shown by red circle 3 in the image below,

On clicking the red Browser Extension icon a new dialog will be presented.  This dialog will show the URL or your Passwordstate instance and it should match the URL of the Passwordstate instance you have just logged into, as shown by red circle 4 in the image below.

Take the time to check the 2 URLs are the same and match the URL provided by your Passwordstate Security Administrators.  Only click on the Confirm Passwordstate URL button if these URLs match.

Confirmation

Now that the Browser Extension has been authenticated it will change colour.  In the image below the icon is shown as black as I’ve removed the automatic ignored URL for Passwordstate (as part of testing that I have been performing).  In most cases, once authenticated your Browser Extension icon will turn blue while you are still on the tab for your logged in Passwordstate session.

If you click on the Browser Extension now it will show details such as the number of any Ignored URLs, when the next automatic sync with Passwordstate is to occur and the ability to Logout (which only logs out the extension – you don’t need to reauthenticate).

As show above the process for authenticating your Passwordstate Browser Extension with your Passwordstate instance is straight forward and provides even better security.

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Filed Under: Hints & Tips

How to Access Passwordstate During A DR Event

September 29, 2022 by

You get the phone call you’ve been dreading, “We’ve lost our network and Active Directory.  We’re unsure of the status of most systems but do have successful backups that we can recover from if required.  When can you get in to the office as we’re calling a DR Event.”. 

Great!  You’ve been asking for the budget to establish High Availability for critical systems for a while but nobody’s interested.  And having good backups is all well and good but not much use if you don’t have access to your privileged accounts!  And you can’t access your Passwordstate instance as the network is down.  Looks like you’re out of luck… or are you?

Is Passwordstate Self Contained on the One Server?

The scenario we’re using in this blog (based on there being no network, high availability for critical systems or AD), will only work for those systems that have their Passwordstate database and website (Microsoft Internet Information Services) installed on the same server.  If your instance is split between 2 servers, one for the webserver and a separate server for your database you’re out of luck (…because you don’t have a network).

Create a HTTPS Binding

The first thing you’re going to need to do is bypass your production server’s HTTPS binding.  To do this you’re going to need to be able to login via the console on your Passwordstate Server (again… no network).  Hopefully you have a Local Login and access to the password for this.  If you haven’t, then the first thing you’re doing once you’re out of the DR event, is to download our native iOS and Android Apps and sync these to your Passwordstate instance.  This’ll give you a secure encrypted cache containing all of all the credentials you’ve been granted access to.

Next, you need to perform the following steps;

  1. Start Microsoft IIS,
  2. Select the passwordstate website,
  3. On the left hand side of the IIS console, under Edit Site click on Bindings…,
  4. Click on the Add button,
  5. In the Add Site Binding dialog select the Type as HTTPS, set the Port as 443. Type a Host name of localhost, and select Require Server Name Indication if you have other servers using the same port number,
  6. Select your SSL certificate from the drop down box,
  7. Then click the OK button.

And finally click on the Close button.

Browse to your Passwordstate URL

Now you potentially have 2 options available to you.  If you have a Local Login with appropriate Security Administrator roles and permissions to the required Password Lists etc. you can logon with that account.  You can then access all the required credentials as appropriate.  Simply browse to https://localhost and click on the indicated buttons and links,

However, if you don’t have a Local Login then you’ll need to login via the Emergency Access Account.  This can be accessed via browsing to https://localhost/emergency,

In the example above we have 2FA enabled for the Emergency Access Account.  The limitation with using the Emergency Access Account is that you won’t have easy access to the credentials you’ll need.  Instead, you’ll need to Export All Passwords to a password protected .ZIP file and then copy this to a USB drive if required. 

Note this will only export Shared Password Lists, you have no access to user’s Private Password Lists.  To export all passwords, navigate to Administration->Export All Passwords and select the Export Option you want and click on Export,

As long as you have console access to your Passwordstate server, and have the webserver and database installed on the same server, you can access your credentials via one of the 2 options outlined above.

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Filed Under: General Post, Hints & Tips

Hardening Passwordstate from Within The UI

September 19, 2022 by

When asked about recommendations for hardening Passwordstate we’ve never really had a single point of reference for customers.  This blog has pulled together the responses previously sent to a number of customers and consolidated it for the first time.  Customers should understand that not all of these recommendations may be appropriate for they way in which they use Passwordstate. 

Each of the suggestions should be considered, and if applicable to your business, assessed formally via an internal risk assessment and approved via a change submission before being implemented. 

Encrypt Your Web.config Files!

Yes, this isn’t performed within the Passwordstate UI, however it is a fundamental best practice approach for securing your Passwordstate instance.  It ensures that should anyone have access to your Web Server’s file system they can’t use the details of the Web.config file to access and retrieve your Password Credentials.

The process of encrypting your Web.config is straight forward and details on how to perform this encryption can be found in our General Installation Instructions.  Theses can be found on our website under Support->Documentation->Installation Instructions,

You should encrypt the Database Connection String and appSettings section of your core Passwordstate Web.config file.  If you’re using our App Sever or HA (High Availability) Module you should encrypt the Database Connection String and appSettings section in the Web.config files for those as well.  If you’re using our Password Reset Portal subscription, you’ll only need to encrypt its appSettings section.

While the detailed instruction for each can be found in the corresponding Installation Instructions document, the approach is easy.  All you’ll need to do is open a Command Prompt with administrator privileges on each of the webservers running the core Passwordstate or optional App Server, HA or Password Reset Portal modules,

  • navigate to C:\Windows\Microsoft.NET\Framework64\v4.0.30319,
  • type in aspnet_regiis.exe -pef “connectionStrings” “c:\inetpub\passwordstate” and press enter.

This will encrypt your Database Connection String.  You should then encrypt your appSettings sectionby,

  • typing aspnet_regiis.exe -pef “appSettings” “c:\inetpub\passwordstate” and pressing enter.

You’d also do this for each App Server, HA Server and the Password Reset Portal Server.  Note you’ll be changing the location of c:\inetpub\passwordstate to the correct locations on each of those webservers.  After each one you’ll need to stop and restart the relevant Windows Service. 

2FA for logging into Passwordstate

Using 2FA (Two-Factor Authentication) allows you to implement an additional level of protection when accessing credentials and data stored within Passwordstate.  You can use this as part of the primary authentication for all users, or in conjunction with SSO (Single Sign-On) for select users.

Click Studios recommends that if you are using SSO (Passthrough AD Authentication) selected as your System Wide Authentication option then don’t apply an additional 2FA option to all users.  It will frustrate them and defeats the purpose of implementing SSO to Passwordstate.  You should instead look at applying an additional 2FA for users that need access to highly privileged or sensitive accounts.

In these cases, you can implement the additional 2FA as part of a User Account Policy applied to specific Security Groups.  Just consider the implications as they relate to inappropriate access to highly privileged or sensitive accounts and restrict that access accordingly.

Use 2FA for Emergency Access

Following on from the concept of applying an additional 2FA for users that need access to highly privileged or sensitive accounts, look at configuring this for access to your Emergency Access account.

The Emergency Access account is highly audited and access to it can be restricted to a specified list of Security Administrators under Administration->Security Administrators.  You can configure the requirement for 2FA with OTP (One-Time Password) to further protect the Emergency Access account and subsequent access to your Passwordstate configuration.

Define Allowed IP Ranges

You can specify the IP ranges that Passwordstate is accessible from, that the Emergency Access account can be used from and where the API (Application Programming Interface) can be initiated from.  These are configured under Administration->System Settings->allowed ip ranges,  

You can also state the behaviour when Passwordstate is tried to be accessed outside of the stated Allowed IP Ranges.  This can range from denying access to additional methods of authentication.

Ensure Brute Force Detection is Enabled

Brute Force Detection works by monitoring for failed login attempts from the same IP Address and username combination.  Once these reach a predetermined number of failed login attempts the corresponding IP and Username is blocked from trying to login to Passwordstate. 

You can configure the maximum number of failed attempts under Administration->System Settings->authentication options->Web Authentication Options,

You can also delay the error message response to make it harder for an attacker to determine if the error is related to an incorrect username or password.

Use Feature Access to Restrict Access (to Features)

Using Feature Access allows you to grant or deny access to multiple features and menus.  This would ideally be done by specifying Security Groups, however you can also set this on individual user accounts.  The options are extensive as highlighted in the image below,

To define access to any of the features simply navigate to Administration->Feature Access and select the tab you want to set access for.  The image above shows the mobile tab where you can set permissions for users allowed to use the native iOS and Android mobile apps.

Specify the Functional Roles Used

Introduced in Passwordstate V9 Build 9493, Authorized Web Servers for the core Passwordstate product and any instances of the App Server, can have specific Functional Roles defined.  There are 7 main roles that can be defined, allowing customers to offload intensive processing associated with these roles to another webserver in your farm,

Click Studios recommends that customers deselect any Functional Roles not required for their Primary, High Availability and App Server instances.

Consider Security Administrators and the Roles they Hold

This one requires careful consideration before enacting.  In large organizations with a correspondingly bigger IT department, you can have the luxury of segregating the Administrative Roles within Passwordstate to multiple Security Administrators.  This ensures that no one individual has the ability to change all areas within Passwordstate.  In smaller organizations you may be forced, out of necessity, to provide more roles to fewer or even 1 Security Administrator.

To define the Administrative Roles within Passwordstate to a Security Administrator simple navigate to Administration->Security Administrators, click on the Administrator and select the roles you want to grant them.

Note, a Security Administrator cannot make changes to their own account, or a security group they are a member of.  Any changes need to be performed by another of the Security Administrators defined in Passwordstate.

Consider Using a Managed Service Account

This relates to database connectivity for Passwordstate.  Both Managed Service Accounts (MSA) and Group Managed Service Accounts (gMSA) effectively use an Active Directory account for service-related tasks while easily keeping that account’s password secure. 

MSA accounts cannot be used to log into a machine, have rotating passwords that are managed by the domain, and cannot be locked out.  Group Managed Service Accounts provide an even higher security option for non-interactive applications/services/processes/tasks that run automatically but need a security credential.

By using and MSA or gMSA you have no ability to know the password that is used for database connectivity as it isn’t stored anywhere within Passwordstate.  You can find instructions on how to configure Passwordstate to use a MSA in our General Installation Instructions here,

Privileged Account Credential Password Visibility

You have a couple of options relating to restricting the visibility of Privileged Account Credentials, used for Active Directory Account lookups, Host and Account Discovery, and Password Resets.  You can hide the value of the password field from all Privileged Account Credentials.  This removes the Password Field and provides on screen information stating it is saved to database,

You can also set visibility of only the Privileged Account Credentials that you have been explicitly granted access to,

Both of these settings are configured under Administration->System Settings->miscellaneous as per the image below,

Hardening the Operating System and IIS

Click Studios would also recommend following established processes to harden your Passwordstate webserver OS and IIS.  The best approach for doing so is to follow Microsoft’s recommendations rather than trying to develop your own. 

The following is offered as a starting point in determining what is appropriate for your organization https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-security-configuration-framework/windows-security-baselines

You can choose some or all of the suggested options in this blog to harden your Passwordstate instance.  The key as always, is to understand what you are doing, the implications of doing it, the benefits of taking that configuration option and that the change mitigates or removes the risk you are trying to address.

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Filed Under: General Post

Example Mapping Field IDs

September 2, 2022 by

One of the new major features in our Browser Extensions for Passwordstate is the ability to easily map website input field IDs to fields within a Password Record.  This allows the Browser Extension to know exactly which input fields on a website’s login page need to be automatically form-filled by fields within your Password Record.  It effectively removes the guess work, on the part of the Browser Extension, when dealing with websites that have similar input fields.

In this week’s blog I’m going to work through a step by step approach to mapping the Username and Password input fields to a Password Record.  However, before we get started, I’ll make a couple of statements up front, those being;

  • You must be on Passwordstate 9.5 – Build 9583 or later, with the latest Browser Extension installed,
  • Don’t do this for every set of credentials you form-fill with our Browser Extensions.  Save it for the websites that need it,
  • This blog works on the assumption the Password Record already exists,
  • I have 2 Password Records for this website, and,
  • I’m deliberately redacting the name of the website used for the examples.  There is no inference the company owning the website has produced an inferior or poorly designed site.  It’s simply one of many websites we use for testing our functionality against.

Form-Filling Incorrect Fields

When I navigate to the website used in our example the issue becomes evident.  The Browser Extension has either detected the incorrect website field IDs to form-fill, or the Password Record has historically referenced field IDs that have changed over time.  The latter is more common than you’d think and is usually the result of the owner/developer continuing to evolve their website. 

At this stage it doesn’t really matter what the underlying cause was as the process I’m going to use will fix it. 

As stated at the beginning of this blog there are 2 Password Records for this website.  This means I’ll need to select the correct one to perform the field mapping I require.  To do this I click on the Browser Extension icon, then click on Show Matching Logins.  This shows the two sets of credentials, or two Password Records, for the website.  In the example I’m selecting the bottom one that I want to automatically form-fill the Your email and Your password fields, 

When I hover my mouse cursor over that record, a right pointing arrow appears on the right hand side, and clicking on this brings up the Password Record details (image below).  What I want to do is navigate to the Password Record in Passwordstate by clicking on the link symbol shown,

Clear Existing Mappings

This will take me through to my Passwordstate instance that the Browser Extension is authenticating against.  I’ll need to login to Passwordstate as normal (as I don’t have Single Sign-On configured in this environment) and the Password Record will be opened for me.  From here I’ll select the website fields tab and clear the UserName Field ID and Password Field ID and then click Save.

Note, this step isn’t really necessary, but it’s a good method of showing where the field IDs are kept and how to clear them. 

Now Map The Correct Fields

I’m now going to navigate back to the website in the example and select the Password Record again from the Browser Extension icon.  Then I’ll select the right pointing arrow on the right hand side, and click on it to bring up the Password Record details.  Now I click on the Map Website Fields button at the bottom of the Password Record,

I’m now presented with the Passwordstate Website Field Mapper dialog.  This allows me to map the Website Fields to my Passwordstate Fields in the Password Record.  I’ll start by mapping the correct field for Username.  To do this ensure I’ve selected Username from the Passwordstate Field drop down box.  Next, I click on the Pick Field button and then click my mouse pointer in the input field for Your email (your website will most likely be different to these – as this is my example).

The Website Field will now show the name of that input field, in this example it’s called email.

I’ll now do the same thing for the Password Field.  I’ve selected Password from the Passwordstate Field drop down box.  Then clicked the Pick Field button and this time clicked the mouse pointer in the input field for Your password (again this is an example).

The Website Field will now show the name of that input field, in this example it’s called secret.  Then I click the Save button.

It really is as easy as those couple of steps.  Now I simply refresh the login page for that website and as you can see the Browser Extension has correctly mapped the Your email and Your password input fields.  If there was only one Password Record for this site then the two fields would have automatically form-filled correctly.

Mapping the website input fields to the fields in your Password Record enables you to successfully auto form-fill the login details for most difficult sites.  The next time you have an issue why don’t you give it a try.

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Filed Under: General Post

Permission Model Examples

August 25, 2022 by

We receive quite a few support calls from customers wanting to understand the differences in our permission models.  To that end we’ve provided examples of the Standard, Advanced and Advanced Permission with Disabled Inheritance in this week’s blog.  Please note that all user account names have been redacted in the images used.

Standard Permission Model

The Standard Permission Model is probably the easiest to understand for those new to Passwordstate.  It works by you applying the required permissions to a Password List, and the direct folder hierarchy or folder path required to access that Password List, inheriting those permissions. Think of it as a bottom-up application of permissions. 

In our example, the Standard Folder Permission Model is the default setting in Passwordstate.  You can confirm the permission model via two different ways.  The folder icon has no indicators next to it – all you can see is the folder.  This is the quick visual indicator that the folder is using the Standard Permission Model.  The second way is by clicking on the folder in the navigation pane and the Folder Properties on the right hand side of the screen will show the Permission Model in use,

We’ve assigned the permissions on the Password List SharePoint Accounts, having added 2 Users and a Security Group with Admin permission.  This is done by selecting the Password List, right clicking on it, selecting View Permissions, clinking on Grant New Permissions, selecting the intended recipients or groups, adding them to the Administrator Permissions box and clicking Save, 

Now if we look at the Folder Permissions on the Business Systems folder you can see the 2 Users and Security Group with Admin permission have had those permissions applied at that folder level.  This shows that the folder has inherited those permissions from the nested Password List, in this case the SharePoint Accounts Password List.  You’ll also note there are additional Modify permissions on the folder.  These have been inherited from a different Password List in the Business Systems Folder.

Advanced Permission Model

Next, we have the Advanced Permission Model.  This works by you applying the required permissions to a top level folder, and all objects beneath that folder, including nested folders and Password Lists, have the same permissions propagated down to them. Think of this as a top-down application of permissions. 

Again, using our example, you can confirm the permission model via two different ways.  The folder icon has a downward pointing blue arrow next to it.  This is the quick visual indicator that the folder is using the Advanced Permission Model.  The second way is by again clicking on the folder in the navigation pane and the Folder Properties on the right hand side of the screen will show that the Permission Model in use is the Advanced Model,

To confirm this, we’ll check the permissions on the Password List Web Sites.  This Password List is located in a nested folder called Halox.  This means the Advanced Permission Model will have propagated the permissions down to both the nested folder Halox and the Password List Web Sites.

The folder Customers has just 2 Users with permissions set to Admin.  To view this, we’ve selected the Password List Web Sites, right clicked on it and selected View Permissions.  You’ll note that the Grant New Permissions option is greyed out.  This is correct as the permissions on the Password List have been propagated down to it from the top level folder Customers,

Next, we’ll confirm the permissions on the Password List Web Sites (image above) match the permissions set on the Customers and Halox folders.  To do this we’ve selected the folder Customers, right clicked on it and selected View Permissions.  Again note, at the Customers folder level the Grant New Permissions option is available as this is the top level folder.  However, when you select the Halox folder the Grant New Permissions option isn’t available.  This is because the permissions on Halox are propagated down from the Customers folder,

Advanced Permission with Disabled Inheritance

The last Permission model we’ll discuss in this blog is a variation of the Advanced Permission Model.  This model blocks inheritance of permissions from any folder above, set’s the permissions for a specific folder and propagates these permissions to any nested folders and password lists.  We typically refer to this model as the Advanced Permission with Disabled Inheritance and it effectively replaces the old Manual Permissions model used in Passwordstate Version 8.

To confirm the permission model for Advanced Permission with Disabled Inheritance you can look for the quick visual indicator next to the folder icon.  This indicator is a downward pointing blue arrow followed by a red cross.  If you click on the folder in the navigation pane the Folder Properties on the right hand side of the screen will show that the Permission Model in use is the Advanced Model with extra detail stating disabling inheritance of permissions from any parent level folders.

For this example, we’re going to build on the Advanced Permissions Model shown earlier in this blog.  In that example permissions were set at the Customers folder and propagated down to all nested folders and Password Lists.  Now, at the Allsand folder, we want to disable inheritance of permissions from Customers and instead set new permissions for the Allsand folder.  These will then be propagated down to all nested objects under Allsand including the Workstation Accounts Password List,

To set Disable Inheritance of any permissions from upper-level folders we right click on the Allsand folder, select Edit Properties and set the Disable Inheritance option to Yes and then click on Save,

We have then set two different User Accounts to have Admin permission on Allsand and these are propagated down to all nested objects, in this case the Workstation Accounts Password List.

Now we’ll confirm the permissions on the Password List Workstation Accounts (image below) match the permissions set on the Allsand folder.  To do this we’ve selected Workstation Accounts, right clicked on it and selected View Permissions.

Take Care When Changing Permission Models

The ability to convert between permission models is protected under Administration->Feature Access->folder options->Convert Folder Permission Models.  You can both restrict this Administration functionality to specific Security Administrators and only these individuals can specify which Users and Security Groups can covert folders between different permission models.

When converting Folder Permission Models take the time to read through the information presented.  Implications with the move to the new permission model will be presented to you and it is important that you understand what those implications mean, i.e., overwriting existing Standard Permissions (bottom-up approach) with Advanced Permissions (top-down approach).

If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Filed Under: General Post