Bad Passwords, Pwned Accounts and Prevention

As the ongoing industry investigation continues, into what has widely become known as Solarigate, it’s worthwhile going back to some base concepts.

There’s an argument to be had that an organization’s privileged accounts should be considered information assets. There is a value associated with each of these assets as well as the risk associated with these assets being known and used by unauthorized parties. If they are used by unauthorized parties then there is also an impact associated with their unauthorized use. There are many methods you can use to categorize, determine the value of the assets and establish the risk and impact associated with unauthorized use.

Microsoft have recently published the final update on their Solarigate investigation and it makes for interesting reading. Two key points stand out as background to this week’s blog (taken word-for-word from the Microsoft report);

  • The search terms used by the actor indicate the expected focus on attempting to find secrets, and
  • The cybersecurity industry has long been aware that sophisticated and well-funded actors were theoretically capable of advanced techniques, patience, and operating below the radar, but this incident has proven that it isn’t just theoretical. For us, the attacks have reinforced two key learnings that we want to emphasize —embracing a Zero Trust mindset and protecting privileged credentials.

And lastly, they state that Protecting credentials is essential. The full article can be found at
https://msrc-blog.microsoft.com/2021/02/18/microsoft-internal-solorigate-investigation-final-update/

Working on the above, it’s essential for an organization to treat their privileged credentials as information assets, protect them and ensure that the passwords used are strong. We’ll be covering Password Strength and Generator Policies next week, so this week we’ll cover off on Bad Passwords, Pwned Accounts and Passwords, and how to minimize the risk of both moving forward.

What are Bad Passwords?

Bad passwords are typically those that are based on words, a sequential series of numbers, or a basic combination of both. These passwords are susceptible to dictionary and brute force attacks and are easily cracked. Examples of bad passwords are;

  • Password
  • Password111
  • 12345678
  • 234567890
  • Linkedin1
  • Vikings

If users have the ability to use Bad Passwords then you’re making it that much easier for bad actors to execute an attack that will successfully hack a user’s account.

How do I know if I’ve been pwned?

Troy Hunt developed the HIBP (Have I Been Pwned) website to allow anyone to quickly assess if they’ve been put at risk as a result of their account having been compromised (pwned) due to a data breach. Users can look-up their email account to see if it’s been previously captured in a data breach here https://haveibeenpwned.com/


The site also provides API (Application Programming Interface) access so that passwords can be checked against the greater than 613 Million real world passwords previously exposed in data breaches. The premise is that if a password has been exposed then it’s unsuitable for ongoing use. Passwordstate provides integration with the HIBP repository via the published API.

How to prevent the use of Bad Passwords?

Passwordstate offers a couple of options to limit the use of Bad Passwords. The first is using the built-in customizable Bad Password Database. This is based on a dictionary style list of common words and sequential numbers. Please note that there are words included in the list that some people may find offensive. They’re included as they’ve proven to be used in or as part of the most common passwords. If you do not want these included in the database you can delete them.

The Bad Passwords configuration is located under Administration->Bad Passwords->Bad Passwords Database as shown below;


This database can be built on within your organization by adding specifics words that you want to prohibit the use of, for example the name of your company. To add a new Bad Password simply click on Add at the bottom of the Bad Passwords Grid and enter the word you wish to add to the database. The example below shows adding the password “clickstudios” to the database,


The second option is to select the Have I Been Pwned API from Administration->Bad Passwords->Bad Passwords Database.


This will reference the HIBP database via the published API from the Add and Edit Password screens. Please note that with Version 8 of Passwordstate you can only select the Custom Database or the Have I Been Pwned API. With V9 of Passwordstate you can elect to use both at the same time.

By using the Bad Passwords feature you are removing one avenue of weakness by ensuring that your user’s passwords are not easily cracked and aren’t the same as those exposed in previous breaches.

As always, we welcome your feedback via support@clickstudios.com.au.

Your Sysadmin Has Resigned, What do You do Next?

Change within your workforce is inevitable! Employee departure is almost a universal constant, right up there alongside death and taxes. Employee’s move on for a range of reasons, some leave abruptly, some unfortunately have their employment terminated, some give their required number of weeks notice and others generously provide some flexibility while you search for a replacement.

However, no matter what the circumstances, when a Systems Administrator leaves there will be disruption. This disruption can be thought of as a continuum ranging from mild inconvenience at one extreme to utter chaos at the other.

As they exit your employment there is a myriad of activities that need to be undertaken spanning Human Resources, Payroll, Outplacement Services, reassignment of existing workload etc. This blog does not cover any of the other disciplines or activities outside of IT. Rather it is focused on how you ensure the integrity of your privileged credentials, and therefore your data and systems once a Systems Administrator has left.

First Things First!

Immediately disable all personal accounts used by your Systems Administrator. Most organisations will start this process as the individual leaves your place of employment for the last time. The accounts should include personal and elevated privilege Active Directory Accounts, Unix / Linux accounts, VPN and mobile device connections etc.

If your Passwordstate Instance is AD Integrated this will now prevent them from logging-in and accessing any privileged credentials that they had permissions to. If you are using Forms-based authentication, or have local Passwordstate login accounts, you will need to login to Passwordstate and set the local account to disabled by selecting the Action Menu next to the user account and clicking on Toggle Status – Enable or Disabled.


Query What Accounts They Had Access To!

One of the invaluable features in Passwordstate is being able to report on what password credentials a user has been granted access to, as well as what they’ve historically accessed. To do so, simply navigate to Administration->Password Lists and click on the Perform Bulk Processing… drop down list underneath the Password Lists grid as per the screen shot below;


This will bring up the Bulk Password Reset screen, which I’ve broken down into multiple parts. The first is the section located to the left-hand side of the page called Search Filter,


Simply enter the User Account of the Systems Administrator, the Site Location you wish to report against (default is All Site Locations) and options for,

  • Recommend resets based on historical user activity, or,
  • All password the user has access to.

    and,

  • Show records enabled for Reset, or,
  • Show records which are not enabled for Reset.

It’s important to note the first two are mutually exclusive, as are the second two options. It’s also important to understand why some password records are not enabled for Reset. In most cases these will be accounts used to login to applications or web pages where Passwordstate doesn’t have the ability to programmatically reset passwords.

Site Locations relate to the use of the Remote Site Locations subscription module, where you can manage accounts located on disconnected networks, either firewalled on your internal network, or firewalled over the Internet.

Once you have entered your search criteria click on the Search button. This will populate the Search Results Grid at the bottom of the page.

Reset those Accounts!

Now move over to the right-hand side of the page to Reset Schedule,


From here, you can,

  • Schedule At a specific date and time to reset the passwords for the accounts you select,
  • Add All Records to Queue – if they are accounts that are enabled for Reset, or
  • Add Selected Records to Queue – by selecting them using the check box for each account returned in the Search Results grid at the bottom of the page. Again, this will only be available if the accounts selected are enabled for Reset.
  • Or you may want to run the Reset job immediately by clicking on Now

If you’ve selected any accounts that are disabled in AD they will still have their passwords reset to the new values. In the event that you have records that are not enabled for Reset, you can still select them and the use the Export control shown at the bottom of the Search Results grid. This will export the details of these accounts to a .CSV file so you can manually change these accounts. Note the passwords for these accounts are not exported in this CSV file.

Lastly, there is a Password Reset Queue grid shown at the very bottom of the page. This shows any currently pending scheduled Reset jobs.

So Why Do All This!

Using Passwordstate to identify accounts that your ex-Systems Administrator had historically accessed, or had permission to, is both straightforward and easy to do. You can quickly identify and then reset those accounts to ensure there is no opportunistic or deliberate attempt to access systems. That’s not to say your Systems Administrator may be intent on causing utter chaos, rather you have a duty to act professionally and take the actions necessary to ensure the integrity of your organization’s privileged credentials, data and systems.

As always, we welcome your feedback via support@clickstudios.com.au.

Reporting Passwords about to Expire

In previous blog entries we’ve run through setting up Scheduled Reports to alert Security Administrators and users when particular events occur. The previous examples focused on alerting an intended audience when extremely sensitive password credentials, say for an organization’s primary bank account, were accessed. However, you can also setup a Scheduled Report to notify an intended audience when password credentials are about to expire. But wait…there’s more.

You can use Passwordstate to share information, based on assigned roles and permissions and with full auditing of access to this information. This can include information relating to,

  • Alarm/Door Codes
  • Credit Cards
  • Software Licences
  • SSL Certificates

Passwordstate provides built in templates for these, and you can create your own for things like hardware or software maintenance contracts etc. The details on what else you can record can be located in a previous blog entry here. Once you’ve got information and/or password credentials in Passwordstate, you can setup Scheduled Reports to notify you when they are due to expire.

Setup Report for Passwords about to Expire

Like with the previous blog examples, we’re going to use the following account for this blog (yes – it’s still a fake account). It does however enable us to report against it,


Next, we’ll setup a Scheduled Report by navigating to Reports->Scheduled Reports as per the screenshot below,


and create a report called Passwords-Expiring-90 with the following options,


Note, I’ve elected to CC Report To one of my colleagues, Email Report As Embedded HTML, selected Do not send report if it produces no results and Selected Report Type as What passwords are expiring soon? You’ll also note under Report Description & Criteria it states to use the expiring passwords settings tab. This is where you set the Password Lists and options you want to use. I’ve selected the Password List called Website Logins, and the number of days in the future you want to include in the report, in this case 90 days. You can also select if you want to include passwords that have already expired.

 


Then simply specify the time and frequency of the report on the Schedule tab, with options for One Time, Daily, Weekly or Monthly. When the report has run, I receive an email as per the following screenshot,


 

Storing SSL Certificates and Reporting Expiry

Using the above example, being notified of passwords that are soon to expire, you can do the same for other types of information stored in Passwordstate.

Here at Click Studios we store all our SSL Certificates, along with their expiry date in Passwordstate. This enables us to run scheduled reports, advising what certificates are due to expire in the next 90 days. I’ve included the redacted screenshots showing the SSL Certificate entry for our QA (Quality Assurance) environment below;

 

and the copy of the certificate,


and the rest is as simple as the steps in the first example. Doing this we never get caught out with certificates expiring on us without notice!

As always, we welcome your feedback via support@clickstudios.com.au.

Auditing and Graphs

Passwordstate provides comprehensive reporting to ensure you can meet the governance requirements within your organization. All reporting makes use of the built-in audit events. There are more than 110 audit events in Passwordstate, providing a rich source of information that spans multiple categories, including,

Access to Passwordstate Access to Passwords All Passwords Exported
Auditing Data Archived Discovery Jobs Documents
Emails Email Templates Emergency Access
Encryption Keys Failed API Hosts
Logins Passwords Password Lists
Password Resets Password Validation Privileged Accounts
Remote Sessions Reporting Restricted Features
Security Administrators Security Groups Self Destruct
Templates User Accounts User Identity

When reporting on audit events, you can specify all sources or be selective. For example, you could report on only audit events relating to your Windows Service or your High Availability node. These events can then be exported to Microsoft Excel for further analysis, or summarized using the built-in Auditing Graphs.

…But before we get into the details for Auditing and Graphs

If you are trying to diagnose issues around a specific Password or Account you can quickly check the Recent Activity grid for the Password List that contains that account. This will provide useful information relating to the account and why activities such as Password Resets may not have occurred. The example below is for the helpdesk account which has been temporarily locked out;


Selecting Data using Auditing Filters

To begin with navigate to Administration->Auditing and decide on the events you want to review. By default, the display grid will show all audit events that have occurred. The Auditing Filters, show in the image below, help you to selectively focus on the specific types of events you are interested in reviewing;


The Platform options shown in the green rectangle are;

  • All, as the name implies this includes audit events for all the platform categories
  • Web, this platform category includes all audit events related to your Passwordstate Website
  • Mobile, this category includes all audit events related to either your Mobile Client installation in Passwordstate up to and including Version 8, or related to the new native Mobile Apps included in Passwordstate V9. Please note that as of the release of Passwordstate V9 the original Mobile Client is deprecated and no longer included with the Installer Files.
  • API, the API category includes those audit events associated with API Calls
  • Windows Service, includes all audit events associated with AD synchronization, Password Resets, Host and Account Discovery jobs, sending emails and querying event logs
  • Browser Extension, covers Browser Extension authentication with Passwordstate, saving, retrieving and updating of passwords and the use of the password generator,
  • Instance, you can also select your Instance to focus on, either your Primary or HA instance or Both

Lastly, you can elect to include Archived Data by selecting either the No or Yes radio buttons. By selecting No you will be querying the live audit events, if you select Yes it will query the Archived Data. Now you can filter down on a number of items as per the image below;


The fields in the Green rectangle above cover;

  • Max Records, allows you to specify the maximum number of records you wish to return as part of the search. If you wish to return all records you can enter 0 in this field
  • Password List, allows you to focus on a specific Password List in the drop down list, or search for events across all Password Lists
  • Activity Type, allows you to focus on specific audit events, or report against All Activities
  • Site Location Activity, allows you to focus on events for a specific Remote Site Location. This only applies if you have deployed and have an active subscription for Remote site Locations. The default for all installations is internal. For Remote Site Locations enter the number that corresponds with the Remote Site Location you wish to report against.
  • Begin and End Date, narrows the focus to the selected date range. Simply use the calendar date pickers for the start date and end dates you wish to focus on. A blank begin date will report all events that match the selected criteria up until the specified end date. By default, the End Date is always the current days date

Then simply click on Search to narrow the focus down to those specific events. Don’t forget that you can also filter down using the standard filter boxes under the column headings in the display grid (shown in the gold rectangle).

Export and Purging Audit Records

You may want to take a copy of the selected records, so that they can be included in a report or you may want to periodically Purge specific Audit Records. The options for these are situated at the bottom of the display grid as per the image below,


The Export to Excel will produce an Excel file called AuditingReport.xls containing the contents as per the executed filter.

If you select Purge Audit Records you will be taken to the Purge Auditing Data screen which explains the process necessary to perform the purge. Please note there is no automated purge within Passwordstate. You will need a Database Administrator, or someone responsible for support and maintenance on your SQL database, to perform the activities required. The Purge Auditing Data screen is shown below,


Graphs based on Auditing Data

Auditing Graphs provide a great summary view of your audited events. Like with the Auditing section, you can define filters for the Graphs that are very similar to those on the Auditing screen.

In the example below I’ve run a simple view based on Audit Activity of Login Attempt Failed for 1 year.


The key difference to note is that the duration timeframe is retrospective from the day the graph is based. In the example above it looks back 1 year from the current date.

The Auditing and Graphing capabilities are extremely useful and enable comprehensive reporting against your governance requirements. If you have any comments or feedback we’d love to hear it via support@clickstudios.com.au.

Ignored URLs and Browser Extensions

There is no doubt that Browser Extensions make your browser-based-life easier. The ability to securely manage website logins, while enforcing a reduced attack vector through unique login credentials, should not be understated. The statistics speak for themselves,

  • A 2018 Global Password Security Report revealed 50% of users reuse the same passwords for personal and work accounts
  • A 2019 online survey by Google identified 65% of people use the same password for multiple or all accounts
  • In the first six months of 2019, data breaches exposed 4.1 billion records
  • A 2018 Data Breach Incident Report confirmed compromised passwords are responsible for 81% of hacking-related breaches
  • Globally businesses are losing $4M on average each year due to credential stuffing attacks using leaked and exposed passwords and credentials

The reuse of usernames and passwords from a compromised site leads to a significantly increased attack vector for your business. So how do Browser Extensions help to reduce this risk, and why do I have issues with some websites.

Encourage and Support the Desired Behaviour

To begin with you need to provide the tools along with the education to your users. There is significant value in encouraging and allowing staff to use Personal Password Lists. This is reflected as one of Click Studios Best Practices for Passwordstate and more information can be found here.

Enabling Personal Password Lists needs to be performed alongside a robust training and education program for staff. This training should help them understand the real world impact associated with credential theft and hacking-related breaches. They’ll need to understand why they should have unique credentials, how they generate and store unique credentials and what to be aware of so they can identify when something doesn’t look right. Don’t forget, to get buy-in you need to show your users what’s in it for them.

Create Strong Passwords Using the Passwordstate Password Generator

One of the features of the Passwordstate Browser Extension is the ability to use the defined Password Generator. This can be set globally, via Administration->System Settings->password options->
With the Password Generator on the menu Tools -> Password Generator, select the following Password Generator Policy as the default:
and prevent users from selecting a different policy by selecting the Yes radio button,


This will make the default Password Generator for Browser Extensions reflect what was set under System Settings as detailed above. Note, the user can still choose another Generator if they want. This is why the education part is so important, Click Studios provides users the choice, however the business should reinforce the security standards they have put in place and the benefits those standards provide.


Understanding the Add Site to Passwordstate Dialog

When navigating to a website, one that you don’t have any saved credentials for, on logging in you will be prompted to Add Site to Passwordstate? The dialog provides you with 3 options, Close, Ignore and Save (note I’ve removed the username for the image below),


Save is straightforward and will create the password record in the chosen Password List. Clicking Close will simply close down the Add Site to Passwordstate dialog box. The tricky option is Ignore. When you click on Ignore you are not only dismissing the Add Site to Passwordstate dialog box, you are also adding an Ignored URL for that website login screen. The end result is that you will now never be prompted to save your credentials for that website URL again – until you delete the Ignored URL record.

To delete an ignored URL, login to Passwordstate and navigate to Preferences->Preferences->browser extension->Ignored URLs, select the URL to delete and click on the Actions icon and click Delete,


It’s worth noting that clicking on Ignore isn’t the only way to prevent the dialog for Add Site to Passwordstate from appearing. Ignored URLs can be manually entered by Security Administrators under Administration->Browser Extension Settings->ignored urls. These ignored URLs are global in effect and prevent all Passwordstate Users from saving credentials for those websites via the Browser Extensions.

Report Sites that have Issues

On occasion you will find a website that our Browser Extension has an issue with, specifically in correctly mapping the user name and password fields. When you come across this, we encourage you to report the issue by clicking on Report Site Issue. This will open up the Report Site Issue page in another Tab and allow you to record the details of the issue. We encourage you to supply as much detail as possible so that our Technical Support and Development Teams can investigate and provide a fix.

As always, we welcome your feedback via support@clickstudios.com.au.

Google Workspace, SAML Authentication and Passwordstate

Last week’s blog was all about SAML2 Authentication with Microsoft Azure. Keeping to a like theme, this week we’ll concentrate on setting up SAML Authentication for Google Workspace (formerly G Suite) and Passwordstate.

Google Workspace provides email and collaboration tools similar in basic function to Microsoft 365 (formerly Office 365). In order to use SAML2 authentication, in Passwordstate with Workspace, you’ll need to specify the settings obtained within the ‘Service/App’ configured within Workspace. The following is a summary of settings that are required;

  • Specify the Certificate Type – either SHA1 or SHA256
  • Details of your X.509 Certificate
  • The IDP Target URL
  • The IDP Issuer URL
  • Audience Restriction

As with the Azure Blog, the terminology isn’t always consistent between SAML2 Providers so you should use the table below to map the Passwordstate SAML2 Authentication Settings to the information provided by Workspace,

Passwordstate Field Workspace Supplied Fields
Audience Restriction Service Provider Entity ID
‘Your Passwordstate URL’/logins/saml/default.aspx ACS URL
‘Your Passwordstate URL’ Service Provider Entity ID
UserID or Email or UserPrincipleName Email
X.509 Certificate (SHA256) Certificate
IDP Target URL SSO URL
IDP Issuer URL Entity ID

Note in the above table ‘Your Passwordstate URL’ is the URL of your Passwordstate Instance. In the examples used in this blog ‘Your Passwordstate URL’ is this time https://passwordstate8.halox.net

Create a Service/App for SAML

In these examples we’re going to configure Passwordstate for SAML Authentication and Single Sign-On with Workspace. First you’ll need to login to your Google Admin Console and click on the Apps icon as per the screen shot below,

then select SAML Apps,


and click on Add a service/App to your domain,


this will take you to Step 1 Enable SSO for SAML Application. Click on SETUP MY OWN CUSTOM APP,


Step 2 Google IdP Information will appear and prepopulate your SSO URL and Entity ID fields for you. Click on NEXT.


this will take you to Step 3 Basic information for your Custom App. Provide an Application Name, in our example Passwordstate, and click NEXT,


on Step 4 Service Provider Details, enter your ACS URL and Service Provider
Entity ID (refer to the table at the beginning of this Blog entry) and ensure Name ID, Primary Email and Name ID Format are selected as per the image below and the click NEXT,


on Step 5 Attribute Mapping click FINISH.


Next, you’ll need to turn this on for everyone by clicking on View details,


and selecting On for everyone, then clicking SAVE,


Download your Passwordstate SAML Metadata

You’ve now created the SAML settings for the Service/App Passwordstate. By clicking on DOWNLOAD METADATA you’ll have access to all the required details  that are required to configure Passwordstate’s SAML2 section,


this will open a dialog enabling you to either, 1: Download IdP metadata, or 2: Copy the SSO URL, Entity ID, and Certificate,


Configure the Passwordstate SAML2 Authentication Settings

To configure your Passwordstate SAML2 Authentication you’ll need to login to Passwordstate and navigate to Administration->System Settings->authentication options. From here you’ll need to set your Web Authentication Options to SAML2 Authentication, and under Primary Site’s SAML2 Authentication Settings enter the details as per the screen snapshot above,


Note we’ve selected to use Email Address, or EMAIL in the Workspace settings as the unique identifier. You’ll need to copy the Certificate from downloaded file or Download metadata screen, ensuring you copy the entire contents into the X.509 Certificate field (including the Begin Certificate and End Certificate lines). The IDP Target URL:, IDP Issuer URL: and Audience Restriction: are all as per the Workspace information (again use the table at the beginning to map the SAML settings). When finished click on the Save & Close button at the bottom of the screen.

Authentication via Workspace SAML

Now you should be able to log out of Passwordstate, and on browsing to your Passwordstate URL be directed to the Google Choose an account and Enter your password challenge screens. Once you’ve logged into Google Workspace Passwordstate should open up as normal.

We hope this helps with Google Workspace and authenticating to Passwordstate using SAML. Please send any comments or feedback to  support@clickstudios.com.au

SAML Authentication with Azure AD

The Click Studios Technical Support group is regularly asked if we support authentication between Passwordstate and Microsoft Azure AD. The simple answer is yes, and in order to do this you must be using SAML2 Authentication as your global authentication setting. This allows you to setup authentication to, and Single Sign-On for, Passwordstate.

In order to use SAML2 authentication in Passwordstate, you must specify a number of settings, each of which can be obtained within the ‘Application’ configured with your SAML2 Provider. The following is a summary of settings that are required;

  • Specify the Certificate Type – either SHA1 or SHA256
  • Details of your X.509 Certificate
  • The IDP Target URL
  • The IDP Issuer URL
  • Audience Restriction

As the terminology isn’t always consistent between SAML2 Providers you should use the table below to map the Passwordstate SAML2 Authentication Settings to the information provided by Azure Active Directory,

Passwordstate Field Azure Active Directory Field
Audience Restriction Identifier (Entity ID)
‘Your Passwordstate URL’/logins/saml/default.aspx Reply URL
‘Your Passwordstate URL’ Sign On URL
‘Your Passwordstate URL’/logins/saml/default.aspx Relay State
UserID or Email or UserPrincipleName Unique User Identifier
X.509 Certificate (SHA256) Certificate (Base64)
IDP Target URL Login URL
IDP Issuer URL Azure AD Identifier
Logout URL Logout URL

Note in the above table ‘Your Passwordstate URL’ is the URL of your Passwordstate Instance. In the examples used in this blog ‘Your Passwordstate URL’ is https://prbpasswordstate.halox.net

Create a Non-Gallery Application in Azure

In these examples we’re going to configure Passwordstate for SAML2 Authentication and Single Sign-On with Azure AD. First you need to login to Azure via the portal and navigate to your Azure Dashboard. From here we select Azure Services->Azure Active Directory as per the screen shot below,

Then select Enterprise applications from the menu on the left,


and click on New Application. This will present one of 2 screens depending on whether you’re using the old App Gallery or the New and Improved App Gallery,


If you’re using the old App Gallery, you’ll see the following screen and will need to click on Non-gallery application as per the image below,


If you’re using the New App Gallery, you’ll see this screen instead and will need to click on Create your own application, give it a name and select ‘integrate any other application you don’t find in the gallery’,


This will create the Enterprise Application with the name you have provided. In this example it’s called Azure Demo-Passwordstate.

Configure and Generate your SAML Single Sign-on Information

Now we need to configure Single Sign-on and generate your SAML Provider settings for use in Passwordstate. First, we click on Single sign-on,


and then click on SAML to be able to specify the settings you require,


this will open the SAML-based Sign-on screen, allowing you to configure settings, download your X.509 Certificate and provide the URLs for configuring your Passwordstate SAML2 Authentication settings,


edit 1 Basic SAML Configuration and 2 User Attributes & Claims by clicking on the pencil Edit icon, and use the basis of the information as per the table at the beginning of this blog. Then click on Download next to Certificate (Base64) under 3 SAML Signing Certificate. Please note, as stated in the image you’ll need to add your users before they are able to login. They can be added via Users and groups on the Left Hand side of the screen,


Configure the Passwordstate SAML2 Authentication Settings

To configure your Passwordstate SAML2 Authentication you’ll need to login to Passwordstate and navigate to Administration->System Settings->authentication options. From here you’ll need to set your Web Authentication Options to SAML2 Authentication, and under Primary Site’s SAML2 Authentication Settings enter the details as per the screen snapshot,


Note we’ve selected to use Email Address, or user.mail in the Azure settings as the unique identifier. You’ll need to open the X.509 Certificate you’ve downloaded previously, with something like Notepad, and copy the entire contents into the X.509 Certificate: field, making sure to include the Begin Certificate and End Certificate lines. The IDP Target URL:, IDP Issuer URL: and Audience Restriction: are all as per the Azure Enterprise Application (our example is Azure Demo-Passwordstate),
SAML-based Sign-on screen. When finished click on the Save & Close button at the bottom of the screen.

Authentication via Azure AD SAML2

Now you should be able to log out of Passwordstate, and on browsing to your Passwordstate URL be directed to the Microsoft Azure Pick an account and Enter password challenge screens. Once you’ve logged into Azure Passwordstate should open up as normal.

We hope this makes it easier to understand how to authenticate Passwordstate with Azure AD using SAML2. Please send any comments or feedback to support@clickstudios.com.au

Control Access to Local Accounts with Credential Check-In and Check-Out

Many organizations implement strict access control to privileged accounts in their Domain and on their Windows Workstations and Servers. They work through a stringent process, ensuring local and domain user accounts have the least amount of privilege possible, lessening the possibility of exploits gaining control of systems.

However, the downfall is that a good percentage of organizations keep the same Local Administrator Account and Password combination for all Workstations. The defence, when challenged on why this is done, is typically along the lines of “we only have a handful of trusted staff that use this account”. In these cases, there is typically no auditing of which staff member used it, when and on which workstation. Key users are also typically entrusted with the generic Local Administrator account so that they can assist Support Teams (when they’re overloaded) by installing and trialling software. All of these scenarios provide the potential for rootkits, keyloggers, and other suspect services being installed without your knowledge.

With Passwordstate, you can easily setup unique Local Administrator and Password combinations for each host, audit and report the access to these accounts, configure Check In and Check Out so only one person can access the account at any point in time and setup scheduled password resets to limit exposure. Enabling PowerShell Remoting is a prerequisite required for this and you should understand the implications of doing so. Microsoft provide a good summary that can be found by searching for “PowerShell Remoting Security Considerations – Microsoft Docs”.

Discover All Hosts and Local Accounts

First, you’ll need to setup a Host Discovery job, identifying all your workstations and adding them into Passwordstate. In the example below I’m identifying all of our Windows 10 Workstations using the following Host Discovery Job.

As you can see from the above image, I’ve targeted the Windows 10 Operating System on our Domain and have specified a Privileged Account with permissions to query Active Directory for this Discovery Job. I’ve also simply selected the CN=Computers (CN being Common Name) on the active directory ous tab. It’s a good idea to initially run the query in Simulation Mode to make sure it’s returning the results you were expecting. Once you’re happy with the result you can unclick Simulation Mode and run the discovery job. You can also specify the frequency of the Discovery Job on the schedule tab. I’ve added in the results of the discovery job to the Hosts tab under a folder called Halox Workstations,


Next, I’ve created a Shared Password List called Local Windows 10 Admin Accounts. This will be used to store the Local Admin Accounts for the Windows 10 Workstations that I’ve added in. In the Password List I’ve selected Enable Password Resets and set the Default Password Reset Schedule to resetting every 90 days. On the customize fields tab it’s worth checking that the Expiry Date field is checked as required as this is updated with the new Expiry Date for the Passwords.


You can also specify the Password Strength Policy and Generator Policies in accordance with your organization’s standards.

Now you can setup the Local Account Discovery job. As per the image below, this discovery job will import all Local Accounts that are members of the Local Administrator’s Group on all Windows 10 Workstations and store the password records in the Local Windows 10 Admin Accounts Password List. You will need to specify the hosts to interrogate on the hosts to be queried tab. Again, you can run this job in Simulation Mode to ensure you are targeting the right machines and verify the results before actually importing them into Passwordstate. Note, If PowerShell Remoting isn’t enabled on the remote systems then you won’t be able to query the Local Administrator accounts on the target hosts.


Schedule Password Resets for Local Accounts

Once you’re confident you are obtaining the right results you can also elect to perform an immediate Password Reset for these accounts by selecting the radio button (bottom of the image). This enables you to bring all the imported accounts under control and reference Passwordstate as the single source of truth for these Local Account credentials.

Alternatively, you can go back to the Password List that the records are being stored in, and from the List Administrator Actions… drop down select Bulk Update Passwords,


When using either the immediate Password Reset or Bulk Update Passwords the Expiry Date will be updated in accordance with the number of days specified under Default Password Reset Schedule to enable future Password Resets to occur correctly.

Enable Check Out and Check In for Local Accounts

Lastly, we’re now at the option for Check In and Check out. This is extremely useful in offering a tight granular control over access to Local Accounts across your workstation fleet. To enable this for all Local Accounts you’ll need to modify the Local Account Discovery job you’ve previously created as follows,

This will now generate a Random Password for each Local Account that is imported, perform an immediate Password Reset on the Host that the Local Account belongs to, and specify the Security Settings of each Password Record limiting access to the password via a Check Out process, immediately perform a Password Reset on Check In and automatically Check In passwords after 12 hours (in case your System Admins have forgotten to). Anyone requiring access to a Checked Out Local Amin Account password will only be able to see who has exclusive access to this credential. All events are of course audited.

You can watch our YouTube video showing the Check In and Check Out functionality here.

We hope this information helps you to understand what options are available to better control access to Local Accounts and improve on your security posture. All feedback is welcome as always via support@clickstuidios.com.au

Specifying Authentication Options

A customer recently asked us to assist in resolving an issue with authentication for some of their users. This sparked some discussion between members of our Technical Support Team as to whether most customers knew where you can set the authentication properties required for access to Passwordstate.

The end result is this blog entry, as a reminder on where authentication properties can be set, and any specific limitations or conditions that apply to those areas. For the purpose of this blog entry we’re using an AD Integrated instance of Passwordstate. If you’re using Forms-Based Authentication then some of the screens may look slightly different.

Global Authentication Options

The first area where authentication options are set controls the settings for all users. This is typically referred to as the Global or System Wide authentication options and is accessed from Administration->System Settings->authentication options as per the image below,

As stated on the screen above, the default System Wide authentication option for Passwordstate is ‘Passthrough AD Authentication’ which requires no additional input from the user.

If you wish to change this simply select the option of your choice from the Choose Authentication Option drop down list. This will change the default authentication options for all Passwordstate users. The screen provides you with options for additional settings used with Manual AD, AD Integrated, Forms Based authentication as well as settings for other options including the popular ones such as SAML, Yubikey and Duo.

Authentication Options for Specific User Groups

Next you can set specific authentication options for groups of users through User Account Policies. This is performed by creating a User Account Policy, specifying an authentication option and assigning that policy to a group of users. To create a User Account Policy, navigate to Administration->User Account Policies and click on Add to create a policy,


Give the User Account Policy a name, description and choose an authentication option at Setting ID A6,

In line with Click Studios Best Practices, we recommend that if you have ‘Passthrough AD Authentication’ selected as your System Wide setting then don’t apply an additional Two-factor Authentication option to all users. It will frustrate your users and defeats the purpose of implementing Single-Sign-on to Passwordstate. You should instead look at applying an additional 2FA for users that need access to highly privileged or sensitive accounts. It is recommended that you do this via Security Groups and not by supplying individual usernames.

Once you’ve selected the authentication options and any other settings you want to apply, click on Save and then using the Actions icon next to your new policy, click on Apply Policy to Users. An example of applying Google Authenticator in addition to Manual AD Authentication / Passthrough AD Authentication can be found here.

User Preferences – Authentication Options

Passwordstate allows users to set a number of preferences. One of the ‘preference sets’ that can be individually configured on a per user basis is authentication options. This allows each user to specify what Authentication Option they wish to use when accessing Passwordstate, and what additional authentication options they want for accessing their Password Lists. For users to set their own individual settings they need to navigate to Preferences->Preferences->authentication options,

From this screen they can choose an Authentication Option as well as configure specific settings for multiple authentication options for 2FA. You should note however that the options that appear here can be hidden and overridden by;

  • An active User Account Policy, that applies to the user, with the Setting ID A6 set as ‘Use the System Wide Authentication Settings’,
  • Specific Authentication Options have been selected to be hidden under Administration->System Settings->authentication options->
    Hide the following Authentication Options on User’s Preferences screen:

     


Additional Authentication Required for IP Ranges

Lastly, you can choose to select different authentication options based on the IP address range that access to Passwordstate is initiated from.

This is especially useful when your System Administrators need access from non-trusted IP ranges, such as needing to access Passwordstate from an externally initiated VPN or when accessing from an Internet connection.

To configure authentication options specific for unregistered IP Ranges navigate to Administration->System Settings->allowed ip ranges->Web Site Allowed IP Ranges, specify the IP ranges for allowing access to Passwordstate and then under setting If the Passwordstate web site is accessed outside of one of the IP Ranges listed above, force the user to authenticate using the following method: choose an authentication option. If there are any settings required for that authentication option you can enter those details on the Administration->System Settings->authentication options screen.


We hope this helps you understand all the areas within Passwordstate where authentication options can be set. If you have any feedback, we’d love to hear it via support@clickstudios.com.au.

Some Examples of Best Practices for Passwordstate

Here at Click Studios a couple of staff from Pre-Sales and Technical Support are pulling together the first draft of our Best Practices guide for Passwordstate. The recommendations provided in the Guide are a direct result of assisting organizations around the world deploy Passwordstate successfully and streamline their privileged access management practices.

As the finished version of the Guide is still a little way off, we thought you may appreciate having a couple of the Best Practices previewed here.

Securing your Web.config File

One of the easiest ways in which you can secure your Passwordstate Instance is to encrypt both the Database Connection String and appSettings Sections of your Web.config file. This ensures that anyone having access to your Web Server’s file system will be unable to use the details of the Web.config file to access and retrieve your Password Credentials.

The process is straightforward and requires you to separately encrypt the Database Connection String and appSettings Sections of your Web.config file using aspnet_regiis.exe. The executable is usually located in the %windows%\Microsoft.NET\Framework\versionNumber folder. Once you’ve encrypted the two sections you’ll need to stop and restart the Passwordstate Service.

The example image below shows the command being executed for the AppSetting section, stopping and then restarting the Passwordstate Service,


Full instructions for performing this can be found within our documentation here or our blog entry here.

Use 2FA with SSO for highly privileged Accounts

Most organizations choose to install the AD Integrated version of Passwordstate and enable Single Sign-On (SSO) access to their Password Lists (Password Vaults).

The use of SSO is great for providing seamless entry to Passwordstate, once users have been successfully authenticated against your Domain, using their Active Directory credentials. However, for access to highly privileged and sensitive account credentials, stored within Passwordstate, we recommend you introduce an additional level of authentication.

An easy way of doing this is by enforcing 2FA, with a Smartphone App like Google Authenticator, for either your Systems Administrators or against access to Password Lists containing the highly sensitive credentials. To do this you create a User Account Policy (UAP) that specifies that users must use Google Authenticator (the example below uses Manual AD and Google Authenticator) and apply this UAP to your target list of AD accounts,


The Systems Wide Settings for Authentication Options remain set as Passthrough AD Authentication. Now anyone in your target list of users will be prompted for their Google Authenticator PIN as an additional level of authentication when browsing to your Passwordstate Website.

Full instructions for performing this can be found in our blog entry here.

Allow the use of Private Password Lists

Allowing the use of Private Password Lists for users within your organization is encouraged. Organizations that adopt and promote the use of Private Password Lists for their employees typically build a healthier cybersecurity awareness in their workforce. These employees more quickly embrace and adopt credential management practices, for both personal and business use within the organization.

You can automatically create Private Password Lists for all new user accounts as they are added to Passwordstate by enabling the option When a new User Account is added to Passwordstate, automatically create a Private Password List for the user. You can also specify the name of the Private Password List using the variables FirstName and Surname and base the new Private Password Lists on an existing or newly created Password List Template.

Once you have chosen your template, you’ll need to enforce the creation of the Private Password Lists on that template by creating a User Account Policy and targeting All Users and Security Groups,

Now each new User will have their own Private Password List and be configured as the Administrator of that List. Again Full instructions for performing this can be found in our blog entry here.

We hope you find this preview of some of our Best Practices useful and don’t forget to provide any feedback via support@clickstudios.com.au.