{"id":586,"date":"2006-05-13T12:54:00","date_gmt":"2006-05-13T12:54:00","guid":{"rendered":"http:\/\/markwilson.me.uk\/blog\/2006\/05\/using-unprivileged-accounts-in-windows.htm"},"modified":"2007-03-09T14:03:11","modified_gmt":"2007-03-09T14:03:11","slug":"using-unprivileged-accounts-in-windows","status":"publish","type":"post","link":"https:\/\/www.markwilson.co.uk\/blog\/2006\/05\/using-unprivileged-accounts-in-windows.htm","title":{"rendered":"Using unprivileged accounts in Windows"},"content":{"rendered":"

A few weeks back, Microsoft UK’s Steve Lamb<\/a> presented a session on using the principle of least privileged access to reduce exposure to security threats under Windows (basically, running as much as possible as a standard, non-administrative user). Unfortunately I missed the event but I was chatting with Steve last week and he filled me in on the basic principles (which I’ve padded out with a few notes from his slidedeck).<\/p>\n

The runas<\/code> command can be used to start a program as a different user (as programs inherit their permissions from the parent process, starting a cmd shell as an Administrator and then launching an application will launch that application as an Administrator. Within the Windows GUI, there is often a right click option for runas<\/code>, although for control panel applets shift and right click is used to expose the runas<\/code> option. Shortcuts can be modified to run with different credentials for applications that always require a higher level of access.<\/p>\n

There are occasions when runas<\/code> just doesn’t work – for example applications that reuse existing instances (Windows Explorer, Microsoft Word) or those that are started through the shell using the ShellExecute() API call or dynamic data exchange (DDE). Unfortunately Microsoft Update is one of those applications for which runas<\/code> won’t work. Aaron Margosis has some advice on his blog to help work around issues with runas and Windows Explorer<\/a>.<\/p>\n

Privileged command shell windows can be set apart using a different colour scheme, for example:<\/p>\n

cmd.exe \/t:cf \/k title Administration Shell<\/code><\/p>\n

For the GUI, the TweakUI power toy<\/a> can be used to set an alternative bitmap for Internet Explorer and Windows Explorer, or <\/span>Aaron Margosis’ PrivBar<\/a> displays the current privilege level.<\/p>\n

Whilst it’s true that using a local account will prevent domain-wide issues, there are side effects in that there is no access to domain resources, different profile settings (and per-user policy settings) are in effect and some applications assume that the installer is the end user. One possible resolution is Aaron Margosis<\/a>‘ MakeMeAdmin tool which allows for temporary elevation of the current account’s privileges (and any applications which inherit the user context. MakeMeAdmin can be downloaded from Aaron’s blog<\/a> and he has a later follow-up post with more information<\/a>.<\/p>\n

Some applications are written to run as Administrator and there’s not a lot that an end user can do about poor coding (other than replacing the application with something else). Adding the user to the local Administrators group to resolve such issues is not good practice, although it may be possible to loosen the ACLs on application-specific resources (i.e. %ProgramFiles%\\applicationname<\/span>\\ and HKEY_LOCAL_MACHINE\\SOFTWARE\\applicationname<\/span>\\Settings) but this should not be carried on operating system resources (e.g. %windir%, %windir%\\System32 and
\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows). The important thing to remember is to do this in a granular fashion, applying additional permissions only to those resources to which access is required.<\/p>\n

If an application writes to HKEY_CLASSES_ROOT, then it’s usually a bug. HKEY_CLASSES_ROOT is a merged view of HKEY_LOCAL_MACHINE\\SOFTWARE\\Classes and HKEY_CURRENT_USER\\SOFTWARE\\Classes so writing to HKEY_CLASSES_ROOT effectively goes to HKEY_CURRENT_USER if the key already exists. Consequently, problems with HKEY_CLASSES_ROOT can often be overcome by pre-creating keys under HKEY_CURRENT_USER.<\/p>\n

If all else fails, utilities such as MakeMeAdmin can be used to allow an application to run with elevated privileges but they require the user to know the Administrator password – alternatives include Valery Pryamikov<\/a>‘s RunAsAdmin<\/a> and DesktopStandard PolicyMaker Application Security<\/a>.<\/p>\n

In Windows Vista, everything changes again with new functionality known as user access control (also known by other names including user access protection and flexible account control technologies):<\/p>\n