We often get asked if it’s possible to bypass SAML Authentication and have an alternative fall back method of Authentication enabled for Passwordstate Users.  The requested use case typically being that SAML Authentication is set globally with an alternative, such as Manual AD Authentication,being available in case of an outage with the SAML provider.

This use case isn’t possible, but with a few changes you can achieve a similar result.

Why Can’t You Have Both With SAML As Default?

By default, when Passwordstate is installed, your Internet Information Server (IIS) is set to Anonymous Authentication.  This means that IIS does not send through your logged in credentials to Passwordstate, and when SAML Authentication is set globally, you are directing all users that browse to your Passwordstate Login URL to first authenticate with the SAML Provider.

Using a simplistic, high level diagram as an example, let’s say your SAML Identity Provider is based in Azure, and you Passwordstate instance is hosted on premise.  The following is the high-level sequence of events when accessing Passwordstate under this use case,

1. The user browses to the Passwordstate login URL,
2. Passwordstate redirects the request to the SAML Identity Provider (IDP) as configured in Passwordstate,
3. The SAML IDP send’s a Login Request to the User,
4. The User receives a Login Request screen (not a Passwordstate Login Screen),
5. The User fills out their SAML Response’s Name Identifier (NameID) and Password and hits enter,
6. The credential set is checked against the IDP’s directory, and,
7. If authorized, the SAML response is then passed through to Passwordstate.

While this is a very simplistic explanation, it does show that all traffic to the Passwordstate Login URL is redirected to the SAML Identity Provider to obtain User Authorization.  When setting the SAML Authentication globally, and using Anonymous Authentication, Passwordstate is unable to validate and choose an authentication option based on User Account Policies (and that’s part of the trick).

What’s The Alternative?

The alternative involves a number of steps.  You’ll need to disable Anonymous Authentication in IIS, set the global Authentication Option in Passwordstate to SAML (if that is what the majority of your users will be authenticating with), create a User Account Policy (UAP) and assign this to all users you want to be authenticated by your chosen alternative Authentication option (in this case Manual AD Authentication).  This may sound complex so let’s break it down. 

Disable Anonymous Authentication

First, let’s disable Anonymous Authentication in IIS.  In doing this you are passing your domain Username through to IIS, so the UAP can be applied, and then the user fills out the login screen details.

As stated above, the default setup during Passwordstate’s installation is to set IIS to Anonymous Authentication.  To disable this, you’ll need to open IIS on your webserver, select your Passwordstate website and double click Authentication,

Now right click Anonymous Authentication and select disable.  The results should look like the screen image below,

Now you’re ready to make the required changes in your Passwordstate Instance.

Set Your Global Authentication Option in Passwordstate

Login to your Passwordstate instance and navigate to Administration TAB->System Settings->Authentication Options->Web Authentication Options and select SAML2 Authentication (the global option we’re using for this example) from the Choose Authentication Options drop down list and click Save,

If you need assistance on configuring your SAML2 Authentication settings please refer to our Security Administrators Manual located under Support->Documentation on our Website.

Now Create A User Account Policy For Manual Login Authentication Users

Now we’ll create a User Account Policy for Manual Login Authentication by navigating to Administration->User Account Policies and clicking on Add.  This will take you to the Add User Account Policy screen.  We’ve previously created a policy for this so we’ll edit it instead by clicking on the name Default Manual AD,

Here you can see we’ve selected the A6 Setting ID that controls Authentication Options and selected Manual Login Authentication from the drop down list,

Once this has been saved, you’re ready to apply it to the users that will be using their AD Accounts to authenticate with Passwordstate.

Apply The UAP to the Selected Users

While still on Administration->User Account Policies you’ll need to click on the Action Icon next to the Default Manual AD Policy you’ve created and select Apply Policy to Users,

From here, you need to search for the Users or Groups you want to add to the Policy.  While you can search for, and assign users to the Policy, we’d always recommend making the assignment based on Group Membership.

You now have the majority of your users being authenticated via SAML and a select number of users being authenticated via their AD Accounts.

By using this alternative, you can achieve a similar result to the use case of SAML Authentication set globally with an alternative authentication being used for select users.  The only caveat is this only works for users logging in from Windows based machines.

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

Passwordstate has flexible Privileged Account Management functionality included in the core product.  This means it is available for customers with Client Access Licenses (support for up to 199 users per instance), Enterprise Licenses (unlimited number of users per instance) and Global Licenses (unlimited number of Enterprise Licenses). 

With Privileged Account Management you can perform on-demand or scheduled Passwords Resets, on-demand or scheduled Heartbeat Validations (check the accuracy of account name and password) in your environments, and discover the account types on your network.  All this is based on networks, their AD infrastructure and devices being accessible to Passwordstate.  This can pose a challenge when you’re dealing with discreate or firewalled networks and remote sites accessible over the internet.

What Are Remote Site Locations?

The Remote Site Locations module is a subscription based offering from Click Studios.  It enables Passwordstate to reach out to those discreate or firewalled networks, and remote sites accessible over the internet, and manage your accounts on those networks.  It does this through the use of an agent, installed on the remote network, which acts as its proxy (authorized to act on behalf of Passwordstate) on that network.

This allows Passwordstate to send to each remote agent, the tasks that need to be run on the remote network.  The agent runs these tasks and reports the details back to Passwordstate.  All that is required for this to occur is an open port on the firewall of the remote site.  This can be locked down to the IP address of your Passwordstate instance and the traffic between the remote agent and your Passwordstate instance uses independent In-Transit encryption.

You can obtain more details on how to install the Remote Site agents here https://www.clickstudios.com.au/downloads/version9/Passwordstate_Agent_Manual.pdf.  Once you’ve installed the agents, and are starting to build up a list of the hosts, accounts and passwords used on these remote sites, you’ll want to ensure the information is tagged to each of the Remote Sites.

What Can Be Associated With A Remote Site Location?

There are multiple objects and associated records that can be linked to a Remote Site Location.  This is referred to as “tagging” in our documentation.  The following are the items can all be tagged with the Remote Site Location name,

• a Domain,
• a Privileged Account Credential,
• a Host record,
• a Folder (Password and Hosts Tab),
• a Password List,
• a Discovery Job (Host and Account).
• a Scheduled Report (not shown in this blog),
• a Security Group (not shown in this blog),
• a User Account (not shown in this blog).

Tagging an Active Directory Domain with a Remote Site Location:  This can be done by navigating to Administration->Active Directory Domains, editing the required entry in your display grid and selecting the proper Site Location from the drop down list.  In the example below we’ve selected the SandDomain Site Location,

Tagging a Privileged Account Credential with a Remote Site Location: This can be done by navigating to Administration->Privileged Account Credentials, editing the required entry in your display grid and selecting the proper Site Location from the drop down list.  In the example below we’ve again selected the SandDomain Site Location,

Tagging a Host Record with a Remote Site Location: This is performed by navigating to Hosts, selecting the appropriate host from the folder hierarchy shown on the left hand side and then clicking on Edit Host Properties on the right hand side.  Again, you can select the correct Site Location from the drop down list,

Tagging a Folder with a Remote Site Location: This is performed by navigating to Passwords or Hosts, selecting the appropriate Folder, right clicking and selecting Edit Properties.  Then you can select the correct Site Location from the drop down list. 

Please be aware, when you tag a Site Location to a Folder,

• all objects within the Folder will also be tagged to the same Site Location, and,
• You can tag any object that has a Site Location of Internal to another Site Location.  However, you cannot tag any other named Site Location to another Site Location name or back to Internal.

Tagging a Password List with a Remote Site Location:  This happens automatically when you add a Password List to a Folder that has already been tagged with a Remote Site Location Name.

Tagging a Discovery Jobs with a Remote Site Location:  As an example, this is performed by navigating to Tools->Account Discovery and selecting the Discovery Job you want to tag.  Click on the Job Name to edit the job,

Then select the appropriate Site Location, again SandDomain in our example, from the drop down list,

With all these examples you’ll obviously need to save the settings, where required, by clicking Save on the bottom right of the screen.

It is a straightforward process to tag your objects in Passwordstate and maintain the relationship between the Site Location and the data that applies to that Remote Site.

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

Have you ever considered if there is an impact associated with performing upgrades to systems?  Or for that matter, how you minimize any potential impact on your internal customers?

Many Operating Systems and Applications use the concept of a “Maintenance Mode”.  This is designed to allow the person performing the change, to perform the actions associated with the change, in a way that doesn’t significantly impact on the users of that system.

So… the next question is does Passwordstate have a “Maintenance Mode” type feature?  Yes, it does.

What is Maintenance Mode?

Located under Administration->Passwordstate Administration->Maintenance and Upgrades you’ll find 3 buttons as shown in the image below, 

• Enable Maintenance Mode: This button allows you to put your Passwordstate instance in Maintenance Mode
• Send Outage Notification:  This button is used to send outage notifications
• Upgrade Information: Is used to obtain upgrade information

The Passwordstate Maintenance Mode feature is designed to place your instance into a restricted login state.  While in this state all new user login requests will be rejected.  Only the user account that has enabled Maintenance Mode can access Passwordstate.  It is highly recommended that you place your instance in Maintenance Mode before performing any upgrades to Passwordstate.

You can also monitor and terminate existing users.

So… How Do You Enable Maintenance Mode?

This is really simple, first you navigate to Administration->Passwordstate Administration->Maintenance and Upgrades and click on the Enable Maintenance Mode button,

Specify the number of minutes that you want to wait before terminating any other users that are logged in and click on the Enable Maintenance Mode button as show below,

In the display grid shown in the green box above, you’ll see all currently logged in users.  These users that are logged into the Passwordstate User Interface will receive a pop-up message advising their session is about to end, to save work and log off.

Please note, as stated on the screen above, if users’ sessions are not clearing it’s because they have closed their browser without logging out. You will need to wait or restart the your Passwordstate web site in IIS and log back in with the user account used to Enable Maintenance Mode.

How do you exit from Maintenance Mode?

How do you disable Maintenance Mode?  If you’ve enabled it and performed an upgrade, your instance will automatically be taken out of Maintenance Mode, on completion of the upgrade process.

If you need to disable it manually, simply return to Administration->Passwordstate Administration.  The section that was previously show as Maintenance and Upgrades is now shown in red as Maintenance Mode – Active.  From here you can click on the Disable Maintenance Mode button,

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

Back in June this year we published a blog post that ran through What Passwordstate Options Are Installed And Where?

But guess what… yeah that’s right… the author went and forgot to include the details for where the Password Reset Portal is installed!  So… this mini-blog-post should be read in conjunction with the original here https://blog.clickstudios.com.au/what-passwordstate-options-are-installed-and-where/.

What Is The Password Reset Portal?

The Click Studios Passwordstate Password Reset Portal is a subscription based Self-Service Portal for your users to unlock, or reset the password for their Active Directory Domain account.  It requires Passwordstate to be installed and you must have active Annual Support and Upgrade Protection on your Passwordstate instance.

It uses secure verification policies to identify your users, allows them to unlock or reset their Active Directory password 24/7 and provides tools to assist with diagnosing where lockouts are occurring.  Once you apply your subscription license key you can access the settings under Administration->Password Reset Portal Administration,

Users access the Password Reset Portal by navigating to the designated URL you have supplied.  The appearance of the site can be tailored under Administration->Password Reset Portal Administration->System Settings->branding,

How Do I Find Where It’s Installed?

The URL for your Password Reset Portal is located under Administration->Password Reset Portal Administration->System Settings->miscellaneous as per the image below (note I’ve redacted the URL in the example), 

Now you can locate the IP address for that webserver.  You can do this by looking up the DNS record for that webserver.  I’m on a Windows 11 client, and to do this I can open a Command Prompt with Administrative privileges, and type nslookup followed by the URL minus the https://,

As an example, if your URL for the Password Reset Portal was https://passwordresetportal.mydomain.com then you would type,

nslookup passwordresetportal.mydomain.com

And it will return your IP address for that webserver. And yes, it really is as simple as that. If you’d like to share your feedback please send it through to support@clickstudios.com.au.

A few weeks ago, we published a blog article on Moving the Passwordstate instance to a new Domain that has a Domain Trust.  That was the first permutation and this week’s blog covers off on the second permutation, moving a Passwordstate instance to a new Domain without a Domain Trust.

The images used in this blog are taken from Builds 9630 (also used in Part 1) and 9653.

Prerequisites – The Same As In Part 1

Again, your instance of Passwordstate will need to be on Version 8 or 9, the same as the first part in this series.

And again, make sure you have the following,

• A recent successful backup of Passwordstate including the database.  Confirmed by navigating to Administration->Backups
• your Emergency Access password in case you need it.  To get this navigate to Administration->Emergency Access

Tasks on the Old Passwordstate Website

Now we’ll perform the required tasks on the Old Passwordstate instance prior to the move.  We’ll need to setup a new Privileged Account Credential that uses an AD Account with permissions to read AD accounts and security groups in the new Domain.  To do this navigate to Administration->Privileged Account Credentials,

And, we’ll add in the new Domain name under Active Directory Domains.  To do this navigate to Administration->Active Directory Domains, and specify the newly created Privileged Account Credential at the Account with Read Access.

Next, we’ll add in the new Authorized Web Server under Administration->Authorized Web Servers,

If you have specified any IP Address Ranges in Allowed IP Ranges then these should be recorded for later and deleted (for now).  To do this navigate to Administration->System Settings->Allowed IP Ranges, and delete all listed networks.  The only network range you should retain is for the New Domain,

You’ll now need to create an Account in Passwordstate that will be used to login on the new Domain.  This is done by navigating to Administration->User Accounts.  Again, if using Client Access Licenses and are running short you can temporarily toggle one of the existing user accounts to disabled,

Once done, you’ll need to add all the Roles for the new Account you’ve just created under Administration->Security Administrators,

Next, you’ll need to stop the Passwordstate website in IIS to prevent any users from logging in to Passwordstate.

Domain Move and Then Test Login

You’re now ready to move your Passwordstate instance to the new Domain.  The instructions for this can be found on our website here,

Please Note: the order shown here is the reverse of that shown in Part 1 of this series.  It is important to perform the instructions in the order listed,

1. First (Red Circle 1), perform the database backup and move using the instructions in the document Moving Passwordstate To A New Database Server
2. Then (Red Circle 2), perform the webserver move to the new Domain following the instructions in the document Moving Passwordstate To A New Web Server,

Now you’ll need to login from a PC in the new Domain and browse to the Passwordstate URL for the instance you just moved.  If this is successful then you’re ready to continue.

Tasks Post Move To New Domain

If the login with the new account was successfully, you’ll need to set the new Domain as the Default and then delete the old Domain.  To do this navigate to Administration->Active Directory Domains, click on the Actions icon next to your new Domain and then select Toggle Default Status.  This will change the current Domain to the default.  You can then delete the old Domain from the Actions icon.

Now navigate to Administration->System Settings->Miscellaneous and update the Base URL field to match your new Passwordstate URL,

You can now start creating the Domain’s Accounts and granting access to the existing Data in Passwordstate.  To do this navigate to Administration->User Accounts.  Here you could either add them one at a time, or alternatively use the Add from AD button, 

Then search and select Users or Security Groups (and their members) to add,

Once you have your User Accounts created, and you’re still on the User Accounts screen, click on the Clone User Permissions button.  This is used to clone permissions between the old Domain’s accounts and the New Domain’s Accounts.  You can do this one at a time like below,

Or by clicking on the Clone Multiple Users button, you can generate a CSV file that can be populated and uploaded.

Next, you’ll need to add the appropriate Security Groups if you’re applying permissions based on AD Security Group membership.  This is not required for Local Groups.  To do this navigate to Administration->Security Groups and click on Add AD Security Group,

Once you’ve added your Security Groups you can Clone Permissions between the old Domain’s Security Groups and the new Domain’s Security Groups,

Final Configuration Changes (If Required)

There are a number of other settings that may need to be changed, depending on your use of them,

1. If you update passwords in Active Directory, you’ll need a Privileged Account Credential associated with the Domain.  This is configured under Administration->Active Directory Domains,
2. If you are using any Password Reset features and / or scripts you’ll need to update each of their Privileged Account Credentials with the new Domain Account.  This is configured under Administration->Privileged Account Credentials,
3. If you are using our Backup feature, you’ll need to update the settings under Administration->Backups.  Full instructions on the required permissions are documented under Help->Security Administrators Manual->Backups,
4. Navigate to Administration->System Settings->Allowed IP Ranges, and add back in any network ranges that you removed prior to the Passwordstate migration,
5. Review you and change your email server settings if required.  This is performed under Administration->System Settings->Email Alerts & Options.

Now Test, And Test Again

Finally Restart the Passwordstate Windows Service to ensure that unattended processing of tasks will occur as normal.  To do this start the Microsoft Services Desktop Application on your Passwordstate webserver, select the Passwordstate Service, right click on it and select Restart,

You’ve now effectively migrated your entire Passwordstate instance, inclusive of website, database and data structure to the new Domain, and cloned permissions from each of the old accounts to the corresponding new account.

Now you need to test and make sure all those users can still see and access all the credentials that have been granted permission to.  Only when you’re comfortable, that all data is accessing by those that should have it, should you delete the old Passwordstate User Accounts, Security Groups in your new instance and then remove the old Passwordstate instance.

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

Click Studios Technical Support deals with support calls ranging from ‘How do I create a new Password List?’  to ‘How do I recover my Passwordstate instance after a DR event?’ and everything in between.  A recent theme in support calls relates to moving a Passwordstate instance to a new AD Domain.

There are 2 permutations that we’ll need to cover off on this topic.  Moving the Passwordstate instance to a new Domain that has a Domain Trust is covered in this blog.  A future blog will cover moving the Passwordstate instance to a new Domain without a Domain Trust.

In layman’s terms when you have multiple Domains, you will not automatically have all resources in one Domain directly available to all other Domains. To enable resources in one Domain to be used in another Domain a trust in Active Directory needs to be established.  This provides secure authentication and communication between the Domains and enables you to grant access to the resource to users, groups, and computers across the different Domains.

Prerequisites

To be able to perform the following your instance of Passwordstate will need to be on Version 8 or 9.  The functionality is not support on previous versions of Passwordstate.

Firstly, make sure you have a recent successful backup of Passwordstate including the database.  If you are using the built in Backup feature this can be confirmed by navigating to Administration->Backups,

Next, it’s good practice to make sure you have your Emergency Access password in case you need it.  To get this navigate to Administration -> Emergency Access,

Don’t worry about the Emergency Access Password shown above (it’s not the real one).

On Your Old Passwordstate Website

Now let’s perform some tasks on the Old Passwordstate Webserver prior to the move.  To begin with we’ll setup a new Privileged Account Credential that uses an AD Account with permissions in the new Domain.  This will be used to read AD Accounts and Security Groups.  To do this navigate to Administration->Privileged Account Credentials,

We’ll also add in the new Domain name under Active Directory Domains.  This will enable the correct Privileged Account Credential to be used for this Domain.  To do this navigate to Administration-> Active Directory Domains,

Ensure the newly created Privileged Account Credential is selected at the Account with Read Access.

We now need to create an Account in Passwordstate that will be used to login from the new Domain.  This is done by navigating to Administration->User Accounts.  Note, if using Client Access Licenses and are running short of available licenses you could either buy some more (subtle hint) or temporarily toggle one of the existing user accounts to disabled (disabled accounts don’t count toward your licensed level),

Now you’ll need to add all the Roles for the new Account you’ve just created.  To do this navigate to Administration->Security Administrators, search for the new Account and tick the top level check box called Passwordstate Administration under Select Roles,

Login Test & Domain Move

Before we go any further, we’ll need to test that you can login correctly with the new Account you’ve created.  If this is successful then you’re ready to start the move of your Passwordstate instance to the new Domain.  The instructions for this can be found on our website here,

It is important to perform the instructions in the order listed,

1. First (Red Circle 1), perform the webserver move to the new Domain following the instructions in the document Moving Passwordstate To A New Web Server,
2. Then (Red Circle 2), perform the database move using the instructions in the document Moving Passwordstate To A New Database Server.

Once you have completed this you’ll need to login again using the new Account you created.  This may prompt you to upgrade the database.  If it does, please click Next to allow this to occur.

New Accounts & Access To Existing Data

You can now start the process of creating the new Domain’s Accounts and granting access to the existing Data in Passwordstate.  Once again, if using Client Access Licenses and are running short of available licenses you can temporarily toggle some of the existing user accounts to disabled (as disabled accounts don’t count toward your licensed level).

When creating the new Domain Accounts, you could either add them one at a time, or alternatively use the Add from AD button, 

This is found under Administration->User Accounts.  This will allow you to search and select Users or Security Groups (and their members) to add,

Once you have added them, and while still on the User Accounts screen, click on the Clone User Permissions button.  This is used to clone permissions between the old Domains account s and the New Domain Accounts.  You can do this one at a time like below,

Or by clicking on the Clone Multiple Users button, you can generate a CSV file that can be populated and uploaded.

When Cloning User Permissions, either individually or in bulk, the following settings are cloned,

• Any Blocked Email Notification settings
• Any memberships to Email Notification Groups
• Any Favorite Passwords
• Any of the ‘Features’ permissions for what menus the user is allowed access to at the bottom of the screen
• Any Grid Settings – which columns to see, width, etc.
• Any permissions to Password Lists (auditing records are added)
• Any Password Permissions (auditing records are added)
• Any permissions to Password Lists Templates (auditing records are added)
• Any Security Admin Roles (auditing records are added)
• Any membership to Local Security Groups (auditing records are added)
• The expand/collapse status of the Password Lists Navigation Tree
• Any User Account Policy permissions
• Any Scheduled Reports

Now you’ll need to add the appropriate Security Groups if you’re applying permissions based on AD Security Group membership.  You do not need to do this for Local Groups.  To do this navigate to Administration->Security Groups and click on Add AD Security Group,

Once you’ve added the appropriate Security Groups you can then Clone Permissions between the old Domains Security Groups and the new Domain’s Security Groups,

When you Clone Security Group Permissions, the following settings are cloned,

• Any memberships to Email Notification Groups
• Any of the ‘Features’ permissions for what menus the user is allowed access to at the bottom of the screen
• Any permissions to Password Lists (auditing records are added)
• Any Password Permissions (auditing records are added)
• Any permissions to Password Lists Templates (auditing records are added)
• Any Security Admin Roles (auditing records are added)
• Any User Account Policy permissions

Now Test, Test and Test

By following the above you’ve effectively migrated your entire Passwordstate instance, inclusive of website, database and data structure.  You’ve then added the new Domain Accounts and cloned the permissions from each of the old accounts to their corresponding new account.

Now you need to test and make sure all those users can still see and access all the credentials that have been granted permission to.  Only when you’re comfortable, that all data is accessing by those that should have it, should you delete the old Passwordstate instance.

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

As part of our continual focus on improving security, we’ve recently reviewed the process used by our Browser Extensions when accessing Passwordstate.  The result being we’ve changed how the extensions authenticate back against your Passwordstate instance.

The changes were introduced in Build 9611, and post upgrading, all browser extensions are required to reauthenticate with your Passwordstate instance.  This will be indicated by the Passwordstate Browser Extension icon having turned red as per the image below.

The reauthentication process will only need to be performed from your Browser Extension under the following situations,

1. After your first upgrade to Build 9611 or a later version,
2. Every time you add the Browser Extension to your web browser,
3. If you logout of your Browser Extension and then browse to a different Passwordstate instance.

When your Browser Extensions are updated through the relevant store, e.g., Google Chrome Store, you won’t have to reauthenticate.  However, if you delete the Browser Extension and then re-add it you will need to reauthenticate. 

Authentication Steps

The process of reauthenticating the Browser Extension with your Passwordstate instance is straight forward.  The biggest gotcha you’re likely to encounter is if you do not confirm the Passwordstate URL within 25 seconds. If this happens, simply refresh Passwordstate whilst logged in to kick off the process again.

To start the process of authentication, click on the red Browser Extension icon located in the Browser Toolbar as shown by the red circle 1 in the image above.  This will display the dialog stating Please browse to your Passwordstate website so this extension can be configured.

You will then need to login to your Passwordstate instance as shown by the red circle 2 in the image below.  Make sure you have selected the correct login type for your account from the drop down list, then enter your Username, Password and click on the Logon button,

Once you have logged in to Passwordstate you will see the normal User Interface based on your assigned permissions.  In these images the UI is showing the Administration tab as my account is setup as a Security Administrator.

A new dialog will now appear beneath the Passwordstate Browser Extension.  The dialog will state Please click on the Passwordstate Browser Extension icon above to authenticate with the extension.  You will need to click on the red Browser Extension icon as shown by red circle 3 in the image below,

On clicking the red Browser Extension icon a new dialog will be presented.  This dialog will show the URL or your Passwordstate instance and it should match the URL of the Passwordstate instance you have just logged into, as shown by red circle 4 in the image below.

Take the time to check the 2 URLs are the same and match the URL provided by your Passwordstate Security Administrators.  Only click on the Confirm Passwordstate URL button if these URLs match.

Confirmation

Now that the Browser Extension has been authenticated it will change colour.  In the image below the icon is shown as black as I’ve removed the automatic ignored URL for Passwordstate (as part of testing that I have been performing).  In most cases, once authenticated your Browser Extension icon will turn blue while you are still on the tab for your logged in Passwordstate session.

If you click on the Browser Extension now it will show details such as the number of any Ignored URLs, when the next automatic sync with Passwordstate is to occur and the ability to Logout (which only logs out the extension – you don’t need to reauthenticate).

As show above the process for authenticating your Passwordstate Browser Extension with your Passwordstate instance is straight forward and provides even better security.

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

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

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.