COMMAND

    Directory service

SYSTEMS AFFECTED

    Win2k

PROBLEM

    Michal Zeman  and Pavol  Mederly came  across one  security issue;
    which may be critical  for large organizations planning  to deploy
    Windows 2000 and Active Directory in one forest.

    Imagine that there is a forest  with more than one domain.   (Tree
    hierarchy does not  matter in this  situation.)  Every  domain has
    its own set of administrators.

    In Active directory there  is one Configuration Container  for the
    whole forest.   So every  domain controller  has its  own copy  of
    Configuration Container  and is  able to  change it  and replicate
    changes to  other domain  controllers.   The only  obstruction for
    changing configuration are  ACLs.  But  ACLs are checked  on local
    system and if  you somehow modify  it to avoid  this checking, you
    can modify this Container.

    How to do it?  It is just a matter of finding a place where ACL is
    checked and patching correspoding DLL to disable this check.

    We think the check is done in Directory Service Agent.  So you can
    patch and  replace it  or add  a patched  version to  original one
    running in the  context of LSA  - for how  to run own  code in the
    context of LSA, see pwdump2 utility.   What you need in this  case
    is SeDebugPrivilege.

    Real issue is: if in  this situation one of domain  controllers is
    hacked, hacker can change links for Site Domain policy, where  are
    stored paths  for logon/logoff  and startup/shutdown  scripts.  So
    run own codes on any other domain controller in forest.

    If you have large organization, every DC is then (almost)  equally
    vulnerable; if a hacker beaks into one, he gets all.

    There a few other ways to get to a hack of this sort.  These  also
    assume a compromised DC in one domain of a multidomain Forest.

SOLUTION

    Use  DNProtect  to  keep  site-connection  objects secured against
    access by SYSTEM context.  Problem is, you need to rerun DNProtect
    every time any change occurs to the object and it isn't  offiially
    supported.  Additionally, the only published info on this  utility
    seems to be a mention of it in "Notes from the Field"

    Promote Replica  DCs using  the Domain  Admin of  that domain, not
    Domain Admin of the empty root domain.  This prevents some  issues
    with    ownership    of    objects    being    marked    as    the
    BUILTIN\Administrator account.   If ownership  is flagged  to this
    account Admins in other DCs  can manipulate the objects.   This is
    easy to prevent but runs counter to MS's recommendations.

    It appears  that keeping  separate domains  from sharing  the same
    sites  has  some   positive  effect,  but   that  is   ridiculous.
    Unfortunately,  the  only  means  of  clearly  providing the fault
    isolation  one  would  expect  from  separate  domains  appears to
    actually  be  se  parate  forests.   Maybe  we just don't get this
    product.    It   seems   fine   for   smaller   organizations,  or
    organizations which already use a single centralized group for all
    IT administration.  In a decentralized environment, it appears  to
    demand either a change in the administrative structure or separate
    forests.