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 -----
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: ActiveDir@mail.activedir.org
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: ActiveDir@mail.activedir.org
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.

Reply via email to