"Elevating priveledges from DA to EA (or from physical DC access to EA)
is simple"
Is this physical access to a DC in the root domain or physical access to
a DC with a forest trust to the root domain?
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, September 15, 2006 12:15 PM
To: [email protected]
Cc: [email protected]; [EMAIL PROTECTED]
Subject: Re: [ActiveDir] Elevating privileges from DA to EA
Hi All
I wanted to weigh in with two comments.
1) Elevating priveledges from DA to EA (or from physical DC access to
EA)
is simple - it takes about 45 minutes and unless you have some very good
active monitoring is difficult to detect. There are automated tools out
there for doing this. I have been known to use the term lazy EAs to
refer
to domain admins.
2) Replication boundaries is another reason for separate domains. a
million objects can lead to huge DITs and very slow replication -
especially in a build a new DC case. Separating that into multiple
domains
- to put smaller load on locations where bandwidth is an issue is worth
considering. For example.
90,000 users. 200 of those are in Alaska
The rest of the world has good bandwidth, Alaska locations all
have
the equivalent of 56K modem speed.
DIT and Sysvol size is about 7G, but for Alaska users there are
only
3 GPOs that affect them
Rather then doing 1 domain I can put the 200 Alaska users in their
own domain. Security wise, there is no advantage. Replication wise,
the
Global Catalgue is a fraction the size of the full database, the Sysvol
never replicates anywhere in Alaska, and replicaiton for that
domain will cause less strain on their bandwidth - 200 users will create
a
much lower amount of changes then 90,000 users.
Regards;
James R. Day
Active Directory Core Team
Office of the Chief Information Officer
National Park Service
202-230-2983
[EMAIL PROTECTED]
"Al Mulnick"
<[EMAIL PROTECTED]
om>
To
Sent by: [email protected]
[EMAIL PROTECTED]
cc
ail.activedir.org
Subject
Re: [ActiveDir] Elevating
09/15/2006 11:34 privileges from DA to EA
AM AST
Please respond to
[EMAIL PROTECTED]
tivedir.org
I agree and add to that some additional thoughts:
Not long ago there was some conversation around a suggestion that
[EMAIL PROTECTED] put out regarding the idea of using multiple
forests
vs. domains in such a model. Personally, I disagree with that
recommendation as given. I think A LOT more additional information is
required before saying that, but I digress.
If you decide to use the multi-domain model, I have to assume that you
either have different password policies or a strong layer-8 contingent
driving things. If the latter, I hate it for you.
If you have a requirement to separate the domains from the forest, your
workload just went through the roof, and with that your costs.
Was it me I'd want to learn from my past mistakes ;0) and approach this
by
reversing the conversation. By that I mean I'd want each potential
domain
owner to absolutely and in a detailed manner specify the functions they
need to execute. From there, we'll encompass the rights needed for each
of
those functions. I think what you'll find is that you can do almost all
of
it with a single domain if different password policies are not needed
(mostly, but you know all of that anyway). From there, I'd be sure to
spell
all of that out the project sponsor because the costs (both ongoing and
up
front) can be significant. The amount of complexity and issues with
other
directory based applications alone can be enough to put them off and
actually follow a recommendation such as this. The push obviously is to
get
as few actual DA's as possible.
Is the threat real? Yes. If you feel you should have multiple domains,
chances are good you really need OU's and a better admin model that
includes less complexity and fewer moving parts.
Oh, one other thing that might be of interst to your planning group: ask
them about their restoration requirements. In that model, restoration
can
be a bloody nightmare especially if the layer-8 issues are not resolved
up
front.
Al
On 9/15/06, Paul Williams <[EMAIL PROTECTED]> wrote:
Neil,
Try a re-read of the first couple of chapters of the first part of the
deployment guide book designing and deploying directory and security
services. Obviously it doesn't spell out how to do this -it doesn't
even
allude to how this is done- but does emphasise when and when not to go
with the regional domain model.
I'm not disputing what anyone is saying here -I agree. I just happen
to
think the regional model can be a good one, and that if done properly
works. Even from a security stand point. The main thing with the
regional design is that there's a central group of service admins, or
a
true delegated model.
If you have multiple groups of service admins it can still work, but
the
issue that has been raised is very real and you probably need to
implement processes and monitor against it (if you're forced into such
a
design by the needs of the business or obtuse upper management ;-).
Although it does seem to be possible to implement disparate groups of
service admins if you follow the delegation whitepaper (you'll need to
improvide, but most of the info. is pertinent), which should put you
in a
much stronger position from a security stand point. If you can
achieve a
very small number of people who are actually members of the
builtin\Administrators group, and the rest only have delegated
permissions and privileges (and preferably very few privileges on the
DCs, i.e. no logon locally) you can achieve what you want.
Joe's been there and done it...
--Paul
----- Original Message -----
From: Almeida Pinto, Jorge de
To: [email protected]
Sent: Friday, September 15, 2006 8:48 AM
Subject: RE: [ActiveDir] Elevating privileges from DA to EA
>>>Al - we are designing a forest with regional domains (don't ask!)
and
one region has suggested it needs to split from this forest since
elevating rights in any regional domain from DA to EA (forest wide) is
'simple' [and this would break the admin / support model].
What is being said is very very true. Either you trust ALL Domain
Admins
(no matter the domain those are in) or you do not trust ANY! Every
Domain
Admin or ANY person with physical access to a DC has the possibility
to
turn the complete forest into crap!
Because if that was NOT the case the DOMAIN would be the security
boundary. Unfortunately it is not! The Forest is the security
boundary,
whereas EVERY single DC in the forest MUST be protected and EVERY
Domain
Admin MUST be trusted!
>>>I am arguing that it is not simple and am looking for methods which
may be used to elevate rights as per the above
When you know HOW, it is as easy as taking candy from a baby
jorge
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Friday, September 15, 2006 09:36
To: [email protected]
Subject: RE: [ActiveDir] Elevating privileges from DA to EA
Thanks for responses, all.
Al - we are designing a forest with regional domains (don't ask!) and
one
region has suggested it needs to split from this forest since
elevating
rights in any regional domain from DA to EA (forest wide) is 'simple'
[and this would break the admin / support model].
I am arguing that it is not simple and am looking for methods which
may
be used to elevate rights as per the above.
Make sense?
neil
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: 14 September 2006 20:59
To: [email protected]
Subject: Re: [ActiveDir] Elevating privileges from DA to EA
Can you reword? I'm not sure I clearly understand the question.
FWIW, going from DA to EA is a matter of adding one's id to the EA
group.
DA's have that right in the root domain of the forest (DA's of the
root
domain have that right). Editing etc. is not necessary. Nor are
key-loggers etc.
If physical access is available, there are plenty of ways to get the
access you require to a domain but I suspect you're asking how can a
DA
from a child domain gain EA access; is that the question you're
looking
to answer?
Just for curiousity, what brings up that question?
Al
On 9/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
It has been suggested by certain parties here that elevating one's
rights from AD to EA is 'simple'.
I have suggested that whilst it's possible it is not simple at all.
Does anyone have any descriptions of methods / backdoors /
workarounds
etc that can be used to elevate rights in this way? Naturally, you
may
prefer to send this to me offline :) [ [EMAIL PROTECTED]
I can think of the following basic methods:
- Remove DC disks and edit offline
- Introduce key logger on admin workstation / DC
- Inject code into lsass
As you can see, I don't want specific steps to 'hack' the DC, just
basic ideas / methods.
Thanks,
neil
PLEASE READ: The information contained in this email is confidential
and
intended for the named recipient(s) only. If you are not an intended
recipient of this email please notify the sender immediately and
delete
your
copy from your system. You must not copy, distribute or take any
further
action in reliance on it. Email is not a secure method of
communication
and
Nomura International plc ('NIplc') will not, to the extent permitted
by
law,
accept responsibility or liability for (a) the accuracy or
completeness
of,
or (b) the presence of any virus, worm or similar malicious or
disabling
code in, this message or any attachment(s) to it. If verification of
this
email is sought then please request a hard copy. Unless otherwise
stated
this email: (1) is not, and should not be treated or relied upon as,
investment research; (2) contains views or opinions that are solely
those of
the author and do not necessarily represent those of NIplc; (3) is
intended
for informational purposes only and is not a recommendation,
solicitation or
offer to buy or sell securities or related financial instruments.
NIplc
does not provide investment services to private customers.
Authorised
and
regulated by the Financial Services Authority. Registered in England
no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St
Martin's-le-Grand,
London, EC1A 4NP. A member of the Nomura group of companies.
PLEASE READ: The information contained in this email is confidential
and
intended for the named recipient(s) only. If you are not an intended
recipient of this email please notify the sender immediately and
delete
your
copy from your system. You must not copy, distribute or take any
further
action in reliance on it. Email is not a secure method of
communication
and
Nomura International plc ('NIplc') will not, to the extent permitted
by
law,
accept responsibility or liability for (a) the accuracy or
completeness
of,
or (b) the presence of any virus, worm or similar malicious or
disabling
code in, this message or any attachment(s) to it. If verification of
this
email is sought then please request a hard copy. Unless otherwise
stated
this email: (1) is not, and should not be treated or relied upon as,
investment research; (2) contains views or opinions that are solely
those
of
the author and do not necessarily represent those of NIplc; (3) is
intended
for informational purposes only and is not a recommendation,
solicitation
or
offer to buy or sell securities or related financial instruments.
NIplc
does not provide investment services to private customers. Authorised
and
regulated by the Financial Services Authority. Registered in England
no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St
Martin's-le-Grand,
London, EC1A 4NP. A member of the Nomura group of companies.
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be
copied, disclosed to, retained or used by, any other party. If you
are
not an intended recipient then please promptly delete this e-mail and
any
attachment and all copies and inform the sender. Thank you.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
