SQL Replication Options for Passwordstate HA

August 18, 2022 by

Let’s start this week’s blog with an admission.  I am not a SQL Database Administrator and I have no desire to become one.  In my professional opinion being a DBA requires a special way of looking at the world and that extends to how your databases are structured, managed and monitored.

This blog is not aimed at educating DBAs, rather it offers the options for replication that can make Passwordstate Administrators lives easier.  We’re also starting this blog from the perspective of what is achievable versus looking at business requirements, risk appetite and budget.  You could think of this as a bottom-up approach versus the top-down approach referenced in https://blog.clickstudios.com.au/ha-auditing-records-and-syslog-servers/.   

HA Options Available

As per our previous blog (link above), when implementing Passwordstate HA you require our HA license, even if you use Virtual Server Replication technologies for your implementation.  The image below is again a simple logical view of the 2 types of HA that Passwordstate could be implemented with using a bottom-up approach.  In both of the diagrams the databases are installed on the webservers to maintain simplicity.

Passwordstate HA with SQL Standard and SQL Express:  The design on the left hand side has been created with the decision not to use SQL Server Standard Edition on the HA Server.  Instead, SQL Server Express (at no cost) has been selected. 

This will only support an Active / Passive HA implementation, with the Primary instance of Passwordstate being the Publisher and using SQL Standard.  The Passive Secondary instance is the Subscriber and is using SQL Express.  Using this model your only supported form of SQL replication between the Publisher and the Subscriber is Transactional.

Passwordstate HA with SQL Standard:  The design on the right hand side has been created with SQL Server Standard Edition used for both the Primary instance and the Secondary instance.  This now provides us some options. 

This will support an Active / Passive HA implementation, or an Active / Active HA implementation. You could setup Transactional replication the same as on the Left Hand Side, or you could setup a Basic Availability Group.  Using a Basic Availability Group, you specify both a Primary Replica and Secondary Replica on your Primary instance.  Both the Primary and Secondary Replicas have a copy of the Passwordstate database. 

A Secondary Replica, also containing a copy of the database, is setup on your Secondary instance.  The Basic Availability Group handles replication between all databases and enables automatic failover of the databases using a SQL Listener, an Active Directory object created when you setup a Basic Availability Group.

Benefits of Basic Availability Groups

So, what are the advantages of using Basic Availability Groups?  An immediate advantage is that you now have an Active / Active implementation of Passwordstate HA at the Database Level.  Add a load balancer, placed in front of both of your webservers, and you can then distribute the load for a single URL between the two webservers.  This will also enable automatic failover at the webserver level in the event one of them becomes unavailable. 

Basic Availability Groups also handle database schema changes natively whereas Transactional replication requires a hands-on approach during upgrades to ensure schema changes are processed.  By using Basic Availability Groups your Passwordstate Upgrades will become that much easier.

Supplemental Information

Basic Availability Groups in SQL Server Standard edition was introduced in SQL Server 2016.  For information on how to configure either Transactional Replication or Setup Basic Availability Groups, please navigate to Support->Documentation on our website and select the documents you require.

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

Filed Under: General Post

New Browser Extension Functionality Explained

August 5, 2022 by

Our Browser Extensions for Passwordstate enable the secure storing of website credentials in your Passwordstate instance.  The credentials can then be used to automatically form-fill credential input fields, such as the Username and Password fields, when you next visit a website that you have credentials for.

With the release of Passwordstate Build 9583 we’ve updated and improved our Browser Extensions for all Chromium based browsers, including Google Chrome, Microsoft Edge, the Brave Browser and Mozilla’s Firefox.

Confirming Your Passwordstate URL – Is It New?

Well no, but it is a really important concept!  You are asked to confirm your Passwordstate website URL is correct as mitigation against a phishing style attack, where you could be asked to click on a link to login to an imitation of your Passwordstate environment.  If this should ever happen the results could be catastrophic and range from harvesting your credentials to outright compromise of your systems.  Take the time to confirm the URL matches the URL for your Passwordstate instance and only then click on Confirm,

Map Website Fields

The new Browser Extension have greatly improved input field detection.  However, with some difficult sites they may still be unable to determine which are the Username and Password fields.  This can be the case with websites that have multiple input fields, or even duplicates of input fields, on the same page.

In these cases, you can map the Website Fields to the Passwordstate Fields.  To do this, simply navigate to the website and click on your Browser Extension icon, click on Show Matching Logins, then click on the arrow to the right of the credentials you are selecting.  At the bottom of the retrieved credentials you’ll see the Map Website Fields button.

When you click on the Map Website Fields button the Passwordstate Website Field Mapper dialog will appear,

From here it’s a straight forward process of,

  1. Selecting the type of Passwordstate Field to map,
  2. Click on the Pick Field button,
  3. Move the mouse cursor to the input field, in this case the Password input field on the website and click in it to select it.

You’d then need to repeat this process for all required input fields, and once complete, click on Save.  This will write the unique website field IDs into your Password Record in Passwordstate and correctly populate those fields each time you navigate to that website.  This then leads us to the next new feature…

Form-Filling More Than 2 Input Fields

You now have the ability to automatically form-fill more than just 2 input fields.  This can be especially useful in situations where sites require a Username, Password and OTP code.  Note, your Security Administrators can turn off the setting allowing the automatic form-filling of OTP Codes.

Additionally, you can configure up to a total of 13 input fields by using the Username, Password, OTP (enabled at the Password List Level) and the Generic Fields one through ten. 

The image below is a composite image, showing the two input screens for a WordPress website that has 2FA (Two Factor Authentication) enabled.  The first screen is automatically form-filled for the Username and Password fields.  On clicking the Log In button the screen prompting for the Authentication Code is displayed and this is also automatically form-filled.  The user then simply clicks the Log In button a second time to complete the login process,

The corresponding Browser Extension record for this example looks like this,

In order to utilise form-filling of more than 2 input fields you’ll need to map the website’s input fields to fields in your Password Record as outlined in the Map Website Fields section above.

Specifying Your URL Matching Option

Another improvement, for improving the accuracy of form-filling input fields on difficult websites, is by specifying the type of URL matching to use.  URL Matching options are specific to each Password Record and are typically required when input fields are located on different webpages with different URLs.  For example, one URL that prompts for Username and a different URL for Password. 

There are 3 URL Matching options that can be selected from, Starts With, Host Name and Base Domain with the default being Starts With,

Clear Existing Website Field IDs

Lastly, if you find you are having problems with multiple Password Records automatically form-filling correctly because of incorrect or previously set Field IDs, you can clear the website Field IDs for all Password Records in a Password List.  This will not affect the credentials for those websites, only the associated Field IDs that have been recorded and stored on the website fields tab for each Password Record.

To clear all the website Field IDs, for all Password Records in a Password List, simply login to Passwordstate, navigate to the Password List you want to perform the action against and click on List Administrator Actions…, then click on Clear Web Site Field ID Values,

Note, your Security Administrator has the ability to clear all Username and Password Field IDs for all Shared Password Lists within Passwordstate.  However, they can’t clear the Password Field IDs for any Private Password Lists.

These improvements to the Browser Extensions should make significant improvements in automatically form-filling your credentials for websites.

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

Filed Under: General Post

SSO For Users Located In A Different Domain

July 29, 2022 by

We’ve recently had a number of customers enquiring about Single Sign-On (SSO) to Passwordstate where they have multiple Active Directory Domains.  In these scenarios, the configuration is typically set for all user accounts located on one Domain and Application Resources including Passwordstate, located on the second Domain.

Normally Single Sign-On with Passwordstate works by passing through the currently logged in user’s credentials, used when logging into their Active Directory Domain from their Windows Operating System, to the Passwordstate instance.  In the case of having multiple Domains, as outlined at top of this blog, you may receive additional prompting. 

To recap on how to setup Passwordstate for SSO please refer to https://blog.clickstudios.com.au/diagnose-and-fix-passthrough-authentication-issues/.  

Browser Prompting

In the examples for this blog, we’ve setup 2 AD Domains with the required trusts.  An Applications Resources Domain (abbreviated to ARD) and a User Accounts Domain (abbreviated to UAD).   Next, we’ve configured SSO and then attempt to navigate to a test Passwordstate instance located in ARD.  The following prompt is received when navigating to the Passwordstate login URL;

In this image it’s the web browser prompting for these credentials.  The request hasn’t yet been received by your Passwordstate instance located in ARD. 

How do you know this?  The Red Circle 1 above shows that the authorization is required for a URL (in ARD), compared to the Domain name shown at Red Circle 2 (UAD).  If you simply enter your Username and Password it won’t work – there are no user accounts located in ARD.  Instead, you’ll need to enter your Username in the format of Domain\Username and then your Password.  This will then log you into the Passwordstate instance.

Rather than getting your users to remember entering Domain\Username and then your Password you can make changes to your web browser Local Intranet Zone to allow the passthrough of credentials, and in doing so, enable SSO to work.

Group Policy Settings

There’s a couple of ways to resolve this.  You could;

  1. Ask your users to make the change themselves (if you’ve given them permission, and don’t care about service), or,
  2. (If it’s a real slow day) you could visit each user and do it for them, or,
  3. Make the changes via Group Policy.

Let’s face it, after you’ve done a couple you’ll be well over having to do it manually.  That being the case we’ll explore doing it via Group Policy.

To do this you’ll need to edit an existing Group Policy called Site To Zone Assignment List, on the UAD and add to this a wildcard of *.ARD where ARD is the name of the Applications Resources Domain. 

The Group Policy is located under User Configuration->Policies->Administrative Templates->Windows Components->Internet Explorer->Internet Control Panel->Security Page,

In the Show Contents dialog box, your wildcard of *.UAD, where UAD is the name of your User Accounts Domain, has a value of 1 (shown with Red Circle 3).  The second row repeats this for your wildcard of *.ARD, where ARD is the name of your Applications Resources Domain, and it also has a value of 1 (shown with Red Circle 4).  The value of 1 sets the wildcard entries, or domains, as being located in the Security Zone of Intranet.

Now after you perform a Group Policy update, and then navigate to the Passwordstate instance login URL, located in the ARD, SSO works correctly with your credentials from the UAD passed through without the user being prompted to supply them. If you’d like to share your feedback please send it through to support@clickstudios.com.au

Filed Under: Hints & Tips

HA Auditing Records and Syslog Servers

July 22, 2022 by

Passwordstate has comprehensive auditing, with over 120 different Audit Events.  These events detail when password credentials and other information has been accessed, by whom, when and much more.  For a comprehensive list of events please refer to https://www.clickstudios.com.au/about/compliance-reporting.aspx.

When you scale out your Passwordstate implementation to include High Availability, in either an Active / Passive or Active / Active design, the storing of Auditing information subtly changes.  Add to this, requirements for Syslog or SIEM (Security Information and Event Management) integration and knowing where auditing is stored and being accessed from can become a little confusing for those new to Passwordstate.

Passwordstate High Availability

Passwordstate supports 2 types of HA (High Availability), Active / Passive and Active / Active.  Both have their use cases and the type of HA implementation you decide on will very much depend on your organization’s business requirements, risk appetite and budget.  When implementing Passwordstate HA you’ll require our HA license, even if you intend on using Virtual Server Replication technologies for your implementation.

The image below is a simple logical view of the 2 types of HA that Passwordstate can be implemented with.  In both of the diagrams the databases are installed on the webservers to maintain simplicity.

Active / Passive Implementations:  This design on the left hand side provides an Active Primary instance of Passwordstate and a Passive Secondary instance.  Your users are serviced from the Primary instance and your secondary instance is effectively on standby.  Replication of SQL data occurs from your Primary instance to the database on the Secondary instance.  Any auditing data from your Secondary instance is posted back to your Primary instances API every few minutes and subsequently inserted into the Primary’s database.

In the event your Primary instance is unavailable, you would normally point users to the Secondary instance where they can access their data as read only.  No credentials can be changed by users while using the Secondary instance.  All access to credentials is logged into a local audit database, and once the Primary Instance resumes normal operation, these audit entries are synchronized back with the Primary instance.

Active / Active Implementations:  This design provides an Active Primary instance of Passwordstate and an Active Secondary instance.  Your users are serviced from either the Primary instance or your Secondary instance.  Both instances support full read & write operations.  Your users are typically directed to an appropriate instance via a load balancer.  Replication of SQL data occurs both ways, i.e., data initially written to your Primary instance is replicated to the database on the Secondary instance and data initially written to the Secondary instance is replicated to your Primary instance. 

In the event your Primary or Secondary instance is unavailable, your load balancers should be configured to direct all Passwordstate traffic to the instance that remains operating.  All access to credentials is logged as normal.  If the Primary instance isn’t available the Secondary instance will synchronize its database and auditing data back to the Primary Instance once it resumes normal operation.  When both instances are running normally the Secondary instance will synchronize its database and auditing data back to the Primary Instance on a regular basis.

Syslog and SIEM Integration

Passwordstate provides the ability to feed your audit entries directly into your Syslog or SIEM solution.  It does this via specifying the Server details including name, port number, date format and specifying the type of protocol to use. 

The setting can be configured under Administration->System Settings-proxy and syslog servers as shown below,

Once configured all audit entries are initially sent from your Primary instance.  In a HA environment, regardless of your configuration (Active / Passive or Active / Active), the audit entries are sent only from your Primary instance.  This has all the audit events for your Primary and Secondary instances as described earlier.

After the initial forwarding of all audit entries, the Passwordstate Windows Service on your Primary instance will monitor for new audit entries and send these through to your Syslog server every couple of minutes.

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

Filed Under: General Post

Custom Reports for Blocked IPs

July 7, 2022 by

We recently assisted a customer who was having troubling identifying the true source IP addresses of devices that were getting blocked in Passwordstate.  This can happen when Passwordstate recognizes a potential Brute Force Attack, typically if a user exceeds the stated number of failed login attempts, set under Administration->System Settings->Authentication Options->Web Authentication Options.

The key configuration, in being able to setup identifying the right IP addresses to block, is to configure the X-Forward-For Support.  This enables you to record the IP address of trusted devices, such as Load Balancers, Firewalls and Proxy Servers so that they are not seen as the originating IP address when client traffic traverses these devices.  This is configured under Administration->System Settings->Proxy & Syslog Servers->X-Forwarded-For Support,

In order for this to be effective you’ll need to configure your Load Balancers, Firewalls and Proxy Servers for X-Forward-For support.  This will differ for each vendors products and you’ll need to reference their documentation or contact them via your established support arrangements.

Setting Up A Report

Once you’ve configured the X-Forwarded-For Support in Passwordstate, and on your associated network devices, you’re ready to setup a report to correctly identify any devices IP addresses that are being blocked.  To setup a scheduled report showing these IP addresses simply navigate to Reports->Scheduled Reports and click on Add Report,

This will take you to the Add Scheduled Report Screen and report settings tab.  From here you’ll need to add a Report Name, decide if you want to CC Report To anyone else, choose the Email Report As format, select Do not send report if it produces no results (highly recommended) and select the report type as Custom Auditing Report,

Next, click on the schedule tab,

From here you’ll select a Report Frequency of One Time, select Generate report every, set the Hours to 00 and the Minutes to 05.  Now we’re ready to set the audit criteria to search for.  To do this select the auditing settings tab, 

From here you’ll select a Platform of All and Instance of Both.  Next, select Activity Type of Brute Forced Blocked IP Added and set the Query Previous Days to 0, Hours to 0 and Minutes to 5 and then click on Save Report. 

You’ll now be taken back to the Scheduled Reports screen and you can see the report has been created and scheduled to run every 5 minutes,

When the Scheduled Report executes, if there are IP addresses that have been blocked you’ll be emailed with the report.  If no IP addresses are blocked you won’t get a report.  You now have the details, within 5 min of them occurring, can track down what is happening on those devices and rectify the situation accordingly.

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

Filed Under: Hints & Tips

Pros and Cons of Remote Session Launchers

June 30, 2022 by

Passwordstate has 2 first-in-class Remote Access Solutions, a Browser Based Launcher and a Client Based Launcher.  These are included with all current versions of the core Passwordstate product and at no additional cost.

The key advantage for these built-in launchers is the use of Remote Session Credentials.  This enables automatic authentication to your remote hosts, removing the need for users to have to manually enter credentials. This feature is especially useful for enabling contractors or vendors accounts to be configured for authenticating to hosts without having to have access to the password record.

Both the Browser Based and Client Based launchers operate the same way in relation to protecting your credentials through encryption.  When credentials are retrieved from Passwordstate they are encrypted, sent to the Remote Session Launcher utility/gateway, decrypted and passed to the remote client.

First Time Installation and Manuals

To access the installation instructions, and install either the Client Based Launcher or Browser Based Gateway, simply navigate to Help->Remote Session Management.  From there you’re presented with the option to Install/Configure either the Launcher or the Browser Based Gateway,

and, just to point out what some people may think is obvious, when you’re Installing and configuring the Client Based Launcher… the PowerShell and .Net Framework requirements need to be on the Client PC, and the installer itself needs to be run on each Client PC that will use the Launcher,

Browser Based Launcher

Once installed, the Browser Based Launcher settings, including the Gateway settings and the installer for the Browser Based Gateway are located under Administration->Remote Session->Management,

The screen above includes a high level description of the features found in this Remote Session Launcher.  Providing greater detail on these, the Pros associated with this Launcher are;

Operating System Independence:  As the Browser Based Launcher runs from within your browser you largely have operating system independence.  This makes it not only quick to deploy but also extremely versatile, as there is no client software and associated compatibility issues, required to be installed on each user’s personal computer. 

Supports RDP and SSH Sessions:  RDP (Remote Desktop Protocol) is the most commonly used protocol for connection through to Windows based servers and PCs.  RDP clients also exist for Linux, Unix, macOS, iOS and Android operating systems.  SSH (Secure Shell Protocol) is a commonly used protocol for operating network services securely over an unsecured network.  It was designed for Unix style operating systems as a replacement for Telnet and unsecured remote Unix shell protocols.  Through RDP and SSH support the majority of an organizations computing and infrastructure fleet can typically be accommodated. 

Session Recording and Playback: This is a significant feature allowing for the recording and playback of initiated RDP and SSH sessions to remote hosts.  The feature is configurable on a per host basis and recorded sessions can be retained indefinitely or automatically purged after a preconfigured number of days.  The recorded sessions capture what is presented to the screen, allowing you to review what commands are typed/opened and the resultant screen updates.

The only real downside for the Browser Based Launcher is that it its support is limited to RDP and SSH sessions, and, that recordings of sessions are produced in a proprietary and highly compressed format which can only be reviewed within the Passwordstate UI (User Interface).

Client Based Launcher

Again, once you’ve installed the Client Based Launcher on each PC, and have setup the appropriate Remote Session Credentials you can start using the Client Based Launcher,

The screen above includes a high level description of the features found in this Remote Session Launcher.  Providing greater detail on these, the Pros associated with this Launcher are;

Support for select 3rd Party Software:  This enables you to continue to use existing investments in products, training and processes in software such as VNC (Virtual Network Computing), Teamviewer and others.  This is offered in Passwordstate for those organizations that heavily use those select 3rd party solutions for other use cases, such as shadowing users when providing training, or for Help Desk Support.  It enables your support teams to use a consistent tool set for all use cases and maximize the return on investment associated with that software.

Local Initiation:  Each launcher is initiated from the client PC.  This can be important in situations where existing 3rd party toolsets have already been installed on those PCs and/or support devices are operated in a high mobility environment (such as work from home/work from office arrangements).

The two downsides associated with this Launcher is that software needs to be deployed to each PC requiring it.  While this isn’t an issue if you’re already deploying the select 3rd Party Software for other purposes, it may be an issue if you’ve just getting around to purchasing it now (you should seriously consider the free Browser Based Option).  The second downside is there is no centralised Passwordstate Session Recording option available.

What’s Our Recommendation?

Firstly, every organization should match the capabilities offered with Passwordstate to their own requirements.  This is really the only way to ensure that capabilities that you plan to rollout match the requirement and use cases within your organization. 

Secondly, and from a purely biased point of view, the Browser Based Launcher option is hard to beat.  No cost or deployment hassles, support for RDP and SSH protocol, and the ability to setup Session Recording for playback later make this our own go to for a Remote Session Launcher (and I did say it was a biased view).  

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

Filed Under: General Post

What Passwordstate Options Are Installed And Where?

June 23, 2022 by

In this week’s blog we’re looking at a scenario where a previous Passwordstate Administrator has left and you’re now in the driving seat.  One of the first tasks you’ve been given by your “overlords” is to find out how far behind your install is and plan what needs to be upgraded.

Being new to Passwordstate, and never having been involved in the upgrade process before, you’re probably thinking “It’s time to find a new job”.  But there’s no need to panic!  Before you start taking drastic steps like planning to move on, let’s work through a high level process aimed at giving you the information you need.  This includes;

  • What version am I running?
  • What is the latest version available?
  • How do I find what options are installed?
  • Where do you obtain instructions on the upgrade process?
  • Are there any dependencies?
  • Where do I get the source files from?

Once you’ve covered off on the above, you’ll be ready to make informed decisions on what needs to be upgraded, when, and apply the upgrades to all required components.

What Version AM I Running & What Is Available?

First things first.  We’re going to assume you’ve been setup as a Passwordstate Security Administrator and granted access to most of the Roles/Features listed on the left side of the screen below.  When you navigate to Administration->Passwordstate Administration you’ll see the About information relating to your core Passwordstate instance,

Note, even through you are shown the Password Reset Portal and Remote Site Locations API Build Numbers, this does not mean you are licensed for these modules or that they are installed.  To check if you have these installed or if they need to be upgraded is covered later in this blog. 

Next, you’ll navigate to the Click Studios website https://www.clickstudios.com.au and under Download->Change Log – V9 you’ll find details on the latest build of Passwordstate.  While Click Studios recommends always being on the latest build of Passwordstate we do recognize that you’ve got other tasks and duties to perform.  We encourage all customers to review the details associated with each build and, in accordance with internal risk and change management practices, decide when to upgrade. 

Note: Each Build incorporates all previous updates and fixes for that Major Version, i.e., Version 8 or V9.  While the image above is focused on V9 you can also confirm the details for Version 8 under Download->Change Log – V8.

Once you’ve decided that you do want to plan out the upgrade you can download the appropriate CSIP (Common Software Installation Process) package from our website located here https://www.clickstudios.com.au/passwordstate-checksums.aspx.  On this page you’ll always find two packages, show by the Red Circles 1 & 2,

Red Circle 1 – or the top entry will always show the latest build of Passwordstate for the current Major Version.  In our example this is the latest build (at the time of this blog) for V9.  Red Circle 2 will always show the last build available for the previous Major Version of Passwordstate, in this case, Version 8.  Underneath the two is the link to the Upgrade Instructions. 

Don’t forget, check the downloaded package’s checksum with the published checksum value shown on the page.  The values published and the checksum of the download package change with every new build.

How Do I Find What Options Are Installed?

To start with we’d recommend looking at what options you are licensed to run.  You can check these details by navigating to Administration->License Information as per the image below,

The two core license types are Client Access Licenses and Annual Support (although a very small number customers may not have Annual Support).  The optional modules of High Availability, Password Reset Portal and Remote Site Locations will only have entries under Registration Name, Expires, License Count and Registration Key if you have either a valid or Trial license applied. 

Once you’ll established what license options you’ve got you can also confirm if and where the AppServer, Browser Based Gateway and/or Self Destruct Website are installed.

For the AppServer, navigate to Administration->Authorized Web Servers.  From here you’ll see the NetBIOS names for your Primary, High Availability and AppServer webservers.  If you need to obtain the IP address for any NetBIOS names you can use the nbtstat (NetBIOS over TCP/IP) command.

To confirm if you have the Self Destruct Push Pull website installed externally from the core website (its default installation) navigate to Administration->System Settings->self destruct messages->Self Destruct Settings and check for an entry under Separate Site URL,

Again, if you need to obtain the IP address for the supplied URL you can perform a DNS lookup of that URL by using the nslookup command.  Lastly, to confirm if you’ve installed the Browser Based Gateway on a separate server navigate to Administration->Remote Session Management->Browser Base Gateway Settings,

And under Configure Remote Session Gateway->Gateway URL you’ll see the URL of the server where it’s installed.  Again, you can use the nslookup command to locate your IP address.

Where Do You Obtain Instructions and Check Dependencies?

This part is really easy.  You have three options available for accessing the Upgrade Instructions.  These are;

  1. Accessed from our website documentation page https://www.clickstudios.com.au/documentation/
  1. Accessed from the website Checksums page https://www.clickstudios.com.au/passwordstate-checksums.aspx (the link is the same as that used for the documentation page above)
  1. Documentation is included in the CSIP Package you download.  Once extracted, the PDF is located in Passwordstate\Upgrade Instructions.  This is simply a local copy of the same Upgrade Instructions available from our website.

And lastly, regardless of how you’ve accessed the Upgrade Instructions, the Upgrade Dependency Matrix, covering all modules is located in Section 12 of the document,

Where Do I Get The Source Files From?

The only location you should ever obtain your source files from is https://www.clickstudios.com.au/passwordstate-checksums.aspx.  Never obtain Passwordstate source files from a 3rd Party Systems Integrator, Authorized Reseller or other person etc. 

When downloading from the Checksums page you will be downloading from the Click Studios Content Delivery Network.  This is a geographically distributed group of servers that provide fast delivery of our CSIP packages. 

Each build of Passwordstate includes the latest source files for all modules.  These are located in the Install path of your Passwordstate webserver under \inetpub\Passwordstate\downloads.

By following the high level processes in this blog you can,

  • Identify your current installed version of Passwordstate,
  • Confirm what you’re licensed for, have installed, and where,
  • Find the latest build available and the changes it contains,
  • Understand what components require updates, and,
  • Obtain the latest source files and instructions. 

From there you can plan out the upgrade(s), submit change requests and seek the approvals to move forward.

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

Filed Under: General Post

What’s the difference between a Security Administrator and Administrator of a Password List?

June 17, 2022 by

Passwordstate uses the concepts of Security Administrators and Password List Administrators.  Both roles are specific in what they allow the user to do within Passwordstate and in relation to accessing Password Records.  The two named roles are sometimes used interchangeably by customers new to Passwordstate. 

While it is quite possible, even probable, that a Security Administrator will be a Password List Administrator of some Password Lists, most Password List Administrators will not be assigned Security Administrator roles.  What are the differences and what do they allow?

What is a Security Administrator!

A Security Administrator is a User Account within Passwordstate, that has been granted access to one, many or all of the roles or features shown under the Administration Tab.  Security Administrators in large organizations typically have access to one or multiple roles but not all.  This allows better segregation of administrative duties and ensures separation of elevated privilege responsibilities.  Conversely, Security Administrators in smaller organizations typically have access to all roles as there are less staff to apportion them to. 

Security Administrators cannot modify their own assigned roles.  This is a built-in feature intended to prevent Security Administrators assigning additional elevated privilege roles to their account.  To modify, including adding or removing roles or access to the features, requires another Security Administrator to do it for them.  For this reason, Click Studios recommendation is there is a minimum of 2 Security Administrators assigned within Passwordstate.

Security Administrators cannot manage permissions or settings on Private Password Lists owned by other accounts.  Using the Password Lists feature they can only see that a Password List exists and who owns it.

They cannot grant themselves access to, or modify their own permissions on Shared Password Lists they don’t already have access to.  In this case when clicking on Shared Password Lists, all passwords will be hidden and some features will be disabled for them.  Note: Under System Settings you can elect to grant Security Administrators Admin Rights to new Shared Password Lists as they are created.

What is a Password List Administrator?

A Password List Administrator is the owner of a Password List.  By default, they have administrative rights to their Password List and are the only account with permission to grant additional users rights to the Shared Password List (Private Password Lists cannot have access granted to other users).

Can you have Multiple Password List Administrators?

For Private Password Lists the answer is no.  There can only be one Password List Administrator for a Private Password List.  Having said that, you can add multiple Password List Administrators to a Shared Password List, however, there is only one owner that originally created the Shared Password List.

Shouldn’t Security Administrators Access Everything?

In short no!  Passwordstate in its default configuration does not allow Security Administrators access to everything.  The founding principle for Passwordstate is to grant access to password records using RBAC (Role Based Access Control).  All users should only be provided with access to the Password Records they need to be able to perform their duties.  This means Security Administrators cannot by default grant themselves access to, or modify their own permissions on Shared Password Lists.

The analogy I like to use here is based on Segregation of Duties (SOD).  This is a basic building block of sustainable risk management and internal control for a business.  In this analogy, a person raising a Purchase Order for goods should not also be the person receiving the goods and then paying the invoice for those goods.  If the same person raises the order, receipts the goods and then pays the invoice, the end to end transaction is open to a lack of appropriate authorization, potential errors, and at worst fraud.

Likewise, Security Administrators responsible for the effective running of your Passwordstate instance, should not also need access to password records allowing access to all Employee Records in your Human Resources System, or, the credentials for the organization’s primary banking account.  In 99.9% of organizations your Security Administrators role won’t include Passwordstate Management, reviews of HR records direct from the database and shuffling funds in and out of the business bank account.  

Relevant Configuration Options

Security Administrators can, if granted access to the Systems Settings role/feature, configure the following under Administration->System Settings->password list options,

  • When administering Password List permissions from within the ‘Administration’ area, prevent Security Administrators from granting themselves permissions to passwords – either via their own account, or security groups which they are a member of (Yes/No)
  • When searching for users in order to grant them access to Password Lists, only show users who are in the same Security Groups as the person granting the access (Yes/No)
  • When a new Shared Password List is created, apply the following permission to the user who created the list (List Administrator/Modify/View)
  • When new Shared Password Lists are created, grant Security Administrators with the selected role below admin rights to the Password List (Do Not Provide Admin Access/All Security Administrators/Password Lists)

We hope this explains the differences between Security Administrators and Password List Administrators and what they can do.  If you’d like to share your feedback please send it through to support@clickstudios.com.au.

Filed Under: General Post

Testing SAML Authentication Without Affecting Other Users

June 9, 2022 by

We were recently asked to recommend an approach where a project team could test the migration from an existing authentication model to SAML (Security Assertion Markup Language) without impacting on the user’s ability to access Passwordstate.

In the example for this blog, we’re currently set for SSO (Single Sign-On) using Passthrough Authentication.  All clients are Windows based.

Don’t Use Your Own Account!

First things first.  Don’t be tempted to just test the changes to your own account.  Especially if your account is a Security Administrators account.  The last thing you’ll want to be doing is repeatedly logging in with the Emergency Access account to reverse any changes if you get the SAML configuration wrong.  

Take the time, and obtain any relevant approvals required, to establish a valid test account.  This should be setup comparable to that of a typical user.  This sort of account can be especially useful across a number of scenarios, including testing folder and password list permissions, User Account Policies etc. and you can (should) always disable the account when not actively using it. 

Disable Anonymous Authentication

Next, you should temporarily disable Anonymous Authentication in IIS (Internet Information Services).  This can be done by running the Internet Information Service (IIS) Manager Desktop App, navigating to the Passwordstate website, clicking on Authentication icon, selecting Anonymous Authentication and right clicking to get the Disable option as per the image below;

Once this has been done, you’ll need to set the Passwordstate system wide Authentication settings to Manual Login Authentication.  This will mean that users will be prompted to enter their AD credentials to login to Passwordstate while you’re testing.

To do this you’ll navigate to Administration->System Settings->authentication options->Web Authentication Options and select Manual Login Authentication from the Choose Authentication Option: drop down list as shown below (don’t forget to click Save at the bottom of the page),

Set your Test Account for SAML Authentication

Now, you can log in using your test account, and change the authentication option to SAML 2 Authentication under Preferences->authentication options->Web Authentication Option and select the SAML option from the Choose Authentication Option: drop down list then click Save,

You can now log out of Passwordstate and on logging back in again you should be redirected to your SAML provider.  You’ll need to login there and if the authentication settings are correct, you’ll be redirected back to Passwordstate and automatically logged in. 

Note: the reason why you’re logging in twice is Passwordstate only identifies your account once the credentials have been submitted (remember Anonymous Authentication is disabled) and you’ve set a preference for using SAML authentication.  Once it is set as the system wide setting all users, on navigating to the login URL, will be redirected to the SAML providers authentication screen.

Don’t Forget The SAML Authentication Settings…

These are set under Administration->System Settings->authentication options-> Primary Site’s SAML2 Authentication Settings and would need the following fields filled out,

The above represents an effective way to test the configuration and migration to SAML authentication while minimizing the impact to your users.  Once you’ve got it working correctly you can then swap over for all users by changing Administration->System Settings->authentication options->Web Authentication Options and select SAML 2 Authentication from the Choose Authentication Option: drop down list.

If you run a mixed client environment then unfortunately you can’t disable Anonymous Authentication in IIS.  This is a limitation with non windows clients, and IIS.  And once you are using SAML2 Authentication as the system wide authentication setting your users won’t be able to set an individual preference for authentication. 

Share your feedback by emailing it through to support@clickstudios.com.au.

Filed Under: General Post, Hints & Tips

What does the Passwordstate Windows Service actually Do?

May 27, 2022 by

Passwordstate, being a web based solution, has a User Interface (UI) accessible via a published URL.  This enables authorized employees access to create, access and share credentials based on their assigned level of permission.  The UI is the second most basic method of accessing a password record (the first being via our Browser Extensions).

For activities that don’t require user intervention, like scheduled password resets and account validations, we have a Windows Service called Passwordstate Service.  This is created during the Passwordstate Installation process and as the description in the image below states, provides management tasks for Passwordstate, 

But what sort of management tasks are handled by this service.  What special properties or permissions does it require?

The Passwordstate Service is Responsible for…

The Passwordstate Service effectively runs in an unattended manner and is responsible for processing scheduled events.  This is done by reading multiple tables and queueing any jobs due to be run.  When multiple jobs are due at the same time they are dynamically queued and sequentially processed.  The Passwordstate Service executes jobs within a defined security context, for example, using the specified Privileged Account Credential for any Active Directory Password Resets.

The following events are handled by the Passwordstate Service,

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

In order to perform these events, the Passwordstate Service is in constant communication with the database.  Each type of event has a specific interval timer used to specify when to next poll for that event.

The Passwordstate Service should only ever be set to logon as the Local System Account as per the image below,

It should not be configured to logon as an Active Directory account.  The only exception to this is if you are using Managed Service Accounts (MSA) and Group Managed Service Accounts (gMSA).  If using these you’ll need to ensure you’ve followed the instructions to Configure Passwordstate to use a Managed Service Account (MSA) to connect to the database located in https://www.clickstudios.com.au/downloads/version9/Installation_Instructions.pdf

Restarting the Service

As outlined previously, the Passwordstate Service is responsible for events that don’t require user intervention.  This means restarting the service is non-disruptive for users that are currently logged into Passwordstate.  To restart the Passwordstate Service, simply fire up the Services App, search down the list of services for Passwordstate Service, right click on the service and select Restart 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.  Once the Passwordstate Service has stopped you’ll need to type in Net Start “Passwordstate Service” and hit enter again as per the image below;   

This performs the equivalent of the Restart command in the Services App (there is no Restart option for the Net command).

The Passwordstate Service enables automation of events that don’t require user intervention.  In the event you need to restart the service you can do so easily and without disrupting your users.

Share your feedback by emailing it through to support@clickstudios.com.au.

Filed Under: General Post, Hints & Tips