RE: Active Directory network security

From: Jason Normanton (netprouk@netprouk.com)
Date: 11/16/02

  • Next message: J M: "RE: Active Directory network security"
    From: "Jason Normanton" <netprouk@netprouk.com>
    To: "'J. .'" <bugtraqlist@hotmail.com>, <focus-ms@securityfocus.com>
    Date: Sat, 16 Nov 2002 15:45:02 -0000
    
    

    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



    Relevant Pages

    • RE: Active Directory network security
      ... AD's group policies can be used to keep AD itself pretty secure, ... down tightly for security within AD, but a rogue laptop that is not a domain ... When Microsoft first touted Active Directory they pushed for a Single Forest ... Auditing is also very important - audit changes in domain admin groups, ...
      (Focus-Microsoft)
    • Re: Site or Domain
      ... Domain aren't security Boundaries, ... forest, and they are not themselves the ultimate security boundary. ... Each Active Directory domain is authoritative for the ... Domain controller hardware and security facilities Each Windows Server ...
      (microsoft.public.windows.server.active_directory)
    • RE: Active Directory network security
      ... >Subject: RE: Active Directory network security ... >X-Mailer: Microsoft Outlook, Build 10.0.2627 ... In fact the only true security boundary in AD is a forest. ... >Domain Admins must be fully trusted. ...
      (Focus-Microsoft)
    • Re: AD Design
      ... If you are the only admins, then multi-domains does not achieve anything ... If you share admin with your clients, then sharing the same forest ... You also need to think about physical security, ...
      (microsoft.public.windows.server.active_directory)
    • Re: Reasons for Empty (headless root) Root
      ... I am very interested in learning more about how the security is between domain and domain vs forest. ... I quickly and easily compromised a root domain from a child domain for the first time in about May 2000 showing how simple it was and nothing has changed. ... Domains are sort of a replication boundary, the config and schema replicate across all DCs in a forest and also obviously GCs replicate across domain NC boundaries. ...
      (microsoft.public.windows.server.active_directory)