When running with static files the security token is passed along.
Under a good, locked-down server configuration, each website runs inside its own Application Pool. The Application Pool then runs under the credentials of a user account specifically for that application pool. FastCGI processes then inherit the credentials of that pool when they're created.
When using ASP.NET, normal ISAPIs, or static files you can use NTFS ACLs to great effect. You can deny access to the pool's user account for resources so that visitors are required to login using their Active Directory credentials (assuming they have an AD account to begin with). IIS then passes these credentials on to the static file handler so it can service the request and not get denied by NTFS.
Example: There is an IIS website "Foo.com" which runs under the application pool "Foo.com-Pool" which runs under an Active Directory user "Foo.com-User". "Foo.com-User" has Read access only to the site's files.
The webmaster wants to make a subdirectory inaccessible to public visitors, so it denies access to "Foo.com-User", but another AD user for a real person can still access it since he still has "Allow" rights to it.
...but IIS doesn't pass the credentials on. It only works for static files and not anything done via ISAPI, which includes FastCGI (and consequently, any FastCGI executables).
Whilst you can get the same effect by denying Anonymous access from within IISAdmin, I find the NTFS ACL-only approach more elegant (and more like Apache's .htaccess ). Are there any workarounds or solutions for this?