RE: Active Directory network security

• Previous message: Jason Normanton: "RE: Active Directory network security"
• Maybe in reply to: RGN: "Active Directory network security"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: "J M" <bugtraqlist@hotmail.com>
To: netprouk@netprouk.com, focus-ms@securityfocus.com
Date: Sat, 16 Nov 2002 20:09:06 +0000

That's actually how we had to end planning our enterprise AD (implementation
still in progress). We are trying to consolidate everything into a single
domain with an empty forest root. Our Enterprise admins (who are also the
only domain admins of the single domain) have a rigorous security check and
there are only 3 of them.

Once the administrator and domain question is fixed, I agree that assigning
an OU to each functional business unit is the best plan. The OU is now the
administrative boundary and the OU admins can't break anything outside of
their own world.

-Jared

>From: "Jason Normanton" <netprouk@netprouk.com>
>To: "'J. .'" <bugtraqlist@hotmail.com>, <focus-ms@securityfocus.com>
>CC: <norman.r@btclick.com>
>Subject: RE: Active Directory network security
>Date: Sat, 16 Nov 2002 15:45:02 -0000
>MIME-Version: 1.0
>Received: from ringo.siteprotect.com ([64.41.120.3]) by
>mc4-f30.law16.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 16
>Nov 2002 07:44:18 -0800
>Received: from emgatncsgc2 (pc-80-194-218-86-ga.blueyonder.co.uk
>[80.194.218.86])by ringo.siteprotect.com (8.9.3/8.9.3) with ESMTP id
>JAA01499;Sat, 16 Nov 2002 09:44:17 -0600
>Message-ID:
><76FFD4489608684BB0F8EF87C6E1743B68E7@emgatncsgc1.corporate.netprouk.com>
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook, Build 10.0.2627
>Importance: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
>In-reply-to:
><76FFD4489608684BB0F8EF87C6E1743B19C71F@emgatncsgc1.corporate.netprouk.com>
>Return-Path: netprouk@netprouk.com
>X-OriginalArrivalTime: 16 Nov 2002 15:44:19.0053 (UTC)
>FILETIME=[069821D0:01C28D87]
>
>Hi All,
> This is all perfectly correct I recently attended a directory
>experts conference at which this little misnoma still appeared
>prevellant. In fact the only true security boundary in AD is a forest.
>Enterprise Admins have ultimate power over the entire forest and all
>Domain Admins must be fully trusted. In my opinion you need to limit the
>number of Domain Admins in your forest to the Absolute minimum. Many of
>the most succesfull implementations I have been involved with use the
>single child domain / empty root domain principle with only two
>enterprise admins and no more than 8 domain admins. If a good OU
>structure is put in place rights can be assigned for data administrators
>at this lower level. If a total security boundary is required between
>business units put in a separate forest one way trusts can already be
>placed between forests but if your main concern is one global address
>list for your organisation in exchange 2000 this can be achieved in a
>multiple forest scenario by using Microsofts Matadirectory services
>product. MMS will correlate data from multiple directories into one
>usable area i.e One GAL. Unfortunately at the moment it is only
>available from Microsoft consulting services.
>
>My 2 Cents
>
>Jason Normanton
>Senior Consultant (Directory Services)
>NetProUK
>http://www.netprouk.com
>
>
>-----Original Message-----
>From: J. . [mailto:bugtraqlist@hotmail.com]
>Sent: 12 November 2002 17:17
>To: focus-ms@securityfocus.com
>Cc: norman.r@btclick.com
>Subject: RE: Active Directory network security
>
>
> >Does anyone have any experience of such a situation?
>I am currently in the exact same situation in a migration project at our
>
>organization.
>
> >Is it as bad as I fear, or is Microsoft A/D secure?
>AD's group policies can be used to keep AD itself pretty secure, but
>opening
>up your firewalls or removing them can open up a whole slew of network
>based
>attacks (that don't depend on AD) between areas of your organization
>that
>were not possible while the firewalls were in place. For example, every
>
>member of an AD domain following all the rules and policies can be
>locked
>down tightly for security within AD, but a rogue laptop that is not a
>domain
>member can now run a penetration test against any IP address on your
>network
>if there are no firewalls.
>
> >Are there are documented cases of this type of migration going wrong
> >due
> >to security being overlooked?
>Check out this article:
>http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/a
>ddeladmin.asp
>
>When Microsoft first touted Active Directory they pushed for a Single
>Forest
>design with multiple domains for each business unit. These domains were
>
>originally portrayed as security barriers within the forest. The above
>article shows that domains should _not_ be considered security barriers,
>and
>the forest is actually the security barrier. This pushes us back to an
>NT4
>style with separate silo's of security. Domains in Active Directory are
>
>administrative boundaries, not security boundaries.
>
>(MS will want you to create multiple forests for security reasons and
>then
>talk about their new "Federated Forest" prodocts coming out and about
>how
>.NET will support kerberos trusts between forests)
>
>After conversations with Microsoft, our organization and Microsoft both
>agreed that multiple domains within a Forest are possible only if _all_
>domain administrators in every domain are completely trusted among each
>other. The fact (stated in the paper) is that a domain admin in domain
>A
>can overcome AD security to affect domain B, or any other domain in the
>forest for that matter. This is why trusting the domain admins is such
>a
>concern in deploying Active Directory.
>
>The other big issue is physical security of the Domain Controllers - an
>offline modification of the forest schema (this is stored on all DC's)
>can
>be uploaded into the distributed AD forest once the DC is back online.
>This
>means if you have a remote office DC with no physical security, a hacker
>on
>site modifying the schema can then "own" your entire forest.
>
>For recommendations to make a secure deployment... If you haven't
>already,
>use group policies like crazy. Use baseline server policies and then
>special application policies to slap on top of those baseline policies.
>
>(Example: apply baseline policy, then apply IIS policy on IIS servers)
>Desktops need good regulation of group policies as well. The NSA's
>documentation of group policies and recommended settings is a good place
>to
>start. Not all of it will work in your environment, but it's great
>info.
>Auditing is also very important - audit changes in domain admin groups,
>Domain Controller downtime, etc... Audit everything that is potentially
>a
>security concern in AD.
>
> >For example, could a compromised workstation in a remote site affect
> >the
> >workstations or servers in another domain?
>For limiting the exposure of a compromised PC to affect other PC's, we
>also
>set the group policy setting to only allow our Desktop Admin group and
>Domain Admin group to connect to the PC's over the network. This way if
>all
>PC's have the same admin account since they are all imaged, a user could
>not
>crack the password and use that account to "hack" into every PC on your
>network. This also stops unwanted file sharing between PC's and keeps
>their
>work data on the servers so they can be backed up nightly.
>
>I hope this helps,
>
>-Jared
>
>_________________________________________________________________
>STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
>http://join.msn.com/?page=features/junkmail

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail

• Next message: auto472736@hushmail.com: "outlook 2000 vs latest outlook express deployment"
• Previous message: Jason Normanton: "RE: Active Directory network security"
• Maybe in reply to: RGN: "Active Directory network security"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]