Password Policy Playbook – Eliminate dangers of old accounts
Adopting a new password policy is a great idea. However, do not forget about old unused accounts that may have weak passwords. What if an account was created for a new employee years ago? Maybe they never showed up and had a default password of “Company123” and the account was never disabled. How about the case where a consultant worked on the network and created test accounts with basic passwords? What if a consultant created an admin account with a weak password? I have seen this before when I was helping a customer in New York. A consultant from years prior had been there working on a Great Plains accounting system. He created a domain admin account with a password of “CompanyName” plus the year. I could not believe it.
How about accounts for services, automation, scripted solutions, outlook resource objects, shared mailboxes, etc.? In most cases, those accounts are set up with “password never expires” and some have had the same weak password for years. Some accounts are user accounts but others may have administrative rights. All of those accounts should have hardened passwords and many should have regular password changes.
Suppose you implement a much better password policy today. What if some users do not cycle through a password change under the new policy? What if their prior password was something like “Summer2024” or “Spencer1234” (named after their cat Spencer) or “JacobSmith2009” (named after their son and birth year)? Once all users *should* have changed their passwords, it is a great time to check to see that the last password set time for all users is a date after your “go live” date for your new password policy.
When undertaking a password project, I suggest you use some tools and scheduling to combat these issues.
Task #1 – Identify and disable old accounts
Identifying and disabling old accounts is easy. I prefer to use a small free utility called DumpACL. It is a really old tool but works just fine with modern OS. I don’t think you can find it on the Internet since the company no longer exists. You can download a copy from our website here (https://nfrontsecurity.com/pickup/dumpacl.zip). Although the OS tracks the last password set time and last logon time, they are not visible in ADUC. You can use the command line “net user” utility to see the data on each account but that would be too time-consuming. I am sure there are some PowerShell scripts that you can run. However, this DumpACL utility is efficient and requires no installation. Here is a quick Youtube video I did for a customer showing the same suggested use as below.
DumpACL has many features. For this task, we will focus on user properties. Go to the Report menu and select Dump Users as a Table. You get the options below. Add the fields for LastLogonTime, PswdLastSetTime, PswdExpires, and AcctDisabled. For the last logon time, it is important to note that the field is populated on each DC individually and not synced among domain controllers. Therefore your last logon time on the DC on your TCP/IP site will likely be the most current and your last logon time on other DCs may be old or set to “never”. DumpACL offers an option to help with this. Notice the bottom checkbox for “Show true last logon time…”. You should check that box to have it go across all DCs and find the most up-to-date last logon time. Once you have made your selections, click OK to run the report.
The report will look like this.
The next step is to get this data into a spreadsheet for better sorting and analysis. Go to File + Save Report As + select the file type as comma-separated values. Give it a name and save it. It will default to a .txt extension. Move the file to your workstation or a machine with Excel, rename the .txt to .csv, and open the file. Now you can sort the file to your liking. Next up is a trick I have used many times. If you simply need to use this data for a one-line command in a batch file or script, you can use Excel’s formulas and text routines to “build” a batch file. Below is an example of using this data to generate the command to disable the user account (net user <username> active:no). Once you have all of the commands in column E, highlight the cells and paste them into Notepad, save it as a .bat file, and run the .bat file to disable the users.
Perhaps you want to track down a few of these accounts. A nice trick that not many people are aware of, is how to have the Find command in ADUC show you the location of the object. In ADUC, right-click on the domain name and select Find. On the Find dialog go to the View menu and select Choose Columns. Add the “Published At” column and click OK. Now your results will show the OU location in the AD of the objects in the results. This is very handy to find misplaced objects.
Task 2 – Find accounts whose passwords never expire
Using the Excel CSV file, look at the column for pswdExpires and inspect the accounts where the value is “No”. How you handle these accounts will be up to you. Perhaps it is an automation account used for scripted tasks. Perhaps it is for a shared mailbox (FYI – you can disable accounts for shared mailboxes without disrupting their functionality). Regardless of the account purpose, you want to be sure you have hardened passwords on these types of accounts.
Some organizations manually change passwords on these accounts on a regular basis like once a year. Why would a company do that? Think about what can happen if an IT employee leaves on bad terms. Sure their user account may have been disabled, but if they know the username and password for accounts used for automation, etc. they can possibly get back to the network. Many years ago we were consulting for a manufacturing company that had a big layoff. An employee affected by the layoff was upset. They found they could use the wireless network from the parking lot. They used another account besides their own to get onto the network and queue a large order that wasted a lot of product.
Using a password vault product or product that changes passwords on these accounts automatically can be helpful. For many service accounts, you can use Microsoft’s managed service accounts. If you are not familiar with managed service accounts you can learn more here – https://techcommunity.microsoft.com/blog/askds/managed-service-accounts-understanding-implementing-best-practices-and-troublesh/397009.
Task 3 – Find accounts with no password change after XX days
Suppose it is January 15, 2025, and you go live with a new password policy. Most of our customers let the natural password expiration take place. Users must change their passwords over the next XX days depending on their overall domain maximum password age. Suppose that time period is 90 days. I always suggest doing some follow-up tasks after that password change cycle has passed. Here is a quick tip – Excel can be handy for calculating dates. In the screen below, I add 90 days to the date of 1/15/2025 and it calculates a date of 4/15/2025. If I had gone live with the new policy on 1/15/2025, I would set a calendar reminder to do some analysis on 4/15/2025 or later.
So what would I do on April 15? I would use DumpACL to pull a table of users and I would analyze the list to see who has an active account (i.e. not a disabled account) and whose last password set time is older than 1/1/2015? Technically, zero real users should fall into that category because everyone should have changed their password. However, you may find a few people. I would inquire to see if they are on vacation or if this is an overlooked account that should have been disabled, etc.
It would also be a great time to do a self-audit. If you are using our nFront Password Filter software, then hopefully you are using the rule to scan against breached passwords. If not, you should run our free nFront Weak Password Scanner or similar tool to inspect your AD for users with breached passwords. With our password filter, you can pull some statics from the registry of each DC to see how many passwords have been rejected or approved. Depending on your configuration, you can also pull logs on rejected passwords. Depending on the logging configuration, you can see common reasons for failure and even the dictionary words related to the failures.
Need assistance? We are here to help.
Would you like help sorting your password policy challenges? Simply fill out the contact us form on our website or email us (hello[at]nFrontSecurity.com).
We can help with tasks like:
- a health check on your existing password policy
- password policy best practices and trends
- configuration options to meet compliance
- presentations to management on the need for an improved password policy
- communication templates for end users
- a plan to get from your current policy to a new policy with the smoothest transition
