Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

RE: AD in the DMZ

Subject: RE: AD in the DMZ
Date: Thu, 4 Nov 2004 16:02:03 -0600
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.




<Prev in Thread] Current Thread [Next in Thread>