Increase Security Using UAC | Get The Best Results Using User Account Control

Fundamentally, it's the IT department's responsibility to ensure the security of the PC assets, prevent the use of unlicensed software, and enforce compliance with government regulations and internal policies. Most companies will find that the only way to do this is to enact a new policy of restricting the number of users who have administrator privileges. Luckily, you'll find this much easier to do on Windows Vista And Windows 7. Read more: http://www.bench3.com/2010/08/get-best-results-using-user-account.html#ixzz0xxbd4XVH

Continued From: http://www.bench3.com/2010/08/get-best-results-using-user-account.html

Levels of Desktop Lockdown

Even with these improvements (mentioned in my early post) in the Windows 7 / Vista OS, not every organization will be able to deploy all of their Windows 7 / Vista desktops with standard user permissions. Some organizations may have applications that still require administrator privileges or they may have users, such as developers, who need to install their own software.

That's OK. Windows 7 / Vista allows multiple levels of desktop control, configurable through user account selection and Group Policy, all of which provide more manageability and security than a full administrator account on Windows XP. Most system settings relevant to UAC settings can be found in the Security Policy Editor (secpol.msc), which is shown in Figure below (Security Policy Editor).

Figure : Security Policy Editor (Click the image for a larger view)

• The first level of control is called Admin Approval Mode. This mode reduces the threat of some types of malware attacks by starting programs with standard user privileges by default and alerting the user if a program is attempting to run with administrator privileges. 

In this mode you can perform audits through the event log when the user runs a program that requires administrator rights. But keep in mind that while an application may run with standard user privileges, this mode doesn't provide the same security as a true standard user account. The user still has administrator privileges and can change policy settings, install unapproved software, and allow powerful malware such as a rootkit to be installed.

• The next level builds upon the first, but uses Group Policy to restrict elevation to programs that are signed with a certificate that is in the Trusted Publishers store. 

This can help prevent unsigned malware from obtaining administrator privileges and can prevent users from installing arbitrary software. However, when running with administrator accounts, savvy, unscrupulous users, or sophisticated malware could disable the policy, at least temporarily, to perform unauthorized actions. Therefore, these first two levels should be used as interim measures while resolving any issues that prevent you from issuing true standard user accounts.

• The next level of security comes from removing users from administrator accounts and making them standard users. 

One feature of UAC is called the Over the Shoulder Credentials Dialog, which standard users will see by default if they start a program that requires administrator credentials. Standard users are blocked from performing that action, but if they know the username and password of an administrator, they may enter it and continue the action. A typical scenario in which this feature could be used involves a traveling laptop user. 

If, for example, the user has an urgent need to install a piece of software while he is on the road, he could call the helpdesk who could provide the password for a local administrator account, which the user could enter and allow the program to run (see Figure below, Requiring an Admin Password). If you provide the administrator password to the user, I recommend that you have processes and tools in place to reset the administrator password when the user reconnects to the network, and that you log the programs that have been run using the administrator credentials. Also be aware that if the PC has been infected by malware, the administrator may be tricked into giving demonstrators privileges to malware that they did not intend to.

Figure [(c) http://technet.microsoft.com ] Requiring an Admin Password (Click the image for a larger view)

You also have the option of disabling the credentials dialog using Group Policy. Set the User Account Control: Behavior of the elevation prompt for standard users setting to Automatically deny elevation requests (see Figure below, Application Blocked by Group Policy ). This is the way we recommend that most enterprises that deploy standard user desktop should configure UAC. Most organizations would do this to prevent the user from calling helpdesk for a password that the IT department doesn't want them to have.

Figure [(c) http://technet.microsoft.com ] Application Blocked by Group Policy (Click the image for a larger view)

For the strongest level of desktop lockdown you can use UAC and standard user accounts combined with Windows Software Restriction Policies (SRP). With SRP, enterprises can go an extra step and prevent any software from running that they did not specifically allow. SRP is designed to block the execution of software unless it meets specific criteria based on Authenticode® certificate, hash, path, or Internet Zone.

SRP is managed through Group Policy, and you can create a very powerful policy to prevent the installation and execution of non-approved programs with little work. A typical policy might disallow all executables except any found in these paths: %WINDIR% and %PROGRAMFILES%, and apply polices to all users except administrators.

With this policy in place, the IT staff can still install whatever software programs it wants into the Program Files directory without having to add each .exe to a whitelist (a list of accepted items). And since the standard user does not have access to these directories, he or she cannot place it somewhere that it will execute.

You may have noticed there was no mention of the Power User group. That's because the Power User group has been removed from Windows 7 / Vista. Some organizations used the Power Users group in an attempt to limit administrator privileges. While making someone a power user may prevent him from making unapproved system configurations, he (or malware running with power user credentials) may be able to gain additional rights and permissions and even complete administrative credentials. For that reason, Windows  7 / Vista has administrator and Standard user as the two primary account types.

Desktop Management Infrastructure

Using File and Registry Virtualization, the new Driver Store infrastructure, and the other features I discussed will make it much easier for you to deploy Windows 7 / Vista desktops with standard user accounts. Even with these techniques, however, you will not be able to support a standard user environment completely unless you have the management infrastructure—tools, processes, and people—to support users who cannot do some things on their own. Some of the issues you need to consider are:

Software Installation:
If users can't install software on their own, you need to provide another way. One way, which doesn't require any other management software, is to use Group Policy. With Group Policy, you can add a program to the Add/Remove programs list. If a user installs a program using this method it will launch with the elevated permissions needed for the user to complete the installation. For a richer solution you could also use SMS or a similar product. Some solutions even allow you to create self-service Web portals where standard users can pick and choose the software they want to install.

Software Updating:
You'll need to have a way to install updates on your PCs, other than sending out an e-mail that says, "Please install this update!" To manage and deploy most Microsoft updates you can use Windows Server Update Services, which is a free download for Windows Server. To deploy a broader range of updates, again, you may consider a desktop management product such as SMS.

Support Processes and Staffing:
When a user calls the helpdesk about something that is causing a performance problem or wants to install something new, in many cases you won't be able just talk them through the process over the phone, since they may not have permissions. Your IT department will need to make greater use of remote assistance and remote administration tools to diagnose issues and change settings. Even Windows Remote Assistance will work differently because logged-in standard users cannot approve the prompts for actions that require administrator privilege, though helpdesk staff could use Remote Desktop to make administrative changes remotely.

Workflow For Installing A Trail Software:

It will be critical to have clear, efficient processes for handling policy exceptions. Let's say someone in the marketing department needs to install a trial version of a new graphic design tool she is evaluating for her department. Who gives the approval to install that software—her manager, her director, or the CIO? How will it get installed and how long will she have to wait? We suggest creating a simple approval workflow that is integrated with the helpdesk issue tracking system. A basic workflow could be:

1. User submits request to install a program and the link to the installation program (on their local hard drive or in their CD tray), and confirms that the software was not obtained illegally and is not being used for malicious purposes.
2. Request is sent to manager for approval.
3. Request is routed to application lead in IT department who can check to ensure there are no known compatibility problems, perform a virus scan, and make sure that the company has not already purchased a site license for that program or a similar program from another vendor.
4. Request is forwarded to a support technician to remotely initiate the installation and notify the user when the software is ready for use.

To create the workflow interface you could either script dynamic Web pages or obtain a commercial helpdesk or issue-tracking package. You will also require different staffing for a managed versus an unmanaged environment. Hopefully, you will need fewer technicians to physically diagnose or reimage unstable or infected PCs. However, you may need to initially allocate additional staff to software packaging and deployment.

Over the long run, you should experience lower support costs as machines remain stable longer, but initially you may experience an increase in helpdesk calls from users asking for help with configuration. The helpdesk calls will taper off after you configure your desktop images and group policies with the settings users need and expect.

Its Psychological, Not Technology:

The final hurdle is not technological, but psychological. Some users may have an adverse reaction to the idea of not having administrator privileges. But I believe most users won't notice a difference. And if you deploy Windows 7 / Vista at the same time that you enforce standard user accounts, the productivity benefits of the integrated desktop search, the new Aero (glass) user interface, and the improvements for mobile users will outweigh any inconveniences that come from not being an administrator. However, if poor processes cause people to wait for weeks to get permission to install a piece of software, then you can expect to have some unhappy employees.

Recent Post:

Get The Best Results Using User Account Control[Part1]