Controlling Access to Local Windows Accounts

Problem

In the last five years Windows 2003 and 2008 have become significant platforms for Intranet Web Applications and Corporate Transaction Processing . Overtime, the Microsoft Active Directory lifecycle experience has graduated into a scalable platform for user management, including the distribution, operation, and action of Group Security Policies. Your reliance on the data held inside these server environments, and the expectation of the correct use of the Active Directory security model has become essential.

Each Windows Server install will typically have between three and six additional powerful privileged accounts (in addition to Windows "Administrator"), controlling the operation of backup, monitoring software, and owning the files and data of application and database software environments. The setup, operation, and audit of these local accounts are outside the control of your Active Directory Group Policies. Core Transactional Applications often explicitly assume software is installed locally to each Windows Server, as a dependence on Active Directory availability is not acceptable.

Audit reporting of which support staff member accessed these local accounts on each server operating system is tiresome, repetitive, and not always amenable to automation. By default the operating system reports on actions taken in the past. Pre-emptive control, when not part of Group Policies, is almost impossible. For every audit report cycle, support staff must visit each server, "log trawling" for events that may have taken place weeks ago. Businesses are reporting that on average it is taking two hours per operating system install, per audit cycle, to collect basic access and command execution information.

Of even greater concern is that reporting only indicates what has happened. By then, inappropriate and fraudulent actions may have already occurred, resulting in significant risk to your corporate value.

Semi-manual mitigations to protect these "local privileged accounts" from your support staff include ad-hoc scripting, the use of shareware third party tools, or the implementation of Microsoft's PowerShell. Each has their weakness and failing:

• The installation, configuration, and operation of scripted solutions to control local accounts is not easily scalable, and makes your audit status totally dependent on the day-to-day actions of your Windows Support staff, and how that person is feeling on that day whilst carrying out that task.
• PowerShell requires significant preparation, with multiple steps of configuration required on each server operating system. Consistency of its configuration is very hard to achieve. Many banking and finance organizations refuse to allow PowerShell to be installed, as it is seen as both too powerful in scope and too much of an administration overhead. Operational efficiencies are very difficult to realize, as a PowerShell specific security team silo is created and added to your security departments.

FoxT Solution

FoxT ServerControl's Local Privileged Account protection capability offers a more effective way to secure your Windows systems from insider fraud. Using FoxT ServerControl, you can centrally provision and administer Windows Server local accounts, and easily implement, enforce, and audit security policies for the support staff controlling access to these privileged local accounts.

By centralizing the management and enforcement of access to local Windows accounts , along with all of your other diverse servers, you both streamline user account administration and the simplify the process of auditing and reporting of your access policies and activities.

Products