Re: [Windows 2003] [IIS 6] A strange access problem

From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 09/12/03 

Date: Fri, 12 Sep 2003 12:02:57 -0700

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.
//
"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...
> 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 ?
> 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...
> 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

Relevant Pages

  • Re: WCF security advice (and clarification) needed
    ... You, the client, resolve the foo.mycompany.com hostname within your ... TCP/IP) with that ticket as the security token. ... There are two parties participating in a security scenario, the server ... HTTP supports other authentication ...
    (microsoft.public.dotnet.framework.webservices)
  • Re: SSPI Kerberos for delegation
    ... We want the authentication to happen without providing credentials ... But SSPI while authenticating from the client to the server can do mutual ...
    (comp.protocols.kerberos)
  • Re: Aironet 1200/Radius Help Needed
    ... I just fired up a W2003 Advanced Server so that I can take ... >> IAS servers (do I need a separate certificate for the secondary IAS ... >> of authentication since it involves just installing the certificate on ... >between the AP and the client. ...
    (microsoft.public.internet.radius)
  • Re: Windows Authentication, Single sign on and Active Directory
    ... service proxy client fails to connect due to authentication failure and then ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ... The server is always in the domain. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: NAT-T and L2TP
    ... I have already applied the update from q818043 to the w2k client ... IKE security association negotiation failed. ... > W2003 server. ...
    (microsoft.public.win2000.ras_routing)