I've been continuing my efforts to get my company's user accounts under control. We have a lot of Windows service accounts that are used by software, and many of these were put into the Domain Admins group without any real thought regarding what rights they legitimately need. Now that my eyes have been opened to this situation, I've been working with our system administrators to find a way to let software run without such a high level of access.
Accounts within the Domain Admins group on a Windows domain have full control, which means they can do things like adding (and removing) computer and user accounts, creating and changing groups, changing security policies and of course reading, writing or deleting all files on every computer on the domain. They are administrators of all servers and workstations. With the possible exception of backup software, none of our applications should need that much access in order to run. Surely there must be a way to give access to the system files an application needs without all those other rights.
The applications' vendors have been of little help, typically responding along these lines: "Our software needs to read and write a lot of files in many locations, so it requires a high enough level of permissions on the system to do that. Running as a domain administrator is the easiest way to ensure that the software will have enough access to run properly."
Of course, the reason our Domain Admins group is stuffed with software accounts is that that's the easiest way to make software work. Overworked, harried system administrators who are under the gun to make something work quickly aren't very motivated to spend time figuring out which privileges are needed so that they can grant only those privileges, and then test to make sure everything works. And it doesn't help that the software manufacturers encourage the quick and easy fix of granting excessive rights.
At the same time, those same overstressed administrators don't spend much time making up strong passwords. You're bound to find an "oracle" account with a password of "oracle" (or maybe "oracle123" at best) on any network, just because rushed system administrators don't think too deeply about risk.
As a result, the accounts that can do the most damage are also the easiest for an attacker to break into.
When I brought these concerns to our Windows gurus, one bright fellow mentioned that it's possible to restrict service account access using delegation. A consultant who is a Windows expert confirmed that delegating rights in a Windows domain can be done in a way that should allow pretty much all software to work without having full rights. Sounds easy enough, but it isn't. The difficulty is that a delegation model needs to be designed and built into the domain, and that's no small task. In our case, we would need to bring in a consultant with more knowledge and experience in that area than our own administrators have.
Accounts run amok
Built-in administrator accounts are another target of my attention. These accounts, with full privileges on individual servers and workstations, exist by default on every Windows computer. And in my company, the passwords are all the same and haven't been changed in a long time. That means we have many former support staffers who still know our administrator password. There's no easy way to change so many passwords, and since they're used for support, a lot of people need them.
Ideally, we would set a different password on every system, but without some kind of password management system, there's no way that would work.
What we have done is that one of our Windows administrators set up a group policy to change the name of the administrator account, which makes it slightly less easy to break into. And he was able to find a way to change the password as well, so that's a step in the right direction.
It's not good enough yet, though. We need a way to change the built-in administrator account password more frequently and still be able to give our support staff the access they need to perform administration tasks on servers and end-user computers. For now, I'll establish a manual process to change the password the way our Windows administrator did, and enforce it in security policy. But I'd really like to find a better way to manage Windows credentials. They don't make it easy.
This week's journal is written by a real security manager, "J.F. Rice," whose name and employer have been disguised for obvious reasons. Contact him at jf.rice@engineer.com.
Join in
To join in the discussions about security, go to blogs.computerworld.com/security.
Read more about security in Computerworld's Security Topic Center.
