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?