I should expose one or two of my VM environments, I could stand to lose a few pounds. :)
There are things that can be done that can be reversed, there are other things that you can't get out of unless you have good working offline backups of your entire forest and your domain is gone until you recover a couple of the DCs and repromote the rest of your environment from them. As you mention, LH doesn't stop everything but it helps in certain scenarios. The primary point is that you are reducing surface area with the RODCs. You can still do some stupid things with them but that is more up to you. Theoretically, you should be able to *properly* deploy an RODC to a site and not have to fear being hacked through it. However, that remains to be seen, as previously mentioned, you cannot prove an environment secure, only insecure. -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Williams Sent: Sunday, September 17, 2006 10:25 AM To: [email protected] Subject: Re: [ActiveDir] Elevating privileges from DA to EA It doesn't matter what domain it is in. If you have access to it you can hack it. What you do once you've hacked it is up to you. Jorge and I just tested this and we we able to do some serious damage. It was trivial to delete domain controllers and move FSMO roles and other things, etc. And this applies to both 2000 and 2003. Longhorn's different. One of the easy attack vectors has been removed. I doubt all have, but can't test at the moment as I'm loosing the will to live waiting for applications to open and the ability to double click things (running on a VM ;-) Note. Its likely that any damage caused can be undone, as AD is very flexible in that regard. However the damage caused by someone accessing data or systems that they shouldn't is much worse, and can cause millions of pounds of loss. --Paul ----- Original Message ----- From: "Kevin Brunson" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, September 15, 2006 9:41 PM Subject: RE: [ActiveDir] Elevating privileges from DA to EA > "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 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
