Re: Are Domains True Security Boundaries?

From: Mike Brannigan [MSFT] (mikebran_at_online.microsoft.com)
Date: 09/14/04 

Date: Tue, 14 Sep 2004 19:31:10 +0100

"John" <test@nowhere.net> wrote in message
news:u3R7A%23mmEHA.2772@tk2msftngp13.phx.gbl...
> Can anyone give me a solid concrete example of what a domain admin could
> do
> in one domain to adversely affect a forest?
>
> I cam come up with some, but would like someone else to give one or two.
> It
> adds validity to our conversation with Europe to hear these thoughts
> coming
> from external individuals.
>
> For example, I have read that even a domain admin in one domain "can
> overcome AD security to affect domain B or any other domain in the
> forest..." how... and what exactly.
>
> Thanks

The DC in a domain contains certain forest wide configuration information
that I have already mentioned (the schema and configuration naming contexts)
those 2 items alone may be attacked by someone of Administrator privilege
and could to an extremely severe situation to develop within the forest.

Another even simpler example is a domain admin in one domain acquiring the
SID of a other user e.g. Enterprise Admin (often an easy task) and then
appending that SID to the SID history of his or some other's account.
This is an effective raising of privileges.

I am not going into too much detail here for obvious reasons, but if
security is a major concern to you and you are not up to speed on all of the
issues then you would be well advised to seek some professional consultancy
especially when dealing with such a large and complex security sensitive
enterprise as you seem to be involved in.

If Europe is concerned about security and has a lack of trust with ANYONE
else that is being given a highly privileged service admin position in ANY
other domain in the forest then they have good grounds for moving you to a
multi forest design.

Left me give you a few things to think about.

The people in your forest who pose a risk to you are the “service admins”
Service admin: admin who can modify operating system behavior
Note: highly privileged service admins exist in all computing systems
    Applying QFEs, SPs, doing upgrades are all legitimate changes to system
behavior
    Malicious service admins can alter system behavior to achieve malicious
ends

Malicious domain controller service admins can do just about anything
    Impersonate any user in any domain
    Read, modify, or delete any Windows-secured resource or config setting
on any machine joined to any domain in forest
    Bypass, disable, or defeat system invariants such as ACLs, auditing,
FSMOs, read-only partitions, etc
    Cause changes to replicate to other DCs
    … and more

Methods of attack (some)
    Inject code into system security context on DC, attach to and modify
code in LSA
    Boot DC to Restore Mode or alternate OS and perform offline edit of AD
database

So who are the Service Admins you need to trust across your entire forest ?

<root>\Enterprise Admins
<root>\Schema Admins
<domain>\Domain Admins
<domain>\Administrators
<domain>\Server Operators
<domain>\Backup Operators
<domain>\Account Operators
<domain>\Print Operators
Plus the above in DS Restore Mode

You also need to consider physical access to your DCs
    Any person with physical access to a domain controller can elevate
themselves to "service admin"
        Boot DC to alternate OS, replace binaries
        Crack passwords stored in DS database

So some things to consider and what the dmain owners or proposed domain
owners must ask themselves and each other.
Each domain owner must agree to following concerning other domains in the
forest:

1. Reasonably believe service admins in other domains will look out for
overall organization’s best interests
“They have no vested interest to attack me.”

2. Agree that other domain owners have service admin management and
selection policies/practices that are equal to or more strict than your own
“I trust their admins and admin management processes as much as I trust
mine.”

3. Agree that domain controllers of other domains are physically secured
using practices equal to or more strict than your own
“They aren’t putting DCs anywhere that I think inadvisable.”

4. Agree that long lasting agreement is in place - criteria remains valid in
future
Divisions are autonomous, people can change jobs – could new management try
to change admin policies?
       Is there sufficient guarantee each division will maintain operational
criteria over time?
        i.e. If Division A has strict service admin selection policies,
they cannot relax them in the future
If any criteria is invalidated in the future, restructuring may be required 

-- 
Regards,
Mike
--
Mike Brannigan [Microsoft]
This posting is provided "AS IS" with no warranties, and confers no
rights
Please note I cannot respond to e-mailed questions, please use these
newsgroups
"John" <test@nowhere.net> wrote in message 
news:u3R7A%23mmEHA.2772@tk2msftngp13.phx.gbl...
> Can anyone give me a solid concrete example of what a domain admin could 
> do
> in one domain to adversely affect a forest?
>
> I cam come up with some, but would like someone else to give one or two. 
> It
> adds validity to our conversation with Europe to hear these thoughts 
> coming
> from external individuals.
>
> For example, I have read that even a domain admin in one domain "can
> overcome AD security to affect domain B or any other domain in the
> forest..."  how... and what exactly.
>
> Thanks
>
>
> "Mike Brannigan [MSFT]" <mikebran@online.microsoft.com> wrote in message
> news:Oizi5lmmEHA.3712@TK2MSFTNGP15.phx.gbl...
>> John,
>>
>> A Domain is a boundary of security policy only.
>> The ONLY true bondary of security is the Forest.
>> So if you do not trust a group of "domain admin" who for whatever reason
> you
>> give their own Domain to then that Domain and those Domain Admins should
> not
>> exist within your forest.
>> The security ramifications go deeper in that you actually have to trust
> all
>> your service admins across the entire forest
>>
>> You need to get your overall structure of ownership and responsibility
>> sorted before you can get to your Domain model.
>> If the European banks wants autonomy - whet?  are they allowed to have it
> ?
>> who is running he overall Enterprise here, can you all agree on having 
>> one
>> group of people have ultimate control of Enterprise wide resources in the
>> directory such as the schema and the configuration naming contexts.
>>
>> This is hugely complex are and beyond the scope of a simple newsgroup
>> response.
>>
>> have you read and digested all the appropriate planning and guidance
>> documentation we produce on this ?
>> See the deployment planning guides and various whitepapers.
>> Start with the Windows Server 2003 Deployment Resource Kit
>>
>> -- 
>>
>> Regards,
>>
>> Mike
>> --
>> Mike Brannigan [Microsoft]
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights
>>
>> Please note I cannot respond to e-mailed questions, please use these
>> newsgroups
>>
>> "John" <test@nowhere.net> wrote in message
>> news:eRdCY4lmEHA.2968@TK2MSFTNGP14.phx.gbl...
>> > Our global company (only about 30,000 users) is in heated debates about
>> > whether to have one domain or multiple domains.   We have determined
> that
>> > the direction of the company is to centralize IT, although we aren't
> 100%
>> > there yet.   We propose building a model with a "core team" able to act
> in
>> > Domain Admin roles, while "weeding out" all the current domain admins
> that
>> > are not "trusted" in the company.
>> >
>> > We have a common security policy, a few core enterprise applications
> that
>> > are looking for a simplified implementation, and our users desire ease
> of
>> > access regardless of where they sit in the company.  (lots of salesmen,
>> > lots
>> > of travelling)   We have even worked through the language issues that
>> > might
>> > exist.
>> >
>> > What we struggle with is the concept of a domain being a security
>> > boundary.
>> > For example, our European group has a largely decentrailized IT
> structure
>> > currently.   They claim they would like all 20 of their current Domain
>> > Admins to have Domain Admin access.  They state for this reason that
> they
>> > want a second domain so that they can apply these rights to these
>> > individuals.
>> >
>> > We feel that adding a second domain and giving untrusted domain admin
>> > rights
>> > away would compromise the entire structure we are trying to build, as
> well
>> > as undermine the goal of centralized IT.   The thought was that if they
>> > truely had the need to be separated in this manner a separate forest
> would
>> > be the true way of separating them out.  However, a second forest is 
>> > not
>> > an
>> > option for our discussion.
>> >
>> > Does anyone have any thoughts on this?  Can we really add a second
> domain
>> > and give all these admins rights and still maintain integrity and
>> > security?
>> > If so, should it be a child domain?   Or are we best to follow the
>> > business
>> > and IT initiative to centralize and work toward "globalization" of our
>> > company.
>> >
>> >
>>
>>
>
>
Loading