| Groups | Blog | Home |
iis security : IIS6 - Virtual Directory to URL share, authentication problems.
I have set up a Virtual Directory set up to a remote share, and selected 'pass users credentials' to authenticate, as some users have more access than others to various folders within the share. Anonymous is also selected, as anonymous users are allowed to access some folders on the share ( I have given 'everyone' read and browse permissions to those folders). Integrated and Basic authentication are selected. I have also given the server 'delegation' rights. It works fine from WindowsXP machines within the domain. It does not work for users logged on to our Windows2003 Terminal Servers, but does work for an administrator logged on to the Terminal Servers. It does not work for users accessing the IIS server as a published server through our Windows2003/ISA Server2004 firewall. The symptoms when it does not work are that the user is asked for username/pw three times, and then the error 401.3 'access denied because of the ACls in force'. However, the IIS logs show that the correct domain\username is being used to try to access the share. The whole of the rest of a fairly complex Intranet web-site works fine, both within the network, and from outside through the firewall. Any help where I start to look next to resolve this? I have already studied about a dozen MS knowledgebase articles without success. Many of them talk about delegation facilities which are only available in a 'Native' Win2003 domain, and I can't make ours that as we have Win2000 Domain controllers (as well as one Win2003 DC). thanks, Bob
Thanks for this very full reply. I have now solved the external access, by
reducing them to basic authentication (and must now work on a certificate for SSL!). I am beginning to understand the internal problems. From what you say (and your book reference was very helpful) we haven't a hope of getting it to work with automatic logons from our many Windows98 machines, as they are not capable of Kerberos? Am I right? If so, I'm not sure where we move from here. I have been aiming for IIS6 on Windows2003 specifically as it allows user credentials to be passed to a UNC share on a remote server, but now it seems that that system has severe restrictions? Any suggestions for a workaround? The data is too large to copy onto the IIS server. I suppose I could run another IIS on the remote server, and route to there? Is this about the only way round it? yours, Bob [quoted text, click to view] "Ken Schaefer" <kenREMOVE@THISadopenstatic.com> wrote in message news:OMdJc08uEHA.1308@TK2MSFTNGP09.phx.gbl... > Two issues: > > a) I am assuming you are relying on automatic logon by the browser? > Automatic logon only works with > (i) Internet Explorer > (ii) the site is in the local Intranet security zone > > b) If you have a Windows 2000 domain then you do not have access to protocol > transition. Protocol transition is where one authentication mechanism is > used to authenticate to IIS, and then IIS gets a Kerberos token to connect > to the remote service, like so: > > browser <---NTLM ----> webserver <--- Kerberos ---> Other Server > > This is only available in a Windows 2003 functional mode domain. If you are > in a Windows 2000 functional mode domain, then authentication *must* be > Kerberos end-to-end: > > browser <--- Kerberos ---> webserver <--- Kerberos ---> Other Server > > So, you need to find out what authentication mechanism your browser is using > to connect to the webserver. Kerberos authentication relies on Kerberos > tickets, which are given out by the KDC (Key Distribution Center). In the > Windows world, the KDCs are hosted on the DCs. So, your browser must be able > to contact the DC to get a Kerberos ticket. Since you have some users > accessing the site through ISA Server, they are not going to be > authenticating using Kerberos - they are going to be authenticating using > NTLM, and that doesn't support double-hop authentication - the token that > IIS gets from the DC does not support authenticated access to "Other > Server". > > I'm not sure what is happening with the Terminal Servers > > Because the browser selects the first listed authentication protocol, and > IIS lists the protocols in descending order of strength, your external > clients are selecting NTLM over Basic authentication (even though you have > both selected). What you can do for your external clients is use Basic only > (with SSL). Basic authentication passes the username/password in clear text, > so IIS can directly impersonate the user when connecting to a remote > resource (of course, you need to strongly audit any code you have running on > the server so that it can't steal the usernames/passwords of users!) > > The following may be helpful: > http://www.adopenstatic.com/resources/books/293_CYA_IIS6_05.pdf > It's a chapter from the IIS6 security book that I co-authored (with Bernard > Cheah) > > Cheers > Ken >
Two issues:
a) I am assuming you are relying on automatic logon by the browser? Automatic logon only works with (i) Internet Explorer (ii) the site is in the local Intranet security zone b) If you have a Windows 2000 domain then you do not have access to protocol transition. Protocol transition is where one authentication mechanism is used to authenticate to IIS, and then IIS gets a Kerberos token to connect to the remote service, like so: browser <---NTLM ----> webserver <--- Kerberos ---> Other Server This is only available in a Windows 2003 functional mode domain. If you are in a Windows 2000 functional mode domain, then authentication *must* be Kerberos end-to-end: browser <--- Kerberos ---> webserver <--- Kerberos ---> Other Server So, you need to find out what authentication mechanism your browser is using to connect to the webserver. Kerberos authentication relies on Kerberos tickets, which are given out by the KDC (Key Distribution Center). In the Windows world, the KDCs are hosted on the DCs. So, your browser must be able to contact the DC to get a Kerberos ticket. Since you have some users accessing the site through ISA Server, they are not going to be authenticating using Kerberos - they are going to be authenticating using NTLM, and that doesn't support double-hop authentication - the token that IIS gets from the DC does not support authenticated access to "Other Server". I'm not sure what is happening with the Terminal Servers Because the browser selects the first listed authentication protocol, and IIS lists the protocols in descending order of strength, your external clients are selecting NTLM over Basic authentication (even though you have both selected). What you can do for your external clients is use Basic only (with SSL). Basic authentication passes the username/password in clear text, so IIS can directly impersonate the user when connecting to a remote resource (of course, you need to strongly audit any code you have running on the server so that it can't steal the usernames/passwords of users!) The following may be helpful: http://www.adopenstatic.com/resources/books/293_CYA_IIS6_05.pdf It's a chapter from the IIS6 security book that I co-authored (with Bernard Cheah) Cheers Ken [quoted text, click to view] "Bob Eadie" <robert@eadies.org.uk> wrote in message news:OHppyZ4uEHA.2684@TK2MSFTNGP12.phx.gbl... >I have IIS6 running on a Win2003 box within a mixed Win2000/Win2003 domain. > > I have set up a Virtual Directory set up to a remote share, and selected > 'pass users credentials' to authenticate, as some users have more access > than others to various folders within the share. Anonymous is also > selected, as anonymous users are allowed to access some folders on the > share > ( I have given 'everyone' read and browse permissions to those folders). > Integrated and Basic authentication are selected. > > I have also given the server 'delegation' rights. > > It works fine from WindowsXP machines within the domain. > > It does not work for users logged on to our Windows2003 Terminal Servers, > but does work for an administrator logged on to the Terminal Servers. > > It does not work for users accessing the IIS server as a published server > through our Windows2003/ISA Server2004 firewall. > > > The symptoms when it does not work are that the user is asked for > username/pw three times, and then the error 401.3 'access denied because > of > the ACls in force'. > > However, the IIS logs show that the correct domain\username is being used > to > try to access the share. > > The whole of the rest of a fairly complex Intranet web-site works fine, > both > within the network, and from outside through the firewall. > > > Any help where I start to look next to resolve this? I have already > studied > about a dozen MS knowledgebase articles without success. Many of them > talk > about delegation facilities which are only available in a 'Native' Win2003 > domain, and I can't make ours that as we have Win2000 Domain controllers > (as > well as one Win2003 DC). > > thanks, > > Bob > >
Hi,
Automatic Logon depends on: a) using IWA -and- b) using IE (5 or above) so, "yes", you can have automatic logon in Windows98 (because Win98 supports NTLM, which is one option underneath IWA) However, passing credentials across from webserver -> remote file server requires Kerberos (if IIS doesn't have the user's password), and Windows98 doesn't support Kerberos. If you have a Windows 2003 functional level domain, then you can use protocol transition, but you dont' have that either :-) There are other options: a) use Basic Authentication (+SSL). However, since you are no longer using IWA, you won't get automatic logon. Users will need to enter their credentials. Perhaps you could use this for your Win98 users only? b) use a common set of credentials to access the remote share (you supply these credentials to IIS). Not useful if you need to enforce different NTFS permissions for users c) write your own application (this is called the "trusted subsystem" approach). The web application would verify the user's permissions, and then use a common set of credentials to access the remote file store. [quoted text, click to view] > I have been aiming for IIS6 on Windows2003 specifically > as it allows user credentials to be passed to a UNC > share on a remote server, but now it seems > that that system has severe restrictions? Windows 2000 did this as well (if I recall correctly). The underlying issue is that the "secure" authentication mechanisms (Digest, NTLM, Kerberos) do not involve passing the user's password to IIS. So IIS never has the user's password. All it has is a token from the domain controller saying that the user is valid. By default, this token does not have permissions to network resources. If you use Basic Authentication, then IIS has the user's username and password, and it can directly impersonate the user (as far as the remote server is concerned, the user might as well be sitting at the IIS console). Cheers Ken [quoted text, click to view] "Bob Eadie" <robert@eadies.org.uk> wrote in message news:ejhy$SBvEHA.2200@TK2MSFTNGP11.phx.gbl... > Thanks for this very full reply. I have now solved the external access, > by > reducing them to basic authentication (and must now work on a certificate > for SSL!). > > I am beginning to understand the internal problems. From what you say > (and > your book reference was very helpful) we haven't a hope of getting it to > work with automatic logons from our many Windows98 machines, as they are > not > capable of Kerberos? Am I right? If so, I'm not sure where we move from > here. > > I have been aiming for IIS6 on Windows2003 specifically as it allows user > credentials to be passed to a UNC share on a remote server, but now it > seems > that that system has severe restrictions? Any suggestions for a > workaround? > The data is too large to copy onto the IIS server. I suppose I could run > another IIS on the remote server, and route to there? Is this about the > only way round it? > > yours, > > Bob > > > > "Ken Schaefer" <kenREMOVE@THISadopenstatic.com> wrote in message > news:OMdJc08uEHA.1308@TK2MSFTNGP09.phx.gbl... >> Two issues: >> >> a) I am assuming you are relying on automatic logon by the browser? >> Automatic logon only works with >> (i) Internet Explorer >> (ii) the site is in the local Intranet security zone >> >> b) If you have a Windows 2000 domain then you do not have access to > protocol >> transition. Protocol transition is where one authentication mechanism is >> used to authenticate to IIS, and then IIS gets a Kerberos token to >> connect >> to the remote service, like so: >> >> browser <---NTLM ----> webserver <--- Kerberos ---> Other Server >> >> This is only available in a Windows 2003 functional mode domain. If you > are >> in a Windows 2000 functional mode domain, then authentication *must* be >> Kerberos end-to-end: >> >> browser <--- Kerberos ---> webserver <--- Kerberos ---> Other Server >> >> So, you need to find out what authentication mechanism your browser is > using >> to connect to the webserver. Kerberos authentication relies on Kerberos >> tickets, which are given out by the KDC (Key Distribution Center). In the >> Windows world, the KDCs are hosted on the DCs. So, your browser must be > able >> to contact the DC to get a Kerberos ticket. Since you have some users >> accessing the site through ISA Server, they are not going to be >> authenticating using Kerberos - they are going to be authenticating using >> NTLM, and that doesn't support double-hop authentication - the token that >> IIS gets from the DC does not support authenticated access to "Other >> Server". >> >> I'm not sure what is happening with the Terminal Servers >> >> Because the browser selects the first listed authentication protocol, and >> IIS lists the protocols in descending order of strength, your external >> clients are selecting NTLM over Basic authentication (even though you >> have >> both selected). What you can do for your external clients is use Basic > only >> (with SSL). Basic authentication passes the username/password in clear > text, >> so IIS can directly impersonate the user when connecting to a remote >> resource (of course, you need to strongly audit any code you have running > on >> the server so that it can't steal the usernames/passwords of users!) >> >> The following may be helpful: >> http://www.adopenstatic.com/resources/books/293_CYA_IIS6_05.pdf >> It's a chapter from the IIS6 security book that I co-authored (with > Bernard >> Cheah) >> >> Cheers >> Ken >> > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |