TivexExchange
asked on
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!
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!
Does the user you enter have access to the UNC?
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.
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.
ASKER
Yes, of course. :) If i type in the share in explorer: \\shares\Users I get in just fine.
ASKER
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!
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!
ASKER
Ah, also, I make sure to use the domain\username format...
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.
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.
ASKER
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?
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?
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.
cheers.
ASKER
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.
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.
apparently the iis is letting the browser default to anonymous - do you have the allow anonymous unchecked for the virtual dir?
cheers.
cheers.
ASKER
Yes indeed... The only checkmark is Windows Authentication
beats me - have you consulted microsoft support/knowlegebase?
cheers.
cheers.
ASKER
Been searching all over the place... :)
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-->files
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
You need to enable delegation for the IIS webserver to allow Kerberos (Windows Integrated Auth) to make the 'double-hop' authentication from client-->webserver-->files
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
ASKER
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?
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?)
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?)
ASKER
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...
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...
ASKER
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.
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!
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!
ASKER
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!
Yes, i used that (users.domain.com) ...
I should get around to this in the next few days... wish me luck!
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...
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...
ASKER
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. :)
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. :)
ASKER
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!
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.
did you try entering "domain\username" in the logon box instead of just "username"?
cheers.
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...
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...
ASKER
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. :)
And also, I do indeed use domain\user for my logins, always. :)
ASKER
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. :)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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...
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...
ASKER
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...
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...
ASKER
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!
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!
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.
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.
suggest accept McBaresark
Up to TivexExchange - technically he provided the final part of the puzzle :-)