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 tReset 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.