IIS and FQDN authentication confusion

Discussion in 'ASP .Net Security' started by Stu Carter, Oct 11, 2005.

  1. Stu Carter

    Stu Carter Guest

    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
     
    Stu Carter, Oct 11, 2005
    #1
    1. Advertising

  2. 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" <> wrote in message
    news:...
    > 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
    >
     
    Joe Kaplan \(MVP - ADSI\), Oct 11, 2005
    #2
    1. Advertising

  3. Hello Joe,

    if you connect from localhost it always works - because technically it is
    not a delegation - they just pass the token locally - so it is a single hop
    only.

    for the rest i can only agree.


    ---------------------------------------
    Dominick Baier - DevelopMentor
    http://www.leastprivilege.com

    > 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" <> wrote in message
    > news:...
    >
    >> 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
     
    Dominick Baier [DevelopMentor], Oct 11, 2005
    #3
  4. Doh, that is right! Thanks, I was so concentrating on the Kerb
    troubleshooting (that I just did for hours last week) that I forgot that
    case. :)

    He may not even have delegation enabled yet.

    Joe K.

    "Dominick Baier [DevelopMentor]" <>
    wrote in message news:...
    > Hello Joe,
    >
    > if you connect from localhost it always works - because technically it is
    > not a delegation - they just pass the token locally - so it is a single
    > hop only.
    >
    > for the rest i can only agree.
    >
    >
    > ---------------------------------------
    > Dominick Baier - DevelopMentor
    > http://www.leastprivilege.com
    >
    >> 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" <> wrote in message
    >> news:...
    >>
    >>> 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

    >
    >
     
    Joe Kaplan \(MVP - ADSI\), Oct 11, 2005
    #4
  5. Stu Carter

    Ken Schaefer Guest

    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)" <> wrote
    in message news:%...
    : 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" <> wrote in message
    : news:...
    : > 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
    : >
    :
    :
     
    Ken Schaefer, Oct 12, 2005
    #5
  6. Stu Carter

    Stu Carter Guest

    Thanks very much everyone, that makes it clear.

    Cheers,
    Stu

    "Ken Schaefer" <> wrote in message
    news:...
    > 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)" <> wrote
    > in message news:%...
    > : 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" <> wrote in message
    > : news:...
    > : > 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
    > : >
    > :
    > :
    >
    >
     
    Stu Carter, Oct 12, 2005
    #6
  7. Stu Carter

    Stu Carter Guest

    You're right, we haven't configured delegation, so we can only do one hop.

    "Joe Kaplan (MVP - ADSI)" <> wrote
    in message news:...
    > Doh, that is right! Thanks, I was so concentrating on the Kerb
    > troubleshooting (that I just did for hours last week) that I forgot that
    > case. :)
    >
    > He may not even have delegation enabled yet.
    >
    > Joe K.
    >
    > "Dominick Baier [DevelopMentor]" <>
    > wrote in message news:...
    >> Hello Joe,
    >>
    >> if you connect from localhost it always works - because technically it is
    >> not a delegation - they just pass the token locally - so it is a single
    >> hop only.
    >>
    >> for the rest i can only agree.
    >>
    >>
    >> ---------------------------------------
    >> Dominick Baier - DevelopMentor
    >> http://www.leastprivilege.com
    >>
    >>> 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" <> wrote in message
    >>> news:...
    >>>
    >>>> 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

    >>
    >>

    >
    >
     
    Stu Carter, Oct 12, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ThunderMusic
    Replies:
    0
    Views:
    548
    ThunderMusic
    Jan 3, 2006
  2. rh0dium
    Replies:
    2
    Views:
    296
    Mike Meyer
    Sep 21, 2005
  3. Scott
    Replies:
    8
    Views:
    1,532
    Scott_lotus
    Sep 7, 2009
  4. GSA

    FQDN to IP

    GSA, Nov 19, 2010, in forum: Java
    Replies:
    10
    Views:
    2,367
  5. Steven Simpson
    Replies:
    0
    Views:
    742
    Steven Simpson
    Feb 6, 2012
Loading...

Share This Page