can someone explain this weird behaviour?

Hi,

The situation: windows xp pro sp2 (IIS 5.1).
In the windows of IIS management, all virtual maps are under "Default
website".

The property "Map security" is first set on "Windows Integrated
Authentification".

There is a virtual map with property "Map security" set to "Anonymous
allowed" because this asp.net application is for anonymous users who must
login before they can perform some actions in the webapplication.
..
There are a login control, a creatuserwizard, password recovery .... in the
login.aspx. There is ASPNETDB.mdf located in dir. App_Data.

Now, when a user tries to login (or to create a new membership user),
notyhing happens (user is not logged or no new membership is created) but
there no error.

After hours searching the solution, I changed the property "Map security"
of the Default website to "Anonymous allowed" and ... eveything works!!

My question is: why does it not work when the property "Map security" of the
Default website is set to "Win. Integ. Auth" and it works when it is set to
"Anonymous"? It's like the property of the virtual map is overruled by the
property of the Default website...
Another virtual map with property "Map security" set to "Win. Integ. Auth"
works always, whatever is the property "Map security" of the Default
Website (anonymous or win. int. auth).

Thanks for explanation about this.
Mich

Re: can someone explain this weird behaviour?

I do not know what you mean by "Map security" because that is not IIS
terminology nor within its UI. I assume you mean "VDir security"
because you talk about "virtual maps under Default Website" and there
are only "virtual directories under Default Website" in IIS parlance.

Why things work/not work completely depends on the specifics of the
custom authentication protocol that you are using, which in this case
comes from ASP.Net and has nothing to do with IIS. There is likely a
logical explanation based on an understanding of the IIS and ASP.Net
request pipeline interaction, especially with security and
authentication since that is where both pipelines overlap and can
conflict, but that discussion is beyond the scope of casual
discussion. You can start with some articles from my blog at
http://blogs.msdn.com/David.Wang , but they only touch the tip of the
iceberg of how messy it can be prior to IIS7. This issue is first
resolved with managed extensibility in IIS7.

When using custom authentication, all URL involved with custom
authentication MUST be under anonymous authentication within IIS
configuration. Behavior may be unexpected otherwise. I suspect that
either the login or redirection URL are different between the apps
that you observe as always working or works only when Default website
has anonymous authentication enabled.


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






On Apr 10, 2:33 am, "Mich" wrote:
> Hi,
>
> The situation: windows xp pro sp2 (IIS 5.1).
> In the windows of IIS management, all virtual maps are under "Default
> website".
>
> The property "Map security" is first set on "Windows Integrated
> Authentification".
>
> There is a virtual map with property "Map security" set to "Anonymous
> allowed" because this asp.net application is for anonymous users who must
> login before they can perform some actions in the webapplication.
> .
> There are a login control, a creatuserwizard, password recovery .... in the
> login.aspx. There is ASPNETDB.mdf located in dir. App_Data.
>
> Now, when a user tries to login (or to create a new membership user),
> notyhing happens (user is not logged or no new membership is created) but
> there no error.
>
> After hours searching the solution, I changed the property "Map security"
> of the Default website to "Anonymous allowed" and ... eveything works!!
>
> My question is: why does it not work when the property "Map security" of the
> Default website is set to "Win. Integ. Auth" and it works when it is set to
> "Anonymous"? It's like the property of the virtual map is overruled by the
> property of the Default website...
> Another virtual map with property "Map security" set to "Win. Integ. Auth"
> works always, whatever is the property "Map security" of the Default
> Website (anonymous or win. int. auth).
>
> Thanks for explanation about this.
> Mich

Re: can someone explain this weird behaviour?

Hi david, thanks for replyinh.
You're right, it's "dir security".
You say:"Why things work/not work completely depends on the specifics of the
custom authentication protocol that you are using, which in this case
comes from ASP.Net and has nothing to do with IIS".

But for the same asp.net application with the same login control etc.. the
only thing that changes is the dir security property of the Default Website:
with "Anonymous", the application works, with "win.int. auth." it doesn't.
There must be somewhere an influence of that property on the application,
no?

In fact, i excpected a simple logical reason for this behaviour. I spznt
hours to solve this and by chance, i found it by changing the famous
property. Is this a normal situation? Am i suppose to know this? Is thsi a
lack of knowledge or experience?

"David Wang" schreef in bericht
news:1176290038.350117.114380@n59g2000hsh.googlegroups.com.. .
>I do not know what you mean by "Map security" because that is not IIS
> terminology nor within its UI. I assume you mean "VDir security"
> because you talk about "virtual maps under Default Website" and there
> are only "virtual directories under Default Website" in IIS parlance.
>
> Why things work/not work completely depends on the specifics of the
> custom authentication protocol that you are using, which in this case
> comes from ASP.Net and has nothing to do with IIS. There is likely a
> logical explanation based on an understanding of the IIS and ASP.Net
> request pipeline interaction, especially with security and
> authentication since that is where both pipelines overlap and can
> conflict, but that discussion is beyond the scope of casual
> discussion. You can start with some articles from my blog at
> http://blogs.msdn.com/David.Wang , but they only touch the tip of the
> iceberg of how messy it can be prior to IIS7. This issue is first
> resolved with managed extensibility in IIS7.
>
> When using custom authentication, all URL involved with custom
> authentication MUST be under anonymous authentication within IIS
> configuration. Behavior may be unexpected otherwise. I suspect that
> either the login or redirection URL are different between the apps
> that you observe as always working or works only when Default website
> has anonymous authentication enabled.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
>
>
> On Apr 10, 2:33 am, "Mich" wrote:
>> Hi,
>>
>> The situation: windows xp pro sp2 (IIS 5.1).
>> In the windows of IIS management, all virtual maps are under "Default
>> website".
>>
>> The property "Map security" is first set on "Windows Integrated
>> Authentification".
>>
>> There is a virtual map with property "Map security" set to "Anonymous
>> allowed" because this asp.net application is for anonymous users who must
>> login before they can perform some actions in the webapplication.
>> .
>> There are a login control, a creatuserwizard, password recovery .... in
>> the
>> login.aspx. There is ASPNETDB.mdf located in dir. App_Data.
>>
>> Now, when a user tries to login (or to create a new membership user),
>> notyhing happens (user is not logged or no new membership is created) but
>> there no error.
>>
>> After hours searching the solution, I changed the property "Map
>> security"
>> of the Default website to "Anonymous allowed" and ... eveything works!!
>>
>> My question is: why does it not work when the property "Map security" of
>> the
>> Default website is set to "Win. Integ. Auth" and it works when it is set
>> to
>> "Anonymous"? It's like the property of the virtual map is overruled by
>> the
>> property of the Default website...
>> Another virtual map with property "Map security" set to "Win. Integ.
>> Auth"
>> works always, whatever is the property "Map security" of the Default
>> Website (anonymous or win. int. auth).
>>
>> Thanks for explanation about this.
>> Mich
>
>

Re: can someone explain this weird behaviour?

IIS security configuration definitely influences the behavior of
applications running on it. Especially custom authentication like the
ASP.Net login control, etc -- think about it this way -- if you want
ASP.Net login control to authenticate username/password, do you want
IIS to also authenticate with another protocol before even allowing
ASP.Net page to execute and authenticate? Just because you put a login
control in ASP.Net page does NOT mean it's the only thing that
authenticates -- you have to look at the entire network stack and know
what happens when. Of course, you can say that this duplicate
authentication scheme seems confusing, and I agree -- and that is why
it got resolved in IIS7 -- but until then, you just need to be aware
of duplicate behaviors that can conflict and result in bizarre
behavior. The "Dir Security" property you change is one of the
potentially conflicting ones, and there are many others.

Simplicity of the reason depends on the level of understanding. I can
say "duplicate authentication implementations can conflict", but
without knowing how the two interact, one can hardly act on such
knowledge.


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





On Apr 11, 6:01 am, "Mich" wrote:
> Hi david, thanks for replyinh.
> You're right, it's "dir security".
> You say:"Why things work/not work completely depends on the specifics of the
> custom authentication protocol that you are using, which in this case
> comes from ASP.Net and has nothing to do with IIS".
>
> But for the same asp.net application with the same login control etc.. the
> only thing that changes is the dir security property of the Default Website:
> with "Anonymous", the application works, with "win.int. auth." it doesn't.
> There must be somewhere an influence of that property on the application,
> no?
>
> In fact, i excpected a simple logical reason for this behaviour. I spznt
> hours to solve this and by chance, i found it by changing the famous
> property. Is this a normal situation? Am i suppose to know this? Is thsi a
> lack of knowledge or experience?
>
> "David Wang" schreef in berichtnews:1176290038.350117.114380@n59g2000hsh.googlegroup s.com...
>
>
>
> >I do not know what you mean by "Map security" because that is not IIS
> > terminology nor within its UI. I assume you mean "VDir security"
> > because you talk about "virtual maps under Default Website" and there
> > are only "virtual directories under Default Website" in IIS parlance.
>
> > Why things work/not work completely depends on the specifics of the
> > custom authentication protocol that you are using, which in this case
> > comes from ASP.Net and has nothing to do with IIS. There is likely a
> > logical explanation based on an understanding of the IIS and ASP.Net
> > request pipeline interaction, especially with security and
> > authentication since that is where both pipelines overlap and can
> > conflict, but that discussion is beyond the scope of casual
> > discussion. You can start with some articles from my blog at
> >http://blogs.msdn.com/David.Wang, but they only touch the tip of the
> > iceberg of how messy it can be prior to IIS7. This issue is first
> > resolved with managed extensibility in IIS7.
>
> > When using custom authentication, all URL involved with custom
> > authentication MUST be under anonymous authentication within IIS
> > configuration. Behavior may be unexpected otherwise. I suspect that
> > either the login or redirection URL are different between the apps
> > that you observe as always working or works only when Default website
> > has anonymous authentication enabled.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Apr 10, 2:33 am, "Mich" wrote:
> >> Hi,
>
> >> The situation: windows xp pro sp2 (IIS 5.1).
> >> In the windows of IIS management, all virtual maps are under "Default
> >> website".
>
> >> The property "Map security" is first set on "Windows Integrated
> >> Authentification".
>
> >> There is a virtual map with property "Map security" set to "Anonymous
> >> allowed" because this asp.net application is for anonymous users who must
> >> login before they can perform some actions in the webapplication.
> >> .
> >> There are a login control, a creatuserwizard, password recovery .... in
> >> the
> >> login.aspx. There is ASPNETDB.mdf located in dir. App_Data.
>
> >> Now, when a user tries to login (or to create a new membership user),
> >> notyhing happens (user is not logged or no new membership is created) but
> >> there no error.
>
> >> After hours searching the solution, I changed the property "Map
> >> security"
> >> of the Default website to "Anonymous allowed" and ... eveything works!!
>
> >> My question is: why does it not work when the property "Map security" of
> >> the
> >> Default website is set to "Win. Integ. Auth" and it works when it is set
> >> to
> >> "Anonymous"? It's like the property of the virtual map is overruled by
> >> the
> >> property of the Default website...
> >> Another virtual map with property "Map security" set to "Win. Integ.
> >> Auth"
> >> works always, whatever is the property "Map security" of the Default
> >> Website (anonymous or win. int. auth).
>
> >> Thanks for explanation about this.
> >> Mich- Hide quoted text -
>
> - Show quoted text -

Re: can someone explain this weird behaviour?

Thanks

"David Wang" schreef in bericht
news:1176315183.077737.150960@y80g2000hsf.googlegroups.com.. .
> IIS security configuration definitely influences the behavior of
> applications running on it. Especially custom authentication like the
> ASP.Net login control, etc -- think about it this way -- if you want
> ASP.Net login control to authenticate username/password, do you want
> IIS to also authenticate with another protocol before even allowing
> ASP.Net page to execute and authenticate? Just because you put a login
> control in ASP.Net page does NOT mean it's the only thing that
> authenticates -- you have to look at the entire network stack and know
> what happens when. Of course, you can say that this duplicate
> authentication scheme seems confusing, and I agree -- and that is why
> it got resolved in IIS7 -- but until then, you just need to be aware
> of duplicate behaviors that can conflict and result in bizarre
> behavior. The "Dir Security" property you change is one of the
> potentially conflicting ones, and there are many others.
>
> Simplicity of the reason depends on the level of understanding. I can
> say "duplicate authentication implementations can conflict", but
> without knowing how the two interact, one can hardly act on such
> knowledge.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
>
> On Apr 11, 6:01 am, "Mich" wrote:
>> Hi david, thanks for replyinh.
>> You're right, it's "dir security".
>> You say:"Why things work/not work completely depends on the specifics of
>> the
>> custom authentication protocol that you are using, which in this case
>> comes from ASP.Net and has nothing to do with IIS".
>>
>> But for the same asp.net application with the same login control etc..
>> the
>> only thing that changes is the dir security property of the Default
>> Website:
>> with "Anonymous", the application works, with "win.int. auth." it
>> doesn't.
>> There must be somewhere an influence of that property on the application,
>> no?
>>
>> In fact, i excpected a simple logical reason for this behaviour. I spznt
>> hours to solve this and by chance, i found it by changing the famous
>> property. Is this a normal situation? Am i suppose to know this? Is thsi
>> a
>> lack of knowledge or experience?
>>
>> "David Wang" schreef in
>> berichtnews:1176290038.350117.114380@n59g2000hsh.googlegroup s.com...
>>
>>
>>
>> >I do not know what you mean by "Map security" because that is not IIS
>> > terminology nor within its UI. I assume you mean "VDir security"
>> > because you talk about "virtual maps under Default Website" and there
>> > are only "virtual directories under Default Website" in IIS parlance.
>>
>> > Why things work/not work completely depends on the specifics of the
>> > custom authentication protocol that you are using, which in this case
>> > comes from ASP.Net and has nothing to do with IIS. There is likely a
>> > logical explanation based on an understanding of the IIS and ASP.Net
>> > request pipeline interaction, especially with security and
>> > authentication since that is where both pipelines overlap and can
>> > conflict, but that discussion is beyond the scope of casual
>> > discussion. You can start with some articles from my blog at
>> >http://blogs.msdn.com/David.Wang, but they only touch the tip of the
>> > iceberg of how messy it can be prior to IIS7. This issue is first
>> > resolved with managed extensibility in IIS7.
>>
>> > When using custom authentication, all URL involved with custom
>> > authentication MUST be under anonymous authentication within IIS
>> > configuration. Behavior may be unexpected otherwise. I suspect that
>> > either the login or redirection URL are different between the apps
>> > that you observe as always working or works only when Default website
>> > has anonymous authentication enabled.
>>
>> > //David
>> >http://w3-4u.blogspot.com
>> >http://blogs.msdn.com/David.Wang
>> > //
>>
>> > On Apr 10, 2:33 am, "Mich" wrote:
>> >> Hi,
>>
>> >> The situation: windows xp pro sp2 (IIS 5.1).
>> >> In the windows of IIS management, all virtual maps are under "Default
>> >> website".
>>
>> >> The property "Map security" is first set on "Windows Integrated
>> >> Authentification".
>>
>> >> There is a virtual map with property "Map security" set to "Anonymous
>> >> allowed" because this asp.net application is for anonymous users who
>> >> must
>> >> login before they can perform some actions in the webapplication.
>> >> .
>> >> There are a login control, a creatuserwizard, password recovery ....
>> >> in
>> >> the
>> >> login.aspx. There is ASPNETDB.mdf located in dir. App_Data.
>>
>> >> Now, when a user tries to login (or to create a new membership user),
>> >> notyhing happens (user is not logged or no new membership is created)
>> >> but
>> >> there no error.
>>
>> >> After hours searching the solution, I changed the property "Map
>> >> security"
>> >> of the Default website to "Anonymous allowed" and ... eveything
>> >> works!!
>>
>> >> My question is: why does it not work when the property "Map security"
>> >> of
>> >> the
>> >> Default website is set to "Win. Integ. Auth" and it works when it is
>> >> set
>> >> to
>> >> "Anonymous"? It's like the property of the virtual map is overruled by
>> >> the
>> >> property of the Default website...
>> >> Another virtual map with property "Map security" set to "Win. Integ.
>> >> Auth"
>> >> works always, whatever is the property "Map security" of the Default
>> >> Website (anonymous or win. int. auth).
>>
>> >> Thanks for explanation about this.
>> >> Mich- Hide quoted text -
>>
>> - Show quoted text -
>
>