[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1853
  • Last Modified:

IIS6.0 UNC Shared Virtual Directory 401.3 Error

Hey all,

I have the current setup:
- Web server (machine name "server") IIS6.0 Windows2003
- Web server has a header of "users.domain.com"
- Virtual directory named "Test"
- Virtual directory has passthru credentials enabled (the Always user the authenticated user's credentials when validating access to the network directory is checked)
- Virtual directory pointing to \\shares\Users
- Virtual directory has anon access removed
- Only Windows Authentication is enabled

- File server (machine name "shares") running Windows2003
- Share of "Users" has Everyone permissions and security set to Full Control

Both of these machines are in the same domain.

When I try to access http://users.domain.com/Test I get a credentials box which I fill out w/ the Administrator's credentials.  However, after that I'm greeted by 2 more attempts which then lead to a 401.3 error.  Does anyone know why on earth I can not for the life of me get access to that UNC share through a web browser?  Is there a local security policy that I have to set?  When I add the share to the "Shares that can be accessed anonymously" list, then I can get through, however the user is not the authenticated user, it's the ANON USER.

Thanks!
0
TivexExchange
Asked:
TivexExchange
  • 18
  • 8
  • 7
  • +1
1 Solution
 
Tacobell777Commented:
Does the user you enter have access to the UNC?
0
 
meverestCommented:
the server 'shares' where \\shares\users is located must be able to authenticate the remote user too, not just 'server' serving the iis.

go to the 'shares' server and make sure that the 'server' users have access to the physical location on disk referred to by 'users' share.

also, make sure that those users have 'access server from the network' allowed.

if the users are domain users, enter domain\username in the login box (or username@domain) instead of just the username.

cheers,  Mike.
0
 
TivexExchangeAuthor Commented:
Yes, of course. :)  If i type in the share in explorer: \\shares\Users I get in just fine.
0
Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

 
TivexExchangeAuthor Commented:
Meverest: Both \\shares and \\server use the same userbase: the domain users.  On \\shares, I enable "Everyone" to have full access.  I'm not sure if there's anything else to do.

Also, as for "Access this computer from the network" (I assume that's the User Right you're talking about), I have that set to "Everyone" for now, just to get this thing working!
0
 
TivexExchangeAuthor Commented:
Ah, also, I make sure to use the domain\username format...
0
 
meverestCommented:
ok,

you've covered just about everything except for disk permission (not just share permission)

it is good that both servers use the same userbase - simplifies things a lot - but you may need to be careful that there are no duplicate accounts set as local users on each server.

i probably don't need to tell you this, but for brevity i'll write it anyhow - excuse me if i'm telling you stuff you already know! ;-)

go to the shares server and open windows explorer.  go to where the \users share is located and right click on it, select properties and security.  make sure that the users are allowed read access to that folder and the relevent sub-folders.

cheers.


0
 
TivexExchangeAuthor Commented:
Ah yes... I mentioned it in the first post but didn't reiterate in the followup, but yes indeed, "Everyone" is set to full control on both the sharing permissions and the disk permissions.

I don't understand why this is so difficult.  I've tried every variation to get this working... the only time I've had success is when I enable Basic Authentication, but I don't want to have plain text going over the wire.  Besides, isn't Windows Authentication supposed to be all I need?
0
 
meverestCommented:
that's interesting - so it works ok with basic auth?  i wonder then whether it is a domain selection issue - maybe the workstations are logged on to the domain in some strange way that causes the auth to get confused...?

cheers.
0
 
TivexExchangeAuthor Commented:
Is there a way to log all attempts at accessing resources over the network as well as the credentials being used?

I use eventvwr to check out Security audits, and although I'm using credentials, the source of the audits get marked as "ANONYMOUS LOGON."  Very bizzare.
0
 
meverestCommented:
apparently the iis is letting the browser default to anonymous - do you have the allow anonymous unchecked for the virtual dir?

cheers.
0
 
TivexExchangeAuthor Commented:
Yes indeed... The only checkmark is Windows Authentication
0
 
meverestCommented:
beats me - have you consulted microsoft support/knowlegebase?

cheers.
0
 
TivexExchangeAuthor Commented:
Been searching all over the place... :)
0
 
McBaresarkCommented:
Sounds like you've got a delegation issue...

You need to enable delegation for the IIS webserver to allow Kerberos (Windows Integrated Auth) to make the 'double-hop' authentication from client-->webserver-->fileserver.  Open up AD Users and Computers, locate the computer account for the webserver and view its properties. Tick the checkbox marked 'Trust computer for delegation' (Windows2K) or one of the options under the 'Delegation' tab (Windows2K3), then sync your domain or wait 15 mins, and you're done.

This enables Kerberos support on the webserver itself (so that it can handle Kerberos negotiation directly rather than having to involve the DCs.)

See http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/remstorg.mspx for more info.

I've got a very similar issue to yours except it's only when trying to enumerate remote UNC share contents from server-side code (ASP/ASP.NET) that I get the error (symptoms exactly like yours).

Good luck - it's very tricky :-P

0
 
TivexExchangeAuthor Commented:
Hmmm... waited 15 mins (not sure how to sync up) ... but that still hasn't done it... do I have to trust any other computers?
0
 
McBaresarkCommented:
No - the 'Computer is trusted for delegation' setting on the webserver should be enough.

I may have spoken to soon - I went back and retested my basic assumptions and it looks like I'm getting EXACTLY the same problem as you (eg I haven't solved it yet). I'm fairly sure I'm on the right track though:

to use passthrough credentials with Windows Integrated Auth you MUST have delegation working correctly. Windows Integrated Auth has two 'sub-types':  NTLM and Kerberos. NTLM can't be delegated directly (although you CAN apparently proxy it, 'upgrading' it to Kerberos on the fly - see the section on Protocol Transition in that Remote Storage URL I posted previously) , whereas Kerberos can.

According to this article: http://support.microsoft.com/default.aspx?scid=kb;en-us;326985 you must have a valid SPN registered in AD matching the FQDN of the website you are serving from IIS to allow Kerberos to grant you a ticket.  Try adding one if you don't already have one for that FQDN. I tried it and it hasn't fixed my issue, but you never know...

Another thing to check (unlikely though) is whether the user account you are authenticating as when browsing the website (the same account which should be being 'passed-through' to the file server) isn't marked as 'Account is sensitive and cannot be delegated' (in AD User and Computers, properties of the user, Account tab).  If this property is ticked the account can't be delegated, preventing the webserver from delegating as that user.

What mode is your domain in (Win2K mixed? Win2K Native? Win2K3 Native?)



0
 
TivexExchangeAuthor Commented:
Everything is w2k3 native, fresh install... no hanky panky. :)

Buttt ahhhhh!  This SPN *does* look like it's the ticket!  The name of the machine is "host" and the website I'm accessing/using is "users" ... Lemme try that...
0
 
TivexExchangeAuthor Commented:
Well crizzap... that didn't do it either, but there's a lot of juicy-lookin' info in there that looks a bit solid for me to investigate.  I'll let you know what I find.
0
 
McBaresarkCommented:
What was the exact SPN you added?  Remember it needs to be the FQDN of the website, not just the hostname. Eg: something like

HTTP/users.domain.com

Another thing to check:  what browser are you using to test this?  You need at least IE5 to use Kerberos at all, and if you have IE6+ you will also need to ensure that the 'Enable Integrated Windows Authentication' option is ticked in Internet Options --> Advanced --> Security for it to work correctly.

Let me know how you go!
0
 
TivexExchangeAuthor Commented:
I'm all MS all the way ... default everything... ie6... long live MS! ;)

Yes, i used that (users.domain.com) ...

I should get around to this in the next few days... wish me luck!
0
 
McBaresarkCommented:
Luck :-)

OK - I've progressed a little towards sorting this one out...

When you next can, do the following:

1) Check that IE has 'Enable Integrated Windows Auth' ticked (as per previous post).
2) Put a dummy ASP/HTML page into the webroot of the 'users.domain.com' site (eg a 'Hello World' ASP page).
3) Close all your IE browser instances (to ensure that you don't use a current session).
4) Browse to your dummy page eg http://users.domain.com/dummy.asp.  You should not be prompted for credentials if you are already logged into the domain. If prompted, re-enter your details - you should only be asked once if at all (I'm assuming here that the user you are logging in with has both NTFS and SMB permissions sufficient to access both the website AND the remote share that the virtual dir is pointing to).
5) *WITHOUT* closing your browser, manually re-browse to the virtual dir you were previously having problems getting to (eg http://users.domain.com/Test). Does it work now?

It worked for me.  What I think is going on here is that if your first browse attempt to hit that web (during your session) targets remote content rather than local, IIS doesn't grant you a Kerberos ticket, and because you don't yet have a valid ticket the second 'hop' from IIS server-->file server is done using the ANONYMOUS account (eg there is no ticket to use for delegation yet). However, if you first hit local content during the session you are granted a Kerberos ticket by IIS, and then this ticket is able to be reused successfully for the duration of the session.

Why this is the case I don't know - whether this is the way it's supposed to work or the above behaviour is simply a workaround I'm unsure.  Using the above logic you could make this usable by putting a default page up which is local to the IIS web which your users hit first, which then redirects them to either the remote content directly or accesses that remote content with server-side code (eg using the FileSystemObject like I'm trying to do).

Anyone else more knowledgeable able to comment in this?  Maybe even explain it?

Luck...
0
 
TivexExchangeAuthor Commented:
Ahhh... well I've just spent another couple hours on this and no avail.  I do have a little more input on this.  The problem is that the host machine is getting Success logins from the account.  However, IIS still doesn't pass the correct login.

I've found that I can provide the Anon access w/ a user name and password, and I can log in just fine, however only under the impersonation of the account that I provide.

The main problem I think we're facing here is the domain scope.  When I try to log in, the credentials box has "Connect to web.domain.com" in the title.  The name of the IIS server is "web".   I'm assuming that my credentials are just plain jane "domain.com" ... How do I get web to accept "domain.com" ?

Since you're really the only one that's providing incredible assistance (THANK YOU!) would you be interested in meeting up on IM somehow and see if we can pow wow on this in real time?  I think it's solveable, but this is too slow. :)
0
 
TivexExchangeAuthor Commented:
Ahhhh... here we go... If I disable anon AND windows authentication, and enable Basic authentication w/ a default domain of "domain.com", I get the "domain.com" scope that I'm looking for and I log in just fine.  So WTF!  I don't want to go through the process of SSL just to get this working... what a waste... i have to be missing something!
0
 
meverestCommented:
there are a lot of comments here, so i won't bother checking if i have already asked this yet :-}

did you try entering "domain\username" in the logon box instead of just "username"?

cheers.
0
 
McBaresarkCommented:
As meverest just suggested, try entering 'domain\yourusername' when challenged for credentials (where domain = the NetBIOS name of your domain, and username = your NetBIOS username). Does it work?

Did you try the numbered steps I suggested last post (hitting local content first, then trying to access remote content during the same session)?  If so, what were your results?

You say "When I try to log in, the credentials box has "Connect to web.domain.com" in the title." - at what point are you getting this - when trying to access local IIS content (eg the dummy.asp page) or the remote virtual dir and its contents?

As you found out, Basic auth work fine - it's very easy to delegate since it doesn't involve Active Driectory and Kerberos (just checks the hashed userid/pwd pair against the local SAM on the target fileserver), but we really don't want to bother with SSL just to get passthrough auth working :-P

Email me at joec423@hotmail.com - I'll give you my IM details and we can chat further if you'd like. I'm on GMT+10:00...

0
 
TivexExchangeAuthor Commented:
As for your list, I can't even get past #4... It keeps asking me for credentials even though I've ensured that I use admin creds with full permissions on every conceivable level.

And also, I do indeed use domain\user for my logins, always. :)
0
 
TivexExchangeAuthor Commented:
Well I just solved another piece of the puzzle.  Looks like when I try to access this puppy locally by doing http://users/Test I log in just fine with the appropriate user.  So there is something horribly wrong w/ using ".domain.com" currently... I just need to figure out how to make all the machines understand that everyone is on the same domain. :)
0
 
McBaresarkCommented:
G'day Again,
Just replied to your email - I'll try to catch you online next time.

Until then, let's me go over some of the basics, just so that I'm clear (some of the things you just mentioned have confused me a little). Can you confirm the following checklist:

a) the IIS server is a domain member of a W2K3 native-mode domain.
b) the domain has a NetBIOS name of 'DOMAIN', and an Active Directory name of 'domain.com'
c) the IIS server has a NetBIOS name of 'SERVER', and an Active Directory name of 'server.domain.com'.
d) you are testing this setup by logging in from a different workstation on the network, which is also a member of the 'domain.com' domain.
e) the website you are testing against is setup to use host header names, and has a host header entry of 'users.domain.com' on port 80.
f) you've also got either a local HOSTS file entry on your workstation pointing 'users.domain.com' at the IIS server's IP address, or a similar DNS host record in your domain's DNS zone (so that when you ping users.domain.com the IIS server responds).
g) the website has both some local content in its webroot (eg dummy.asp) and a virtual dir called '/Test' pointing at a remote share on another fileserver, which also contains some web content.
h) the other fileserver hosting the content is also a domain member, and is called ?????.
i) the user account you are using to authenticate when browsing to the website is a domain account (not local to a single machine), called 'domain\myaccount' (NetBIOS) or 'myaccount@domain.com' (AD).
j) this user account has at least 'Read' permissions to the share that the '/Test' virtual dir is pointing to.
k) this user account has at least 'Read and Execute' NTFS permissions to the directory and all contents that this share is pointing to.
l) the IIS server is configured as 'Trusted for delegation' (either for all services, or just for HTTP (tcp/80)).
m) the 'domain\myaccount' is not configured as 'Sensitive and can't be delegated'.
n) you have an SPN configured called 'HTTP/users.domain.com' pointing at the IIS webserver.
o) you are using IE6+ with 'Enable Integrated Authentication' ticked.
p) you are NOT using a proxy server to connect to the website.
q) the website is configured to allow only Integrated Windows Auth, and the '/Test' virtual dir is configured to use passhthrough credentials.

Not sure of the answer to h) - the name of the remote fileserver you are pointing the '/Test' virtual dir at.  Also, a couple of posts back you said you were getting a credentials challenge dialog with 'web.doman.com' in the title. What host is 'web.domain.com'?  You haven't mentioned this previously (it's not the IIS server is it?). And finally, in your last post you said that you are not challenged when you browse to 'http://users/Test' locally (I presume you mean that you are still accessing the web from a seperate workstation, and not from the console of the IIS server?). Yet, in your initial post in this thread you said that the IIS server is called 'SERVER'.  How is it answering to 'http://users'?  Do you know if this is the result of NetBIOS or a DNS lookup? Is your local workstation's IP stack setup to automatically append the DNS domain to the end of all queries?  If not, the 'http://users' request is being answered by NetBIOS.

A lot of questions - but once these are cleared up we can at least rule out some things :-)
0
 
TivexExchangeAuthor Commented:
a-q is absolutely correct!  Good job.

What was once "server" is now "web" ... Sorry about that.  I've since nuked this machine and started over.  So it's "web.domain.com" that has a iis site "users.domain.com"  I'm assuming that the reason why it's answering to plain "http://users" is because of the SetSPN?  users is *not* the name of the machine, "web" is.  Ahh... then again there is a DNS record here in my local DNS server for "*" to point to the IP address of "web".  Sooo... hehe.  Still not sure exactly with how NetBIOS works...
0
 
TivexExchangeAuthor Commented:
Man I just found this tasty nugget:
http://support.microsoft.com/?id=832769

I thought for sure that this would be the answer to all my problems, since upon looking at the MetaBase file revealed that the NTAuthenticationProviders attribute was not specified for my users virtual server... but it still doesn't work heh...
0
 
TivexExchangeAuthor Commented:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerbdel.mspx

Pretty much has every answer you can imagine.

The problem here is that "users.domain.com" was not part of the intranet, which i have no idea why that's not default in a domain'd environment.  For some reason IE6 doesn't default to Kerebos over internet.  Now it's just a matter of forcing it to do so.  Thanks McBaresark for your assistance!
0
 
McBaresarkCommented:
This issue is now pretty much resolved (correct TivexExchange?)

To recap: all of the items I listed in my last post need to be in place, PLUS (this is the key) the website you are delegating from needs to be added to the Trusted Intranet zone in IE as TivexExchange just pointed out.  If the website is not in this zone it seems that IE doesn't bother using your Kerberos TGT at all, and your delegation won't work.

I guess this highlights something important:  Kerberos is not intended to be used on the public internet with clients which are not part of your Kerberos infrastructure.  Kerberos requires (in the Microsoft case) a domain infrastructure to be in place. A standalone user at home is usually not part of a domain, and if they are, there is no trust relationship between your (IIS) domain and theirs, thus no way of them taking part in your Kerberos infrastructure, and thus no way of using Kerberos delegation correctly.  Their connections to your website will be coming in with one of the earlier auth packages (Anonymous, Basic or NTLM), of which only Basic can normally be delegated (but not using Kerberos).

However, the new 'Protocol Transition' feature of W2K3 Server allows these older auth protocols to be upgraded to Kerberos on the fly. A discussion on this probably belongs in another thread though...

That link TivexExchange just posted is excellent - highly recommended if anyone is having trouble getting Kerberos delegation working.
0
 
meverestCommented:
suggest accept McBaresark
0
 
McBaresarkCommented:
Up to TivexExchange - technically he provided the final part of the puzzle :-)
0

Featured Post

Granular recovery for Microsoft Exchange

With Veeam Explorer for Microsoft Exchange you can choose the Exchange Servers and restore points you’re interested in, and Veeam Explorer will present the contents of those mailbox stores for browsing, searching and exporting.

  • 18
  • 8
  • 7
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now