If you are trying to use Integrated authentication and it's over the Internet, there is a probability it won't work. Do you know if you are using Basic, NTLM, or Kerberos authentication. If you don't know... you should, and you should configure it that way. Also, as Bernard points out, IE has different authentication behavior between Intranet sites (sitenames without dots) and Internet sites (sitenames with at least one dot). Once again, that would be a client-configuration issue. -- //David IIS This posting is provided "AS IS" with no warranties, and confers no rights. // [quoted text, click to view] "Massimo" <barone@mclink.it> wrote in message news:%23DC84oLeDHA.3204@TK2MSFTNGP11.phx.gbl...
"Massimo" <barone@mclink.it> ha scritto nel messaggio news:ewtiuMLeDHA.1820@TK2MSFTNGP10.phx.gbl... [quoted text, click to view] > Now, the problem... > > When I connect to this server using http://frontend, > http://frontend/Exchange, http://www, http://www/Exchange or http://test, > everything works fine. The standard website works, OWA works, requiring > authentication, and the test website works, requiring authentication too. > When I connect using the FQDNs, such as http://frontend.mydomain.com, > http://www.mydomain.com/Exchange or http://test.mydomain.com, authentication > stops working: the standard site keeps being accessible (since it grants > anonymous access), but all authentication-requiring sites and folders keep > asking for username/password and rejecting them. So I'm getting access > denied on both OWA and the test website. > > I really can't understand this... if it is some sort of permission problem, > why is the behaviour changing based on the hostname used ? A little update: if I try to access the website through its IP, it still doesn't work; i.e., http://192.168.42.20/Exchange doesn't work, only http://frontend/Exchange and http://www/Exchange do. [quoted text, click to view] > Can someone spread some light on this, please ? I really need to get this > to work, and soon.
It's even more urgent now... I really need help on this :-( Massimo
I have a very strange problem with a Windows 2003 webserver. The machine is part of a (2003) domain which we'll call "mydomain.com", and DNS is so configured: frontend.mydomain.com -> 192.168.42.20 www -> frontend.mydomain.com test -> frontend.mydomain.com The webserver is running two sites: the default site and another one listening for requests containing the host header "test.mydomain.com" or "test". On the default site, Exchange OWA (2003) is also installed. The default site root is configured for anonymous access, while the Exchange virtual sub-folder requires authentication (both windows-integrated or standard). The test site is configured to allow only authenticated access, again both windows-integrated and standard. NTFS permissions are set on both sites to allow access to appropriate users (or IIS service accounts). Now, the problem... When I connect to this server using http://frontend, http://frontend/Exchange, http://www, http://www/Exchange or http://test, everything works fine. The standard website works, OWA works, requiring authentication, and the test website works, requiring authentication too. When I connect using the FQDNs, such as http://frontend.mydomain.com, http://www.mydomain.com/Exchange or http://test.mydomain.com, authentication stops working: the standard site keeps being accessible (since it grants anonymous access), but all authentication-requiring sites and folders keep asking for username/password and rejecting them. So I'm getting access denied on both OWA and the test website. I really can't understand this... if it is some sort of permission problem, why is the behaviour changing based on the hostname used ? Can someone spread some light on this, please ? I really need to get this to work, and soon. Thanks... Massimo
"Massimo" <barone@mclink.it> ha scritto nel messaggio news:ewtiuMLeDHA.1820@TK2MSFTNGP10.phx.gbl... [quoted text, click to view] > Now, the problem... > > When I connect to this server using http://frontend, > http://frontend/Exchange, http://www, http://www/Exchange or http://test, > everything works fine. The standard website works, OWA works, requiring > authentication, and the test website works, requiring authentication too. > When I connect using the FQDNs, such as http://frontend.mydomain.com, > http://www.mydomain.com/Exchange or http://test.mydomain.com, authentication > stops working: the standard site keeps being accessible (since it grants > anonymous access), but all authentication-requiring sites and folders keep > asking for username/password and rejecting them. So I'm getting access > denied on both OWA and the test website. > > I really can't understand this... if it is some sort of permission problem, > why is the behaviour changing based on the hostname used ? A little update: if I try to access the website through its IP, it still doesn't work; i.e., http://192.168.42.20/Exchange doesn't work, only http://frontend/Exchange and http://www/Exchange do. [quoted text, click to view] > Can someone spread some light on this, please ? I really need to get this > to work, and soon.
It's even more urgent now... I really need help on this :-( Massimo
"Bernard" <qbernard@hotmail.com> ha scritto nel messaggio news:u9B3fRNeDHA.3584@tk2msftngp13.phx.gbl... [quoted text, click to view] > Try this > Intranet Site Is Identified as an Internet Site When You Use an FQDN > or IP Address > http://support.microsoft.com/?id=303650 I don't think that's my problem... and, howewer, I need that websites to be accessible from the Internet, so they *should* work when accessing them across different domain. Massimo
"David Wang [Msft]" <someone@online.microsoft.com> ha scritto nel messaggio news:%23awE%23dPeDHA.1680@TK2MSFTNGP09.phx.gbl... [quoted text, click to view] > If you are trying to use Integrated authentication and it's over the > Internet, there is a probability it won't work.
Ok, but shouldn't IIS resort to standard authentication, once integrated failed ? [quoted text, click to view] > Do you know if you are using Basic, NTLM, or Kerberos authentication. If > you don't know... you should, and you should configure it that way.
There is also another strange behaviour; in the IIS console, I configured the websites to use mydomain.com as the default authentication domain, so I only have to specify the username and password in the client (OWA also was pre-configured this way). But when I'm accessing them with FQDN or IP, the logon dialog says it's accessing "frontend.mydomain.com", and after the first failed logon attempt, it shows the username as frontend.mydomain.com\username, instead of mydomain.com\username. I hope this can help you finding out what's happening... [quoted text, click to view] > Also, as Bernard points out, IE has different authentication behavior > between Intranet sites (sitenames without dots) and Internet sites > (sitenames with at least one dot). Once again, that would be a > client-configuration issue.
But I need to access these websites from the Internet, too... and they show the same behaviour when accessing them with FQDN or IP from an Internet connection. Massimo
Try this Intranet Site Is Identified as an Internet Site When You Use an FQDN or IP Address http://support.microsoft.com/?id=303650 -- Regards, Bernard Cheah http://support.microsoft.com/ Please respond to newsgroups only ... [quoted text, click to view] "Massimo" <barone@mclink.it> wrote in message news:#DC84oLeDHA.3204@TK2MSFTNGP11.phx.gbl... > "Massimo" <barone@mclink.it> ha scritto nel messaggio > news:ewtiuMLeDHA.1820@TK2MSFTNGP10.phx.gbl... > > > Now, the problem... > > > > When I connect to this server using http://frontend, > > http://frontend/Exchange, http://www, http://www/Exchange or http://test, > > everything works fine. The standard website works, OWA works, requiring > > authentication, and the test website works, requiring authentication too. > > When I connect using the FQDNs, such as http://frontend.mydomain.com, > > http://www.mydomain.com/Exchange or http://test.mydomain.com, > authentication > > stops working: the standard site keeps being accessible (since it grants > > anonymous access), but all authentication-requiring sites and folders keep > > asking for username/password and rejecting them. So I'm getting access > > denied on both OWA and the test website. > > > > I really can't understand this... if it is some sort of permission > problem, > > why is the behaviour changing based on the hostname used ? > > A little update: if I try to access the website through its IP, it still > doesn't work; i.e., http://192.168.42.20/Exchange doesn't work, only > http://frontend/Exchange and http://www/Exchange do. > > > Can someone spread some light on this, please ? I really need to get this > > to work, and soon. > > It's even more urgent now... I really need help on this :-( > > Massimo >
Let me clear up your misconceptions about authentication... Authentication is something that is MUTUALLY NEGOTIATED between the client and the server. The user only gets to configure the authentication types (anonymous/basic/Integrated/etc) that the server will negotiate with. Likewise, the client can be configured to auto-negotiate or not, based on configuration (IE does this with Zones). So, there is no "fallback" authentication upon failure. It is all in the negotiation between the client an the server, and it's all defined by user configuration. It would be a security risk for the server/client to automatically fallback and not allow the user to configure when/how. Now that you understand that authentication is a process of mutual negotiation between the client browser and the server, let's look at the details: - Integrated Authentication is actually a selection of several protocols. For a stand-alone server, this means NTLM by default. For a server in a domain, IIS favors Kerberos, though NTLM is a configurable default as well. Kerberos is not possible for stand-alone server since it needs Active Directory. - NTLM does not work well in an Internet environment because it is a connection based protocol. If there is a proxy in between the client and the server, it can disrupt NTLM. You cannot control whether there is a proxy because you cannot control whether the client comes from a proxy or not. Thus, in general, this is hit-or-miss. In an Intranet scenario, NTLM works well. - Kerberos is ticket-based authentication that doesn't have the connection restrictions, though it needs port access to a KDC to obtain its tickets. - Basic auth is simplest because it is base64 encoding of "username:password" sent with the request. Hence it needs to be encrypted with SSL to be safe. I've already explained that IE configures auto-logon based on Zone, and Zone determination is affected by the presence of dots in the URL. What I think you should do is: 1. If your server can use Kerberos, do that. This requires the server to be in a domain and access to an Active Directory 2. If #1 is not possible, try Basic over SSL. If you are interested in more debugging -- get a Network sniffer hooked up (Windows Server 2003 comes with one, Network Monitor, that you can install from Add/Remove Windows Components) and sniff the entire request/response transaction between your client and the server in your failing case, post it. The sniff will tell everything about what's causing your access-denied dialogs without any more speculation. -- //David IIS This posting is provided "AS IS" with no warranties, and confers no rights. // [quoted text, click to view] "Massimo" <barone@mclink.it> wrote in message news:%23NiPvvPeDHA.956@TK2MSFTNGP09.phx.gbl...
"David Wang [Msft]" <someone@online.microsoft.com> ha scritto nel messaggio news:%23awE%23dPeDHA.1680@TK2MSFTNGP09.phx.gbl... [quoted text, click to view] > If you are trying to use Integrated authentication and it's over the > Internet, there is a probability it won't work.
Ok, but shouldn't IIS resort to standard authentication, once integrated failed ? [quoted text, click to view] > Do you know if you are using Basic, NTLM, or Kerberos authentication. If > you don't know... you should, and you should configure it that way.
There is also another strange behaviour; in the IIS console, I configured the websites to use mydomain.com as the default authentication domain, so I only have to specify the username and password in the client (OWA also was pre-configured this way). But when I'm accessing them with FQDN or IP, the logon dialog says it's accessing "frontend.mydomain.com", and after the first failed logon attempt, it shows the username as frontend.mydomain.com\username, instead of mydomain.com\username. I hope this can help you finding out what's happening... [quoted text, click to view] > Also, as Bernard points out, IE has different authentication behavior > between Intranet sites (sitenames without dots) and Internet sites > (sitenames with at least one dot). Once again, that would be a > client-configuration issue.
But I need to access these websites from the Internet, too... and they show the same behaviour when accessing them with FQDN or IP from an Internet connection. Massimo
Did you configure the NTAuthenticationProviders property on one of the servers but not the other? Maybe they are running different software and one of the software made the setting change for you? -- //David IIS This posting is provided "AS IS" with no warranties, and confers no rights. // [quoted text, click to view] "Massimo" <barone@mclink.it> wrote in message news:uRCjhwWeDHA.3280@tk2msftngp13.phx.gbl...
"Massimo" <barone@mclink.it> ha scritto nel messaggio news:eAJiPiWeDHA.3228@tk2msftngp13.phx.gbl... [quoted text, click to view] > > Let me clear up your misconceptions about authentication... > > That's fine, and thanks for your explanations. > But it seems like it's a problem of that specific webserver, since another > server works fine both with the computer name (http://server1) and the full > name ( http://server1.mydomain.com). And they are configured in the same way, > allowing both windows-integrated and standard authentication, with the > default authentication domain being mydomain.com. > So, why does one of them work and not the other ? > > I changed some configuration and authentication parameters on the web server > that's not working (I moved wwwroot and there are some sites allowing > anonymous connections using accounts different than IUSR_SERVERNAME), but > if this is a permission problem, why is it based on the name I access the > server with ? A little update: I've disabled windows integrated authentication, and now the server works, requiring me to input username and password, of course. The other server keeps working fine with both modes. So, why are these two servers acting so different ? Another strangeness I saw, maybe this can help: when I try to login to the "wild" server from different machines, I type my usernames and password, and when the dialog comes back because authentication failed, it says MACHINENAME\username, where MACHINENAME is the name of the computer I'm sitting at, the one I'm trying to login from. This is strange, shouldn't it try to login using domain accounts ? The default authentication domain for the server is, of course, my AD domain. Massimo
"David Wang [Msft]" <someone@online.microsoft.com> ha scritto nel messaggio news:eSd8INWeDHA.2268@TK2MSFTNGP10.phx.gbl... [quoted text, click to view] > Let me clear up your misconceptions about authentication...
That's fine, and thanks for your explanations. But it seems like it's a problem of that specific webserver, since another server works fine both with the computer name (http://server1) and the full name ( http://server1.mydomain.com). And they are configured in the same way, allowing both windows-integrated and standard authentication, with the default authentication domain being mydomain.com. So, why does one of them work and not the other ? I changed some configuration and authentication parameters on the web server that's not working (I moved wwwroot and there are some sites allowing anonymous connections using accounts different than IUSR_SERVERNAME), but if this is a permission problem, why is it based on the name I access the server with ? Massimo
"Massimo" <barone@mclink.it> ha scritto nel messaggio news:eAJiPiWeDHA.3228@tk2msftngp13.phx.gbl... [quoted text, click to view] > > Let me clear up your misconceptions about authentication... > > That's fine, and thanks for your explanations. > But it seems like it's a problem of that specific webserver, since another > server works fine both with the computer name (http://server1) and the full > name ( http://server1.mydomain.com). And they are configured in the same way, > allowing both windows-integrated and standard authentication, with the > default authentication domain being mydomain.com. > So, why does one of them work and not the other ? > > I changed some configuration and authentication parameters on the web server > that's not working (I moved wwwroot and there are some sites allowing > anonymous connections using accounts different than IUSR_SERVERNAME), but > if this is a permission problem, why is it based on the name I access the > server with ? A little update: I've disabled windows integrated authentication, and now the server works, requiring me to input username and password, of course. The other server keeps working fine with both modes. So, why are these two servers acting so different ? Another strangeness I saw, maybe this can help: when I try to login to the "wild" server from different machines, I type my usernames and password, and when the dialog comes back because authentication failed, it says MACHINENAME\username, where MACHINENAME is the name of the computer I'm sitting at, the one I'm trying to login from. This is strange, shouldn't it try to login using domain accounts ? The default authentication domain for the server is, of course, my AD domain. Massimo
Can someone please post his thoughts on this ? [quoted text, click to view] > > > Let me clear up your misconceptions about authentication... > > > > That's fine, and thanks for your explanations. > > But it seems like it's a problem of that specific webserver, since another > > server works fine both with the computer name (http://server1) and the full > > name ( http://server1.mydomain.com). And they are configured in the same > > way, allowing both windows-integrated and standard authentication, with > > the default authentication domain being mydomain.com. > > So, why does one of them work and not the other ? > > > > I changed some configuration and authentication parameters on the web > > server that's not working (I moved wwwroot and there are some sites > > allowing anonymous connections using accounts different than > > IUSR_SERVERNAME), but if this is a permission problem, why is it based > > on the name I access the server with ? > > A little update: I've disabled windows integrated authentication, and now > the server works, requiring me to input username and password, of course. > The other server keeps working fine with both modes. > So, why are these two servers acting so different ? > Another strangeness I saw, maybe this can help: when I try to login to the > "wild" server from different machines, I type my usernames and password, and > when the dialog comes back because authentication failed, it says > MACHINENAME\username, where MACHINENAME is the name of the computer I'm > sitting at, the one I'm trying to login from. This is strange, shouldn't it > try to login using domain accounts ? The default authentication domain for > the server is, of course, my AD domain. Massimo
"Bernard" <qbernard@hotmail.com> ha scritto nel messaggio news:ujsrJ02eDHA.1764@TK2MSFTNGP09.phx.gbl... [quoted text, click to view] > I'm not sure why you getting 2 different response from > your two servers. you might want to recheck settings > and related files and folder NTFS permissions configuration.
Yesm that was my first thought, but why this happens only when accessing my server with its FQDN, and not when accessing it by the machine name ? Everything else is unchanged... [quoted text, click to view] > next, on the system prompt of machine name login, did you > specific default login domain in IIS ? refer > http://support.microsoft.com/?id=262233 Yes, I did. Massimo P.S. It's an IIS 6.0.
I'm not sure why you getting 2 different response from your two servers. you might want to recheck settings and related files and folder NTFS permissions configuration. next, on the system prompt of machine name login, did you specific default login domain in IIS ? refer http://support.microsoft.com/?id=262233 -- Regards, Bernard Cheah http://support.microsoft.com/ Please respond to newsgroups only ... [quoted text, click to view] "Massimo" <barone@mclink.it> wrote in message news:Oi2NQMreDHA.3280@tk2msftngp13.phx.gbl... > Can someone please post his thoughts on this ? > > > > > Let me clear up your misconceptions about authentication... > > > > > > That's fine, and thanks for your explanations. > > > But it seems like it's a problem of that specific webserver, since > another > > > server works fine both with the computer name (http://server1) and the > full > > > name ( http://server1.mydomain.com). And they are configured in the same > > > way, allowing both windows-integrated and standard authentication, with > > > the default authentication domain being mydomain.com. > > > So, why does one of them work and not the other ? > > > > > > I changed some configuration and authentication parameters on the web > > > server that's not working (I moved wwwroot and there are some sites > > > allowing anonymous connections using accounts different than > > > IUSR_SERVERNAME), but if this is a permission problem, why is it based > > > on the name I access the server with ? > > > > A little update: I've disabled windows integrated authentication, and now > > the server works, requiring me to input username and password, of course. > > The other server keeps working fine with both modes. > > So, why are these two servers acting so different ? > > Another strangeness I saw, maybe this can help: when I try to login to the > > "wild" server from different machines, I type my usernames and password, > and > > when the dialog comes back because authentication failed, it says > > MACHINENAME\username, where MACHINENAME is the name of the computer I'm > > sitting at, the one I'm trying to login from. This is strange, shouldn't > it > > try to login using domain accounts ? The default authentication domain for > > the server is, of course, my AD domain. > > Massimo >
"David Wang [Msft]" <someone@online.microsoft.com> ha scritto nel messaggio news:udrxIA7eDHA.3076@tk2msftngp13.phx.gbl... [quoted text, click to view] > Did you configure the NTAuthenticationProviders property on one of > the servers but not the other?
Where can I configure that ? [quoted text, click to view] > Maybe they are running different software and > one of the software made the setting change for you?
Both of them run IIS 6 with Exchange OWA; no other web softwares are installed. Massimo
the different behavior of browsing via FQDN and non FQDN is explained in the first Kb I gave you. this is due to IE zone control settings. -- Regards, Bernard Cheah http://support.microsoft.com/ Please respond to newsgroups only ... [quoted text, click to view] "Massimo" <barone@mclink.it> wrote in message news:u58RV33eDHA.616@TK2MSFTNGP11.phx.gbl... > "Bernard" <qbernard@hotmail.com> ha scritto nel messaggio > news:ujsrJ02eDHA.1764@TK2MSFTNGP09.phx.gbl... > > > I'm not sure why you getting 2 different response from > > your two servers. you might want to recheck settings > > and related files and folder NTFS permissions configuration. > > Yesm that was my first thought, but why this happens only when accessing my > server with its FQDN, and not when accessing it by the machine name ? > Everything else is unchanged... > > > next, on the system prompt of machine name login, did you > > specific default login domain in IIS ? refer > > http://support.microsoft.com/?id=262233 > > Yes, I did. > > Massimo > > P.S. > It's an IIS 6.0. >
This is what David refer to - HOW TO: Configure IIS to Support Both Kerberos and NTLM Authentication http://support.microsoft.com/?id=215383 -- Regards, Bernard Cheah http://support.microsoft.com/ Please respond to newsgroups only ... [quoted text, click to view] "Massimo" <barone@mclink.it> wrote in message news:O3xyPn7eDHA.1872@TK2MSFTNGP09.phx.gbl... > "David Wang [Msft]" <someone@online.microsoft.com> ha scritto nel messaggio > news:udrxIA7eDHA.3076@tk2msftngp13.phx.gbl... > > > Did you configure the NTAuthenticationProviders property on one of > > the servers but not the other? > > Where can I configure that ? > > > Maybe they are running different software and > > one of the software made the setting change for you? > > Both of them run IIS 6 with Exchange OWA; no other web softwares are > installed. > > Massimo > >
"Bernard" <qbernard@hotmail.com> ha scritto nel messaggio news:%23Jje9cNfDHA.1872@TK2MSFTNGP09.phx.gbl... [quoted text, click to view] > the different behavior of browsing via FQDN and non FQDN > is explained in the first Kb I gave you. this is due to IE > zone control settings.
This *can't* be due to IE zone control settings, since I'm using the very same workstation with the very same IE to connect to two intranet servers, and one of them works while the other doesn't. Please, stop repeating it's an IE issue, or otherwise explain why this IE should behave differently with two servers on the same subnet... Massimo
Fair enough. the kb I point explained the diff behavior of using FQDN and non FQDN and this still stand valid in most case maybe not yours. Now - let do further testing. a) get Metabase explorer - http://www.microsoft.com/downloads/details.aspx?familyid=56fc92ee-a71a-4c73-b628-ade629c89499 compare your two IIS 6.0 box settings. this will take sometime, since we have no ideas. b) verify the all web related files/scripts NTFS permissions. (try duplicate some file for test) c) configure authentication and do you testing. Now if there's no different on a,b,c settings, you should get the same response. if not........ update us on the outcome. -- Regards, Bernard Cheah http://support.microsoft.com/ Please respond to newsgroups only ... [quoted text, click to view] "Massimo" <barone@mclink.it> wrote in message news:eVWb23QfDHA.2236@TK2MSFTNGP12.phx.gbl... > "Bernard" <qbernard@hotmail.com> ha scritto nel messaggio > news:%23Jje9cNfDHA.1872@TK2MSFTNGP09.phx.gbl... > > > the different behavior of browsing via FQDN and non FQDN > > is explained in the first Kb I gave you. this is due to IE > > zone control settings. > > This *can't* be due to IE zone control settings, since I'm using the very > same workstation with the very same IE to connect to two intranet servers, > and one of them works while the other doesn't. > Please, stop repeating it's an IE issue, or otherwise explain why this IE > should behave differently with two servers on the same subnet... > > Massimo >
"Bernard" <qbernard@hotmail.com> ha scritto nel messaggio news:uV0qokZfDHA.1712@TK2MSFTNGP11.phx.gbl... [quoted text, click to view] > Now - let do further testing. > a) get Metabase explorer - > http://www.microsoft.com/downloads/details.aspx?familyid=56fc92ee-a71a-4c73-b628-ade629c89499 > compare your two IIS 6.0 box settings. > this will take sometime, since we have no ideas. > > b) verify the all web related files/scripts NTFS permissions. > (try duplicate some file for test) > > c) configure authentication and do you testing. > > Now if there's no different on a,b,c settings, you > should get the same response. if not........ update us > on the outcome. Ok, thanks for the suggestions. I'll check them as soon as possible. Massimo
Don't see what you're looking for? Try a search.
|