We include a copy of admin.aspx as part of the standard installation for our vertical market app, which we've now deployed on close to 200 customer sites. In some cases the customer gives us access to their server, but often we rely on their staff to handle the configuration. The upshot is that, even though we ask them (sometimes repeatedly) to secure the admin page, there are sites where you can open the page without providing credentials.
Our backup strategy has been to at least ensure that they have a value in their AdminAccount setting (if nothing else, we'll use the Edit Config option to set it to Any). That way, if an unauthenicated user does run the Admin page, they'll get the secondary login prompt if they try to hit any of the links.
The exceptions are the Kill options that show up in the process list at the bottom of the page. It appears that any anonymous user can click a Kill link and stop the corresponding process without providing any authentication. That action appears to be handled by the aspx code in response to a ProcessID querystring parameter - could that code be modified so it only proceeds if the user is not authenticated?
I realize the preferred solution is to add the proper page security, but as I said, that's not always something we can control.
--stein
Recent versions of Admin.aspx will not open if the user is not logged in on any non-local IP address. So you have to be logged in.
The Web Connection Admin links are locked down by default with AdminAccount=ANY
which requires some sort of login. You can override this by leaving the value completely blank, but that's a setting that has to be explicitly made.
+++ Rick ---
A lot of our customers probably haven't upgraded the admin page since the switch from admin.asp to .aspx. Will try to get them on a current version which should resolve this issue.
We always set AdminAccount=Any unless they specify a specific service account to use. That provides a security backup for cases where they are running older admin pages without restricting the permissions, but the AdminAccount setting does not apply to the Kill Process links.
--stein