Then they have to make changes, test the functionality of the software services that use those accounts and try to fix whatever breaks because of the reduced privileges. Our developers are already overworked on business projects, so my concerns may stay on the back burner for a while, at least until some insistent requirement comes along that makes the problem a priority.
Training accounts are somewhat easier to address. We have roughly 100 Windows user accounts that are called train1, train2, etc. These are used by employees and customers who go through our training programs to learn how to use various software platforms. You'd easily be able to guess their passwords as well, but at least their privileges aren't excessive. I had the training department and system administrators work together to choose better passwords, and set them to expire every 90 days. I still don't like shared accounts like this, but I can comfort myself that their privileges are limited and the passwords are better now.
Test accounts had the same problem as training accounts. Scores of IT people over the years had created such accounts for various purposes. Some of these were easy to track down because they had "test" in the name. Others were more difficult to find, because some administrators created additional accounts in their name or accounts with other unexpected names.
I was able to find these by subtracting all the known account names and looking at what was left. I instituted a new policy of naming test accounts after the people who use them, forcing the passwords to expire every 90 days and disabling the accounts when they are not actively being used.
Built-in administrator accounts are the final frontier. I'll talk more about those next time.
Sign up for CIO Asia eNewsletters.