Windows Authentication when Web Server is in DMZ

Discussion in 'ASP .Net Security' started by InstantKiwi, Aug 10, 2006.

  1. InstantKiwi

    InstantKiwi Guest

    Hi All,

    I am an applications developer with very basic knowledge of networking
    security concepts so please bear with while I try my best to explain
    the situation.

    I am looking for some best practice advice for how to structure the
    infrastructure for an internet facing web application. Here are some
    basic details of what we currently have in our environment...

    - Win2K3 on all servers
    - ISA 2004
    - Connections are only allowd to be made to my SQL Server instance
    using Windows authentication
    - My SQL Server is a member of my internal domain so that my internal
    AD users can access certain data using various internal applications
    (MS Office, custom apps, etc).

    We are developing an ASP.NET 2.0 web application designed to capture
    data from a known set of external users from a number of different
    external organisations. Our design is to create a new OU in our
    internal AD to use as the credential store for these users/groups. We
    will simply be using AD to authenticate users so we will not have to
    extend the AD schema. We will store all our extended user details in
    our application database.

    Given that I am only allowed to use Windows authentication against SQL
    Server then my web application must either:
    1. Impersonate an explicit domain account; OR
    2. Impersonate the logged on user (being a domain account user)

    Either way it would seem to me that the web server will either
    1. Have to be a member of my internal domain; OR
    2. Sit in the DMZ with a whole raft of holes in the internal firewall
    to accomodate windows auth.

    What is the best way to do this in a secure manner?

    I have done a fair bit of searching around to find "best practice"
    articles for essentially deploying an internet facing web application
    that must use windows authentication to connect to a database server on
    the internal domain but seem to have come up short. Any suggestions
    would be greatly appreaciated.
    InstantKiwi, Aug 10, 2006
    1. Advertisements

  2. Doesn't ISA allow you to put the web server in the internal network and
    proxy all of the web traffic back to the web server? That seems like the
    way to go.

    You'll want to use something like basic authentication (with SSL of course)
    on the web server so that your external clients can authenticate. They
    probably won't be able to use IWA auth as they won't be members of your
    domain, so Basic is more appropriate here. You could also do Forms auth
    with the ActiveDirectoryMembershipProvider if you want.

    Regarding whether you impersonate the logged in user or use the fixed
    service account depends on your application architecture
    (impersonated/delegated vs. trusted sub-system). Both are valid and have
    their good and bad points. Note that you don't necessarily need to use a
    special service account, as in IIS 6 (Win2K3 server), the IIS app pool runs
    as network service by default which will appear to the remote SQL server as
    the machine account. You can delegate your permissions to the machine
    account if you want (assuming you want a trusted subsystem).

    I'm also a huge fan of Microsoft's new federation product, Active Directory
    Federation Services (ADFS). With it, you can potentially allow your clients
    to use your applications with their own accounts instead of having to
    provision accounts in your domain and maintain them. It also allows you to
    easily stand up an alternate identity store like an ADAM instance to use for
    your client's identities (if they can't set up ADFS or another WS-Federation
    product) so you don't have to put them in your AD and subvert your company's
    security. :)


    Joe K.
    Joe Kaplan \(MVP - ADSI\), Aug 12, 2006
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.