Microsoft has released a white paper called "Applying the Principle of Least Privilege to User Accounts on Windows XP".

Need more to say? ;-)

If your app doesn't tell you why it want's admin rights like XML Spy Home Edition does, Michael Willers' PDF "Das Application Compatibility Toolkit - Dr. Watson in Sachen Adminrechten" will help you, trust me. Of course, only if you are able to read german content, sorry for that ;-)

After installing and re-registering XML Spy 2005 Home Edition I entered my new registration code. After clicking "Save Settings" I got this one:

Come on guys, I'm non-admin!

Imho it is the easiest way to debug ASP.NET 1.1 applications as non-admin using VisualStudio.NET 2003, when you're following these instructions:

Grant the following rights to your LUA (= Limited User account) for the directories listed below:

&INSTALLROOT% is of the form c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 and %WINDIR% is of the form C:\WINDOWS.

After this you have to add your LUA to the security groups 'Debugger Users' and 'VS Developers'

By default, with a restricted user login, you cannot debug Web applications because the user running the debugger is not a member of the proper group to debug other users' programs (Administrators), and the Web server started ASP.NET as the NETWORK_SERVICE account.

If you do not want to grant this login membership in the local Administrators group or run the debugger as the local Administrator, you need to change the account that ASP.NET is running as. On Windows XP Professional, edit machine.config as shown below and put in your username and password in clear text. This has the potential disadvantage of requiring all ASP.NET applications on the machine to run as your user account, but is the best method for IIS 5, and allows you to debug and build Web apps the same way you did in the past.

As an Administrator, edit the attributes of the file "%INSTALLROOT%\Config\machine.config" 'on the processModel tag, as shown:

<processModel
                enable="true"
                userName="DOMAIN\username"
                password="MyPassword"
                ...
/ >

If you do not set a restrictive ACL on the machine.config file, putting your userid and password in cleartext allows anyone to see your password. Even if you set a restrictive ACL, all users in the Administrators group will still be able to see it.

The resolution to the above security risk is the following: Use the aspnet_setreg.exe utility to put an encrypted version of the LUA's username and password in the registry by using the following command:

aspnet_setreg.exe -k:SOFTWARE\MY_SECURE_APP\processModel -u:"username" -p:"MyPassword"

Then modify the processModel as follows to point it to the registry:

<processModel
    userName="registry:HKLM\SOFTWARE\MY_SECURE_APP\processModel\ASPNET_SETREG,userName"
    password="registry:HKLM\SOFTWARE\MY_SECURE_APP\processModel\ASPNET_SETREG,password"
...... />

By default the DACL on the "HKLM\SOFTWARE\MY_SECURE_APP" hive grants Full Control to only System, Administrators and Creator Owner. Since ASP.NET is running under my userid, the caveat here is to make sure that I gave my userid (ex. "username") Read access to this registry hive where the userid and password are now stored.

My machine needed to be rebooted after modifying all these settings - so it won't by a disprofit if you do it also ;-)

This list contains software running without or with resolvable problems when running the local system as non-admin.

It is not exhaustive and will be updated from time to time.

FTP-Clients

• FileZilla 2.2.9

HTML / CSS-Editors

• Allaire / Macromedia Homesite 4.5.1 (more details)

Image Processing

• Jasc Paint Shop Pro 7.0 AE

Internet Browsers

• Microsoft Internet Explorer 6.x
• Mozilla FireFox 1.0.6

Mail and News Clients

• Microsoft Office Outlook 2003
• Microsoft Outlook Express 6.x

RSS Readers

• FeedDemon 1.5

Virus Scanners

• McAfee VirusScan 10.0.x

If you know a piece of software running as non-admin, please let me know.

To say it in a few words: replace it (ICQ 2003b Pro - why Pro???) by icq 5 (lite) or some other well-behaving instant messaging client.

ICQ Pro is a beast concerning non-admin - trust me.

I'm using Homesite since being first public beta (developed by Nick Bradbury, the creator of some really good pieces of software).

As i have been running it until now as admin, there have been no problems.

But when switching to non-admin, i got some OLE Exceptions.

When googling a little bit, i found an article at macromedia (they bought Allaire which themselves bought Homesite a few years ago from Nick B.) called "Windows 2000/NT users get an error when trying to launch HomeSite or Studio 4.5.1".

The articles describes what to do, when getting these OLE Exceptions.

One phrase in this article is "Each users that runs HomeSite or ColdFusion Studio needs Read/Write permissions to these registry keys".

This does not only mean that you need to have read and write access to the values in the keys. You also need to have the rights to read and create subkeys!

After realizing this, i got Homesite running as non-admin. Still a great tool ;-)