RE: UNC file share and NTLM user identity

• Previous message: Mike Moore [MS]: "Re: Setting Principal for HttpWorkerRequest"
• In reply to: Michael Leung: "UNC file share and NTLM user identity"
• Next in thread: Michael Leung: "RE: UNC file share and NTLM user identity"
• Reply: Michael Leung: "RE: UNC file share and NTLM user identity"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: michmo@online.microsoft.com ("Mike Moore [MS]")
Date: Fri, 18 Apr 2003 23:52:26 GMT

Hi Michael,

I apologize for the delay in getting back to you. I've been on vacation. I
will look into this further on Monday.

One quick note - Earlier I mentioned shell extensions. I checked and found
out that this will not work for you. Shell namespace extensions cannot be
used to access remote file shares. A file system driver would be required
to make the remote share appear as though it were local. If you have
programmers who are already comfortable with writing drivers, then this
might be an option.

Thank you, Mike Moore
Microsoft, ASP.NET

This posting is provided "AS IS", with no warranties, and confers no rights.

--------------------
| >Content-Class: urn:content-classes:message
| >From: "Michael Leung" <kmleung@hec.com.hk>
| >Sender: "Michael Leung" <kmleung@hec.com.hk>
| >References: <01ed01c2fc3f$53a88f10$a601280a@phx.gbl>
| >Subject: UNC file share and NTLM user identity
| >Date: Sun, 13 Apr 2003 19:24:01 -0700
| >Lines: 58
| >Message-ID: <032c01c3022c$e9b621f0$3301280a@phx.gbl>
| >MIME-Version: 1.0
| >Content-Type: text/plain;
| > charset="iso-8859-1"
| >Content-Transfer-Encoding: 7bit
| >X-Newsreader: Microsoft CDO for Windows 2000
| >X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
| >Thread-Index: AcMCLOmzNnNyBwWXQJ6DG08fp8rXCQ==
| >Newsgroups: microsoft.public.dotnet.framework.aspnet.security
| >Path: cpmsftngxa06.phx.gbl
| >Xref: cpmsftngxa06.phx.gbl
microsoft.public.dotnet.framework.aspnet.security:4797
| >NNTP-Posting-Host: TK2MSFTNGXA02 10.40.1.51
| >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.security
| >
| >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
| >

• Previous message: Mike Moore [MS]: "Re: Setting Principal for HttpWorkerRequest"
• In reply to: Michael Leung: "UNC file share and NTLM user identity"
• Next in thread: Michael Leung: "RE: UNC file share and NTLM user identity"
• Reply: Michael Leung: "RE: UNC file share and NTLM user identity"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]