RE: website inside or outside the domain?

From: Henry Sieff (hsieff@orthodon.com)
Date: 02/11/03

  • Next message: Richard Spooner: "Re: Secure Instant Messenger for Windows?"
    From: Henry Sieff <hsieff@orthodon.com>
    To: "'Chris W. Parker'" <cparker@swatgear.com>, focus-ms@securityfocus.com
    Date: Mon, 10 Feb 2003 17:30:50 -0600
    
    

    > -----Original Message-----
    > From: Chris W. Parker [mailto:cparker@swatgear.com]
    > Sent: Monday, February 10, 2003 12:24 PM
    > To: focus-ms@securityfocus.com
    > Subject: website inside or outside the domain?
    >
    >
    > Hello.
    >
    > Is it a better practice in general to join a webserver to a
    > domain or to
    > leave it in it's own workgroup?

    In general, it is better not to have domain authentication traffic
    traversing any trust boundary, so, assuming you are talking about an
    internet-accessible web server, it is best not to use your internal domain
    to authenticate.

    There are two scenarios:
    1) publicly accessible web server in a DMZ, with a DC also in the DMZ
    2) ditto, but with the DC in an internal

    In #1, you have your DC on the wire with the rest of your public servers;
    since we always assume your publicly accessible servers will one day be
    hacked, they will then have unfettered access to the crown jewels.

    In #2, you need to open up sufficient ports between the Web Server and the
    DC to render it practically indistinguishable from scenario #1.

    Multi-domain models with trust relationships do not improve this situation.

    >
    > The reason I ask is because managing the permissions on the
    > webserver is
    > made difficult since I don't have access to the domain users
    > and groups.
    > That is, (as far as I know) I cannot add a domain group (i.e.
    > DOMAIN\weborders) to a resource on the webserver. Instead I
    > have to make
    > a group locally on the webserver that mimics the group (and users in
    > that group) on the domain.

    Yup. If you are securing access to your applications using built in NT
    authentication, that is indeed true.

    > Another reason I would like to join the webserver to the domain is
    > because I could turn off Anonymous Access and force the users
    > to login.
    > BUT I am imagining their domain credentials would automatically be
    > passed to the intranet site thus logging them in
    > automagically. I would
    > then have access to their username's from within my .asp pages.

    Yup, this works as you have described.
     
    > The only reason I have not joined the server to the domain yet is
    > because I am not sure what sorts of negative side effects
    > there might be
    > that I don't know about.

    As I said, once you are allowing your publicly accessible web server to
    participate in domain authentication, you are losing some benefit of
    segementing a network, and you are basically saying that you believe your
    web server is unhackable.

    > Can anyone shed any light on these situations and/or offer
    > alternatives?

    Although using the built in authentication system of NT/2000 makes it a
    little easier to get started writing web-apps and give you some emasure of
    security (particularly when those apps are deployed only within a continuous
    trust boundary e.g. a corporate intranet only accessible from the internal
    network) its not the best model to use.

    A couple of things you can try:
    1) Build your authentication into the application, and simply use a backend
    database to store usernames and (hopefully) hashed passwords. This has the
    added advantage of making it easier to deploy tools for your users to manage
    their password via the web.
    2) Use a VPN to make your web server accessible only to clients who have a
    token; this at least allows you to give some measure of protection to your
    web server besides the NT/2000 authentication and makes it harder to break
    it. This won't work if you want to host publicly accessible apps on the same
    server.

    The NT/2000 authentication built into IIS should be thought of as an
    extension of your local network, since it makes use of some pretty important
    resources on that network. You shouldn't expose it to anyone who you
    wouldn't want snooping around.

    Henry Sieff



    Relevant Pages

    • Re: Working on a Web Server 2003
      ... I'm not trying to install the web server on a DC. ... > Are you trying to setup and secure a webserver on a DC? ... > A built in account that has a high level of access rights ... Network Service: ...
      (microsoft.public.windows.server.active_directory)
    • Re: Working on a Web Server 2003
      ... I'm not trying to install the web server on a DC. ... > Are you trying to setup and secure a webserver on a DC? ... > A built in account that has a high level of access rights ... Network Service: ...
      (microsoft.public.inetserver.iis)
    • RE: Network troubleshooting, any experts?
      ... >> Now the problem is that all computers on the network can browse the ... >> telnet and ssh with no problem, except for the web server. ... >> the webserver. ...
      (Fedora)
    • Integrated Windows Authentication not working on a domain network
      ... When I enable NT challenge/response on my NT4 web server in a domain ... When I enable Integrated Windows Authentication on my W2K Professional ... Explorer pop-up logon window asking them to logon to the network. ...
      (microsoft.public.inetserver.iis.security)
    • Re: Integrated Windows Authentication not working on a domain network
      ... > When I enable NT challenge/response on my NT4 web server in a domain ... > When I enable Integrated Windows Authentication on my W2K Professional ... > Explorer pop-up logon window asking them to logon to the network. ...
      (microsoft.public.inetserver.iis.security)