"David Wang" wrote:

> When I see weird and erratic behavior, my first question is "do you
> have custom ISAPI Filter installed on the server". Both global as well
> as per-site.
>
> The password dialog is supposed to appear for Basic authentication
> *unless* the client is allowed to auto-login with Basic. That's not
> allowed by default for security reasons. You hardly want the browser
> to automatically hand over your login password to ANY website which
> asks for it, right?
>
> Thinking more esoterically now -- what are the login rights assigned
> to your test user. IIS uses a specific login type (configurable), so
> ability to login via remote desktop is insufficient proof that IIS can
> login that user. See this URL for more info:
> http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/cf438d2c-f9c7-4351-bf56-d2ab950d7d6e.mspx?mfr=true
>
> Usually the defaults when you just create a user via NET USER name
> password /ADD will suffice, but sometimes Group Policies of a domain
> can alter this behavior (even if you've unjoined this machine from a
> domain).
>
> Are you sure you don't have a proxy or network policy/device which is
> simply forbidding Basic authentication altogether (because it exposes
> the user's password)? For example, it'd be really easy for such a
> proxy or network device (or even ISAPI Filter...) to simply strip off
> the Authorization: Basic header being sent with your requests, at
> which point since you don't have Anonymous enabled, IIS will return
> 401.2 EVEN THOUGH you have basic auth enabled -- because to IIS, your
> request has been stripped to an anonymous by removing the
> Authorization: Basic header. You can test this theory by temporarily
> enabling Anonymous and Basic authentication and ACL'ing files to allow
> access to the IUSR.
>
> > working with fails if the initial challenge isn't basic authentication and(as
> > I understand it, and please correct if this is wrong) IIS will try integrated
> > first and basic second if both are enabled.
>
> Not exactly. IIS only advertises to the HTTP Browser the
> authentication protocol it requires with a certain ordering. It is the
> HTTP Browser which determines which authentication protocol to use. IE
> will choose Integrated before Basic if both are enabled.
>
> Brief explanation of what's going on here:
>
> HTTP, like many network protocols, is a give-and-take sort of
> protocol. When it comes to authentication, you can only configure the
> server to REQUIRE certain authentication protocols to get access to
> secured resources. If an HTTP browser requests the secured resource
> without using the required authentication protocol, the server simply
> responds 401.2 with a list of required protocols.
>
> At this point, the browser can either choose to ignore the server's
> suggestion (not wise), choose an authentication protocol to negotiate
> (and pop up the login dialog as necessary by security/Internet Zone
> settings), or auto-login with some credentials in a proprietary
> algorithm. Now, since the browser is attempting to authenticate with a
> requested authentication protocol, the server either replies:
> - 401.1 if the username/password is incorrect
> - 401.3 if the credentials are alright but the NTFS ACLs deny the
> authenticated credentials access to the secured resource
> - 401.4/401.5 if the credentials are alright but an ISAPI Filter/ISAPI
> Extension denied access for arbitrary reason
> - Anything else indicates the credentials are alright and action
> according to HTTP status code was performed on the server
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
>
>
> On Oct 26, 1:23 am, Jude Fisher <JudeFis...@discussions.microsoft.com>
> wrote:
> > Roger,
> >
> > Yes, to restate the setup is as follows:
> >
> > Test directory with simple static test page in it.
> >
> > On the IIS directory security tab, anonymous access is disabled, digest
> > authentication is disabled, integrated authentication is disabled and basic
> > authentication only is enabled. The two text boxes at the bottom (domain and
> > realm) are empty.
> >
> > On the windows explorer security dialog for the folder, the test user
> > account created has full permissions for the folder and the file that's in it.
> >
> > I've tested that the user account can log on through remote desktop
> > connection and once logged on can open that directory and file using windows
> > explorer, so the NTFS permissions seem to be OK.
> >
> > I then try to access the static page using internet explorer (either from my
> > remote machine or on the server via remote desktop). I've also tested with
> > firefox and safari. In all cases I get the same result. A windows security
> > dialog box pops up. I've tried entering every combination of
> > COMPUTERNAME\USER I can think of, prepending the workgroup (this computer
> > isn't part of a domain) instead of the computername etc. The dialog box just
> > pops up again and after a few attempts the page refreshes to a 401.2 error.
> > This behaviour is consistent if I use the administrator account for the
> > machine or any other account,
> >
> > With both success and failure logging enabled I see nothing related to this
> > log in attempt in the security event log.
> >
> > If I go back into the IIS directory security tab and enable integrated
> > security either instead of or in addition to basic authentication, then
> > refresh the browser, then the log in attempted works at the first time of
> > asking. This won't do for my purposes because the external provider we're
> > working with fails if the initial challenge isn't basic authentication and(as
> > I understand it, and please correct if this is wrong) IIS will try integrated
> > first and basic second if both are enabled.
> >
> > I have tried this twice now with separate directories, starting from
> > creating the directory and step by step enabling and disabling all the
> > different settings and everything appears to work exactly as you expect it
> > would until I set directory security to use basic authentication only, and
> > then everything breaks.
> >
> > Thanks again for your time in looking into this. I'm afraid I expect it
> > eventually to be something dumb and simple that I've missed - just hoping to
> > get to the bottom of it while I still have some hair left.
> >