> As far as I know (I'm not a developer) you can put
> together a script that will prompt for a password
> anytime it is requested.

That's one way. A CGI, for example, can check the
HTTP_AUTHORIZATION header value, base64-decode it
and see if it matches. If so, it can output a page, if not
if should output 'Status: 401' and 'WWW-Authenticate:
basic realm=(something)'.

But! IIS likes to think it knows how to do everything and
will get in your way when you try to do auth yourself
like this. With CGI (not sure about others like ASP), if
you output such an error, IIS will "helpfully" send a
customised error page instead, and set the wrong
return code. So you'd have to turn off the custom error
page for 401s in Internet Services Manager first.

Also, IIS will "helpfully" hijack any incoming auth headers
and test them against the Windows user database
instead of letting you have a go at them. You will have
to go to ISM's Directory Security tab and turn off all
forms of auth that are not "anonymous access". Again,
some webapp environments may get around this so
you don't have to change the settings, but I don't think
this happens in ASP.

> Setting NTFS permissions for web access gets pretty ugly.

Yes. IIS's authentication features are all based on the user
database of the local box/domain. Which is of course
utterly useless for 99.9% of all web sites. Another great
"integration" feature, there.

There are plugins you can get for IIS to make it do
something less wrongheaded with authentication, ie. work
more like Apache. But even Apache gets in your way by
refusing to let you see submitted passwords in standard
CGI until you recompile it defining the flag
-DSECURITY_HOLE_PASS_AUTHORIZATION. For many setups
(eg. non-multi-user-server, embedded CGI interpreter) this
is not a security hole at all, and having to do a recompile
just to turn the option on is a big pain in the bum.
and@doxdesk.com