"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: ActiveDir@mail.activedir.org Cc: ActiveDir@mail.activedir.org; [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: ActiveDir@mail.activedir.org [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: ActiveDir@mail.activedir.org 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. 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
