Re: IIS and FQDN authentication confusion

From: Ken Schaefer (kenREMOVE_at_THISadOpenStatic.com)
Date: 10/12/05


Date: Wed, 12 Oct 2005 11:56:24 +1000

Hi,

In addition to the comments from Joe and Dominick, and to answer your
questions about the differences in your scenarios:

Scenario 2 does not work because the site is not in the Intranet zone. By
default IE will *not* attempt Kerberos authentication for sites in the
Internet zone, and all websites with FQDN are in the Internet zone unless
you add them to the Intranet zone. Unless you add the site to the Intranet
zone -or- start accessing the site using a NetBIOS style name, IE will use
NTLM auth which is not delegatable. There is no "fall back" mechanism. IE
will see the various WWW-Authenticate headers (Negotiate, NTLM and Basic),
and choose the first one (i.e. the strongest one) on the list. This will be
NTLM (even if you only specify Negotiate, this allows IE to choose NTLM over
Kerberos). So there is no "fallback" to Basic auth.

Scenario 3 works because IIS has the user's username/password in clear text
and can directly logon as that user.

Cheers
Ken

"Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
in message news:%237NyDgozFHA.2076@TK2MSFTNGP14.phx.gbl...
: It sounds like you might not be getting Kerberos authentication to the web
: server when you use the FQDN, and thus delegation is not working. You
might
: check the security logs (assuming logon audits are enabled) and verify
: whether Kerberos or NTLM is used.
:
: Using a packet sniffer like ethereal and also a tool like Wfetch (IIS 6
: resource kit) can also help troubleshoot this stuff.
:
: If that is the issue, it is possible that you might be missing a needed
SPN
: for the web server that matches the FQDN which results in no TGT request
: being generated on the client end.
:
: HTH,
:
: Joe K.
:
: "Stu Carter" <Stu.Carter@nospam.nospam> wrote in message
: news:u4TyqmnzFHA.464@TK2MSFTNGP15.phx.gbl...
: > Hi,
: >
: > ENV: Windows 2003 Server SP1, IIS6, .Net 1.1
: >
: > I'd like to know why the authentication and delegation differs when
: > accessing a web site using the Fully Qualified Domain Name as opposed to
: > 'localhost'.
: >
: > We have an ASP.Net application which has only 'Integrated
authentication'
: > enabled on the virtual directory. The ASP.Net application access a
remote
: > resource on behalf of the authenticated user.
: >
: > The authentication and impersonation modes are:
: > <authentication mode="Windows" />
: > <identity impersonate="true" />
: >
: > I test this with 3 authentication scenarios (IE running on the IIS
server
: > in every one).
: >
: > 1) I connect to the app using http://localhost/MyApp, everything is fine
: > and the remote resource is accessible.
: >
: > 2) I specify the FQDN - http://mybox.domain.local/MyApp and I am
prompted
: > for credentials. Now, I know that this is because IE thinks I am
outside
: > the intranet zone - fair enough. The thing I don't understand is that
: > although my credentials are accepted, subsequent access to the remote
: > resource is denied ('Access denied' error).
: >
: > 3) So I thought - OK, must be something to do with basic authentication
: > then. So I reconfigured the Virtual directory to have only 'Basic
: > Authentication' expecting the same result. I was surprised at the
: > outcome - using either localhost or the FQDN worked. The web app could
: > access the remote resource on my behalf.
: >
: > My question is - what is the difference between scenario 2 and 3?
: >
: > I am thinking that in scenario 2, IE is failing back to 'Basic
: > Authentication'? If that is the case, then scenario 3 should not work
: > either.
: >
: > So, is scenario 2 actually 'Basic authentication', but not allowing
: > delegation because it thinks I am not on the Intranet?!!
: >
: > I'd appreciate
: > <authentication mode="Windows" />
: >
: > <identity impersonate="true" />
: >
: > Thanks,
: > Stuart
: >
: >
: > NB. To reproduce - the simple scenario is two servers:
: >
: > Web Server - ASP.Net app reading a file off of a share on the file
: > server.
: > File Server
: >
:
:



Relevant Pages

  • Re: Access denied ( From one site to another, that is in another server)
    ... I am working at the next scenario: ... The second server has install DotNet Framework too. ... > Bassel Tabbara ... > | belongs to the site that has Windows Authentication. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • IIS 6 und Kerberos
    ... Authentication isn't allowed anonym and Authentication methode is Window integriert. ... The eventlog writes a security event 529 logon/logoff, Unkown username or wrong password, logontyp 3, Auth paket Kerberos. ... Originally we configured the MOSS with SQL Server on other server for Kerberos. ... the scenario above was built. ...
    (microsoft.public.inetserver.iis.security)
  • Re: External Access to IIS via Kerberos Authentication
    ... By default Integrated Authentication is only used in the intranet zone and ... in it is not in the intranet zone. ... Kerberos also requires that the client machine be a member of the forest. ... > - The server has been trusted for delegation. ...
    (microsoft.public.inetserver.iis.security)
  • Re: Authentication problem
    ... If you change to basic authentication, ... the user logs into the same domain & both the IIS> Server domain & the user domain are the same. ... The domain> is set to be in the intranet zone. ... The login prompt should not ...
    (microsoft.public.inetserver.iis.security)
  • Re: wi-fi e-mail sending from iPaq
    ... you have to understand which authentication method does your ... SMTP server uses, as there are mainly three scenarios that I have commonly ... The third scenario scenario is partially supported. ...
    (microsoft.public.pocketpc)