Groups | Blog | Home
all groups > iis security > september 2003 >

iis security : [Windows 2003] [IIS 6] A strange access problem


David Wang [Msft]
9/11/2003 11:02:45 PM
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> ha scritto nel messaggio
news:ewtiuMLeDHA.1820@TK2MSFTNGP10.phx.gbl...

[quoted text, click to view]

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]

It's even more urgent now... I really need help on this :-(

Massimo

Massimo
9/12/2003 12:22:37 AM
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
9/12/2003 1:13:01 AM
"Massimo" <barone@mclink.it> ha scritto nel messaggio
news:ewtiuMLeDHA.1820@TK2MSFTNGP10.phx.gbl...

[quoted text, click to view]

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]

It's even more urgent now... I really need help on this :-(

Massimo
Massimo
9/12/2003 8:59:27 AM
"Bernard" <qbernard@hotmail.com> ha scritto nel messaggio
news:u9B3fRNeDHA.3584@tk2msftngp13.phx.gbl...

[quoted text, click to view]

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
Massimo
9/12/2003 9:03:17 AM
"David Wang [Msft]" <someone@online.microsoft.com> ha scritto nel messaggio
news:%23awE%23dPeDHA.1680@TK2MSFTNGP09.phx.gbl...

[quoted text, click to view]

Ok, but shouldn't IIS resort to standard authentication, once integrated
failed ?

[quoted text, click to view]

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]

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
Bernard
9/12/2003 10:20:01 AM
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]

David Wang [Msft]
9/12/2003 12:02:57 PM
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]
"David Wang [Msft]" <someone@online.microsoft.com> ha scritto nel messaggio
news:%23awE%23dPeDHA.1680@TK2MSFTNGP09.phx.gbl...

[quoted text, click to view]

Ok, but shouldn't IIS resort to standard authentication, once integrated
failed ?

[quoted text, click to view]

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]

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



David Wang [Msft]
9/12/2003 1:32:29 PM
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> ha scritto nel messaggio
news:eAJiPiWeDHA.3228@tk2msftngp13.phx.gbl...

[quoted text, click to view]

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

Massimo
9/12/2003 10:00:59 PM
"David Wang [Msft]" <someone@online.microsoft.com> ha scritto nel messaggio
news:eSd8INWeDHA.2268@TK2MSFTNGP10.phx.gbl...

[quoted text, click to view]

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
9/12/2003 10:26:33 PM
"Massimo" <barone@mclink.it> ha scritto nel messaggio
news:eAJiPiWeDHA.3228@tk2msftngp13.phx.gbl...

[quoted text, click to view]

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
Massimo
9/14/2003 1:26:45 PM
Can someone please post his thoughts on this ?

[quoted text, click to view]

Massimo
Massimo
9/15/2003 1:38:15 PM
"Bernard" <qbernard@hotmail.com> ha scritto nel messaggio
news:ujsrJ02eDHA.1764@TK2MSFTNGP09.phx.gbl...

[quoted text, click to view]

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]

Yes, I did.

Massimo

P.S.
It's an IIS 6.0.
Bernard
9/15/2003 5:37:54 PM
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
9/15/2003 8:47:39 PM
"David Wang [Msft]" <someone@online.microsoft.com> ha scritto nel messaggio
news:udrxIA7eDHA.3076@tk2msftngp13.phx.gbl...

[quoted text, click to view]

Where can I configure that ?

[quoted text, click to view]

Both of them run IIS 6 with Exchange OWA; no other web softwares are
installed.

Massimo

Bernard
9/17/2003 12:51:06 PM
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]

Bernard
9/17/2003 12:52:16 PM
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
9/17/2003 1:22:51 PM
"Bernard" <qbernard@hotmail.com> ha scritto nel messaggio
news:%23Jje9cNfDHA.1872@TK2MSFTNGP09.phx.gbl...

[quoted text, click to view]

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
9/18/2003 12:00:08 PM
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
9/18/2003 3:10:34 PM
"Bernard" <qbernard@hotmail.com> ha scritto nel messaggio
news:uV0qokZfDHA.1712@TK2MSFTNGP11.phx.gbl...

[quoted text, click to view]

Ok, thanks for the suggestions.
I'll check them as soon as possible.

Massimo
AddThis Social Bookmark Button