We’ve recently had a number of enquiries around the best way of Stopping and Restarting Passwordstate.  Most of these enquiries have been related to businesses getting ready to test their Annual DR (Disaster Recovery) and BCP (Business Continuity Plans).

With this scenario in mind, we’ll establish for the sake of the blog entry, that we’re talking about a Passwordstate Primary Instance with HA (High Availability) instance in an Active / Passive configuration.  It is assumed that the HA instance is on a separate network with associated infrastructure enabling it to be contactable as required.

The image above represents a simplified logical view for this blog entry.  The webserver and database servers are installed on separate Windows Servers and all members in the example are connected over a traditional diverse pathed ethernet networks.  The Passwordstate webservers site behind a load balancer.

What Needs to Be Stopped?

The premise for this blog is you want to ensure your High Availability Instance is running and can be pointed to in the event your Primary instance is non-functional.  In order to test this, you need to effectively stop your Primary instance and then test your HA instance is functioning.  But how do you do this?

You could simply shutdown the Primary instance webserver.  Or you could follow shutdown the Primary Instance Passwordstate Windows Service and IIS (Internet Information Services) Site.  The Passwordstate Windows Service is used to perform all background tasks for the website, which typically includes;

• Sending email notifications,
• Sending out scheduled reports,
• Performing scheduled password resets, heartbeats and discovery jobs,
• Checking for new builds online,
• Removing expiring access to passwords, and,
• Sending auditing data from you HA server to your primary server (in Active/Passive HA configuration)

However, simply shutting down the Passwordstate Windows Service is not enough.  This will only stop the scheduled actions listed above. You’ll also need to Stop the Passwordstate IIS Site to prevent people form being able to login to Passwordstate and access Credentials via the API or via our Browser Extensions.

How do I stop the Windows Service and IIS Site?

There are a couple of ways of stopping the Passwordstate Windows Service.  The first is via Windows Services App.  Simply start the Services App, Search down the list of services for Passwordstate Service, right click on the service and select Stop as per the image below; 

Alternatively, you could fire up the Windows CMD Shell as an Administrator and type in Net Stop “Passwordstate Service” and hit enter as per the image below;

Next, you’ll need to stop the Passwordstate IIS website.  To do this you’ll need to start the Internet Information Services (IIS Manager) App on your webserver.  Expand the sites folder, select Passwordstate and click on Stop under Manage Website as per the image below;

This instance of Passwordstate is now effectively stopped and will not service logins, credential access via API or Browser Extensions and no scheduled background actions will run.

How do my Load balancers monitor the availability of Passwordstate?

If you were using a High Availability instance of Passwordstate, that is running in Active/Active mode, then it’s possible that you have a load balancer in front of both of your sites.  Typically, your load balancer should automatically fail over to a working site, if one of them became unavailable.

Passwordstate has a dedicated page that your load balancers can monitor, to confirm if it is running successfully, and this page is called “keepalive”.  This is designed to provide a return code of 200 if a Passwordstate instance is up and running.  The keepalive page your load balancer should periodically check is <your Passwordstate URL> with ‘/keepalive’ appended to the URL.

You may be tempted to use your normal Passwordstate login URL but you shouldn’t.  The reason for this is you may have Anonymous Authentication disabled for your Passwordstate login page.  If so ten this may return results that your load balancer may interpret as a failure triggering a failover when it isn’t required.  Many Load Balancers don’t like pages that redirect and your primary URL will redirect to different login pages, depending on the type of authentication you have set.

The Keep Alive page is always set to use Anonymous Authentication and it will never redirect.

How to restart the Windows Service and IIS Site?

Once you’ve finished your testing simply start the Internet Information Services (IIS Manager) App on your webserver, expand the sites folder, select Passwordstate and click on Start under Manage Website as per the image below;

Then start either the Services App searching for the Passwordstate Service, right click on the service and select Start as per the image below;

Or fire up the Windows CMD Shell as an Administrator and type in Net Start “Passwordstate Service” and hit enter as per the image below;

That’s all there is to it.  As outlined above you have a number of methods of effectively shutting down a Passwordstate instance for DR and BCP testing.

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

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.

Please Note: This blog article applies to Passwordstate Build 9400 or higher.

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.

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.

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.

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 Tab	Setting ID	Setting	Value
User preferences	A14	Show the Permission Model icon indicators next to Folders and Password Lists in the Passwords Navigation Tree	No
Password List Screen Options	B4	Make the Recent Activity Grid visible to the user This is all the Auditing data for the selected Password List	False
	B6	Make the Pie Charts visible to the user Pie Charts on the right-hand side of the page	False
Home Page Screen Options	C1	Dashboard Layout Settings Use the icon to the right to organise Zones and Panels. Do not try to modify the data in this textbox manually	Tick Zone 1 and Zone 2
	C2	Show the Password Statistics Chart Show or hide the chart which represents Auditing data, displayed at the bottom of the page	False

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.

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

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 11^th 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

Please Note: This blog article applies to Passwordstate Build 9381 or lower. 

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