Windows Authentication when Web Server is in DMZ

microsoft.public.dotnet.security

10 Aug 2006 1:58 AM

InstantKiwi

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.

12 Aug 2006 4:25 AM

Joe Kaplan (MVP - ADSI)

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. :)

HTH,

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--

Show quoteHide quote

"InstantKiwi" <xtradotcodo***@xtra.co.nz> wrote in message
news:1155175108.641964.212270@i3g2000cwc.googlegroups.com...
> 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.
>