The biggest reason to avoid least privilege on the desktop is that striking a balance between usability and security is much harder on a desktop than on a server. However, technologies do exist to help implement least privilege successfully on the desktop.
The single biggest roadblock in running as a standard user is application compatibility. Windows developers have become used to logging in to their machines with administrative privileges. This inevitably results in software that requires administrative privileges to work correctly. One of Microsoft's goals with User Account Control is to try to change this practice, and force programmers into developing software as a standard user. Application compatibility problems with Least Privilege Security range from programs failing to launch, to not retaining user settings. Error messages appearing at inopportune moments, inconveniencing users, and making it appear that the application wasn't designed to run on the system where it's installed are a result of bad practice on the part of developers. Frequent UAC prompts in Vista led many users to think that the problem was with UAC rather than due to a poorly coded application.
Earlier versions of Intuit's QuickBooks software for small businesses were probably the most well-known Least Privilege Security compatibility offenders. Until recently, it was a requirement for users of QuickBooks to be a member of the administrators, or pre-Vista power users group, forcing many businesses to risk the integrity of their systems by allowing users to run with administrative privileges. Fortunately today, most commonly used off-the-shelf enterprise applications will run with least privilege user accounts. For legacy applications and other programs that are still incompatible with Least Privilege Security, there are many technologies that can be used to solve compatibility problems, such as virtualization techniques and compatibility shims, which will be covered in the second half of this book.
Security is always a trade-off against usability, and least privilege is no exception. Implementing Least Privilege Security prior to Windows Vista involved a lot of work, and most system administrators simply didn't have the time, resources, or management backing to make it work in such a way that it would be accepted by end users. That's not to say that it's impossible to implement Least Privilege Security in Windows XP, but it does require time and testing on your part. There are many common settings that users can't change as a standard user in Windows XP. User Account Control has addressed most of these issues in Vista and Windows 7.
Let's take a look at the issue of changing a system's time zone, date, or time. As a standard user in Windows XP, you cannot change any of these settings. Changing the date and time is protected because Kerberos, the standard network authentication protocol in Windows 2000 and later, relies on date and time synchronization for successful authentication with a domain controller. If a system's date and time doesn't fall within close range of the domain controller, the user will not be able to log in. Hackers can manipulate the date and time to cover their tracks and as such this provides another reason to restrict access to these settings. For non-domain computers, Windows synchronizes the time and date with an Internet time server, so standard users don't require access to modify time and date settings.
Time zone is another matter as it simply changes the way the time is displayed to users, not affecting their ability to log in if the time zone is different to the server's. Prior to Windows Vista, standard users were not able to change the time zone, causing much frustration for notebook users. It may not seem such a big deal to most system administrators, but users are not likely to accept that they can't change the time zone on their notebook if they travel a lot, deeming it as a problem with their system. The time zone is just one example of a problem you will encounter when implementing Least Privilege Security in Windows XP.
In spite of it being considered a routine task by most users, standard users cannot burn data to a CD or DVD in Windows XP. As you can see, removing administrative privileges in Windows XP is likely to create problems very quickly if the change is not carefully planned.
Though Least Privilege Security makes it harder for users to break their systems, it also makes it more difficult for users to fix problems or make necessary changes without involving the help desk. This may not be a problem for desktops that are located in an office with easy access to IT support, but for remote workers without administrative privileges, should a serious problem occur, there could be a long wait before a solution is implemented. Help desks often rely on remote workers to change important system settings to fix serious problems. This is somewhat of a catch-22 situation, as it's likely that if a user doesn't have administrative privileges, those important settings can't be modified and the system will work reliably, but should something need to be changed, the user has to call the help desk.
It's commonplace for system administrators to rely on remote workers, who rarely visit the office, to install operating system updates and third-party software patches, which requires administrative privileges. Issues also arise when users want to install hardware. If a suitable driver isn't already available on the system, a standard user cannot add a new device driver. Many smaller businesses don't require users to adhere to a list of supported hardware, further exacerbating the problem. There are certain categories of employees, such as engineers and sales representatives, who may need to install or update software on a regular basis.
Even in a large organization, it may not be possible to deliver all such software automatically from a central distribution point. Help desks are not used to supporting Least Privilege Security as it's not the standard configuration in older versions of Windows. Along with many Windows professionals, first-level support and help desks often have little understanding of the Windows security model. To support Least Privilege Security, system administrators and help desks need to have a good understanding of basic security principles such as the Windows security model, User Account Control, and how to solve common problems related to Least Privilege Security. So, before implementing Least Privilege Security in your enterprise, you need to consider training costs for support staff.