Requesting Access to Passwords

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

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

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

Overview of Supported Workflow

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

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

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

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

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

Request Access to a Password or Password List

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

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

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

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

How to Approve the Request

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

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

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

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

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

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

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

What Happens Behind the Scenes?

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

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

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

If you have feedback and are unsure where to send it?  Send it through to support@clickstudios.com.au.

Importing Passwords with Build 9400

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

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

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

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

Where’s the Import Passwords List Administrator Action Gone?

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

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

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

Example of importing via a .CSV file

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

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

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

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

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

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

Importing from Other Systems

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

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

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

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

If the Other Systems End Up Changing?

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

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

If you have feedback and are unsure where to send it?  Send it through to support@clickstudios.com.au.

Browser Based Remote Session Settings

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

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

What’s Required?

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

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

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

Browser Based Gateway Settings

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

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

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

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

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

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

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

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

Remote Session Credentials

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

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

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

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

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

The other options that are provided include;

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

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

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

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

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

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

Host Properties

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

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

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

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

If you have feedback and are unsure where to send it?  Send it through to support@clickstudios.com.au.

Customizing Email Templates

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

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

Where are Email Templates Located?

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

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

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

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

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

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

Passwordstate Email Templates

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

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

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

Password Reset Portal Email Templates

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

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

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

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

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

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

If you have feedback and are unsure where to send it?  Send it through to support@clickstudios.com.au.

Customizing the Passwordstate UI

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

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

What Can be Simplified?

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

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

Passwordstate Build and Notifications

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

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

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

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

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

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

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

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

Unused Menu Groups and Items

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

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

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

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

Access to HOSTS

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

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

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

User Account Policies

Our recent Blog entry https://blog.clickstudios.com.au/develop-user-account-policies/ talks about how useful User Account Policies are for controlling settings for different groups of users.  We’re not going to go back over the same material but simply highlight the settings and values you can consider for simplifying the UI for your users.

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

And when you put it all together…

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

To this,

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

If you have feedback and are unsure where to send it?  Send it through to support@clickstudios.com.au.

Develop User Account Policies

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

What’s needed to assign Granular Permissions?

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

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

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

How do you assign these Granular Permissions?

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

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

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

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

So…What Are User Account Policies?

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

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

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

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

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

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

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

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

Apply the User Account Policy to your Security Group

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

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

User Account Policies Are Additive

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

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

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

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

What’s with the Red Crosses?

With the production release of Passwordstate V9 in March 2021 we changed the existing Permission Models used in Passwordstate Version 8.  These changes, based on feedback from our Global user community, were aimed at simplifying the methods of assigning permissions while still providing flexibility.

Recently our support team have been receiving a number of Support Requests asking for assistance with issues associated with understanding and rectifying incorrect permissions.  We’ve also been receiving support requests stating there appears to be an error, with some folders showing red crosses on them.  So…what’s with the Red Crosses? 

A Quick Recap on Version 8 Permission Models

First let’s do a quick recap on the permission models that existed before Passwordstate V9.

The Standard Permission Model enables the permissions to be set on the Password List, in the image below the Credit Cards Password List. These permissions are then inherited or rolled-up through the Folder Structure to enable access to the Password List.  Again, in the example anyone that is provided permission to Credit Cards also has permission applied to the folders Finance, London and Click Studios to ensure they can get to the Credit Cards Password List.

Using the Propagating Permission Model, you set the permissions required at folder level and these permissions propagate down to the target Password Lists. You would set the permissions at the London folder and all nested folders and any Password Lists they contain will have those permissions set the same.  In the example blow, London and Finance have the same permissions and the two Password Lists, Credit Cards and Online Systems are accessible.  If the folder has a downward pointing green arrow then the permissions model is Propagating.

With the Manual Permissions Model, you could specify a folder to have the permissions manually set.  Manual Permissions only apply to the folder they are set on and do not inherit permissions from any nested folders or Password Lists beneath it.  If a folder has a blue padlock, then the permissions model is Manual.

You’ll note that in the image above the Click Studios folder is set using the Manual Permissions Model and the folders London, Finance and the two Password Lists in the Finance Folder have been set using the Propagating Permissions Model.

What Changed under V9?

The Beta 1 release of Passwordstate V9 introduced 2 significant changes to the Permissions model.  The image below shows the reference in the Change Log, dated 11th January 2021,

  • The first of these changes was that Folders and Password Lists could be configured to block inheritance from parent objects, and,
  • and second, the Manual Permissions Model was removed and replaced with blocking of inheritance and propagation of permissions to nested folders and Password Lists.

This model was subsequently called the Advanced Permissions Model.  But what does that actually mean? 

An Example

Let’s use an example to clarify the new model.  The Advanced Permissions Model allows you to disable inheritance of permissions from above, at any folder level in your structure, and then set and propagate a different set of permissions to any folders and Password Lists below that folder level.  It effectively replaces the Manual Permissions Model used under version 8.  Let’s use an example based on the image below;

The Red Circle 1 shows that Propagating permissions have been set at the Customers Folder and these are propagating down to each folder as shown the Blue downward arrow.  Except for the Allsand folder which has blocked inheritance from above, has different permissions applied to it and is propagating these to any nested Password Lists.

Red Circle 2 also shows that inherited Permissions have been blocked by using the Advanced Permission Model at the Customer Service Folder, with a different set of permissions set for that folder and these propagating down to the nested Password List Web Logins.

In Summary, the Red Crosses simply show that inheritance has been blocked at that folder and new permissions have been set and propagated down to any nested folders or Password Lists.

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

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

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