I hear what you're saying Wim, but as soon as someone tells me that they
require a highly secure domain in addition to a domain they already have
the place I start is with a new Forest. Once you get into asking some
questions about the requirements and what they are really looking to get
out of this new domain then you may be able to move to a more secured
single forest design.
From the sounds of the initial post in this thread there is a new domain
that is going to be brought up in an un-trusted network. That statement
right there throws up flags for me: if the network isn't trusted then
neither are the users/admins and I don't want them in my production
forest. Oren also mentions that he is looking for a way to block the
enterprise admins from having access to this new and un-trusted domain.
That statement leads me to believe that the people running this new
domain will be getting far more than just some delegated rights, which
is why I pointed out that with Domain Admin rights a user can get
themselves Enterprise Admin privlidges very easily.
The scenario you layed out is definitely a good way to go, but it
certainly won't fit with many places. If you have a centralized
administration model and you don't care about users in the other domain
being able to see objects throughout the forest then that model makes a
lot of sense. In the scenario that Oren layed out, from the basic
information he provided I still think that a separate forest is required
to keep your production environment safe. If the network the new domain
was going to be in was a trusted network then that would change the
landscape dramatically and your advice would certainly be on the right
track.
Phil
-----Original Message-----
From: Wim_Remes@msp.be [mailto:Wim_Remes@msp.be]
Sent: Saturday, December 18, 2004 4:45 PM
To: Renouf, Phil
Cc: Scott Mulcahy; focus-ms@securityfocus.com; oren@held.org.il
Subject: RE: Subdomain security
Hi,
First, you were correct when saying that the only true security boundary
is the forest...but I'm always looking on what I'm trying to secure.
There are a few reasons to implement seperate forests, there's a million
others for making extensive use of delegation of authority. In my
opinion there should only be one single ID that has 'enterprise admin'
rights and that should be unknown to any normal admin. It should be only
used when a change to the root domain is required and approved through
change management. 99% of all daily admin tasks can be performed without
domain admin rights, you can allow anything to a simple user by using
delegation of authority (and he won't be able to make himself enterprise
admin). with proper ID Management and procedures implemented, you would
have a dream of a domain, not compromising security on any level.
Changes to the group membership can be ruled out by using a 'restricted
groups' policy on the domain level.
there's lots of info about restricted groups around, I'm posting the
jsiinc.com link cuz JSI has loads of other information (both
security-related and general) that can help you out on many isssues.
Regards,
Wim Remes
MCSE:Security
-----"Renouf, Phil" <Phil.Renouf@tdsecurities.com> wrote: -----
To: "Scott Mulcahy" <scottcm-secfocus@hotmail.com>,
<focus-ms@securityfocus.com>
From: "Renouf, Phil" <Phil.Renouf@tdsecurities.com>
Date: 17/12/2004 19h13
cc: <oren@held.org.il>
Subject: RE: Subdomain security
I'm fairly certain that an enterprise admin can get admin privs
anywhere in the forest.
Not to mention that as a Domain Admin it is very easy for someone to get
themselves enterprise admin rights. One important thing to monitor is
changes to the group membership of the major admin groups (Enterprise,
Schema, Domain etc.). I know that MOM does this pretty well, but I am
sure other monitoring tools offer that as an option.
Phil
------------------------------------------------------------------------
---
------------------------------------------------------------------------
---
---------------------------------------------------------------------------
---------------------------------------------------------------------------
