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.
Sign up for MIS Asia eNewsletters.