With the IFM feature in 2003 the promotion issue is not that much of an issue.
Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:ActiveDir- > [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Friday, September 15, 2006 1: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
