If the Windows NT Challenge/Response authentication option is set on the Internet Service Manager configuration, the IIS will honor authenticated browser-initiated NTLM-based authentication.
We've covered this scenario in the Secure Intranet Interaction section before.
Recall that the NTLM protocol is secure in that the user's password is never transmitted over the network. This also makes the authentication significantly weaker because the server doesn't have the complete credentials of the user. It can only access local resources under impersonation with NTLM authentication.
Regardless of the authentication method you use, the appropriate permissions must be carefully set to all directories or files accessible through IIS, taking care to protect any sensitive contents. For complete safety, if IIS is to be used for disseminating public information, no sensitive data should be stored on the same machine. This is particularly important if you can't guarantee the correct behavior (from a security standpoint) of any and all extensions and scripts running on the system. Recall that IIS by default runs under the system user security context with complete access to all local resources. A badly coded server extension may accidentally allow access to local files which the requester would otherwise have no access to. However, the extension will not be able to accidentally access nonlocal resources. To prevent this from happening, an ISAPI extension must take certain steps in order to ensure that it doesn't grant requesting users more rights than they are entitled to.