In Build 7721, we’ve placed a large focus on simplifying the process of configure password records to perform resets on remote systems. In additional to this, it’s now a lot easier to search for accounts which belong to specific hosts, and we’ve also simplified the UI (User Interface) so it’s easy to see at a glance what the status is of the most recent password reset, and account heartbeat attempts. This post will also mention other notable changes as well.
Password Reset Changes
In this build, we have significantly simplified the process of configuring password records to perform resets on remote systems – either Active Directory, or accounts on any of the other 19 systems we currently provide scripts for.
This first screen shows how to configure Active Directory accounts – the main difference now is the ‘Domain’ has its own field, which is searchable in case you have more than one domain.
The next screen shows a Local Administrator’s account on a Windows 10 desktop. The main difference here is the Host Name field, where previously you had to link the password record to the host record on a separate screen – it can now all be done on the same screen.
On the Reset Options tab, you can also select the Password Reset Script from here as well – previously, this had to be done on a different screen as well.
You will notice that the ‘Failed Reset Options’ settings are gone as well. This is because of the new queuing system we’ve built (more information below), and now the Expiry Date field is not updated unless there is a successful reset.
We’ve also redesigned the Password List screen as well, to provide better visibility into the status of Resets and Heartbeats. As you can see from the screenshot below, you have the traffic like signals for the status, and clicking on the icon will filter all auditing data on that record. There is also a Dependencies column now as well, so if there are any related ‘dependant’ reset tasks as well, you can click on the hyperlink for the count, and it will take you to those dependencies. Dependencies are generally things like Windows Services, Scheduled Tasks, IIS Application Pools, etc. You can also have your own custom reset script as a dependency as well – it can perform any action you want, and doesn’t necessarily need to be associated with a Host record.
We’ve also built a new queuing system for the Password Resets. Whenever a password is updated for an account now, and password reset tasks are added to a queue. Only when the reset is successfully, will it update any data in Passwordstate – previously it use to update the password first in Passwordstate, and then try and perform the reset on the remote system. If there was an issue performing the remote reset, the changes where rolled back in Passwordstate.
From the screen Resets – Queued Password Resets, you can see at a glance all resets sitting in the queue – this will only show records your account has access to. It will also show a filtered view of auditing data for records sitting the in the queue as well – so you have a “time-lined” view of the reset process.
A large architectural change in Build 7721, is the previous one-to-many relationship between Password and Host records. Previously you use to be able to have the same password, linked to many hosts. This has now changed to a one-to-one relationship, primarily for the reasons of:
- Best practice dictates you do not use the same password across multiple systems
- The simplified design approach makes it a lot easier to search for accounts which below to specific hosts – you can now search for the Host’s name on any of the relevant password screens
Changes to Host Records
In previous builds of Passwordstate, you need to grant users permissions to Host records, so that they could configure password resets for accounts which belonged to Hosts, and also to use with the Remote Session Launcher feature. Permissions on Hosts have now been deprecated, greatly simplifying these two processes.
With the removal of permissions, this does mean any user has full access to the screen Resets -> Hosts – so they can add/edit/delete records. If you wish to restrict who is allowed to do this, it can be done in one of two ways.
- On the screen Administration -> Menu Access. You can remove user’s permissions from the main Resets, or Hosts navigation menu items
- If you still want you users to have access to the Resets -> Hosts menu, you can restrict who is allowed to make changes on this screen. This is done on the screen Administration -> System Settings -> Hosts tab, then click on the ‘Host Permissions’ button
Password Reset Support for HP and Juniper Devices
In this build, we’ve also added support for performing password resets, and account Heartbeat validation on the following platforms:
- HP H3C routers and switches
- HP Procurve routers and switches
- Juniper Junos routers and switches
- And Juniper ScreenOS firewalls
Changes to API Methods
With the changes to the Password Reset processes in this build, we’ve also updated our API so you can configure records for password resets as well. Specific changes to the API are:
- When you Add/Edit password records, you can enable the options for password resets and heartbeat validation. Along with this, you can select appropriate scripts, privileged account credentials, and schedules
- You can also add password reset ‘dependencies’ processes to existing accounts as well i.e. associate credentials with a Windows Service, or Scheduled Tasks, or IIS Application pool, etc
- And now that Host records no longer require permissions to be associated with them, the ‘Add Host’ method has removed this requirement also
In this build, we made some performance improvements for customers who have hundreds of Folders and Password Lists visible in the Navigation tree – typically, it was our MSP customers who were experiencing this. Below are some before and after timings of these changes:
- Create 350 Folders, with 5 Password Lists per folder, and 10 Passwords in each of the Password Lists – a total of 17,500 passwords
- Applied permissions via a User’s account, and also 5 Security Groups the account was a member of. When there are ‘duplicate’ permissions like this because of Security Groups, we need to iterate through all those records and determine which Security Groups has the highest permission – so this has a performance impact as well for this many Password Lists
Performance Prior to any Code Changes
- 14 to 15 Seconds to Load the site
- 9 to 12 seconds to change Password Lists
Performance After Code Changes
- 6.7 seconds to Load the site
- Almost instance to change Password Lists now
There are also various other features and improvements in this build. In particular, they are:
- SQL Server 2016 Support
- Perform reset on Local Admin Account Discovery
- Scheduled Reports can now be run on a more frequent basis – multiple times per day if required
- Internet Explorer Browser Extension is now out of beta
- Remote Session Launcher Utility now supports the use of local Windows Accounts for RDP sessions
We hope you like this changes in this build. The password reset updates, and new queuing system, form the basis of some more exciting Enterprise Password Management features planned for version 8.