With IIS, start by denying the anonymous user’s permission to read the subtree you want to protect. On a standalone server named UDELL or in a domain of the same name, that anonymous account by default is IUSR_UDELL. Normally the anonymous user can read the entire web subtree, either because you’ve granted read permission for that account or because it belongs to a group that has read permission. To revoke read permission, locate the folder you want to protect (e.g., /web/Docbase/ProductAnalysis/docs) in the Windows Explorer, do right-click → Properties → Security → Permissions, and remove the anonymous user. While you’re there, add the name of the account to which you do want to grant access. Be sure to click Replace Permissions on Subdirectories if you want to apply these changes to the whole subtree.

You also need to tell IIS that it’s OK to use basic authentication when the anonymous user’s credentials fail—as will happen now that you’ve revoked that user’s permission to read the subtree. In IIS 4, you do this in the Microsoft Management Console (MMC). Find the virtual root corresponding to the directory you want to protect—or one of its parents, if you want basic authentication to be available more broadly on this server—and do right-click → Properties → Directory Security → Anonymous Access and Authentication Control → Edit. Check the Basic Authentication box. If need be, you can use its associated Edit button to specify an authenticating domain controller instead of the default, which is the local server’s directory.

This second step—configuring IIS to use basic authentication for files that the anonymous user doesn’t have permission to read—is crucial but easy to forget. If you do forget, IIS behaves very strangely when you try to access protected pages. It prompts for credentials but accepts none—not even those of the administrator.