RE: AD in the DMZ

["Jeffrey Gorton" <jpgorton () swbell net>]

I'm guessing the reference was to ADAM.  To my mind, ADAM and AD present the
same risk in this scenario (I think that's what you said as well). 

My solution to date is to not allow the trust relationship and to create
separate accounts (with a different naming convention) in the DMZ forest.  

I'm not only concerned about enumerating the internal AD users.  I'm
concerned about what else can happen with those ports open to an attacker on
the web server.   

-Jeff

-----Original Message-----
From: David Mowers [mailto:davemo () winse microsoft com] 
Sent: Thursday, November 04, 2004 12:52 PM
To: Non Proprio; Jeffrey Gorton
Cc: webappsec () securityfocus com
Subject: RE: AD in the DMZ

Hello,

I'm not sure what Microsoft's "identity management" application is referring
to. Can you provide more information on what you think this might be?

To be sure, the concern raised in this thread is a common one and you can
find Microsoft documentation that says both the "trust-based" and the
"shadow account" approaches are possible for the extranet/intranet access
scenario.

The original issue in this thread must be considered through a threat
modeling process. Yes, enumeration of AD accounts is something that would be
possible today, but any alternative design should be subjected to the same
concern. The fact of the matter is, if the external-facing web application
can authenticate some number of users then a compromise of that server would
almost surely provide a way to enumerate the same set of users. This would
be true if the organization set up separate
(shadow) accounts in the extranet AD or used some other completely different
kind of identity store such as an LDAP server or database. 

On the plus side for using the architecture described, it provides user
convenience (SSO) and also reduces greatly the management overhead of
maintaining multiple accounts. More accounts almost always adds additional
points of security vulnerability, so you might be trading a problem you know
about (and can design/deploy/operate to protect
against) for a problem you don't know about or for a system that can't be
managed effectively. 

I would recommend that anyone carefully consider all relevant aspects of the
architecture before deciding that one alternative is more secure then
another.

Dave Mowers
Microsoft Security Solutions


Check out the Microsoft Identity and Access Management Solution Series at
http://www.microsoft.com/technet/security/topics/identity/idmanage/defau
lt.mspx


-----Original Message-----
From: Non Proprio [mailto:non () synaxis org]
Sent: Sunday, October 31, 2004 2:07 PM
To: Jeffrey Gorton
Cc: webappsec () securityfocus com
Subject: Re: AD in the DMZ

Wow, great minds think alike. My developers have the exact same thing in
mind.

I'm torn between getting 'business done" and demanding a better form of
identity management. The problem is that there's not time to really
implement a full solution, so what I'm faced with is having to get customers
connected in a world of Microsoft AD. 


Since the development team has bitten into Microsoft hook, line and sinker
we're faced with a real business issue.

What about Microsoft's "identity management" application? Has anyone fiddled
with this in reference to web apps?



On Oct 28, 2004 04:26 PM, Jeffrey Gorton <jpgorton () swbell net> wrote:

> I am aware of an internet-facing web application that is running on 
> Microsoft SharePoint and using an Active Directory forest (that
resides in a
> separate firewalled network segment) for user authentication.  There
is also
> a one-way trust relationship with the AD forest on the internal
network (the
> DMZ AD trusts the internal AD) so that internal users can access DMZ 
> resources.  There is a firewall between the two AD forests, but the
LDAP and
> necessary Windows ports are open.
>
> An Internet user authenticates with a DMZ AD account.  An internal
user
> authenticates into the internal AD and then accesses DMZ resources
(the DMZ
> AD contacts the internal AD for authentication).
>
> It seems to me that, if the SharePoint server is compromised, the
attacker
> will be able to enumerate users on the internal AD.  Is this so?  What
are
> the problems with this design?
>
> Thanks.