RE: Microsoft Active Directory security concerns
- From: "Robertson, Seth (JSC-IM)" <Seth.Robertson-1@xxxxxxxx>
- Date: Tue, 13 Jun 2006 13:05:23 -0500
It's a bit more trouble, but the proper way to do this (and a way I've
seen it implemented at several places) is to stand up a separate forest
for your DMZ(s) with no trusts between it and your internal forest.
When using a single domain, it is possible for an attacker to gain
control of the web server (for example, through an IIS vulnerability)
and perhaps use application/database service accounts to leverage
control deeper into the network. If you HAVE to make them part of the
same domain, there are issues relating to WHO in the domain is allowed
to log in (using SharePoint or IIS?) remotely and using your firewall to
limit the traffic from your DMZ web servers into the internal network.
Just to clarify, there is no such thing as an "external" OU with respect
to AD itself. What they're proposing is creating a new OU within your
domain. That way you isolate the web farm from th internal network to
protect it. Depending on how many servers you're talking about, you
could also consider making those servers standalone (not a member of any
domain). The costs of standing up a new domain are certainly greater
than a new OU: new hardware, software licenses, replication traffic
planning, etc. And it is far easier to move user, groups, or computers
from one OU to another rather than between domains. But if your users
are your customers rather than your employees, it's unlikely you'll be
shuffling existing accounts into your new domain anyway.
Another problem you'll encounter is managing the separate forest. Your
operations/engineer folks will need accounts for THAT forest too
(without cross-forest trust) OR you can create a one-way trust so that
IT accounts in the internal domain can manage the DMZ domain but DMZ
accounts have no access to the internal domain (but that comes with
additional risk). ALSO you'll have to consider opening the firewall for
about 15 ports between your engineers and the DMZ servers. These two
links are your bible: http://support.microsoft.com/?id=179442 and
http://support.microsoft.com/?id=832017 .
If the budget dollars are there look into getting approval to go to the
SANS Securing Windows track coming up (I believe in July) in Washington,
D.C. There's still time to register, book your flight and hotel, etc.
It isn't offered more than once or twice a year from my knowledge.
These issues are discussed in that course and you'll have access to a
world-reknowned expert to perhaps get a couple of your business-specific
questions answered. Training, food, airfare, and a hotel could run
around $5,000 for the entire trip.
Seth Robertson
-----Original Message-----
From: DHegenbarth@xxxxxxxxxxxxx [mailto:DHegenbarth@xxxxxxxxxxxxx]
Sent: Tuesday, June 13, 2006 11:06 AM
To: security-basics@xxxxxxxxxxxxxxxxx
Subject: Microsoft Active Directory security concerns
All,
I have spent most of my time in network security and IDS/IPS technology
so I'm fairly new to security pertaining to MS Active Directory. We are
being asked to evaluate web portal authentication/authorization for
users, most of whom are not employees of our company. Our NT group
wants to add / maintain users in an "external OU", in an existing
domain, under our existing AD forest. I think this is a bad idea but I
am not versed enough in AD to argue the point. Are there glaring issues
with this strategy? My concern is that if someone were to gain access to
AD they might not only effect external applications but internal
production as well.
Are "external OU's" that secure? Are there more secure authentication
schemes?
Any thoughts would be greatly appreciated.
Dave
- Prev by Date: RE: Microsoft Active Directory security concerns
- Next by Date: Re: In light of what has happened with the theft of the VA laptop, what are the "best practices" for securing laptops?
- Previous by thread: RE: Microsoft Active Directory security concerns
- Next by thread: Re: re: Microsoft Active Directory security concerns
- Index(es):
Relevant Pages
|
