Importing Passwords via CSV

Passwordstate is an Enterprise Password Management Solution…check.  It allows the secure storage of passwords and other associated data of interest…check.  It provides auditing of access and change on these passwords and associated data…check.  But how do you get Password Records into Passwordstate?  Good Question!

Passwordstate provides a number of mechanisms to add Password Records into Passwordstate.  These include adding records via;

  • Browser Extension.  This is arguably the most basic method of adding a password record to Passwordstate.  It is limited to web site credentials and a user’s Private Password List or selectable for any of the Shared Password Lists they have access to.  On entering your Account Credentials on a web site login screen you’ll be prompted to save the record in Passwordstate.
  • UI (User Interface).  This is the next most basic method of adding a password record.  It requires the user to have logged into Passwordstate.  From here the user chooses where the record should be added, either a Shared or Private Password List and adds the new password record and all associated information.
  • AD Synchronization.  This is typically setup by a Security Administrator and is based on adding your Active Directory Domain information and then synchronizing selected AD User Accounts and/or Security Groups (including their Users) into Passwordstate.
  • API.  You can use custom scripts to utilize the Passwordstate Standard and Windows Integrated APIs to add password records.
  • CSV (Comma-separated Values).  You can generate a CSV template and populate it with the records to be imported.

Adding Password Records Use Case

The example we are using for this week’s blog is the migration of user accounts for the CEO’s Performance Management Portal.  These were previously stored in a separate password management system and are being migrated into Passwordstate.  Prior to the migration I’ve created a Shared Password List under the CEO Office Folder and called it Performance Portal.  As you can see in the image below there are currently no Password Records in this Password List,

I’ve based the Password List on the Web Site Logins template and created the Password List using the Add Shared Password List Wizard.

Next, we’ll generate an appropriate CSV (Comma-separated Values) Template that matches the default fields for our Password List.  This is done by clicking on the List Administrator Actions… drop down list and clicking on Import Passwords,

This brings up the Import Passwords Screen, effectively a mini-wizard style process that allows the creation of the CSV Template that is used for capturing the records that will be imported,

Simply click on the Generate CSV Template button.  This will create a Comma-separated Value file as shown in the image below.  Note that I have Microsoft Excel installed and that is why the file titled results.csv is shown as an Excel file.

When you click on Open file the results.csv file will open, in this example with Excel.  I’ve copied across all the data to the correct fields as per the image below and saved the file, making sure not to convert it to a .xls file.

Now we’re ready to test the import and if everything is ok, import those password records.

Check and Import the Records

In this example, we’ve already created the Shared Password List called Performance Portal, and created a matching import template based on the type of Password List we’re storing the records in.  We’ve populated the CSV template results.csv with the records and are now ready to import them.

The first thing we now do is test the import process.  This is found on the tab labelled step 3 – import data,

Simply select the file results.csv using the Select button, and then click on Test Import.  This provides you with an opportunity to test importing the data against the field definitions shown under step 2 – populate template with data.  All being well you’ll be presented with the Import Successful screen advising the test import of records successfully passed the import process.

Now click on the Continue button, reselect the step 3 – import data tab, reselect the results.csv file and then click on Import Passwords.  You will now be presented with the Import Successful screen as show below;

And to prove the records were imported correctly, on clicking Continue we are automatically taken back to the Performance Portal Password List showing that the records have indeed been imported as per the image below,

The Import using a CSV template is a useful means of bulk importing password records from other systems and spreadsheets.  The key is ensuring that the right CSV template is used (generated for the target Password List).  And to be 100% sure test the import first!

Got feedback? We’d love to hear it via support@clickstudios.com.au

Updates to Licensing and Encryption Keys

We recently published a blog on how easy it was to rotate your Passwordstate Encryption Keys https://blog.clickstudios.com.au/how-to-rotate-your-encryption-keys/.  Since then we’ve released V9 Build 9350 which introduces a number of related features.

Key Rotation Reminder

NIST recommends a life span of up to two years for Symmetric Data Encryption keys. This is the type of encryption key used by Passwordstate and Click Studios strongly recommends that customers manage and rotate their Passwordstate encryption keys on a regular basis.  Please note that while the NIST standard is for up to 2 years, the environment in which it is used, the characteristics of the data being protected along with your organization’s risk factors need to be taken into account.

With this in mind, Passwordstate now allows you to set a notification prompting you to update your Encryption keys.  This can be found under Administration->Encryption Keys as per the image below,

The options provided are for 6, 12, 18 or 24 months. The reminder works by sending a message to the Notification area located in the top right-hand side of the UI (User Interface).  The notification sent is;

Encryption Key Rotation Reminder. Best Practise recommends it’s time to generate new encryption keys, and re-encrypt your data. This can be done on the screen Administration -> Encryption Keys.

This notification is only a reminder and there is no enforced rotation of encryption keys.  The reminder is only visible to Security Administrators that have been granted access to the Encryption Keys Role under Administration->Security Administrators.

Confirming the Encryption Used

When Passwordstate is first installed you have the option of installing it to use either 256 Bit AES Encryption or FIPS 140-2 (Federal Information Processing Standards) Encryption.  Click Studios recommends installing your Passwordstate instance to use the default 256 Bit AES Encryption unless you are mandated by the United States Government to configure your Microsoft Windows environment in FIPS compliance mode.

If you’re unsure what encryption is currently being used in your Passwordstate instance, simply navigate to Administration->Passwordstate Administration and look at FIPS Encryption.  If you are using the default 256 Bit AES Encryption the value will be set to No.  If you are running FIPS Encryption then the value will be set to Yes,

Changing the type of Encryption Used

For the purpose of the blog, you’ve confirmed the type of encryption used (256 Bit AES Encryption) and need to change to FIPS encryption.  The first thing that is required is to obtain a FIPS version of your license keys.  To do this you’ll need to request a copy from Click Studios sales team via sales@clickstudios.com.au.  When requesting the FIPS license keys you’ll need to send through an image of your License Information screen with all license Keys fully visible (the screen below has the keys redacted),   

Once you’ve received the new license keys you’re ready to start.  Navigate to Administration->Encryption Keys-> Encryption Key Rotation and make sure to read the information provided.  Once you’ve completed any required steps, you’ll need to Enable Maintenance Mode, return to the Previous screenand then click Begin Key Rotation,

And So It Begins

The first thing you are prompted for is to confirm you’ve read the notifications and understand that action is required by you, and if you want to migrate from the standard AES 256 Bit Encryption to the FIPS 140-2 Encryption.  Tick both boxes and then click on Begin Key Rotation.

You’ll now be able to update the license keys in the Update License Information screen with the updated keys provided by Click Studios Sales.  Copy and paste each key into it’s respective field, ensuring there are no leading or trailing spaces (the keys in the image below have been redacted), and then click Next,

You will now be taken to the Encryption Key Rotation screen showing all the Tables and Records that will be re-encrypted with the new FIPS based keys.  To commence the process, click on Re-Encrypt Data.  The image below shows the data being re-encrypted with the tick symbol showing completed tables and the clock symbol showing tables and records still to be processed,

When the process is complete the Key Rotation Complete screen is presented.  Again, please read the details presented, undertake any post Key Rotation tasks as advised and then click on the Start Passwordstate button,

Once you have logged back into Passwordstate you can check that you’ve been re-encrypted using FIPS 140-2 encryption by navigating to Administration->Passwordstate Administration and look at FIPS Encryption.  It will now show FIPS Encryption set to Yes,

And proving you can change it back again

And for the purpose of this blog, I’ve changed our demo environment back again by running the same process and re-encrypting using AES 256 Bit Encryption.

Restrictions on Usage

The type of keys you use are registered in our internal licensing portal and are used for automatically generating your license keys on renewal of your Annual Support and Upgrade Protection.  If you ask for FIPS keys and then decide to use your AES keys you will need to let us know.  Otherwise we’ll generate new license keys in the incorrect format.

Customers with Global Licenses will need to use either the 256 Bit AES Encryption or FIPS 140-2 keys.  It is not possible to have both sets recorded in our internal Licensing Portal and renewed automatically.

Tracking when to rotate your encryption keys, and converting between AES and FIPS encryption (and vice versa) is easy under V9 Build 9350.   We hope this information helps you to understand the process and would love to hear any feedback via support@clickstudios.com.au

Passwordstate and SSL Certificates Explained

A Secure Sockets Layer Certificate, or SSL Certificate is a digital certificate that authenticates a website’s identity and enables an encrypted connection.  It’s a security protocol that creates an encrypted link between a webserver and a web browser.  SSL certificates are used by an organization to ensure secure and private communication between their website and a customer’s or employee’s web browser. 

How do you know if you’re using an SSL connection?  You’ll see a padlock icon next to the URL in the address bar followed by HTTPS (HyperText Transfer Protocol Secure).  Think of it as a means of preventing those nasty little Cyber Criminals from eavesdropping in on your communication, or worse, modifying information that’s being exchanged between the webserver and your web browser.

Those in the know will tell you that TLS (Transport Layer Security) is the current protocol that’s used but the industry still refers to the protocol as SSL (like Hoover is used for vacuum cleaner and Band-Aid for sticky plasters).

Passwordstate uses an SSL Certificate (TLS 1.2) to ensure the communication between your Passwordstate instance and your web browser or native mobile app is secure, encrypted and can’t be eavesdropped.

How do SSL Certificates Work?

SSL Certificates ensure the data transferred between Passwordstate and your web browser is impossible to read. It does this by using encryption to scramble data in transit.  A high-level overview on how the hand-shaking process works looks a little like this;

Any data that is exchanged between the Passwordstate webserver and your web browser is now sent over this encrypted and secure SSL session.

SSL Certificate Best Practices

SSL certificates should only be acquired from a trusted source and should match the URL of your Passwordstate website.  All SSL certificates have an expiry date.  This date can range from one, to many years, and it’s a good idea to track the expiry date so you can renew the certificate before it expires (Hint: you can do this in Passwordstate with the Expiry Date field and What passwords are expiring soon? report).

There are three types of SSL certificates that you can use for your Passwordstate website.  Each of these has its advantages and disadvantages.  There are Self-Signed SSL Certificates, Internal CA (Certificate Authority) SSL Certificates, and Online CA SSL Certificates.  The high-level advantages and disadvantages are shown in the table below;

Certificate TypeAdvantagesDisadvantages
Self-Signed SSL CertificateEasy to create with PowerShell as requiredBrowsers don’t trust them by default
 It’s freeRequires manual effort to for each web browser to trust
  Wild card not available with this type of certificate
Internal CA SSL CertificatesBetter securityRequires a configuration change to your DC
 It’s freeBrowsers will complain when accessing Passwordstate outside of your own network, or from a non domain joined machine
 Browsers will not complain if accessing Passwordstate from a domain joined machine 
 You can use a wildcard certificate to support multiple URLs 
Online CA SSL CertificatesMost secure certificate that all browsers will acceptIs more costly
 Best end user experience for all scenarios 

When to Use Each Type of Certificate

Self-Signed SSL Certificate:

When installing Passwordstate for the first time the default URL chosen by the installer is the name of your server.  While you have the option to change this, the installer process will create a Self-Signed SSL certificate for you that matches this URL.  This SSL certificate is recommended if you’re:

  • A small business and don’t have many users,
  • Don’t intend on accessing Passwordstate outside of your own network,
  • Would prefer not to spend additional money on a certificate,
  • Are okay with installing a certificate for your web browsers as a once off process for each machine.

Certificate Issued from an internal CA:

Internal CA generated SSL Certificates provide for better security and end user experience.  This type of SSL certificate is recommended if you’re:

  • Installing Passwordstate on an Active Directory domain joined server,
  • Already have an internal Certificate Authority setup,
  • Not anticipating the need to access Passwordstate from outside of your own network, or from a non Domain joined machine.

Certificate Issued from an Online CA:

There are multiple Certificate Authorities online that you can purchase your SSL Certificate from.  These certificates come either with a static DNS Name or as a Wildcard certificate.  Click Studios recommends you do your research and purchase from a Certificate Authority that is suitable for you where:

  • You’re are a big or small company, and intend on accessing Passwordstate from anywhere,
  • Want to access Passwordstate from a non domain joined machine,
  • Intend to use the certificate for other Passwordstate features, such as the Browser Based Gateway, the Self Destruct Site and the App Server and these are installed on different web servers,
  • You’re are an MSP, and intend on using the Browser Based Gateway with multiple Remote Sites across the internet.  In this case a wildcard certificate will be required to allow RDP and SSH sessions to remote networks.

Additional Information

Links related to Self-Signed SSL Certificates:

Links related to Internal CA Issued Certificates:

Links related to Online CA Certificates:

We hope this information helps you to understand your options for SSL Certificates and where each of the different types are appropriate.  Have Feedback? We’d love to hear it and you can send it through to support@clickstudios.com.au

Password Lists Linked to Templates

Passwordstate provides the capability of storing both Shared Password Lists and Private Password Lists.  Shared Password Lists, as implied can be used to share either the entire contents of the list, or just individual Password Records.  Private Password Lists, again as implied, cannot be shared and are private to Owner / Password List Administrator of the list.  This is regardless of whether the Private Password List was created directly by the Owner, or it was created for them as part of the process of adding their account in to Passwordstate.

And just recapping, Passwordstate allows more than just the storing of Passwords.  In fact, the number of different types of Passwords and associated details / meta data is almost limitless.  This provides you with substantial flexibility when it comes to storing information in Passwordstate. 

To get you started Passwordstate provides 15 Password List Templates and a Password List Wizard.  You can also add your own Password List Templates to for specific fields containing data you want to control and audit access to.  You can even link your Password Lists to the Password List Template it’s based on. 

Why Link Password Lists to Templates?

When a Password List is created, you have the option to Link this Password List to the selected Template that it’s based on.  But what advantages does this provide?  Password List Templates are used to apply consistency to settings for your Password Lists.  In large implementations, instead of having to manually modify hundreds or even thousands of Password Lists to incorporate a change, you can instead link them to the Template they’re based on.  When you do this, you manage all settings for all those Password Lists from that Template.

In the example above, the PeopleSoft Password List has been created and linked to the Enabled for Password Resets Template. This means the majority of options for the PeopleSoft Password List will be disabled when you chose to Edit Password List Details as per the image below;

And to be clear, it could be any of the above settings, or fields located under the customize fields tab that need to be changed.  For any Password Lists that are linked to a Template you only need to make the change to that Template.  To do this you’ll need to navigate to Administration->Password List Templates, select the Template and click on its name in the Password List field.

Once you’ve made your changes and clicked Save, the changes are cascaded to all Password Lists that have been linked resulting in enormous savings in time!

Implications on Linking Password Lists to Templates

So you ask, what’s the downside?  You can only make individual changes to a Password Lists that isn’t linked.

To unlink the PeopleSoft Password List, from the Enabled for Password Resets Template in our example, we’ll need to click on the Action icon for that Template and select Linked Password Lists,

From there you’ll be able to select the Password List (PeopleSoft) and click on the << button and then click on Save.

Please be aware, ‘Unlinking’ Password Lists that contain any non-compatible Generic Field Types, will cause those values to be cleared in the database.  The same is true when ‘Linking’ a Password List to a Template.  You’ll be presented with a dialog box presenting you with this warning and requesting confirmation before performing the action.

How do I Find What Password Lists are Linked to Templates?

To identify which Password Lists are linked to which Templates simply look at the Linked Password Lists column in the display grid for Password List Templates.  You can click on the Linked Password Lists column to sort it based on Highest to Lowest or Lowest to Highest.  Then open the Template you’re interested in and it’ll show the names of all the Password Lists linked to that Template.

Have Feedback? We’d love to hear it and you can send it through to support@clickstudios.com.au

Expert Insights Best-Of Cybersecurity Awards: Click Studios Awarded Again!

Expert Insights is an online publication with editorial and technical teams in the UK and US covering cybersecurity and cloud-based business technologies.

They are the leading cybersecurity resource and review platform, helping users research hundreds of B2B solutions, with editorial buyers’ guides, blog articles, industry analyses, interviews and technical product reviews written by industry experts. 

Over 80,000 business owners, IT admins and users visit Expert Insights each month to make the right cybersecurity decisions with confidence.

Expert Insights Announces Fall Best-Of Cybersecurity Awards: Click Studios Passwordstate Awarded Best-Of Business Password Management!

Expert Insights has announced their fall 2021 Best-Of Cybersecurity Awards. Click Studios, an Agile software development company specialising in the development of the secure Enterprise Password Management solution called Passwordstate, has been awarded Best-Of Business Password Management again!

Expert Insights’ Best-Of Cybersecurity Awards recognize the world’s best cybersecurity companies and products based on research by Expert Insights’ independent technical analysts and editorial team, customer feedback and industry recognition.

Click Studios Passwordstate earned its award thanks its granular admin controls, with policies around when users must reset passwords and how long and complex passwords need to be. This makes Passwordstate a good option for large organizations that need to ensure strong password security across all of their employees efficiently.

Customers continue to praise the reporting and auditing offered by Passwordstate. Admins have access to 49 pre-defined reports, giving teams more visibility over who has had access to which accounts within the organization, and where passwords have been shared.

Passwordstate is accessed via a browser, and mobile app, so employees can access their passwords wherever they need to. Access to Passwordstate and passwords can be configured for multi factor authentication, helping to ensure encrypted passwords are secure.

Click Studios Response

Click Studios General Manager, Customer Engagement and Technology stated “This is great recognition once again, that Click Studios with it’s Enterprise Password Management solution Passwordstate, competes on a feature for feature basis with the industry heavy hitters.  Where we come into our own is the outstanding quality of our Technical Support and we price our solution so that it’s affordable for everyone.  Because it really is important!”.

For more information on Passwordstate, please reach out to sales@clickstudios.com.au

To read the full announcement by Expert Insights please visit https://expertinsights.com/insights/the-top-password-managers-for-businesses/

Mobile App Settings

We recently published a blog on Reporting on Mobile Client Usage.  Since then, a number of the Technical Support team members have asked what we’ve published on how to configure the Mobile App.  Looks like there isn’t much outside of the official documentation so we’ve produced this week’s blog.

Control Who Has Access

The native Mobile Apps for iOS and Android Smartphones incorporate Biometrics Support for application access.  They provide 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. 

While the apps are free and available from the Apple App and Google Play Stores you may want to control who has access to that functionality.  This is really no different in principle to the Browser Extensions feature, where you set the permission for the user, or preferably the Security Group, that you want to enable access for.

To set the permission for those users that can access the Mobile App navigate to Administration->Feature Access->mobile and click on the Set Permissions button,

From here, you’ll select the User or Security Group that you want to apply permission for.  In the example below we’re setting the permission for one of our users, Abagail, to be able to access the Mobile Native App feature.  Once you’ve selected all your Security Groups and Users click on the >> button and click Save,

Specify Settings for the App

You can now set the global mobile access options for those users that have been granted access.  To do this navigate to Administration->System Settings->mobile access options.  The first section relates to the Mobile App Settings,

Here you can make settings for;

Brute Force Dictionary Attacks:  Just like protecting your Passwordstate instance, you can specify the maximum number of failed login attempts before the active session for that mobile client is locked out.  In the image above we’ve kept the default at 3.

Enable Mobile Access Permission on Password Lists: You can choose to enable Mobile Access by default when adding permissions to Passwords Lists.

Passwords Masked or Visible:  You can specify if the passwords are masked or visible in the Mobile App.

Password Strength Policy for the Master Password:  Set the Password Strength Policy you want to use when users set their Master Password for the Mobile App authentication.

Cache Life:  Set the number of days the offline cache can live for before the user must re-authenticate.  Re-authentication occurs when entering their email account and Master Password and also when they resync their cache on the device.

The second set of settings relates to the Mobile App URL and Security,

URL for the Passwordstate App Server:  Set the URL for your Passwordstate App Server.

Reset the Pairing Secret for the App Server.

SSL Public Key:  Query and save the Public Key for the SSL Certificate.  This mitigates against Man-in-the-Middle attacks.

Once done save the settings by clicking the Save button.  Please note, if you change the App Server URL or your SSL Certificate you will need to clear then re-query and save the SSL Public Key.

Users Preferences and their Master Password

Lastly each user sets their Master Password for the authentication from the Mobile App to the Passwordstate App Server.  To do this they must navigate to Preferences->mobile access options as per the image below;

Here they will set the Master Password which generates a QR Code.  This QR code needs to be scanned in on the Mobile App that has been installed on that user’s smartphone.  The user can also set their preference for the home page search to be based on a Password List Search or Password Search.

If you’d like to provide feedback, please send it to support@clickstudios.com.au.

Reporting on Mobile Client Usage

The Passwordstate native Mobile Client apps for Android and iOS were introduced in V9 Build 9000.  These replaced the old Mobile Client support providing remote access to managed credentials while away from your normal place of work (desk). 

The native apps are designed to work with the Passwordstate App Server, which brokers the connectivity between the client device and your Passwordstate instance.  It allows for storing password records that a user is authorized to access, locally on the smartphone, within an encrypted cache.  Users have the ability to use the biometric capability of the smartphone when accessing the data within the encrypted cache.  All authentication and access of credentials is audited and synced back automatically with Passwordstate on next connection.

But how do you know when your users are using the offline copy of their passwords.  How do you ensure that they are using them when and where required?

We Have a Report for That!

Passwordstate has over 100 different Audit events, including those relating to usage of the Mobile Apps.  As stated above all access to stored credentials within the encrypted cache, and all synchronizations of credentials between your Passwordstate instance and a Mobile Client, are audited.  These audit records are uploaded automatically each time the Mobile App successfully synchronizes with the App Server. 

This ensures you can report on the activity of your users that have been setup for Mobile Client usage.  To be able to do this Navigate to Administration->Reporting 

And select the Activity Report called Mobile Client Activity,

You can now filter the report based on User Account, Site Location and Duration in terms of the reporting period you select from the drop-down list,

and once you’ve clicked Run Report button the audit records matching the selected filters will be shown within the display grid.   

You can now export the results to Excel for further manipulation as required,

Make the report a Scheduled Report

Don’t forget you can setup the Mobile Client Activity report as a scheduled report and have it emailed through on a regular basis.  Simply navigate to Reports->Scheduled Reports and add a report like in the image below.

If you’d like to provide feedback, please send it to support@clickstudios.com.au.

How to Rotate Your Encryption Keys

Click Studios uses Symmetric Data Encryption within Passwordstate to protect your sensitive data.   It does this using 256bit AES (Advanced Encryption Standard) data encryption to encrypt (cipher) and decrypt (decipher) information. At a high level the process of encryption and decryption looks like this;

AES is the first and only publicly accessible cipher approved by the US National Security Agency (NSA) for protecting top secret information. 256bit AES is practically unbreakable by brute force based on current computing power, making it the strongest encryption standard available.  In short, by using symmetric encryption algorithms, data is converted into a form that cannot be understood by anyone not possessing the secret key to decrypt it.

NIST the National Institute of Standards and Technology, recommends that Symmetric Data Encryption Keys be changed every 2 years, or earlier based on an organization’s risk factors.  Your Passwordstate Encryption Keys shouldn’t be “set and forget”, they should be managed and rotated on a regular basis.

But Before You Start…

Make sure you have a backup of your Passwordstate Database and take a copy of your Web.config file.  The built-in Backup functionality is perfect for taking a backup and you can do this by navigating to Administration->Backups and Upgrades->Backup Now

If you’ve never used the built-in functionality, you’ll need to configure settings first under Administration->Backups and Upgrades->Settings.  Information on how to do this can be found here https://www.clickstudios.com.au/documentation/ for both Domain and Workgroup implementations.

Follow the Bouncing Ball…

Now that you’ve taken a backup of your Passwordstate database and have a copy of your Web.config file you’re ready to get started.  And it really is as easy as following the bouncing ball! 

Under Administration->Encryption Keys you’ll find 2 buttons, Export Keys and Key RotationExport Keys allows you to create a password protected Zip file containing your Encryption keys and we’ll cover more on that later.  First, we’re going to focus on Key Rotation.  To get started click on the Key Rotation button,

You’ll now be prompted to ensure you have a backup of your Passwordstate Database and a copy of your Web.config file.  Take the time to read through the information before clicking on the box next to I have read the notification above and understand some action is required of me before and after the key rotation.  If this check box isn’t ticked then you won’t be able to proceed with the Key Rotation.  Once you’re ready, and you’ve ticked the check box, you can click on the Begin Key Rotation button,

As you can see in the image above, The Encryption Key Rotation screen lists all of the tables, the number of records in each table and the Status for each.  To commence the rec-encryption process click on the Re-Encrypt Data button.

The status symbol of a Clock means that table hasn’t been re-encrypted yet.  The status of a Tick means the table has now been re-encrypted and the Flashing Blue Squares identifies the current table being re-encrypted.  A Status message of Please Wait… is shown at the bottom left-hand-side of the display grid listing the tables. 

As the tables are re-encrypted, they will cycle off the first page of the display grid and be replaced by tables awaiting to be re-encrypted.  When there are less tables awaiting to be re-encrypted, than take up the full display grid, you’ll start to see those tables that have been completed (shown by a status of Tick) moving back up the display grid.  Once complete you’ll be taken to the Key Rotation Complete Screen.  Again, take the time to read through the information before clicking the Start Passwordstate button.  This will log you off and you will need to log back into Passwordstate.

Don’t Forget… Take a copy of your New Encryption Keys

Now, cycling back to the Export Keys button.  Once you’ve successfully rotated your encryption keys it’s good practice to take a copy of them.  This can be done by navigating to Administration->Encryption Keys and clicking on the Export Keys button.  You’ll be taken to the Export Encryption Keys screen which tells you that the split secrets that make up your Passwordstate Encryption Keys are exported via a Password Protected ZIP file.  To begin the export process, click on the Export Keys button,

This will pop up the Password Protected Zip File dialog, which will require you to supply a password for the Zip file.  You will also be required to check the box stating that you cannot use the native Windows Compression to extract the contents of the Zip file.  Once that’s done you can click on the Export Keys button to create the Zip file containing the exported encryption keys.

The process of rotating your Passwordstate Encryption Keys is that simple and the effort required to rotate them is minimal.  There really is no reason not to be managing them appropriately.

We’d love to hear your feedback, send it to support@clickstudios.com.au.

Guide to set up Folder Structure and Permissions

You’ve decided that managing your organization’s passwords is essential.  You’ve selected a Password Management System that has the level of security you need, while retaining the flexibility to meet individual stakeholder’s requirements.  You anticipate there’ll be substantial interest and take-up as you roll out the solution.  The only question remains, how do you ensure that the way in which credentials are stored make them easy to locate, ensure they’re accessible to only those that need them, and make management of the solution as straightforward as possible.

Surely the best way to store all the credentials is in one big Password List stored in the root location?  That way you could just assign the permissions on a credential-by-credential basis!  Or maybe you should let everyone create their own Password Lists and store them all together.  If one user needs access to the same credential, they can just enter it in their Password List as well! …..No!  Absolutely Not!  Let’s rethink that approach!

Organizational Structure is Important

An organization’s structure lays out the official functional relationships governing the workflow and day to day operations in the organization. The structure makes it easier to add new positions and provides a flexible method for growth.  Without it, employees find it difficult to know who they officially report to and who has final responsibility over operational elements.  It provides a basis for segregation of duties to ensure appropriate governance.

Organizational structure improves operational efficiency. Departments work better together by focusing their effort on productive tasks without duplication.  The following diagram is a fictional organizational structure for the company An Example and we’ll be using it for this blog.

Using an organization’s structure is a good place to start when organizing your password credentials.  First, we’re going to create folders for all of the Level 1 entities in the diagram below.  These are the top-level functional bodies within this organization.  You’ll note that the CEO folder is grouped at Level 1 also.  There is no value in creating a CEO folder with all other folders nested beneath it so it’s grouped at the same Level as all other top-level folders.  Each of these top-level folders may or may not have additional folders nested beneath depending on the complexity of the organizational unit and the granularity of permissions you wish to set,

Next, we create the nested Level 2 folders for each of the Level 1 folders we’ve created.  The diagram below shows the examples of the two folders that will be nested beneath Operations (Chief Operating Officer), Operational Services and Metallurgical and Chemical laboratories.  Likewise, under Finance (Chief financial officer), we have IT and Legal (Legal matters).

Security Groups and Permissions

Most organizations that use Microsoft’s Active Directory (AD) will have AD Security Groups that closely match their organizational structure.  The group charged with IT Security will likely already have agreed and implemented your AD Security Groups and populated them with the appropriate user accounts aligned with the structure.  That’s the same in this example and it makes assigning permissions to your folders that much easier. 

If you aren’t using Microsoft AD and AD Security Groups you can still create your own Forms based User Accounts and Local Security Groups.  It’ll just mean there’s more initial work to create these and regular maintenance will be required to keep these up to date.

You may from time to time be tempted to use individual users instead of Security Groups to assign permissions.  Whilst this can be done it should always be used as the exception to the rule…the rule being use Security Groups whenever you can!

In the example above we’ve created a Folder under IT called Desktop Support.  We’ve thencreated a Shared Password List called Production Desktops

The permissions for accessing Production Desktops and the Desktop Support Folder is based on the AD Security Group Desktop Support.  Only members of this AD Security Group have been given Admin Access to the Password List.  IT staff not in the Desktop Support AD Security Group have no access.

Permission Model Types

It’s probably worthwhile recapping on the two permission models you can use within Passwordstate, Standard and Advanced

The Standard Permission Model applies the permissions in a bottom-up approach.  When you apply the permissions to the Production Desktops Password List the access is applied to all Folders in that hierarchy i.e. An Example->Finance->IT->Desktop Support.

Using the Advanced Permissions Model applies permission in a top-down approach.  If we were to apply the Desktop Support Security Group at the IT Folder Level it would provide access to IT->Desktop Support-Production Desktops Password List and IT->Legal and any Password Lists or subfolders located under the Legal Folder.  Note the image below is just to show the Advanced Model and doesn’t apply to the Desktop Support example we are using,

Both Permission Models are valid and can be used effectively.  The most appropriate model is the one that best suits the way in which your and/or your Security Administrators prefer to work.

Restrictions that can be Applied

There are a number of restrictions that can be applied to manage the folder structure and where Password Lists are placed.  The first is limiting who has permission to create new Folders in the root of Passwords Home.  This can be found by navigating to Administration->Feature Access->folder options and clicking on the Set Permissions button, 

The second is limiting who has permission to create Password Lists in the root of Passwords Home.  If you’ve gone to the extent of creating an organised folder structure then the last thing you’ll want is for Shared or Private Password Lists to be inadvertently dumped in the root.  This also applies to restricting who is allowed to Drag-N-Drop Password Lists around in the structure you’ve created.  These permissions can be set by navigating to Administration->Feature Access->password list options and againclicking on the Set Permissions button for each of the settings you wish to restrict,

Additional Items for Consideration

As you build your Folder structure and start creating Password Lists there are a couple of other points to consider with links to our blog entries below;

Performance Improvements: https://blog.clickstudios.com.au/performance-improvements-how-to-troubleshoot-and-resolve-issues/

Optimal sizing of your Password Lists: https://blog.clickstudios.com.au/password-list-performance-testing/

In Summary

With a bit of thought and alignment you can effectively build a folder hierarchy and manage your Password Lists by using;

  • The Organizational Structure as your basis,
  • Using Security Groups to your advantage,
  • Using the appropriate Permission Model, and
  • Restricting who can apply structural changes

This will ensure your Passwordstate instance accommodates changes and growth while minimizing the on-going management effort.  We’d love to hear your feedback, send it to support@clickstudios.com.au.

Troubleshoot HA Polling Issues

We’ve recently had a few technical support calls querying how to diagnose High Availability issues.  To make things easier, with identifying the health of all Passwordstate Servers, we included the health status under the Authorized Web Servers screen in Passwordstate 9.0 Build 9000.  This uses a traffic light approach of “green is good”, “red needs investigation”.

So, if your HA server shows a status of red what do you do next?

Recap on HA Implementations

To start with let’s recap on Passwordstate’s High Availability offerings.  The following logical diagram shows 2 variations of Passwordstate with High Availability.  The solution, as depicted by the Green Dot 1, is an Active / Passive implementation.  This allows the Passwordstate High Availability instance to be enabled, and will provide read only access to requests in the event of an issue with the Passwordstate Primary Instance.  All access events are audited and synced with the Passwordstate Primary Instance once recovered.

The solution, as depicted by the Blue Dot 2,shows an Active / Active implementation.  This requires a Load Balancer redirecting the End User’s Passwordstate traffic to either the Passwordstate Primary Instance or the Passwordstate Secondary Instance.  This offering allows users to update data in both the Primary and Secondary instances of Passwordstate.  It requires Basic Availability Groups, or Always On Availability Groups to be implemented in Microsoft SQL Server Standard and above.

Your High Availability Server along with your Primary Server will show up on the Authorized Web Servers page.  This page is available at Administration->Authorized Web Servers and details the Polling Health, Last Poll Time, Server Role and HA Mode along with the Install Path.  Our test environment is shown in the screenshot below;  

Note the Host Names must be entered in their NETBIOS name format not FQDN (Fully Qualified Domain Name).

High Availability: Active-Passive Implementation

When running your Passwordstate High Availability model in Active / Passive mode your HA Server will initiate the polling.  It does this through the Passwordstate Windows Service attempting to contact the Primary instance’s API.  When it successfully connects to the API it will complete the poll and your Primary instance will record the Polling Health status as green for your HA Server.

If your Polling Health status isn’t showing as “green is good” you’ll need to investigate the cause.  The first thing you can check is if the API is functional.  To do this try creating a password using the password generator icon in the top right-hand side of your Passwordstate User Interface;

When clicking on the password generator a password should be generated in the dialog box as shown above.  If this works successfully then the API is functioning correctly.

You can also check if the connection to your API is functioning correctly by opening a web browser and typing in the URL for your Passwordstate instance with the following appended to the URL /api/highavailability/primarypoll/polltest.  If the connection is successful, you’ll see the following result;

If the connection fails, in this example because the Application Pool wasn’t running, you’ll see an error message like;

It does this via a GET request to the specified Uri (URL) as an asynchronous operation.  For more information on the GET request please see https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient.getasync?view=net-5.0 .

Connection issues are always caused by issues with an incorrectly configured Load Balancer, Reverse Proxy or Firewall issues between the two Passwordstate instances.  You can also check the Authorized Webserver Host Names are the Netbios names and not the FQDN.

High Availability: Active-Active Implementation

When running your Passwordstate High Availability model in Active / Active mode your High Availability Server (secondary instance) writes its Polling Health status directly into the Passwordstate Database.  As with Active / Passive implementations this will then show the Polling Health status as green for your HA Server. 

Again, the biggest issue we find with a Passwordstate instance not correctly participating in an Active / Active HA implementation is incorrectly configured Firewalls or your Passwordstate Windows Service isn’t started. Again, check the Authorized Webserver Host Names are the Netbios names and not the FQDN.

Knowing where to look when you experience HA Polling Issues is straightforward.  Unfortunately Click Studios can’t tell you how to resolve your Load Balancer, Reverse Proxy or Firewall issues as the number of suppliers for these is huge and growing. You will need to log a call with the vendor responsible for the equipment if you are unable to identify and resolve the issue.

Got feedback?  We’d love to hear it!  Send it through to support@clickstudios.com.au.