Serious Bug: FormsAuthentication over Intranet MS Listen Up!!!!!

[Mark Olbert]

I have been wrestling with FormsAuthentication working on some, but not all, of my development
websites. I think I've determined what is causing the problem, but I can't figure out the
workaround/solution to use in the VS.NET environment.

Background: I recently changed my development environment so that, instead of having access to only
one website at a time on my WinXP development machine I now "host" the sites on a backend Win2K
server. This is all on an intranet; no traversal of the public internet takes place.

To differentiate among the different sites I use multihoming, with each site getting a unique IP
address in the 192.168.1.xxx range. I should point out that the same problem whose "solution" I
describe here also occurred when I was >>not<< using multihoming, but different host header names
instead.

After making that switch, and transitioning the development sites to the Win2K server, I found that
certain Forms Authentication setups that had been running well for months suddenly stopped working.

I confirmed this problem in a stripped-down test application that has only two forms, one a login
form and one an empty form in a protected subdirectory of the site. No real authentication is done;
clicking on the Submit button of the login from simply calls:

FormsAuthentication.RedirectFromLoginPage("user1", true);

Note that this call sets up, or should set up, a persistent cookie.

Only it doesn't. No cookie at all is created, and so the user gets continually bounced back to the
login form.

After researching this for hours on google groups and msdn I came across an old MSDN article
entitled Internet Explorer Drops Site Server Cookie for Intranet Site IP Address (279186). The
article, which dates back to 2002, talks about a problem that can be cured by using the numeric IP
address for an intranet site, rather than its human-readable name.

In desperation I tried (outside of VS.NET) accessing the site with a numeric IP...and the cookie was
created! Authentication succeeded, and I was able to see the protected page.

Accessing the site using the human readable name continued to fail outside of VS.NET, as it had
inside of the development environment.

This problem seems to me to be very serious, in that how the heck can a developer "host" multiple
projects on an intranet that use FormsAuthentication if some of them succeed and some of them
fail???

I anxiously await feedback from Microsoft on how to fix this stupid problem.

- Mark

 

[Natty Gur]

Hi,

It’s far from being a solution but i just wonder way are you using
multihoming in intranet solution. I use to host about 60 application on
single site (single IP) that use
FormsAuthentication without any problems.

Natty Gur[MVP]

blog : http://weblogs.asp.net/ngur
Mobile: +972-(0)58-888377

 

[Mark Olbert]

Ignorance?

Actually, I'm open to suggestion as to how best to handle multiple development sites simultaneously.
I'm currently trying multihoming, but I've also tried the host header approach (I encountered the
same problem, BTW).

What do you do/recommend?

- Mark

 

[Shiv Kumar]

Mark,

This is not a bug actually. As per the W3C, when searching the cookie list
for valid cookies, a comparison of the domain attributes of the cookie is
made with the Internet domain name of the host from which the URL will be
fetched. If there is a tail match, then the cookie will go through path
matching to see if it should be sent. "Tail matching" means that domain
attribute is matched against the tail of the fully qualified domain name of
the host. A domain attribute of "matlus.com" would match host names
"delphi.matlus.com" as well as "delphi.isapi.matlus.com".
Only hosts within the specified domain can set a cookie for a domain and
domains must have at least two (2) or three (3) periods in them to prevent
domains of the form: ".com", ".edu", and "va.us". Any domain that fails
within one of the seven special top-level domains listed below only require
two periods. Any other domain requires at least three. The seven special top
level domains are: "COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT". The
default value of domain is the host name of the server, which generated the
cookie response.

 

[Steven Cheng[MSFT]]

Hi Mark,


I'm sorry for keeping you waiting on the former post. I'm now assisting you
on it. Please feel free to followup in the former thread. As for the
question you mentioned in this one:
"how best to handle multiple development sites simultaneously"

In VS.NET there is a "CopyProject" function for you to copy an ASP.NET web
application from one place to another. You can try it via select the
"Project-->Copy Project..." menu. In the popup setting dialog, speciy a
destination position(using web url). Then, the VS.NET will help you to copy
the current web project to the specified place. Please try it out to see
whether it helps.


Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Natty Gur]

Hi,

I don’t see any need to use multiple sites on the same machine in
intranet situation. Usually this technique used by ISP that needs to
serve different sites with different IP's. This is certainly not the
case while developing intranet applications. you can host all your
applications in single site.

There are also situations where single application demand heavy network
traffic and to minimize that application impact on other application you
might set it to different IP with different network card.

Natty Gur[MVP]

blog : http://weblogs.asp.net/ngur
Mobile: +972-(0)58-888377

 

[Shiv Kumar]

This is certainly not the

case while developing intranet applications. you can host all your
applications in single site.

Provided you don't use global.asax in any form and your web.config file has
no special settings required by any of the applications.

 

[Natty Gur]

Why ?
Every application run in its own application domain and got its own
global.asax and web.config .

Natty Gur[MVP]

blog : http://weblogs.asp.net/ngur
Mobile: +972-(0)58-888377

 

[Mark Olbert]

Natty,

I've found that if I don't treat separate development projects (which will ultimately end up as
different websites, for different clients) as separate sites I run into problems like not being able
to resolve local addresses through MapPath() properly.

You may have misunderstood what I was getting at when I said "intranet". These projects will end up
running as separate, standalone websites once they are deployed. They don't all belong to the same
client.

I'm still interested in hearing what you do to develop separate projects for separate clients.

- Mark

 

[Mark Olbert]

Shiv,

I'm not sure I quite follow your argument, but if I'm understanding you, it still doesn't explain
why the site delivers the cookie when it is accessed as http://192.168.1.150 and fails to deliver
the cookie when it is accessed as http:://devproject1.arcabama.com, even though the DNS maps
192.168.1.150 to devproject1.arcabama.com. That's what my research shows as happening.

- Mark

 

[Mark Olbert]

Steven,

CopyProject wouldn't be appropriate in this particular case, because the test project I built (which
is exhibiting the problem) was built from the ground up on the Win2K server.

I'm interested in hearing an explanation as to why accessing a site via its numeric IP address
results in a cookie delivery while accessing it via its human-readable name fails to deliver a
cookie, even though the IP address and the name are mapped to each other in the DNS.

- Mark

 

[Shiv Kumar]

Mark,

Ok, I didn't understand "human readable" to mean it was dotted I assumed
it to be a single machine name kind of situation rather than a domain name.

I know from experience you can't use, say localhost (even though localhost
maps to 127.0.0.1) in applications that use cookies (not just ASP.NET but
any kind) or netbois names. You have to use IP addresses in these situation.
I've not tried names like you use. I guess there must be something in the
cookie specification that talks to non routable IP addresses being mapped to
dotted domain names as well then (from a security point of view).

All I can say is this is not a bug IMHO

 

[Mark Olbert]

Ah, but besides the fact that I think the behavior is pretty weird, the other reason I think it's a
bug is that it works on some of the intranet sites and not others...

- Mark

 

[Shiv Kumar]

Ah, but besides the fact that I think the behavior is pretty weird, the
other reason I think it's a

bug is that it works on some of the intranet sites and not others...

Sure, it's probably a bug. The question is where? I'm sure you've been
there before. It work here but not there etc. Eventually, you see the cause
of the problem and it's not a bug in your dev tool or platform but a
configuration bug of some sort.

Happy bug hunting

 

[Steven Cheng[MSFT]]

Hi Mark,


Thanks for your response. As you mentioned that the "Copy Project" may be
unsuitable for your situation, would you please provide some further info
on your situation(such as the reason why the "CopyProject" unsuitable) so
that we can try to search for some other approachs. The "Copy Project"
function is independent of the operation system(whehter server or
workstation). Here is the relative description in MSDN:
http://msdn.microsoft.com/library/en-us/vsintro7/html/vxtskcopyingproject.as
p?frame=true

In addition, you've mentioned another problem that "cookie delivery"
doesn't work in case of using the "domain name" address rather than the IP
address, does this problem occur within the same web application in the
former message(the particular test project)? would you please also provide
some more info on it so as for me to look for some relative materials to
assist you. Thanks.


Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Mark Olbert]

Steven,

The reason copy project is not appropriate is because I simply built the test project that's having
the problem, from scratch, on the server.

And yes, the built-from-scratch test project is experiencing the same problem.

- Mark

 

[Steven Cheng[MSFT]]

Hi Mark,

Thank you for the response. Regarding on the issue, we are
finding proper resource to assist you and we will update as soon as posible.


Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Eric]

Have you checked the MSDN knownledge article 313116?

Eric

 

[Steven Cheng[MSFT]]

Hi Mark,


Based on your situation that you used the "multi-homed network
configuration" for FormAuthenticaion, I'd like to confirm something so as
for us to do further throublshoot on it. Would you please check the
following items:

1. I think you may add an extra submit button to his logon page. Then add
code to the load event to add a test cookie and also write to the browser
the value of that cookie, if it exists. After he submits the page a couple
times, the cookie value should appear. If this works, then we know that
FormsAuthentication is likely to be the problem.

2. If the above test fails, we need to try another test. Would you please
try the same experiment with an *.ASP page placed in the same folder as the
..NET project that is failing. If the ASP page fails, then we know it's not
caused by .NET. If it works, then we know the problem is specific to .NET.

3.If the ASPX and ASP pages both fail, then try adding an HTML page and use
IIS settings to add a cookie header such as:
name: Set-Cookie
value: abc=testing; expires=Sat, 01-Jan-2050; path=/

Then after request the HTML page, you can look in the cookie folder on
your machine to see if you can got the cookie. If it works, then it's both
ASP and ASPX. If it fails, I'll look for other causes.


Please try out the preceding suggestions. And if you have any new findings
on this issue, please also let me know. Thanks.


Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Mark Olbert]

Steven,

I'll try your suggestions over the next few days, except for the one about trying an "old style" ASP
page. I don't know ASP, and don't intend to learn it just to debug something.

- Mark