UNC file share and NTLM user identity
From: Michael Leung (kmleung@hec.com.hk)
Date: 04/14/03
- Next message: Michael Leung: "Windows Authentication Problem"
- Previous message: Mike Forman: "Authentication Ticket expiration"
- In reply to: Michael Leung: "UNC file share and NTLM user identity"
- Next in thread: Mike Moore [MS]: "RE: UNC file share and NTLM user identity"
- Reply: Mike Moore [MS]: "RE: UNC file share and NTLM user identity"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Michael Leung" <kmleung@hec.com.hk> Date: Sun, 13 Apr 2003 19:24:01 -0700
Hi Bassel, Moore & Karl,
Many thanks for your input.
20 NLB is just an example to highlight the complexity in
deployment - an important element in the cost of
ownership. As I have mentioned in my first posting, we are
not developing large-scale internet applications. While we
are evaluating ASP.NET, we found its potential of being
able to build intuitive and GUI-rich
internal "client/server-like" applications (using
javascript, custom-control and XML loading from host
without form submission). Again, the major benefit is easy
of deployment and the isolation of our application from
the ever-changing desktop environment. Of course, these
applications are also internet-ready.
So, we are not talking about hundreds of simultaneous
users making hundreds of hits per second to our IIS. We
may have fewer than 50 simultaneous users making a few
requests per second. However, each request is resource-
hungry because the applications are intuitive and GUI-
rich. Therefore, scale-out using NLB can compensate the
degraded performance on UNC fileshare.
In response to Karl, our applications are already
stateless. Users can bookmark any page and we use NTLM to
identify user role and access rights per request. We use
session variables purely because of the expensive $ per
SQL statement of our backend database (DB2/390). We don't
what to execute a particular SQL twice during a session
and therefore, we store the result-set using session
variables. Saving sessions in SQLServer is not preferred
because we do not want to introduce a second database just
for this purpose. (using DB2/390 is given - a company
directive) In addition, getting rid of client-affinity
doesn't solve the availability issue at all. A NLB member
having corrupted web-content is still alive and without
client-affinity, 50% of users selected by random are
affected assuming we have 2 NLBs. Even worse, users may
not report the problem if a "refresh" seems to solve the
problem, until it is very late. (e.g. 3am in the morning)
As for SAN storage network latency, I believe it is not a
big issue since ASPNET are compiled and stored in "c:\
winnt\microsoft.net\framework\v1.0.3705\temporary asp.net
files\". Every time when we deploy, we will clean this
directory up.
There are Lots of sayings that Kerberos authentication may
solve my problem but unfortunately, 95% of our clients are
using PanChinese NT4.0 and are upgrading to XP very slowly.
So we maintain our requirement: NTLM + NLB + UNC fileshare
and the problem statement is that User.Identity.Name is
lost once the web content is on a UNC fileshare.
Michael Leung
- Next message: Michael Leung: "Windows Authentication Problem"
- Previous message: Mike Forman: "Authentication Ticket expiration"
- In reply to: Michael Leung: "UNC file share and NTLM user identity"
- Next in thread: Mike Moore [MS]: "RE: UNC file share and NTLM user identity"
- Reply: Mike Moore [MS]: "RE: UNC file share and NTLM user identity"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
