Using Application Control to Limit Administrators on Servers. What Works, What Doesn’t.
First, there are administrators and then there are ADMINISTRATORS. This blog takes a look at what can be done to control administrators in our environments. Why would we want to limit our administrators? After all, they ARE the people who manage our infrastructure. It may be that organizations just make people administrators because it seems like the easiest way to allow them to do their job.
November 30, 2011
First, there are administrators and then there are ADMINISTRATORS. This blog takes a look at what can be done to control administrators in our environments. Why would we want to limit our administrators? After all, they ARE the people who manage our infrastructure. It may be that organizations just make people administrators because it seems like the easiest way to allow them to do their job. This is the primary reason I see. The alternative is to provide them with just the permissions they need, restricting access from applications or management tools they don’t need, or shouldn’t use. Other reasons organizations grant administrative controls are due to the multiple tools needed for management of the infrastructure, and we want to make sure administrators use the right tools. A great example is the desire to stop administrators from using the native Hyper-V Management tool, so the organization uses System Center Virtual Machine Manager console to control access.
ADMINISTRATORS are people on a server who are members of the local Administrators’ group. They become an Administrator through direct membership or through a domain joined server where the user is a domain administrator. These people have authority to do anything they want. Yes, you can apply group policies to set what the user can or can’t do. You can also use application control solutions to limit what the administrator can run. Initially all these solutions will work, until the experienced administrator decides they really want to perform the action, and circumvents the solution. The experienced administrator can replace the print spooler service with their own custom application to schedule a command prompt, opening up and run as a local system.
Then, they will use PSEXEC, or a multitude of other options, to run what they want to and turn off policies they don’t like. We can make things harder for administrators by limiting access to system tools and the registry editor. However, if we do this, can they still do their job as an administrator? And, why are they administrators at your organization? Many application whitelisting tools will automatically provide full access to local administrators, enabling them to perform the functions they need. Make sure that administrators can get their jobs done and that application restriction policies aren’t getting in their way, forcing them to “improvise”.
Then we have “administrators”. These are not people that have administrative privileges on the box but rather have been given specific rights through means such as Authorization Manager or application specific tools. Generally, these users will not be able to bypass restrictions you place on them and application control policies can be trusted. But, it is important to ensure that the management applications these administrators require to do their job are whitelisted. A good approach for these administrators is to create domain groups with these users who need access to management tools, then whitelist the tools to the domain groups.
Ultimately, you should not have many ADMINISTRATORS in your organization. Those who are ADMINISTRATORS will be trusted people in your organization. For others who just need to administer aspects of the operating system or application, don’t make them ADMINISTRATORS but rather grant them the rights and access they need to do their job. This enables the organization to restrict and control users, even though it’s a little more work up front!
About the Author
You May Also Like