Basic Authentication fails with Error 401.2 where Integrated succe

Hi,

I'm a developer rather than a server tech and I've run into some problems
configuring a website.

An external provider we're using requires that a specific script be in a
directory that is protected by Basic Authentication. This isn't something
I've had to do before so I've been stumbling along following the KB
instructions. I've set up a test directory but I can't seem to get
authentication working properly. Here are the details:

I'm running IIS 6 on Windows Server 2003 with Asp.Net 1.1 and 2.0 both
installed.

The directory is configured with regular read priveleges, no scripts or
executables for the moment. The page inside the directory that I am using for
testing is just a plain html page with one line of text in it.

The directory is configured in IIS with only Basic Authentication checked
(Anonymous access, digest and integrated access are all cleared) and the
domain and realm fields are empty.

I have a limted access account I want to use for this but for testing I've
also tried my administrator account, which has priveleges to the folder and
also local log on priveleges for the machine. Problems are consistent
whichever account is used.

The error occurs whether I'm connecting remotely or (through remote desktop)
via localhost, which should rule out any proxies.

The error returned is HTTP Error 401.2 - Unauthorized: Access is denied due
to server configuration.

*IMPORTANT* (I'm hoping this points directly to the problem!) - If I check
the integrated authentication box in the IIS security configuration, suddenly
the log in works. If I clear it so only basic is checked, it breaks again.

Thanks in advance for any assistance.

Re: Basic Authentication fails with Error 401.2 where Integrated succe

Have you looked into the security event log, assuming that it
is configured to record login failures?
You will probably see a unknown account or bad password
event message, indicating the account that the domain.
This last is probably not correct if the login attempt did not
use domain\account syntax in the login attempt, where domain
might need to be the local machine name of the webserver if
domain account is not in use.


"Jude Fisher" wrote in message
news:6CF2177C-D68E-46CD-A95D-1FF4D51BC8C0@microsoft.com...
> Hi,
>
> I'm a developer rather than a server tech and I've run into some problems
> configuring a website.
>
> An external provider we're using requires that a specific script be in a
> directory that is protected by Basic Authentication. This isn't something
> I've had to do before so I've been stumbling along following the KB
> instructions. I've set up a test directory but I can't seem to get
> authentication working properly. Here are the details:
>
> I'm running IIS 6 on Windows Server 2003 with Asp.Net 1.1 and 2.0 both
> installed.
>
> The directory is configured with regular read priveleges, no scripts or
> executables for the moment. The page inside the directory that I am using
> for
> testing is just a plain html page with one line of text in it.
>
> The directory is configured in IIS with only Basic Authentication checked
> (Anonymous access, digest and integrated access are all cleared) and the
> domain and realm fields are empty.
>
> I have a limted access account I want to use for this but for testing I've
> also tried my administrator account, which has priveleges to the folder
> and
> also local log on priveleges for the machine. Problems are consistent
> whichever account is used.
>
> The error occurs whether I'm connecting remotely or (through remote
> desktop)
> via localhost, which should rule out any proxies.
>
> The error returned is HTTP Error 401.2 - Unauthorized: Access is denied
> due
> to server configuration.
>
> *IMPORTANT* (I'm hoping this points directly to the problem!) - If I check
> the integrated authentication box in the IIS security configuration,
> suddenly
> the log in works. If I clear it so only basic is checked, it breaks again.
>
> Thanks in advance for any assistance.
>
>

Re: Basic Authentication fails with Error 401.2 where Integrated s

Roger,

Thanks for replying.

The event log doesn't appear to be recording failures. How would I turn that
on?

Thanks again.

Jude Fisher

"Roger Abell [MVP]" wrote:

> Have you looked into the security event log, assuming that it
> is configured to record login failures?
> You will probably see a unknown account or bad password
> event message, indicating the account that the domain.
> This last is probably not correct if the login attempt did not
> use domain\account syntax in the login attempt, where domain
> might need to be the local machine name of the webserver if
> domain account is not in use.
>
>
> "Jude Fisher" wrote in message
> news:6CF2177C-D68E-46CD-A95D-1FF4D51BC8C0@microsoft.com...
> > Hi,
> >
> > I'm a developer rather than a server tech and I've run into some problems
> > configuring a website.
> >
> > An external provider we're using requires that a specific script be in a
> > directory that is protected by Basic Authentication. This isn't something
> > I've had to do before so I've been stumbling along following the KB
> > instructions. I've set up a test directory but I can't seem to get
> > authentication working properly. Here are the details:
> >
> > I'm running IIS 6 on Windows Server 2003 with Asp.Net 1.1 and 2.0 both
> > installed.
> >
> > The directory is configured with regular read priveleges, no scripts or
> > executables for the moment. The page inside the directory that I am using
> > for
> > testing is just a plain html page with one line of text in it.
> >
> > The directory is configured in IIS with only Basic Authentication checked
> > (Anonymous access, digest and integrated access are all cleared) and the
> > domain and realm fields are empty.
> >
> > I have a limted access account I want to use for this but for testing I've
> > also tried my administrator account, which has priveleges to the folder
> > and
> > also local log on priveleges for the machine. Problems are consistent
> > whichever account is used.
> >
> > The error occurs whether I'm connecting remotely or (through remote
> > desktop)
> > via localhost, which should rule out any proxies.
> >
> > The error returned is HTTP Error 401.2 - Unauthorized: Access is denied
> > due
> > to server configuration.
> >
> > *IMPORTANT* (I'm hoping this points directly to the problem!) - If I check
> > the integrated authentication box in the IIS security configuration,
> > suddenly
> > the log in works. If I clear it so only basic is checked, it breaks again.
> >
> > Thanks in advance for any assistance.
> >
> >
>
>
>

Re: Basic Authentication fails with Error 401.2 where Integrated s

How are you trying to log in? With domain\account when
using a domain account ?? The auditing settings are in the
Local Security Policy which you will find in Administrative
Tools (though domain policy may be controlling).

"Jude Fisher" wrote in message
news:E1E3B299-F273-44FF-B61E-7DAC0CEF25AB@microsoft.com...
> Roger,
>
> Thanks for replying.
>
> The event log doesn't appear to be recording failures. How would I turn
> that
> on?
>
> Thanks again.
>
> Jude Fisher
>
> "Roger Abell [MVP]" wrote:
>
>> Have you looked into the security event log, assuming that it
>> is configured to record login failures?
>> You will probably see a unknown account or bad password
>> event message, indicating the account that the domain.
>> This last is probably not correct if the login attempt did not
>> use domain\account syntax in the login attempt, where domain
>> might need to be the local machine name of the webserver if
>> domain account is not in use.
>>
>>
>> "Jude Fisher" wrote in message
>> news:6CF2177C-D68E-46CD-A95D-1FF4D51BC8C0@microsoft.com...
>> > Hi,
>> >
>> > I'm a developer rather than a server tech and I've run into some
>> > problems
>> > configuring a website.
>> >
>> > An external provider we're using requires that a specific script be in
>> > a
>> > directory that is protected by Basic Authentication. This isn't
>> > something
>> > I've had to do before so I've been stumbling along following the KB
>> > instructions. I've set up a test directory but I can't seem to get
>> > authentication working properly. Here are the details:
>> >
>> > I'm running IIS 6 on Windows Server 2003 with Asp.Net 1.1 and 2.0 both
>> > installed.
>> >
>> > The directory is configured with regular read priveleges, no scripts or
>> > executables for the moment. The page inside the directory that I am
>> > using
>> > for
>> > testing is just a plain html page with one line of text in it.
>> >
>> > The directory is configured in IIS with only Basic Authentication
>> > checked
>> > (Anonymous access, digest and integrated access are all cleared) and
>> > the
>> > domain and realm fields are empty.
>> >
>> > I have a limted access account I want to use for this but for testing
>> > I've
>> > also tried my administrator account, which has priveleges to the folder
>> > and
>> > also local log on priveleges for the machine. Problems are consistent
>> > whichever account is used.
>> >
>> > The error occurs whether I'm connecting remotely or (through remote
>> > desktop)
>> > via localhost, which should rule out any proxies.
>> >
>> > The error returned is HTTP Error 401.2 - Unauthorized: Access is denied
>> > due
>> > to server configuration.
>> >
>> > *IMPORTANT* (I'm hoping this points directly to the problem!) - If I
>> > check
>> > the integrated authentication box in the IIS security configuration,
>> > suddenly
>> > the log in works. If I clear it so only basic is checked, it breaks
>> > again.
>> >
>> > Thanks in advance for any assistance.
>> >
>> >
>>
>>
>>

Re: Basic Authentication fails with Error 401.2 where Integrated succe

On Oct 24, 1:45 am, Jude Fisher
wrote:
> Hi,
>
> I'm a developer rather than a server tech and I've run into some problems
> configuring a website.
>
> An external provider we're using requires that a specific script be in a
> directory that is protected by Basic Authentication. This isn't something
> I've had to do before so I've been stumbling along following the KB
> instructions. I've set up a test directory but I can't seem to get
> authentication working properly. Here are the details:
>
> I'm running IIS 6 on Windows Server 2003 with Asp.Net 1.1 and 2.0 both
> installed.
>
> The directory is configured with regular read priveleges, no scripts or
> executables for the moment. The page inside the directory that I am using for
> testing is just a plain html page with one line of text in it.
>
> The directory is configured in IIS with only Basic Authentication checked
> (Anonymous access, digest and integrated access are all cleared) and the
> domain and realm fields are empty.
>
> I have a limted access account I want to use for this but for testing I've
> also tried my administrator account, which has priveleges to the folder and
> also local log on priveleges for the machine. Problems are consistent
> whichever account is used.
>
> The error occurs whether I'm connecting remotely or (through remote desktop)
> via localhost, which should rule out any proxies.
>
> The error returned is HTTP Error 401.2 - Unauthorized: Access is denied due
> to server configuration.
>
> *IMPORTANT* (I'm hoping this points directly to the problem!) - If I check
> the integrated authentication box in the IIS security configuration, suddenly
> the log in works. If I clear it so only basic is checked, it breaks again.
>
> Thanks in advance for any assistance.



Yes, your last detail points directly to the problem.

Here is the meaning of 401.2 and how to troubleshoot it:
http://blogs.msdn.com/david.wang/archive/2005/07/14/HOWTO_Di agnose_IIS_401_Access_Denied.aspx

Basically, you have said that enabling Integrated Authentication makes
401.2 go away, which tells me that the client is using Integrated
Authentication and NOT Basic Authentication.

If the external provider is using basic authentication against your
IIS configuration, then IIS will NOT return 401.2 given your stated
configuration. Meanwhile, if the client is using Integrated
authentication, IIS will return 401.2 UNTIL Integrated Authentication
is enabled.

The latter is exactly what you observed.

This issue has nothing to do with the user account used (you've
verified), and you've thankfully eliminated proxying as a source of
altering authentication schemes.

I suggest you go back to your external provider for them to clarify
their requirements because they are not doing what they say. Either
they change to require Integrated Auth, or they change their code to
actually use Basic auth.



//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Re: Basic Authentication fails with Error 401.2 where Integrated s

David,

Thanks for your detailed answer.

Can you tell me why I can't log in when I try to test the page through a web
browser? Would the browser for some reason be trying to use integrated
security?

Thanks again.

Jude Fisher

"David Wang" wrote:

> On Oct 24, 1:45 am, Jude Fisher
> wrote:
> > Hi,
> >
> > I'm a developer rather than a server tech and I've run into some problems
> > configuring a website.
> >
> > An external provider we're using requires that a specific script be in a
> > directory that is protected by Basic Authentication. This isn't something
> > I've had to do before so I've been stumbling along following the KB
> > instructions. I've set up a test directory but I can't seem to get
> > authentication working properly. Here are the details:
> >
> > I'm running IIS 6 on Windows Server 2003 with Asp.Net 1.1 and 2.0 both
> > installed.
> >
> > The directory is configured with regular read priveleges, no scripts or
> > executables for the moment. The page inside the directory that I am using for
> > testing is just a plain html page with one line of text in it.
> >
> > The directory is configured in IIS with only Basic Authentication checked
> > (Anonymous access, digest and integrated access are all cleared) and the
> > domain and realm fields are empty.
> >
> > I have a limted access account I want to use for this but for testing I've
> > also tried my administrator account, which has priveleges to the folder and
> > also local log on priveleges for the machine. Problems are consistent
> > whichever account is used.
> >
> > The error occurs whether I'm connecting remotely or (through remote desktop)
> > via localhost, which should rule out any proxies.
> >
> > The error returned is HTTP Error 401.2 - Unauthorized: Access is denied due
> > to server configuration.
> >
> > *IMPORTANT* (I'm hoping this points directly to the problem!) - If I check
> > the integrated authentication box in the IIS security configuration, suddenly
> > the log in works. If I clear it so only basic is checked, it breaks again.
> >
> > Thanks in advance for any assistance.
>
>
>
> Yes, your last detail points directly to the problem.
>
> Here is the meaning of 401.2 and how to troubleshoot it:
> http://blogs.msdn.com/david.wang/archive/2005/07/14/HOWTO_Di agnose_IIS_401_Access_Denied.aspx
>
> Basically, you have said that enabling Integrated Authentication makes
> 401.2 go away, which tells me that the client is using Integrated
> Authentication and NOT Basic Authentication.
>
> If the external provider is using basic authentication against your
> IIS configuration, then IIS will NOT return 401.2 given your stated
> configuration. Meanwhile, if the client is using Integrated
> authentication, IIS will return 401.2 UNTIL Integrated Authentication
> is enabled.
>
> The latter is exactly what you observed.
>
> This issue has nothing to do with the user account used (you've
> verified), and you've thankfully eliminated proxying as a source of
> altering authentication schemes.
>
> I suggest you go back to your external provider for them to clarify
> their requirements because they are not doing what they say. Either
> they change to require Integrated Auth, or they change their code to
> actually use Basic auth.
>
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>

Re: Basic Authentication fails with Error 401.2 where Integrated s

Roger,

I've set up the test directory as described in my first post. I'm then
trying to access the page (http://localhost/test/test.html) through internet
explorer. I get a windows log in box as a prompt. As you can imagine, I've
tried every possible combination of things but I'm mostly trying with
COMPUTERNAME\USER and the password. The password is for the moment set to
something absurdly simple so I'm sure it's not a problem with that.

I've enabled failure logging and tested a regular remote desktop log in to
verify the failure is being recorded (it is). When I attempt to access the
directory above, however, I don't get a failure audit. I don't get any event
at all for the user I'm trying to log in with. What I do get is a success
audit for the IUSR account (even though anonymous access is turned off and I
am denied access to the page I'm trying to get to). Some details from that
success audit:

User Name: IUSR_XXXXXXXXXXXXXXXX
Domain: XXXXXXXXXXXXXXXX
Logon ID: XXXXXXXXXXXXXXXX
Logon Type: 8
Logon Process: Advapi
Authentication Package: Negotiate
Workstation Name: XXXXXXXXXXXXXXXX
Logon GUID: -
Caller User Name: NETWORK SERVICE
Caller Domain: NT AUTHORITY
Caller Logon ID: XXXXXXXXXXXXXXXX
Caller Process ID: 184
Transited Services: -
Source Network Address: -
Source Port: -

I actually get two (identical) success audits for this account, and a
success audit for the NETWORK_SERVICE account, but it is as if the attempt to
log in through the username/password box just never happened.

Not sure if any of that is useful but any help would be appreciated.

Thanks for your time so far.

Jude Fisher



"Roger Abell [MVP]" wrote:

> How are you trying to log in? With domain\account when
> using a domain account ?? The auditing settings are in the
> Local Security Policy which you will find in Administrative
> Tools (though domain policy may be controlling).
>
> "Jude Fisher" wrote in message
> news:E1E3B299-F273-44FF-B61E-7DAC0CEF25AB@microsoft.com...
> > Roger,
> >
> > Thanks for replying.
> >
> > The event log doesn't appear to be recording failures. How would I turn
> > that
> > on?
> >
> > Thanks again.
> >
> > Jude Fisher
> >
> > "Roger Abell [MVP]" wrote:
> >
> >> Have you looked into the security event log, assuming that it
> >> is configured to record login failures?
> >> You will probably see a unknown account or bad password
> >> event message, indicating the account that the domain.
> >> This last is probably not correct if the login attempt did not
> >> use domain\account syntax in the login attempt, where domain
> >> might need to be the local machine name of the webserver if
> >> domain account is not in use.
> >>
> >>
> >> "Jude Fisher" wrote in message
> >> news:6CF2177C-D68E-46CD-A95D-1FF4D51BC8C0@microsoft.com...
> >> > Hi,
> >> >
> >> > I'm a developer rather than a server tech and I've run into some
> >> > problems
> >> > configuring a website.
> >> >
> >> > An external provider we're using requires that a specific script be in
> >> > a
> >> > directory that is protected by Basic Authentication. This isn't
> >> > something
> >> > I've had to do before so I've been stumbling along following the KB
> >> > instructions. I've set up a test directory but I can't seem to get
> >> > authentication working properly. Here are the details:
> >> >
> >> > I'm running IIS 6 on Windows Server 2003 with Asp.Net 1.1 and 2.0 both
> >> > installed.
> >> >
> >> > The directory is configured with regular read priveleges, no scripts or
> >> > executables for the moment. The page inside the directory that I am
> >> > using
> >> > for
> >> > testing is just a plain html page with one line of text in it.
> >> >
> >> > The directory is configured in IIS with only Basic Authentication
> >> > checked
> >> > (Anonymous access, digest and integrated access are all cleared) and
> >> > the
> >> > domain and realm fields are empty.
> >> >
> >> > I have a limted access account I want to use for this but for testing
> >> > I've
> >> > also tried my administrator account, which has priveleges to the folder
> >> > and
> >> > also local log on priveleges for the machine. Problems are consistent
> >> > whichever account is used.
> >> >
> >> > The error occurs whether I'm connecting remotely or (through remote
> >> > desktop)
> >> > via localhost, which should rule out any proxies.
> >> >
> >> > The error returned is HTTP Error 401.2 - Unauthorized: Access is denied
> >> > due
> >> > to server configuration.
> >> >
> >> > *IMPORTANT* (I'm hoping this points directly to the problem!) - If I
> >> > check
> >> > the integrated authentication box in the IIS security configuration,
> >> > suddenly
> >> > the log in works. If I clear it so only basic is checked, it breaks
> >> > again.
> >> >
> >> > Thanks in advance for any assistance.
> >> >
> >> >
> >>
> >>
> >>
>
>
>

Re: Basic Authentication fails with Error 401.2 where Integrated s

OK. So I am assuming that your test.html is simple static html
that does not involve this vendors parts. I am also assuming
that when you set up /test you did set the NTFS permissions
directly or via IIS so that the account you are testing with does
have read. The logins you see for IUsr_ and Network Service
are likely from spinning up IIS backside support on first hits
on the /test site, and your not seeing login failure messages
most likely means that the login was successful. If permissions
on /test/test.html do not allow access by your authenticated test
user account then IIS will reprompt for an account that does.
Could that be what is happening? Likely not as you have said
that all works if you enable integrated authentication, with the
precise same test setup, right?
Let us know if above assumptions are correct, OK? We can
then look at what is left, if we can figure what it is.

Roger


"Jude Fisher" wrote in message
news:7B8342C2-2804-4B57-ACE2-457352396425@microsoft.com...
> Roger,
>
> I've set up the test directory as described in my first post. I'm then
> trying to access the page (http://localhost/test/test.html) through
> internet
> explorer. I get a windows log in box as a prompt. As you can imagine, I've
> tried every possible combination of things but I'm mostly trying with
> COMPUTERNAME\USER and the password. The password is for the moment set to
> something absurdly simple so I'm sure it's not a problem with that.
>
> I've enabled failure logging and tested a regular remote desktop log in to
> verify the failure is being recorded (it is). When I attempt to access the
> directory above, however, I don't get a failure audit. I don't get any
> event
> at all for the user I'm trying to log in with. What I do get is a success
> audit for the IUSR account (even though anonymous access is turned off and
> I
> am denied access to the page I'm trying to get to). Some details from that
> success audit:
>
> User Name: IUSR_XXXXXXXXXXXXXXXX
> Domain: XXXXXXXXXXXXXXXX
> Logon ID: XXXXXXXXXXXXXXXX
> Logon Type: 8
> Logon Process: Advapi
> Authentication Package: Negotiate
> Workstation Name: XXXXXXXXXXXXXXXX
> Logon GUID: -
> Caller User Name: NETWORK SERVICE
> Caller Domain: NT AUTHORITY
> Caller Logon ID: XXXXXXXXXXXXXXXX
> Caller Process ID: 184
> Transited Services: -
> Source Network Address: -
> Source Port: -
>
> I actually get two (identical) success audits for this account, and a
> success audit for the NETWORK_SERVICE account, but it is as if the attempt
> to
> log in through the username/password box just never happened.
>
> Not sure if any of that is useful but any help would be appreciated.
>
> Thanks for your time so far.
>
> Jude Fisher
>
>
>
> "Roger Abell [MVP]" wrote:
>
>> How are you trying to log in? With domain\account when
>> using a domain account ?? The auditing settings are in the
>> Local Security Policy which you will find in Administrative
>> Tools (though domain policy may be controlling).
>>
>> "Jude Fisher" wrote in message
>> news:E1E3B299-F273-44FF-B61E-7DAC0CEF25AB@microsoft.com...
>> > Roger,
>> >
>> > Thanks for replying.
>> >
>> > The event log doesn't appear to be recording failures. How would I turn
>> > that
>> > on?
>> >
>> > Thanks again.
>> >
>> > Jude Fisher
>> >
>> > "Roger Abell [MVP]" wrote:
>> >
>> >> Have you looked into the security event log, assuming that it
>> >> is configured to record login failures?
>> >> You will probably see a unknown account or bad password
>> >> event message, indicating the account that the domain.
>> >> This last is probably not correct if the login attempt did not
>> >> use domain\account syntax in the login attempt, where domain
>> >> might need to be the local machine name of the webserver if
>> >> domain account is not in use.
>> >>
>> >>
>> >> "Jude Fisher" wrote in message
>> >> news:6CF2177C-D68E-46CD-A95D-1FF4D51BC8C0@microsoft.com...
>> >> > Hi,
>> >> >
>> >> > I'm a developer rather than a server tech and I've run into some
>> >> > problems
>> >> > configuring a website.
>> >> >
>> >> > An external provider we're using requires that a specific script be
>> >> > in
>> >> > a
>> >> > directory that is protected by Basic Authentication. This isn't
>> >> > something
>> >> > I've had to do before so I've been stumbling along following the KB
>> >> > instructions. I've set up a test directory but I can't seem to get
>> >> > authentication working properly. Here are the details:
>> >> >
>> >> > I'm running IIS 6 on Windows Server 2003 with Asp.Net 1.1 and 2.0
>> >> > both
>> >> > installed.
>> >> >
>> >> > The directory is configured with regular read priveleges, no scripts
>> >> > or
>> >> > executables for the moment. The page inside the directory that I am
>> >> > using
>> >> > for
>> >> > testing is just a plain html page with one line of text in it.
>> >> >
>> >> > The directory is configured in IIS with only Basic Authentication
>> >> > checked
>> >> > (Anonymous access, digest and integrated access are all cleared) and
>> >> > the
>> >> > domain and realm fields are empty.
>> >> >
>> >> > I have a limted access account I want to use for this but for
>> >> > testing
>> >> > I've
>> >> > also tried my administrator account, which has priveleges to the
>> >> > folder
>> >> > and
>> >> > also local log on priveleges for the machine. Problems are
>> >> > consistent
>> >> > whichever account is used.
>> >> >
>> >> > The error occurs whether I'm connecting remotely or (through remote
>> >> > desktop)
>> >> > via localhost, which should rule out any proxies.
>> >> >
>> >> > The error returned is HTTP Error 401.2 - Unauthorized: Access is
>> >> > denied
>> >> > due
>> >> > to server configuration.
>> >> >
>> >> > *IMPORTANT* (I'm hoping this points directly to the problem!) - If I
>> >> > check
>> >> > the integrated authentication box in the IIS security configuration,
>> >> > suddenly
>> >> > the log in works. If I clear it so only basic is checked, it breaks
>> >> > again.
>> >> >
>> >> > Thanks in advance for any assistance.
>> >> >
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>

Re: Basic Authentication fails with Error 401.2 where Integrated s

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.

Jude Fisher / JcFx

"Roger Abell [MVP]" wrote:

> OK. So I am assuming that your test.html is simple static html
> that does not involve this vendors parts. I am also assuming
> that when you set up /test you did set the NTFS permissions
> directly or via IIS so that the account you are testing with does
> have read. The logins you see for IUsr_ and Network Service
> are likely from spinning up IIS backside support on first hits
> on the /test site, and your not seeing login failure messages
> most likely means that the login was successful. If permissions
> on /test/test.html do not allow access by your authenticated test
> user account then IIS will reprompt for an account that does.
> Could that be what is happening? Likely not as you have said
> that all works if you enable integrated authentication, with the
> precise same test setup, right?
> Let us know if above assumptions are correct, OK? We can
> then look at what is left, if we can figure what it is.
>
> Roger
>
>
> "Jude Fisher" wrote in message
> news:7B8342C2-2804-4B57-ACE2-457352396425@microsoft.com...
> > Roger,
> >
> > I've set up the test directory as described in my first post. I'm then
> > trying to access the page (http://localhost/test/test.html) through
> > internet
> > explorer. I get a windows log in box as a prompt. As you can imagine, I've
> > tried every possible combination of things but I'm mostly trying with
> > COMPUTERNAME\USER and the password. The password is for the moment set to
> > something absurdly simple so I'm sure it's not a problem with that.
> >
> > I've enabled failure logging and tested a regular remote desktop log in to
> > verify the failure is being recorded (it is). When I attempt to access the
> > directory above, however, I don't get a failure audit. I don't get any
> > event
> > at all for the user I'm trying to log in with. What I do get is a success
> > audit for the IUSR account (even though anonymous access is turned off and
> > I
> > am denied access to the page I'm trying to get to). Some details from that
> > success audit:
> >
> > User Name: IUSR_XXXXXXXXXXXXXXXX
> > Domain: XXXXXXXXXXXXXXXX
> > Logon ID: XXXXXXXXXXXXXXXX
> > Logon Type: 8
> > Logon Process: Advapi
> > Authentication Package: Negotiate
> > Workstation Name: XXXXXXXXXXXXXXXX
> > Logon GUID: -
> > Caller User Name: NETWORK SERVICE
> > Caller Domain: NT AUTHORITY
> > Caller Logon ID: XXXXXXXXXXXXXXXX
> > Caller Process ID: 184
> > Transited Services: -
> > Source Network Address: -
> > Source Port: -
> >
> > I actually get two (identical) success audits for this account, and a
> > success audit for the NETWORK_SERVICE account, but it is as if the attempt
> > to
> > log in through the username/password box just never happened.
> >
> > Not sure if any of that is useful but any help would be appreciated.
> >
> > Thanks for your time so far.
> >
> > Jude Fisher
> >
> >
> >
> > "Roger Abell [MVP]" wrote:
> >
> >> How are you trying to log in? With domain\account when
> >> using a domain account ?? The auditing settings are in the
> >> Local Security Policy which you will find in Administrative
> >> Tools (though domain policy may be controlling).
> >>
> >> "Jude Fisher" wrote in message
> >> news:E1E3B299-F273-44FF-B61E-7DAC0CEF25AB@microsoft.com...
> >> > Roger,
> >> >
> >> > Thanks for replying.
> >> >
> >> > The event log doesn't appear to be recording failures. How would I turn
> >> > that
> >> > on?
> >> >
> >> > Thanks again.
> >> >
> >> > Jude Fisher
> >> >
> >> > "Roger Abell [MVP]" wrote:
> >> >
> >> >> Have you looked into the security event log, assuming that it
> >> >> is configured to record login failures?
> >> >> You will probably see a unknown account or bad password
> >> >> event message, indicating the account that the domain.
> >> >> This last is probably not correct if the login attempt did not
> >> >> use domain\account syntax in the login attempt, where domain
> >> >> might need to be the local machine name of the webserver if
> >> >> domain account is not in use.
> >> >>
> >> >>
> >> >> "Jude Fisher" wrote in message
> >> >> news:6CF2177C-D68E-46CD-A95D-1FF4D51BC8C0@microsoft.com...
> >> >> > Hi,
> >> >> >
> >> >> > I'm a developer rather than a server tech and I've run into some
> >> >> > problems
> >> >> > configuring a website.
> >> >> >
> >> >> > An external provider we're using requires that a specific script be
> >> >> > in
> >> >> > a
> >> >> > directory that is protected by Basic Authentication. This isn't
> >> >> > something
> >> >> > I've had to do before so I've been stumbling along following the KB
> >> >> > instructions. I've set up a test directory but I can't seem to get
> >> >> > authentication working properly. Here are the details:
> >> >> >
> >> >> > I'm running IIS 6 on Windows Server 2003 with Asp.Net 1.1 and 2.0
> >> >> > both
> >> >> > installed.
> >> >> >
> >> >> > The directory is configured with regular read priveleges, no scripts
> >> >> > or
> >> >> > executables for the moment. The page inside the directory that I am
> >> >> > using
> >> >> > for
> >> >> > testing is just a plain html page with one line of text in it.
> >> >> >
> >> >> > The directory is configured in IIS with only Basic Authentication
> >> >> > checked
> >> >> > (Anonymous access, digest and integrated access are all cleared) and
> >> >> > the
> >> >> > domain and realm fields are empty.
> >> >> >
> >> >> > I have a limted access account I want to use for this but for
> >> >> > testing
> >> >> > I've
> >> >> > also tried my administrator account, which has priveleges to the
> >> >> > folder
> >> >> > and
> >> >> > also local log on priveleges for the machine. Problems are
> >> >> > consistent
> >> >> > whichever account is used.
> >> >> >
> >> >> > The error occurs whether I'm connecting remotely or (through remote
> >> >> > desktop)
> >> >> > via localhost, which should rule out any proxies.
> >> >> >
> >> >> > The error returned is HTTP Error 401.2 - Unauthorized: Access is
> >> >> > denied
> >> >> > due
> >> >> > to server configuration.
> >> >> >
> >> >> > *IMPORTANT* (I'm hoping this points directly to the problem!) - If I
> >> >> > check
> >> >> > the integrated authentication box in the IIS security configuration,
> >> >> > suddenly
> >> >> > the log in works. If I clear it so only basic is checked, it breaks
> >> >> > again.
> >> >> >
> >> >> > Thanks in advance for any assistance.
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

Re: Basic Authentication fails with Error 401.2 where Integrated s

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/WindowsServer20 03/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
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.
>
> Jude Fisher / JcFx
>
>
>
> "Roger Abell [MVP]" wrote:
> > OK. So I am assuming that your test.html is simple static html
> > that does not involve this vendors parts. I am also assuming
> > that when you set up /test you did set the NTFS permissions
> > directly or via IIS so that the account you are testing with does
> > have read. The logins you see for IUsr_ and Network Service
> > are likely from spinning up IIS backside support on first hits
> > on the /test site, and your not seeing login failure messages
> > most likely means that the login was successful. If permissions
> > on /test/test.html do not allow access by your authenticated test
> > user account then IIS will reprompt for an account that does.
> > Could that be what is happening? Likely not as you have said
> > that all works if you enable integrated authentication, with the
> > precise same test setup, right?
> > Let us know if above assumptions are correct, OK? We can
> > then look at what is left, if we can figure what it is.
>
> > Roger
>
> > "Jude Fisher" wrote in message
> >news:7B8342C2-2804-4B57-ACE2-457352396425@microsoft.com...
> > > Roger,
>
> > > I've set up the test directory as described in my first post. I'm then
> > > trying to access the page (http://localhost/test/test.html) through
> > > internet
> > > explorer. I get a windows log in box as a prompt. As you can imagine, I've
> > > tried every possible combination of things but I'm mostly trying with
> > > COMPUTERNAME\USER and the password. The password is for the moment set to
> > > something absurdly simple so I'm sure it's not a problem with that.
>
> > > I've enabled failure logging and tested a regular remote desktop log in to
> > > verify the failure is being recorded (it is). When I attempt to access the
> > > directory above, however, I don't get a failure audit. I don't get any
> > > event
> > > at all for the user I'm trying to log in with. What I do get is a success
> > > audit for the IUSR account (even though anonymous access is turned off and
> > > I
> > > am denied access to the page I'm trying to get to). Some details from that
> > > success audit:
>
> > > User Name: IUSR_XXXXXXXXXXXXXXXX
> > > Domain: XXXXXXXXXXXXXXXX
> > > Logon ID: XXXXXXXXXXXXXXXX
> > > Logon Type: 8
> > > Logon Process: Advapi
> > > Authentication Package: Negotiate
> > > Workstation Name: XXXXXXXXXXXXXXXX
> > > Logon GUID: -
> > > Caller User Name: NETWORK SERVICE
> > > Caller Domain: NT AUTHORITY
> > > Caller Logon ID: XXXXXXXXXXXXXXXX
> > > Caller Process ID: 184
> > > Transited Services: -
> > > Source Network Address: -
> > > Source Port: -
>
> > > I actually get two (identical) success audits for this account, and a
> > > success audit for the NETWORK_SERVICE account, but it is as if the attempt
> > > to
> > > log in through the username/password box just never happened.
>
> > > Not sure if any of that is useful but any help would be appreciated.
>
> > > Thanks for your time so far.
>
> > > Jude Fisher
>
> > > "Roger Abell [MVP]" wrote:
>
> > >> How are you trying to log in? With domain\account when
> > >> using a domain account ?? The auditing settings are in the
> > >> Local Security Policy which you will find in Administrative
> > >> Tools (though domain policy may be controlling).
>
> > >> "Jude Fisher" wrote in message
> > >>news:E1E3B299-F273-44FF-B61E-7DAC0CEF25AB@microsoft.com...
> > >> > Roger,
>
> > >> > Thanks for replying.
>
> > >> > The event log doesn't appear to be recording failures. How would I turn
> > >> > that
> > >> > on?
>
> > >> > Thanks again.
>
> > >> > Jude Fisher
>
> > >> > "Roger Abell [MVP]" wrote:
>
> > >> >> Have you looked into the security event log, assuming that it
> > >> >> is configured to record login failures?
> > >> >> You will probably see a unknown account or bad password
> > >> >> event message, indicating the account that the domain.
> > >> >> This last is probably not correct if the login attempt did not
> > >> >> use domain\account syntax in the login attempt, where domain
> > >> >> might need to be the local machine name of the webserver if
> > >> >> domain account is not in use.
>
> > >> >> "Jude Fisher" wrote in message
> > >> >>news:6CF2177C-D68E-46CD-A95D-1FF4D51BC8C0@microsoft.com...
> > >> >> > Hi,
>
> > >> >> > I'm a developer rather than a server tech and I've run into some
> > >> >> > problems
> > >> >> > configuring a website.
>
> > >> >> > An external provider we're using requires that a specific script be
> > >> >> > in
> > >> >> > a
> > >> >> > directory that is protected by Basic Authentication. This isn't
> > >> >> > something
> > >> >> > I've had to do before so I've been stumbling along following the KB
> > >> >> > instructions. I've set up a test directory but I can't seem to get
> > >> >> > authentication working properly. Here are the details:
>
> > >> >> > I'm running IIS 6 on Windows Server 2003 with Asp.Net 1.1 and 2.0
> > >> >> > both
> > >> >> > installed.
>
> > >> >> > The directory is configured with regular read priveleges, no scripts
> > >> >> > or
> > >> >> > executables for the moment. The page inside the directory that I am
> > >> >> > using
> > >> >> > for
> > >> >> > testing is just a plain html page with one line of text in it.
>
> > >> >> > The directory is configured in IIS with only Basic Authentication
> > >> >> > checked
> > >> >> > (Anonymous access, digest and integrated access are all cleared) and
> > >> >> > the
> > >> >> > domain and realm fields are empty.
>
> > >> >> > I have a limted access account I want to use for this but for
> > >> >> > testing
> > >> >> > I've
> > >> >> > also tried my administrator account, which has priveleges to the
> > >> >> > folder
> > >> >> > and
> > >> >> > also local log on priveleges for the machine. Problems are
> > >> >> > consistent
> > >> >> > whichever account is used.
>
> > >> >> > The error occurs whether I'm connecting remotely or (through remote
> > >> >> > desktop)
> > >> >> > via localhost, which should rule out any proxies.
>
> > >> >> > The error returned is HTTP Error 401.2 - Unauthorized: Access is
> > >> >> > denied
> > >> >> > due
> > >> >> > to server configuration.
>
> > >> >> > *IMPORTANT* (I'm hoping this points directly to the problem!) - If I
> > >> >> > check
> > >> >> > the integrated authentication box in the IIS security configuration,
> > >> >> > suddenly
> > >> >> > the log in works. If I clear it so only basic is checked, it breaks
> > >> >> > again.
>
> > >> >> > Thanks in advance for any assistance.- Hide quoted text -
>
> - Show quoted text -

Re: Basic Authentication fails with Error 401.2 where Integrated s

"David Wang" wrote in message
news:1193394701.846693.170260@z24g2000prh.googlegroups.com.. .
> 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

configurable - interesting; thanks for that info

> 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/WindowsServer20 03/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).
>

Yes, I raced through those and the thing is that those would
or should all result in an event log message, given the machine
is set to write them


> 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.
>

I lean toward some interaction on lines you outline, where
filter is casual, or a mismatch in the SSPI requirements between
the server and client (as failure to do NTLM after it has been
negotiated seems to result in login failures without event messages
getting written).

>> 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
> 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.
>>
>> Jude Fisher / JcFx
>>
>>
>>
>> "Roger Abell [MVP]" wrote:
>> > OK. So I am assuming that your test.html is simple static html
>> > that does not involve this vendors parts. I am also assuming
>> > that when you set up /test you did set the NTFS permissions
>> > directly or via IIS so that the account you are testing with does
>> > have read. The logins you see for IUsr_ and Network Service
>> > are likely from spinning up IIS backside support on first hits
>> > on the /test site, and your not seeing login failure messages
>> > most likely means that the login was successful. If permissions
>> > on /test/test.html do not allow access by your authenticated test
>> > user account then IIS will reprompt for an account that does.
>> > Could that be what is happening? Likely not as you have said
>> > that all works if you enable integrated authentication, with the
>> > precise same test setup, right?
>> > Let us know if above assumptions are correct, OK? We can
>> > then look at what is left, if we can figure what it is.
>>
>> > Roger
>>
>> > "Jude Fisher" wrote in message
>> >news:7B8342C2-2804-4B57-ACE2-457352396425@microsoft.com...
>> > > Roger,
>>
>> > > I've set up the test directory as described in my first post. I'm
>> > > then
>> > > trying to access the page (http://localhost/test/test.html) through
>> > > internet
>> > > explorer. I get a windows log in box as a prompt. As you can imagine,
>> > > I've
>> > > tried every possible combination of things but I'm mostly trying with
>> > > COMPUTERNAME\USER and the password. The password is for the moment
>> > > set to
>> > > something absurdly simple so I'm sure it's not a problem with that.
>>
>> > > I've enabled failure logging and tested a regular remote desktop log
>> > > in to
>> > > verify the failure is being recorded (it is). When I attempt to
>> > > access the
>> > > directory above, however, I don't get a failure audit. I don't get
>> > > any
>> > > event
>> > > at all for the user I'm trying to log in with. What I do get is a
>> > > success
>> > > audit for the IUSR account (even though anonymous access is turned
>> > > off and
>> > > I
>> > > am denied access to the page I'm trying to get to). Some details from
>> > > that
>> > > success audit:
>>
>> > > User Name: IUSR_XXXXXXXXXXXXXXXX
>> > > Domain: XXXXXXXXXXXXXXXX
>> > > Logon ID: XXXXXXXXXXXXXXXX
>> > > Logon Type: 8
>> > > Logon Process: Advapi
>> > > Authentication Package: Negotiate
>> > > Workstation Name: XXXXXXXXXXXXXXXX
>> > > Logon GUID: -
>> > > Caller User Name: NETWORK SERVICE
>> > > Caller Domain: NT AUTHORITY
>> > > Caller Logon ID: XXXXXXXXXXXXXXXX
>> > > Caller Process ID: 184
>> > > Transited Services: -
>> > > Source Network Address: -
>> > > Source Port: -
>>
>> > > I actually get two (identical) success audits for this account, and a
>> > > success audit for the NETWORK_SERVICE account, but it is as if the
>> > > attempt
>> > > to
>> > > log in through the username/password box just never happened.
>>
>> > > Not sure if any of that is useful but any help would be appreciated.
>>
>> > > Thanks for your time so far.
>>
>> > > Jude Fisher
>>
>> > > "Roger Abell [MVP]" wrote:
>>
>> > >> How are you trying to log in? With domain\account when
>> > >> using a domain account ?? The auditing settings are in the
>> > >> Local Security Policy which you will find in Administrative
>> > >> Tools (though domain policy may be controlling).
>>
>> > >> "Jude Fisher" wrote in
>> > >> message
>> > >>news:E1E3B299-F273-44FF-B61E-7DAC0CEF25AB@microsoft.com...
>> > >> > Roger,
>>
>> > >> > Thanks for replying.
>>
>> > >> > The event log doesn't appear to be recording failures. How would I
>> > >> > turn
>> > >> > that
>> > >> > on?
>>
>> > >> > Thanks again.
>>
>> > >> > Jude Fisher
>>
>> > >> > "Roger Abell [MVP]" wrote:
>>
>> > >> >> Have you looked into the security event log, assuming that it
>> > >> >> is configured to record login failures?
>> > >> >> You will probably see a unknown account or bad password
>> > >> >> event message, indicating the account that the domain.
>> > >> >> This last is probably not correct if the login attempt did not
>> > >> >> use domain\account syntax in the login attempt, where domain
>> > >> >> might need to be the local machine name of the webserver if
>> > >> >> domain account is not in use.
>>
>> > >> >> "Jude Fisher" wrote in
>> > >> >> message
>> > >> >>news:6CF2177C-D68E-46CD-A95D-1FF4D51BC8C0@microsoft.com...
>> > >> >> > Hi,
>>
>> > >> >> > I'm a developer rather than a server tech and I've run into
>> > >> >> > some
>> > >> >> > problems
>> > >> >> > configuring a website.
>>
>> > >> >> > An external provider we're using requires that a specific
>> > >> >> > script be
>> > >> >> > in
>> > >> >> > a
>> > >> >> > directory that is protected by Basic Authentication. This isn't
>> > >> >> > something
>> > >> >> > I've had to do before so I've been stumbling along following
>> > >> >> > the KB
>> > >> >> > instructions. I've set up a test directory but I can't seem to
>> > >> >> > get
>> > >> >> > authentication working properly. Here are the details:
>>
>> > >> >> > I'm running IIS 6 on Windows Server 2003 with Asp.Net 1.1 and
>> > >> >> > 2.0
>> > >> >> > both
>> > >> >> > installed.
>>
>> > >> >> > The directory is configured with regular read priveleges, no
>> > >> >> > scripts
>> > >> >> > or
>> > >> >> > executables for the moment. The page inside the directory that
>> > >> >> > I am
>> > >> >> > using
>> > >> >> > for
>> > >> >> > testing is just a plain html page with one line of text in it.
>>
>> > >> >> > The directory is configured in IIS with only Basic
>> > >> >> > Authentication
>> > >> >> > checked
>> > >> >> > (Anonymous access, digest and integrated access are all
>> > >> >> > cleared) and
>> > >> >> > the
>> > >> >> > domain and realm fields are empty.
>>
>> > >> >> > I have a limted access account I want to use for this but for
>> > >> >> > testing
>> > >> >> > I've
>> > >> >> > also tried my administrator account, which has priveleges to
>> > >> >> > the
>> > >> >> > folder
>> > >> >> > and
>> > >> >> > also local log on priveleges for the machine. Problems are
>> > >> >> > consistent
>> > >> >> > whichever account is used.
>>
>> > >> >> > The error occurs whether I'm connecting remotely or (through
>> > >> >> > remote
>> > >> >> > desktop)
>> > >> >> > via localhost, which should rule out any proxies.
>>
>> > >> >> > The error returned is HTTP Error 401.2 - Unauthorized: Access
>> > >> >> > is
>> > >> >> > denied
>> > >> >> > due
>> > >> >> > to server configuration.
>>
>> > >> >> > *IMPORTANT* (I'm hoping this points directly to the problem!) -
>> > >> >> > If I
>> > >> >> > check
>> > >> >> > the integrated authentication box in the IIS security
>> > >> >> > configuration,
>> > >> >> > suddenly
>> > >> >> > the log in works. If I clear it so only basic is checked, it
>> > >> >> > breaks
>> > >> >> > again.
>>
>> > >> >> > Thanks in advance for any assistance.- Hide quoted text -
>>
>> - Show quoted text -
>
>

Re: Basic Authentication fails with Error 401.2 where Integrated s

David,

1) Just as a check I used NET USER /ADD on my test account and as expected
it told me the user account already existed.

2) No ISAPI filters are listed for any of the websites on this computer.

3) I didn't set the server up myself (this is a dedicated server from a
major UK host) but I can't see anything in Local Security Settings that could
be causing the issue - is there anything specific I should be looking for,?

"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/WindowsServer20 03/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
> 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.
> >
> > Jude Fisher / JcFx
> >
> >
> >
> > "Roger Abell [MVP]" wrote:
> > > OK. So I am assuming that your test.html is simple static html
> > > that does not involve this vendors parts. I am also assuming
> > > that when you set up /test you did set the NTFS permissions
> > > directly or via IIS so that the account you are testing with does
> > > have read. The logins you see for IUsr_ and Network Service
> > > are likely from spinning up IIS backside support on first hits
> > > on the /test site, and your not seeing login failure messages
> > > most likely means that the login was successful. If permissions
> > > on /test/test.html do not allow access by your authenticated test
> > > user account then IIS will reprompt for an account that does.
> > > Could that be what is happening? Likely not as you have said
> > > that all works if you enable integrated authentication, with the
> > > precise same test setup, right?
> > > Let us know if above assumptions are correct, OK? We can
> > > then look at what is left, if we can figure what it is.
> >
> > > Roger
> >
> > > "Jude Fisher" wrote in message
> > >news:7B8342C2-2804-4B57-ACE2-457352396425@microsoft.com...
> > > > Roger,
> >
> > > > I've set up the test directory as described in my first post. I'm then
> > > > trying to access the page (http://localhost/test/test.html) through
> > > > internet
> > > > explorer. I get a windows log in box as a prompt. As you can imagine, I've
> > > > tried every possible combination of things but I'm mostly trying with
> > > > COMPUTERNAME\USER and the password. The password is for the moment set to
> > > > something absurdly simple so I'm sure it's not a problem with that.
> >
> > > > I've enabled failure logging and tested a regular remote desktop log in to
> > > > verify the failure is being recorded (it is). When I attempt to access the
> > > > directory above, however, I don't get a failure audit. I don't get any
> > > > event
> > > > at all for the user I'm trying to log in with. What I do get is a success
> > > > audit for the IUSR account (even though anonymous access is turned off and
> > > > I
> > > > am denied access to the page I'm trying to get to). Some details from that
> > > > success audit:
> >
> > > > User Name: IUSR_XXXXXXXXXXXXXXXX
> > > > Domain: XXXXXXXXXXXXXXXX
> > > > Logon ID: XXXXXXXXXXXXXXXX
> > > > Logon Type: 8
> > > > Logon Process: Advapi
> > > > Authentication Package: Negotiate
> > > > Workstation Name: XXXXXXXXXXXXXXXX
> > > > Logon GUID: -
> > > > Caller User Name: NETWORK SERVICE
> > > > Caller Domain: NT AUTHORITY
> > > > Caller Logon ID: XXXXXXXXXXXXXXXX
> > > > Caller Process ID: 184
> > > > Transited Services: -
> > > > Source Network Address: -
> > > > Source Port: -
> >
> > > > I actually get two (identical) success audits for this account, and a
> > > > success audit for the NETWORK_SERVICE account, but it is as if the attempt
> > > > to
> > > > log in through the username/password box just never happened.
> >
> > > > Not sure if any of that is useful but any help would be appreciated.
> >
> > > > Thanks for your time so far.
> >
> > > > Jude Fisher
> >
> > > > "Roger Abell [MVP]" wrote:
> >
> > > >> How are you trying to log in? With domain\account when
> > > >> using a domain account ?? The auditing settings are in the
> > > >> Local Security Policy which you will find in Administrative
> > > >> Tools (though domain policy may be controlling).
> >
> > > >> "Jude Fisher" wrote in message
> > > >>news:E1E3B299-F273-44FF-B61E-7DAC0CEF25AB@microsoft.com...
> > > >> > Roger,
> >
> > > >> > Thanks for replying.
> >
> > > >> > The event log doesn't appear to be recording failures. How would I turn
> > > >> > that
> > > >> > on?
> >
> > > >> > Thanks again.
> >
> > > >> > Jude Fisher
> >
> > > >> > "Roger Abell [MVP]" wrote:
> >
> > > >> >> Have you looked into the security event log, assuming that it
> > > >> >> is configured to record login failures?
> > > >> >> You will probably see a unknown account or bad password
> > > >> >> event message, indicating the account that the domain.
> > > >> >> This last is probably not correct if the login attempt did not
> > > >> >> use domain\account syntax in the login attempt, where domain
> > > >> >> might need to be the local machine name of the webserver if
> > > >> >> domain account is not in use.
> >
> > > >> >> "Jude Fisher" wrote in message
> > > >> >>news:6CF2177C-D68E-46CD-A95D-1FF4D51BC8C0@microsoft.com...
> > > >> >> > Hi,
> >
> > > >> >> > I'm a developer rather than a server tech and I've run into some
> > > >> >> > problems
> > > >> >> > configuring a website.
> >
> > > >> >> > An external provider we're using requires that a specific script be
> > > >> >> > in
> > > >> >> > a
> > > >> >> > directory that is protected by Basic Authentication. This isn't
> > > >> >> > something
> > > >> >> > I've had to do before so I've been stumbling along following the KB
> > > >> >> > instructions. I've set up a test directory but I can't seem to get
> > > >> >> > authentication working properly. Here are the details:
> >
> > > >> >> > I'm running IIS 6 on Windows Server 2003 with Asp.Net 1.1 and 2.0
> > > >> >> > both
> > > >> >> > installed.
> >
> > > >> >> > The directory is configured with regular read priveleges, no scripts
> > > >> >> > or
> > > >> >> > executables for the moment. The page inside the directory that I am
> > > >> >> > using
> > > >> >> > for
> > > >> >> > testing is just a plain html page with one line of text in it.
> >
> > > >> >> > The directory is configured in IIS with only Basic Authentication
> > > >> >> > checked
> > > >> >> > (Anonymous access, digest and integrated access are all cleared) and
> > > >> >> > the
> > > >> >> > domain and realm fields are empty.
> >
> > > >> >> > I have a limted access account I want to use for this but for
> > > >> >> > testing
> > > >> >> > I've
> > > >> >> > also tried my administrator account, which has priveleges to the
> > > >> >> > folder
> > > >> >> > and
> > > >> >> > also local log on priveleges for the machine. Problems are
> > > >> >> > consistent
> > > >> >> > whichever account is used.
> >
> > > >> >> > The error occurs whether I'm connecting remotely or (through remote
> > > >> >> > desktop)
> > > >> >> > via localhost, which should rule out any proxies.
> >
> > > >> >> > The error returned is HTTP Error 401.2 - Unauthorized: Access is
> > > >> >> > denied
> > > >> >> > due
> > > >> >> > to server configuration.
> >
> > > >> >> > *IMPORTANT* (I'm hoping this points directly to the problem!) - If I
> > > >> >> > check
> > > >> >> > the integrated authentication box in the IIS security configuration,
> > > >> >> > suddenly
> > > >> >> > the log in works. If I clear it so only basic is checked, it breaks
> > > >> >> > again.
> >
> > > >> >> > Thanks in advance for any assistance.- Hide quoted text -
> >
> > - Show quoted text -
>
>
>

Re: Basic Authentication fails with Error 401.2 where Integrated s

Further to the above, here are the results of the MS Authentication & Access
Control Diagnostics tool. These are from the directory I want to be working
with rather than the /test one but the settings and results are identical.
Where it says COMPUTERNAME\
ACCOUNTNAME, this is the account that I am trying to grant access to:

------------------------------------------------------------ ----------------
Check Permissions Results
Status Result
Verifying: D:\home\Clients\Marketing4Tradesmen\cpi\*
Account: COMPUTERNAME\ACCOUNTNAME Access type: FULL
Check of D:\home\Clients\Marketing4Tradesmen\cpi\* complete, no errors
Diagnostics complete
------------------------------------------------------------ ----------------
View Permissions Results

D:\home\Clients\Marketing4Tradesmen\cpi\.
COMPUTERNAME\USERNAME: (OI)(CI)F
D:\home\Clients\Marketing4Tradesmen\cpi\order-postprocess.as px
COMPUTERNAME\USERNAME: F

Diagnostics complete

View Site Configuration
W3SVC/1 Default
ServerState Server started
ServerBindings :80:
AuthFlags 5 (0x5) "AuthAnonymous | AuthNTLM"
------------------------------------------------------------ ----------------
Authentication Results Url: http://localhost/clients/Marketing4Tradesmen/cpi/

AnonymousUserPass logon failed Path:W3SVC

AuthType:Anonymous AnonymousPasswordSync
The current configuration requires IIS subauthentication. However, the IIS
subauthentication component, iissuba.dll, is not currently configured.
Path:W3SVC

AuthType:Anonymous
AnonymousPasswordSync
The current configuration uses IIS subauthentication for anonymous
authentication. This requires that the worker process be configured to run as
the Local System identity, which is not recommended for security reasons.
Path:W3SVC

AuthType:Anonymous
must be domain member Path:W3SVC

AuthType:Kerberos
Basic authentication is not a secure authentication protocol. You should
consider using Secure Sockets Layer (SSL) for added security.
Path:W3SVC/1/ROOT/clients/Marketing4Tradesmen/cpi
AuthType:Basic

Test Authentication

[THIS POPS A DIALOG BOX. VERIFYING THE PASSWORD FORTHE USER I AM WORKING
WITH RETURNS THE RESULT 'SUCCESS'. AUTHENTICATING THIS USER RETURNS:]
Server's response: HTTP/1.1 401 Unauthorized
Learn about IIS status codes

Path:W3SVC/1/ROOT/clients/Marketing4Tradesmen/cpi
AuthType:Basic

Diagnostics complete
------------------------------------------------------------ ----------------
Server Permissions Results

Verifying: C:\WINDOWS\help\iishelp\common\*
Account: BUILTIN\Administrators Access type: FULL
Account: NT AUTHORITY\SYSTEM Access type: FULL
Account: COMPUTERNAME\IIS_WPG Access type: READ
Account: BUILTIN\Users Access type: READ | EXECUTE
Check of C:\WINDOWS\help\iishelp\common\* complete, no errors


Verifying: C:\WINDOWS\IIS Temporary Compressed Files\*
Account: BUILTIN\Administrators Access type: FULL
Account: NT AUTHORITY\SYSTEM Access type: FULL
Account: COMPUTERNAME\IIS_WPG Access type: READ | WRITE
Account: CREATOR OWNER Access type: FULL
CREATOR OWNER does not have 'FULL' access to .
Check of C:\WINDOWS\IIS Temporary Compressed Files\* complete, errors found


Verifying: C:\WINDOWS\system32\inetsrv\*
Account: BUILTIN\Administrators Access type: FULL
Account: NT AUTHORITY\SYSTEM Access type: FULL
Check of C:\WINDOWS\system32\inetsrv\* complete, no errors


Verifying: C:\WINDOWS\system32\inetsrv\*
Account: BUILTIN\Users Access type: READ | EXECUTE
BUILTIN\Users does not have 'READ | EXECUTE' access to ASP Compiled
Templates
BUILTIN\Users does not have 'READ | EXECUTE' access to History
BUILTIN\Users does not have 'READ | EXECUTE' access to
MBSchema.bin.00000000h
BUILTIN\Users does not have 'READ | EXECUTE' access to MBSchema.xml
BUILTIN\Users does not have 'READ | EXECUTE' access to MetaBase.xml
Check of C:\WINDOWS\system32\inetsrv\* complete, errors found


Verifying: C:\WINDOWS\system32\inetsrv\ASP Compiled Templates\*
Account: COMPUTERNAME\IIS_WPG Access type: READ
Check of C:\WINDOWS\system32\inetsrv\ASP Compiled Templates\* complete, no
errors


Verifying: C:\inetpub\adminscripts\*
Account: BUILTIN\Administrators Access type: FULL
Check of C:\inetpub\adminscripts\* complete, no errors


Verifying: C:\WINDOWS\system32\Logfiles\*
Account: BUILTIN\Administrators Access type: FULL
Check of C:\WINDOWS\system32\Logfiles\* complete, no errors


Diagnostics complete

System Information:

System time Mon, 29 Oct 2007 10:05:15 GMT
OS Windows 2003 Service Pack 2
W3SVC IIS6 - World Wide Web Publishing service is running
MSFTPSVC IIS6 - FTP Publishing service is not started
Host name COMPUTERNAME
Dns suffix jcfx.eu
Workgroup name WORKGROUPNAME
ModuleFileName C:\Program Files\IIS Resources\AuthDiag\authdiag.exe version:
1.0:43.0

"Jude Fisher" wrote:

> David,
>
> 1) Just as a check I used NET USER /ADD on my test account and as expected
> it told me the user account already existed.
>
> 2) No ISAPI filters are listed for any of the websites on this computer.
>
> 3) I didn't set the server up myself (this is a dedicated server from a
> major UK host) but I can't see anything in Local Security Settings that could
> be causing the issue - is there anything specific I should be looking for,?
>
> "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/WindowsServer20 03/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
> > 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.
> > >
> > > Jude Fisher / JcFx
> > >
> > >
> > >
> > > "Roger Abell [MVP]" wrote:
> > > > OK. So I am assuming that your test.html is simple static html
> > > > that does not involve this vendors parts. I am also assuming
> > > > that when you set up /test you did set the NTFS permissions
> > > > directly or via IIS so that the account you are testing with does
> > > > have read. The logins you see for IUsr_ and Network Service
> > > > are likely from spinning up IIS backside support on first hits
> > > > on the /test site, and your not seeing login failure messages
> > > > most likely means that the login was successful. If permissions
> > > > on /test/test.html do not allow access by your authenticated test
> > > > user account then IIS will reprompt for an account that does.
> > > > Could that be what is happening? Likely not as you have said
> > > > that all works if you enable integrated authentication, with the
> > > > precise same test setup, right?
> > > > Let us know if above assumptions are correct, OK? We can
> > > > then look at what is left, if we can figure what it is.
> > >
> > > > Roger
> > >
> > > > "Jude Fisher" wrote in message
> > > >news:7B8342C2-2804-4B57-ACE2-457352396425@microsoft.com...
> > > > > Roger,
> > >
> > > > > I've set up the test directory as described in my first post. I'm then
> > > > > trying to access the page (http://localhost/test/test.html) through
> > > > > internet
> > > > > explorer. I get a windows log in box as a prompt. As you can imagine, I've
> > > > > tried every possible combination of things but I'm mostly trying with
> > > > > COMPUTERNAME\USER and the password. The password is for the moment set to
> > > > > something absurdly simple so I'm sure it's not a problem with that.
> > >
> > > > > I've enabled failure logging and tested a regular remote desktop log in to
> > > > > verify the failure is being recorded (it is). When I attempt to access the
> > > > > directory above, however, I don't get a failure audit. I don't get any
> > > > > event
> > > > > at all for the user I'm trying to log in with. What I do get is a success
> > > > > audit for the IUSR account (even though anonymous access is turned off and
> > > > > I
> > > > > am denied access to the page I'm trying to get to). Some details from that
> > > > > success audit:
> > >
> > > > > User Name: IUSR_XXXXXXXXXXXXXXXX
> > > > > Domain: XXXXXXXXXXXXXXXX
> > > > > Logon ID: XXXXXXXXXXXXXXXX
> > > > > Logon Type: 8
> > > > > Logon Process: Advapi
> > > > > Authentication Package: Negotiate
> > > > > Workstation Name: XXXXXXXXXXXXXXXX
> > > > > Logon GUID: -
> > > > > Caller User Name: NETWORK SERVICE
> > > > > Caller Domain: NT AUTHORITY
> > > > > Caller Logon ID: XXXXXXXXXXXXXXXX
> > > > > Caller Process ID: 184
> > > > > Transited Services: -
> > > > > Source Network Address: -
> > > > > Source Port: -
> > >
> > > > > I actually get two (identical) success audits for this account, and a
> > > > > success audit for the NETWORK_SERVICE account, but it is as if the attempt
> > > > > to
> > > > > log in through the username/password box just never happened.
> > >
> > > > > Not sure if any of that is useful but any help would be appreciated.
> > >
> > > > > Thanks for your time so far.
> > >
> > > > > Jude Fisher
> > >
> > > > > "Roger Abell [MVP]" wrote:
> > >
> > > > >> How are you trying to log in? With domain\account when
> > > > >> using a domain account ?? The auditing settings are in the
> > > > >> Local Security Policy which you will find in Administrative
> > > > >> Tools (though domain policy may be controlling).
> > >
> > > > >> "Jude Fisher" wrote in message
> > > > >>news:E1E3B299-F273-44FF-B61E-7DAC0CEF25AB@microsoft.com...
> > > > >> > Roger,
> > >
> > > > >> > Thanks for replying.
> > >
> > > > >> > The event log doesn't appear to be recording failures. How would I turn
> > > > >> > that
> > > > >> > on?
> > >
> > > > >> > Thanks again.
> > >
> > > > >> > Jude Fisher
> > >
> > > > >> > "Roger Abell [MVP]" wrote:
> > >
> > > > >> >> Have you looked into the security event log, assuming that it
> > > > >> >> is configured to record login failures?
> > > > >> >> You will probably see a unknown account or bad password
> > > > >> >> event message, indicating the account that the domain.
> > > > >> >> This last is probably not correct if the login attempt did not
> > > > >> >> use domain\account syntax in the login attempt, where domain
> > > > >> >> might need to be the local machine name of the webserver if
> > > > >> >> domain account is not in use.
> > >
> > > > >> >> "Jude Fisher" wrote in message
> > > > >> >>news:6CF2177C-D68E-46CD-A95D-1FF4D51BC8C0@microsoft.com...
> > > > >> >> > Hi,
> > >
> > > > >> >> > I'm a developer rather than a server tech and I've run into some
> > > > >> >> > problems
> > > > >> >> > configuring a website.
> > >
> > > > >> >> > An external provider we're using requires that a specific script be
> > > > >> >> > in
> > > > >> >> > a
> > > > >> >> > directory that is protected by Basic Authentication. This isn't
> > > > >> >> > something
> > > > >> >> > I've had to do before so I've been stumbling along following the KB
> > > > >> >> > instructions. I've set up a test directory but I can't seem to get
> > > > >> >> > authentication working properly. Here are the details:
> > >
> > > > >> >> > I'm running IIS 6 on Windows Server 2003 with Asp.Net 1.1 and 2.0
> > > > >> >> > both
> > > > >> >> > installed.
> > >
> > > > >> >> > The directory is configured with regular read priveleges, no scripts
> > > > >> >> > or
> > > > >> >> > executables for the moment. The page inside the directory that I am
> > > > >> >> > using
> > > > >> >> > for
> > > > >> >> > testing is just a plain html page with one line of text in it.
> > >
> > > > >> >> > The directory is configured in IIS with only Basic Authentication
> > > > >> >> > checked
> > > > >> >> > (Anonymous access, digest and integrated access are all cleared) and
> > > > >> >> > the
> > > > >> >> > domain and realm fields are empty.
> > >
> > > > >> >> > I have a limted access account I want to use for this but for
> > > > >> >> > testing
> > > > >> >> > I've
> > > > >> >> > also tried my administrator account, which has priveleges to the
> > > > >> >> > folder
> > > > >> >> > and
> > > > >> >> > also local log on priveleges for the machine. Problems are
> > > > >> >> > consistent
> > > > >> >> > whichever account is used.
> > >
> > > > >> >> > The error occurs whether I'm connecting remotely or (through remote
> > > > >> >> > desktop)
> > > > >> >> > via localhost, which should rule out any proxies.
> > >
> > > > >> >> > The error returned is HTTP Error 401.2 - Unauthorized: Access is
> > > > >> >> > denied
> > > > >> >> > due
> > > > >> >> > to server configuration.
> > >
> > > > >> >> > *IMPORTANT* (I'm hoping this points directly to the problem!) - If I
> > > > >> >> > check
> > > > >> >> > the integrated authentication box in the IIS security configuration,

Re: Basic Authentication fails with Error 401.2 where Integrated s

You want to read the URL that I mentioned in my prior response to make
sure that Basic Authentication is allowed to function on your server.

I suspect the problem is either:
1 some security module running on network packets stripping off
Authorization: Basic header and causing IIS to return 401.2 before
even invoking any security login code of IIS
2 some security lockdown performed on the colo server that is
preventing basic authentication (and probably other things - we just
don't know what) from working within IIS


It is harder to validate #2 because it comes down to setting-by-
setting comparison of a working server with your server. I don't want
to get into that situation because I'd rather have the colo server
company tell me what they HAVE changed (they should have those changes
listed in an automation script somewhere since they built the server
for you) instead of trying to ask everyone else what could/not have
changed.

#1 requires that you validate with something like Network Monitor on
the server itself that the Authorization: Basic header is received by
the IIS web server (and not removed by some network security module).
And please verify that there is no GLOBAL ISAPI FILTER -- you only
mentioned the ISAPI Filters tab for each website but not the global
ISAPI Filters tab for all websites. At the same time, no Wildcard
Application Mapping for *ANY* of the Application mapping settings
applicable to the URL under question. There's no simple command to do
this -- because we are talking about deep, internal server
modifications (potentially made by other setup programs), one has to
know how IIS works to uncover what other setup programs have
configured.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//







On Oct 29, 3:17 am, Jude Fisher
wrote:
> Further to the above, here are the results of the MS Authentication & Acc=
ess
> Control Diagnostics tool. These are from the directory I want to be worki=
ng
> with rather than the /test one but the settings and results are identical.
> Where it says COMPUTERNAME\
> ACCOUNTNAME, this is the account that I am trying to grant access to:
>
> ------------------------------------------------------------ -------------=
--=AD-
> Check Permissions Results
> Status Result
> Verifying: D:\home\Clients\Marketing4Tradesmen\cpi\*
> Account: COMPUTERNAME\ACCOUNTNAME Access type: FULL
> Check of D:\home\Clients\Marketing4Tradesmen\cpi\* complete, no errors
> Diagnostics complete
> ------------------------------------------------------------ -------------=
--=AD-
> View Permissions Results
>
> D:\home\Clients\Marketing4Tradesmen\cpi\.
> COMPUTERNAME\USERNAME: (OI)(CI)F
> D:\home\Clients\Marketing4Tradesmen\cpi\order-postprocess.as px
> COMPUTERNAME\USERNAME: F
>
> Diagnostics complete
>
> View Site Configuration =20
> W3SVC/1 Default
> ServerState Server started
> ServerBindings :80:
> AuthFlags 5 (0x5) "AuthAnonymous | AuthNTLM"
> ------------------------------------------------------------ -------------=
--=AD-
> Authentication Results Url:http://localhost/clients/Marketing4Tradesmen/c=
pi/
>
> AnonymousUserPass logon failed Path:W3SVC
>
> AuthType:Anonymous AnonymousPasswordSync
> The current configuration requires IIS subauthentication. However, the IIS
> subauthentication component, iissuba.dll, is not currently configured.
> Path:W3SVC
>
> AuthType:Anonymous
> AnonymousPasswordSync
> The current configuration uses IIS subauthentication for anonymous
> authentication. This requires that the worker process be configured to ru=
n as
> the Local System identity, which is not recommended for security reasons.
> Path:W3SVC
>
> AuthType:Anonymous
> must be domain member Path:W3SVC
>
> AuthType:Kerberos
> Basic authentication is not a secure authentication protocol. You should
> consider using Secure Sockets Layer (SSL) for added security.
> Path:W3SVC/1/ROOT/clients/Marketing4Tradesmen/cpi
> AuthType:Basic
>
> Test Authentication
>
> [THIS POPS A DIALOG BOX. VERIFYING THE PASSWORD FORTHE USER I AM WORKING
> WITH RETURNS THE RESULT 'SUCCESS'. AUTHENTICATING THIS USER RETURNS:]
> Server's response: HTTP/1.1 401 Unauthorized
> Learn about IIS status codes
>
> Path:W3SVC/1/ROOT/clients/Marketing4Tradesmen/cpi
> AuthType:Basic
>
> Diagnostics complete =20
> ------------------------------------------------------------ -------------=
--=AD-
> Server Permissions Results
>
> Verifying: C:\WINDOWS\help\iishelp\common\*
> Account: BUILTIN\Administrators Access type: FULL
> Account: NT AUTHORITY\SYSTEM Access type: FULL
> Account: COMPUTERNAME\IIS_WPG Access type: READ
> Account: BUILTIN\Users Access type: READ | EXECUTE
> Check of C:\WINDOWS\help\iishelp\common\* complete, no errors
>
> Verifying: C:\WINDOWS\IIS Temporary Compressed Files\*
> Account: BUILTIN\Administrators Access type: FULL
> Account: NT AUTHORITY\SYSTEM Access type: FULL
> Account: COMPUTERNAME\IIS_WPG Access type: READ | WRITE
> Account: CREATOR OWNER Access type: FULL
> CREATOR OWNER does not have 'FULL' access to .
> Check of C:\WINDOWS\IIS Temporary Compressed Files\* complete, errors fo=
und
>
> Verifying: C:\WINDOWS\system32\inetsrv\*
> Account: BUILTIN\Administrators Access type: FULL
> Account: NT AUTHORITY\SYSTEM Access type: FULL
> Check of C:\WINDOWS\system32\inetsrv\* complete, no errors
>
> Verifying: C:\WINDOWS\system32\inetsrv\*
> Account: BUILTIN\Users Access type: READ | EXECUTE
> BUILTIN\Users does not have 'READ | EXECUTE' access to ASP Compiled
> Templates
> BUILTIN\Users does not have 'READ | EXECUTE' access to History
> BUILTIN\Users does not have 'READ | EXECUTE' access to
> MBSchema.bin.00000000h
> BUILTIN\Users does not have 'READ | EXECUTE' access to MBSchema.xml
> BUILTIN\Users does not have 'READ | EXECUTE' access to MetaBase.xml
> Check of C:\WINDOWS\system32\inetsrv\* complete, errors found
>
> Verifying: C:\WINDOWS\system32\inetsrv\ASP Compiled Templates\*
> Account: COMPUTERNAME\IIS_WPG Access type: READ
> Check of C:\WINDOWS\system32\inetsrv\ASP Compiled Templates\* complete, =
no
> errors
>
> Verifying: C:\inetpub\adminscripts\*
> Account: BUILTIN\Administrators Access type: FULL
> Check of C:\inetpub\adminscripts\* complete, no errors
>
> Verifying: C:\WINDOWS\system32\Logfiles\*
> Account: BUILTIN\Administrators Access type: FULL
> Check of C:\WINDOWS\system32\Logfiles\* complete, no errors
>
> Diagnostics complete
>
> System Information:
>
> System time Mon, 29 Oct 2007 10:05:15 GMT
> OS Windows 2003 Service Pack 2
> W3SVC IIS6 - World Wide Web Publishing service is running
> MSFTPSVC IIS6 - FTP Publishing service is not started
> Host name COMPUTERNAME
> Dns suffix jcfx.eu
> Workgroup name WORKGROUPNAME
> ModuleFileName C:\Program Files\IIS Resources\AuthDiag\authdiag.exe versi=
on:
> 1.0:43.0
>
>
>
> "Jude Fisher" wrote:
> > David,
>
> > 1) Just as a check I used NET USER /ADD on my test account and as expec=
ted
> > it told me the user account already existed.
>
> > 2) No ISAPI filters are listed for any of the websites on this computer.
>
> > 3) I didn't set the server up myself (this is a dedicated server from a
> > major UK host) but I can't see anything in Local Security Settings that=
could
> > be causing the issue - is there anything specific I should be looking f=
or,?
>
> > "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/WindowsServer2 003/Librar.=
..
>
> > > 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 authenticat=
ion 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
> > > 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, di=
gest
> > > > authentication is disabled, integrated authentication is disabled a=
nd basic
> > > > authentication only is enabled. The two text boxes at the bottom (d=
omain and
> > > > realm) are empty.
>
> > > > On the windows explorer security dialog for the folder, the test us=
er
> > > > account created has full permissions for the folder and the file th=
at'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 usin=
g windows
> > > > explorer, so
>
> ...
>
> read more =BB- Hide quoted text -
>
> - Show quoted text -

Re: Basic Authentication fails with Error 401.2 where Integrated s

David,

>>And please verify that there is no GLOBAL ISAPI FILTER -- you only
mentioned the ISAPI Filters tab for each website but not the global
ISAPI Filters tab for all website

Thank you, this was the issue.

I didn't realise the Web Sites folder in IIS manager threw up a global
properties dialog. My host had helpfully installed a control panel (Matrix)
which included a custom ISAPI filter called "Log In Filter". Removing that
solved the problem immediately. It would have been nice, of course if the
host (Fasthosts) could have told me about this but all their support was able
to do was offer to restore the server from scratch in order to repair the
problem they were certain I had caused. Not useful.

Thanks also to Roger for the time spent on this.

Jude Fisher / JcFx.Eu

"David Wang" wrote:

> You want to read the URL that I mentioned in my prior response to make
> sure that Basic Authentication is allowed to function on your server.
>
> I suspect the problem is either:
> 1. some security module running on network packets stripping off
> Authorization: Basic header and causing IIS to return 401.2 before
> even invoking any security login code of IIS
> 2. some security lockdown performed on the colo server that is
> preventing basic authentication (and probably other things - we just
> don't know what) from working within IIS
>
>
> It is harder to validate #2 because it comes down to setting-by-
> setting comparison of a working server with your server. I don't want
> to get into that situation because I'd rather have the colo server
> company tell me what they HAVE changed (they should have those changes
> listed in an automation script somewhere since they built the server
> for you) instead of trying to ask everyone else what could/not have
> changed.
>
> #1 requires that you validate with something like Network Monitor on
> the server itself that the Authorization: Basic header is received by
> the IIS web server (and not removed by some network security module).
> And please verify that there is no GLOBAL ISAPI FILTER -- you only
> mentioned the ISAPI Filters tab for each website but not the global
> ISAPI Filters tab for all websites. At the same time, no Wildcard
> Application Mapping for *ANY* of the Application mapping settings
> applicable to the URL under question. There's no simple command to do
> this -- because we are talking about deep, internal server
> modifications (potentially made by other setup programs), one has to
> know how IIS works to uncover what other setup programs have
> configured.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
>
>
>
> On Oct 29, 3:17 am, Jude Fisher
> wrote:
> > Further to the above, here are the results of the MS Authentication & Access
> > Control Diagnostics tool. These are from the directory I want to be working
> > with rather than the /test one but the settings and results are identical.
> > Where it says COMPUTERNAME\
> > ACCOUNTNAME, this is the account that I am trying to grant access to:
> >
> > ------------------------------------------------------------ -----------------
> > Check Permissions Results
> > Status Result
> > Verifying: D:\home\Clients\Marketing4Tradesmen\cpi\*
> > Account: COMPUTERNAME\ACCOUNTNAME Access type: FULL
> > Check of D:\home\Clients\Marketing4Tradesmen\cpi\* complete, no errors
> > Diagnostics complete
> > ------------------------------------------------------------ -----------------
> > View Permissions Results
> >
> > D:\home\Clients\Marketing4Tradesmen\cpi\.
> > COMPUTERNAME\USERNAME: (OI)(CI)F
> > D:\home\Clients\Marketing4Tradesmen\cpi\order-postprocess.as px
> > COMPUTERNAME\USERNAME: F
> >
> > Diagnostics complete
> >
> > View Site Configuration
> > W3SVC/1 Default
> > ServerState Server started
> > ServerBindings :80:
> > AuthFlags 5 (0x5) "AuthAnonymous | AuthNTLM"
> > ------------------------------------------------------------ -----------------
> > Authentication Results Url:http://localhost/clients/Marketing4Tradesmen/cpi/
> >
> > AnonymousUserPass logon failed Path:W3SVC
> >
> > AuthType:Anonymous AnonymousPasswordSync
> > The current configuration requires IIS subauthentication. However, the IIS
> > subauthentication component, iissuba.dll, is not currently configured.
> > Path:W3SVC
> >
> > AuthType:Anonymous
> > AnonymousPasswordSync
> > The current configuration uses IIS subauthentication for anonymous
> > authentication. This requires that the worker process be configured to run as
> > the Local System identity, which is not recommended for security reasons.
> > Path:W3SVC
> >
> > AuthType:Anonymous
> > must be domain member Path:W3SVC
> >
> > AuthType:Kerberos
> > Basic authentication is not a secure authentication protocol. You should
> > consider using Secure Sockets Layer (SSL) for added security.
> > Path:W3SVC/1/ROOT/clients/Marketing4Tradesmen/cpi
> > AuthType:Basic
> >
> > Test Authentication
> >
> > [THIS POPS A DIALOG BOX. VERIFYING THE PASSWORD FORTHE USER I AM WORKING
> > WITH RETURNS THE RESULT 'SUCCESS'. AUTHENTICATING THIS USER RETURNS:]
> > Server's response: HTTP/1.1 401 Unauthorized
> > Learn about IIS status codes
> >
> > Path:W3SVC/1/ROOT/clients/Marketing4Tradesmen/cpi
> > AuthType:Basic
> >
> > Diagnostics complete
> > ------------------------------------------------------------ -----------------
> > Server Permissions Results
> >
> > Verifying: C:\WINDOWS\help\iishelp\common\*
> > Account: BUILTIN\Administrators Access type: FULL
> > Account: NT AUTHORITY\SYSTEM Access type: FULL
> > Account: COMPUTERNAME\IIS_WPG Access type: READ
> > Account: BUILTIN\Users Access type: READ | EXECUTE
> > Check of C:\WINDOWS\help\iishelp\common\* complete, no errors
> >
> > Verifying: C:\WINDOWS\IIS Temporary Compressed Files\*
> > Account: BUILTIN\Administrators Access type: FULL
> > Account: NT AUTHORITY\SYSTEM Access type: FULL
> > Account: COMPUTERNAME\IIS_WPG Access type: READ | WRITE
> > Account: CREATOR OWNER Access type: FULL
> > CREATOR OWNER does not have 'FULL' access to .
> > Check of C:\WINDOWS\IIS Temporary Compressed Files\* complete, errors found
> >
> > Verifying: C:\WINDOWS\system32\inetsrv\*
> > Account: BUILTIN\Administrators Access type: FULL
> > Account: NT AUTHORITY\SYSTEM Access type: FULL
> > Check of C:\WINDOWS\system32\inetsrv\* complete, no errors
> >
> > Verifying: C:\WINDOWS\system32\inetsrv\*
> > Account: BUILTIN\Users Access type: READ | EXECUTE
> > BUILTIN\Users does not have 'READ | EXECUTE' access to ASP Compiled
> > Templates
> > BUILTIN\Users does not have 'READ | EXECUTE' access to History
> > BUILTIN\Users does not have 'READ | EXECUTE' access to
> > MBSchema.bin.00000000h
> > BUILTIN\Users does not have 'READ | EXECUTE' access to MBSchema.xml
> > BUILTIN\Users does not have 'READ | EXECUTE' access to MetaBase.xml
> > Check of C:\WINDOWS\system32\inetsrv\* complete, errors found
> >
> > Verifying: C:\WINDOWS\system32\inetsrv\ASP Compiled Templates\*
> > Account: COMPUTERNAME\IIS_WPG Access type: READ
> > Check of C:\WINDOWS\system32\inetsrv\ASP Compiled Templates\* complete, no
> > errors
> >
> > Verifying: C:\inetpub\adminscripts\*
> > Account: BUILTIN\Administrators Access type: FULL
> > Check of C:\inetpub\adminscripts\* complete, no errors
> >
> > Verifying: C:\WINDOWS\system32\Logfiles\*
> > Account: BUILTIN\Administrators Access type: FULL
> > Check of C:\WINDOWS\system32\Logfiles\* complete, no errors
> >
> > Diagnostics complete
> >
> > System Information:
> >
> > System time Mon, 29 Oct 2007 10:05:15 GMT
> > OS Windows 2003 Service Pack 2
> > W3SVC IIS6 - World Wide Web Publishing service is running
> > MSFTPSVC IIS6 - FTP Publishing service is not started
> > Host name COMPUTERNAME
> > Dns suffix jcfx.eu
> > Workgroup name WORKGROUPNAME
> > ModuleFileName C:\Program Files\IIS Resources\AuthDiag\authdiag.exe version:
> > 1.0:43.0
> >
> >
> >
> > "Jude Fisher" wrote:
> > > David,
> >
> > > 1) Just as a check I used NET USER /ADD on my test account and as expected
> > > it told me the user account already existed.
> >
> > > 2) No ISAPI filters are listed for any of the websites on this computer.
> >
> > > 3) I didn't set the server up myself (this is a dedicated server from a
> > > major UK host) but I can't see anything in Local Security Settings that could
> > > be causing the issue - is there anything specific I should be looking for,?
> >
> > > "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/WindowsServer2 003/Librar....
> >
> > > > 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
> > > > 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
> >
> > ...
> >
> > read more ;- Hide quoted text -
> >
> > - Show quoted text -
>
>
>

Re: Basic Authentication fails with Error 401.2 where Integrated s

Glad to hear a good resolution.

Yeah, ISAPI Filter (and ISAPI Extension) are low-level extensions/
modifications of IIS server behavior. Thus, they are my most likely
culprits whenever IIS is not behaving the way it should.

It sounds like the ISAPI Filter is doing one standard Custom
Authentication pattern where the authenticated user credential is not
a real Windows user. What basically happens is the ISAPI Filter
hijacks SOME authentication pattern (in this case, the Basic
authentication pattern) to make the browser pop up the login dialog
and send over the username/password, base64 decode the credentials,
authenticate against its own database, then alter the Authorization:
string to anonymous in SF_NOTIFY_PREPROC_HEADERS event (remember, the
username/password is not a real Windows user, so it cannot allow IIS
to see it past SF_NOTIFY_PREPROC_HEADERS because then IIS will try to
login with it, fail, and return 401.1).

The net effect is that you must have Anonymous authentication enabled
everywhere you want this custom Authentication filter to work, and the
filter hijacks the Basic Authentication pattern to pop up the login
dialog box. Of course, this filter destroys anyone trying to use Basic
authentication, but that's really a bug in the ISAPI filter in that it
implements an authentication protocol that does not peacefully coexist
with other protocols.

Another way for the filter to get the username/password is to send
back a HTML page that POSTs the username/password back to the server.
This will not require the filter to hijack the Basic authentication
pattern and thus allow it to co-exist with other authentication
schemes, but it *still* requires Anonymous authentication to be
enabled.

Anyways, this topic gets confusing complicated really quick, depending
on the custom ISAPI Filter code... so I'll stop here. :-)


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//








On Oct 30, 2:24 am, Jude Fisher
wrote:
> David,
>
> >>And please verify that there is no GLOBAL ISAPI FILTER -- you only
>
> mentioned the ISAPI Filters tab for each website but not the global
> ISAPI Filters tab for all website
>
> Thank you, this was the issue.
>
> I didn't realise the Web Sites folder in IIS manager threw up a global
> properties dialog. My host had helpfully installed a control panel (Matri=
x)
> which included a custom ISAPI filter called "Log In Filter". Removing that
> solved the problem immediately. It would have been nice, of course if the
> host (Fasthosts) could have told me about this but all their support was =
able
> to do was offer to restore the server from scratch in order to repair the
> problem they were certain I had caused. Not useful.
>
> Thanks also to Roger for the time spent on this.
>
> Jude Fisher / JcFx.Eu
>
>
>
> "David Wang" wrote:
> > You want to read the URL that I mentioned in my prior response to make
> > sure that Basic Authentication is allowed to function on your server.
>
> > I suspect the problem is either:
> > 1. some security module running on network packets stripping off
> > Authorization: Basic header and causing IIS to return 401.2 before
> > even invoking any security login code of IIS
> > 2. some security lockdown performed on the colo server that is
> > preventing basic authentication (and probably other things - we just
> > don't know what) from working within IIS
>
> > It is harder to validate #2 because it comes down to setting-by-
> > setting comparison of a working server with your server. I don't want
> > to get into that situation because I'd rather have the colo server
> > company tell me what they HAVE changed (they should have those changes
> > listed in an automation script somewhere since they built the server
> > for you) instead of trying to ask everyone else what could/not have
> > changed.
>
> > #1 requires that you validate with something like Network Monitor on
> > the server itself that the Authorization: Basic header is received by
> > the IIS web server (and not removed by some network security module).
> > And please verify that there is no GLOBAL ISAPI FILTER -- you only
> > mentioned the ISAPI Filters tab for each website but not the global
> > ISAPI Filters tab for all websites. At the same time, no Wildcard
> > Application Mapping for *ANY* of the Application mapping settings
> > applicable to the URL under question. There's no simple command to do
> > this -- because we are talking about deep, internal server
> > modifications (potentially made by other setup programs), one has to
> > know how IIS works to uncover what other setup programs have
> > configured.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Oct 29, 3:17 am, Jude Fisher
> > wrote:
> > > Further to the above, here are the results of the MS Authentication &=
Access
> > > Control Diagnostics tool. These are from the directory I want to be w=
orking
> > > with rather than the /test one but the settings and results are ident=
ical.
> > > Where it says COMPUTERNAME\
> > > ACCOUNTNAME, this is the account that I am trying to grant access to:
>
> > > ------------------------------------------------------------ ---------=
------=AD--
> > > Check Permissions Results
> > > Status Result
> > > Verifying: D:\home\Clients\Marketing4Tradesmen\cpi\*
> > > Account: COMPUTERNAME\ACCOUNTNAME Access type: FULL
> > > Check of D:\home\Clients\Marketing4Tradesmen\cpi\* complete, no erro=
rs
> > > Diagnostics complete
> > > ------------------------------------------------------------ ---------=
------=AD--
> > > View Permissions Results
>
> > > D:\home\Clients\Marketing4Tradesmen\cpi\.
> > > COMPUTERNAME\USERNAME: (OI)(CI)F
> > > D:\home\Clients\Marketing4Tradesmen\cpi\order-postprocess.as px
> > > COMPUTERNAME\USERNAME: F
>
> > > Diagnostics complete
>
> > > View Site Configuration =20
> > > W3SVC/1 Default
> > > ServerState Server started
> > > ServerBindings :80:
> > > AuthFlags 5 (0x5) "AuthAnonymous | AuthNTLM"
> > > ------------------------------------------------------------ ---------=
------=AD--
> > > Authentication Results Url:http://localhost/clients/Marketing4Tradesm=
en/cpi/
>
> > > AnonymousUserPass logon failed Path:W3SVC
>
> > > AuthType:Anonymous AnonymousPasswordSync
> > > The current configuration requires IIS subauthentication. However, th=
e IIS
> > > subauthentication component, iissuba.dll, is not currently configured.
> > > Path:W3SVC
>
> > > AuthType:Anonymous
> > > AnonymousPasswordSync
> > > The current configuration uses IIS subauthentication for anonymous
> > > authentication. This requires that the worker process be configured t=
o run as
> > > the Local System identity, which is not recommended for security reas=
ons.
> > > Path:W3SVC
>
> > > AuthType:Anonymous
> > > must be domain member Path:W3SVC
>
> > > AuthType:Kerberos
> > > Basic authentication is not a secure authentication protocol. You sh=
ould
> > > consider using Secure Sockets Layer (SSL) for added security.
> > > Path:W3SVC/1/ROOT/clients/Marketing4Tradesmen/cpi
> > > AuthType:Basic
>
> > > Test Authentication
>
> > > [THIS POPS A DIALOG BOX. VERIFYING THE PASSWORD FORTHE USER I AM WORK=
ING
> > > WITH RETURNS THE RESULT 'SUCCESS'. AUTHENTICATING THIS USER RETURNS:]
> > > Server's response: HTTP/1.1 401 Unauthorized
> > > Learn about IIS status codes
>
> > > Path:W3SVC/1/ROOT/clients/Marketing4Tradesmen/cpi
> > > AuthType:Basic
>
> > > Diagnostics complete =20
> > > ------------------------------------------------------------ ---------=
------=AD--
> > > Server Permissions Results
>
> > > Verifying: C:\WINDOWS\help\iishelp\common\*
> > > Account: BUILTIN\Administrators Access type: FULL
> > > Account: NT AUTHORITY\SYSTEM Access type: FULL
> > > Account: COMPUTERNAME\IIS_WPG Access type: READ
> > > Account: BUILTIN\Users Access type: READ | EXECUTE
> > > Check of C:\WINDOWS\help\iishelp\common\* complete, no errors
>
> > > Verifying: C:\WINDOWS\IIS Temporary Compressed Files\*
> > > Account: BUILTIN\Administrators Access type: FULL
> > > Account: NT AUTHORITY\SYSTEM Access type: FULL
> > > Account: COMPUTERNAME\IIS_WPG Access type: READ | WRITE
> > > Account: CREATOR OWNER Access type: FULL
> > > CREATOR OWNER does not have 'FULL' access to .
> > > Check of C:\WINDOWS\IIS Temporary Compressed Files\* complete, error=
s found
>
> > > Verifying: C:\WINDOWS\system32\inetsrv\*
> > > Account: BUILTIN\Administrators Access type: FULL
> > > Account: NT AUTHORITY\SYSTEM Access type: FULL
> > > Check of C:\WINDOWS\system32\inetsrv\* complete, no errors
>
> > > Verifying: C:\WINDOWS\system32\inetsrv\*
> > > Account: BUILTIN\Users Access type: READ | EXECUTE
> > > BUILTIN\Users does not have 'READ | EXECUTE' access to ASP Compiled
> > > Templates
> > > BUILTIN\Users does not have 'READ | EXECUTE' access to History
> > > BUILTIN\Users does not have 'READ | EXECUTE' access to
> > > MBSchema.bin.00000000h
> > > BUILTIN\Users does not have 'READ | EXECUTE' access to MBSchema.xml
> > > BUILTIN\Users does not have 'READ | EXECUTE' access to MetaBase.xml
> > > Check of C:\WINDOWS\system32\inetsrv\* complete, errors found
>
> > > Verifying: C:\WINDOWS\system32\inetsrv\ASP Compiled Templates\*
> > > Account: COMPUTERNAME\IIS_WPG Access type: READ
> > > Check of C:\WINDOWS\system32\inetsrv\ASP Compiled Templates\* comple=
te, no
> > > errors
>
> > > Verifying: C:\inetpub\adminscripts\*
> > > Account: BUILTIN\Administrators Access type: FULL
> > > Check of C:\inetpub\adminscripts\* complete, no errors
>
> > > Verifying: C:\WINDOWS\system32\Logfiles\*
> > > Account: BUILTIN\Administrators Access type: FULL
> > > Check of C:\WINDOWS\system32\Logfiles\* complete, no errors
>
> > > Diagnostics complete
>
> > > System Information:
>
> > > System time Mon, 29 Oct 2007 10:05:15 GMT
> > > OS Windows 2003 Service Pack 2
> > > W3SVC IIS6 - World Wide Web Publishing service is running
> > > MSFTPSVC IIS6 - FTP Publishing service is not started
> > > Host name COMPUTERNAME
> > > Dns suffix jcfx.eu
> > > Workgroup name WORKGROUPNAME
> > > ModuleFileName C:\Program Files\IIS Resources\AuthDiag\authdiag.exe v=
ersion:
> > > 1.0:43.0
>
> > > "Jude Fisher" wrote:
> > > > David,
>
> > > > 1) Just as a check I used NET USER /ADD on my test account and as e=
xpected
> > > > it told me the user account already existed.
>
> > > > 2) No ISAPI filters are listed for any of the websites on this comp=
uter.
>
> > > > 3) I didn't set the server up myself (this is a dedicated server fr=
om a
> > > > major UK host) but I can't see anything in Local Security Settings =
that could
> > > > be causing the issue - is there anything specific I should be looki=
ng for,?
>
> > > > "David Wang" wrote:
>
> > > > > When I see weird and erratic behavior, my first question is "do y=
ou
> > > > > 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 n=
ot
> > > > > allowed by default for security reasons. You hardly want the brow=
ser
> > > > > to automatically hand over your login password to ANY website whi=
ch
> > > > > asks for it, right?
>
> > > > > Thinking more esoterically now -- what are the login rights assig=
ned
> > > > > to your test user. IIS uses a specific login type (configurable),=
so
> > > > > ability to login via remote desktop is insufficient proof that II=
S can
> > > > > login that user. See this URL for more info:
> > > > >http://www.microsoft.com/technet/prodtechnol/WindowsServer2 003/Lib=
rar....
>
> > > > > Usually the defaults when you just create a user via NET USER name
> > > > > password /ADD will suffice, but sometimes Group Policies of a dom=
ain
> > > > > can alter this behavior (even if you've unjoined this machine fro=
m a
> > > > > domain).
>
> > > > > Are you sure you don't have a proxy or network policy/device whic=
h is
> > > > > simply forbidding Basic authentication altogether (because it exp=
oses
> > > > > 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:
>
> ...
>
> read more =BB- Hide quoted text -
>
> - Show quoted text -