An alternate suggestion for Core Reason:
Use a message queue or similar concept to shuttle the information about services to start/stop back and forth between different security contexts instead of trying to hardwire those things together under ASP.NET.
For example,
Under your ASP.NET non-administrator account, write some values to file or registry (a log of some kind) that contain information about what services to stop or start.
Your controller service running as a true admin polls the written data location and when it sees info, follows those commands to start and stop the appropriate services.
You get around the problem with a workaround instead of a security hack, or instead of disabling UAC altogether.
Update for monitoring:
- Same idea as above but somewhat reversed - the main/controller service for this scenario that runs on the system writes to a log file. It s the service that writes about other services.
- Put an auto-refresh on the web page. Each time your webpage refreshes it watches that log for changes = info about services that have stopped or started (can keep its own scratch file for change detection). The refresh might be a META Refresh tag, or an AJAX callback to the server (more subtle).
- Web page issues instructions as before.
The problem is if that main/controller service stops and nothing gets reported (logs/messages stop being passed). Make a special case for that one service, if you can, by telling Windows to restart it if it stops, or to reboot the machine if it can t start that service ...
.. By the way, have you looked into Windows tools to automatically watch services and restart them on failure, instead of using a web page monitor, or is that not feasible for your requirements?