RE: [ActiveDir] Elevating privileges from DA to EA

Fri, 15 Sep 2006 19:35:00 -0700

I am the type that argues that 3-5 EA/DA folks is good for any size org. Showing that the large companies with hundreds of thousands of seats can accomplish it helps illustrate that smaller companies should be able to accomplish it and that instead of making the job harder,it makes it easier. It may be tougher up front while you fight the political battles and learn how your environment and processes really work but once that is done, life is much easier as AD doesn't tend to just break on its own, people screw up. The less chances available for those screwups the smoother things run.
 
When I see companies with tens or hundreds or even thousands of folks with admin (or other native built in group) access in a forest I just get an upset stomach because I know that things are almost certainly not running as smoothly as they could be. In fact, from my experiences, the more admins there are, it seems the more harried and running they all are.
 
Getting down to a few EA/DAs is all about process and automation. Do it right, it is feasible and works great. Do it wrong, you have admins burning out every 3 months. I understand that admins don't have time to automate things and make the environment better. I have been in similar positions, positions where I had no choice but to work 80-100 a week every week always carrying a pager, etc. When in those positions I made the conscious choice to make sure I found a little time every day (even 30 minutes) to do some little bit. This slowly adds up. If you attack the items you are spending the most time on during the day, you slowly start freeing yourself up more and more and if it is to automate something that is being done manually more than likely you are saving even more time when that something is done correctly and consistently every time (everyone makes mistakes when doing things manually).
 
Absolutely you need to be running separate admin and normal user IDs for admins. You could be the best admin in the world but it is stupid not to take care to make sure that if for some reason you make some small slip, the chances are reduced that something bad can result. My general recommendation is normal ID and dollar sign ID, e.g. jricha34 and $jricha34. Maybe even going to double dollar for enterprise admin to make that stand out even more so jricha34, $jricha34, and $$jricha34. Also make sure that these IDs are not used interactively on workstations and avoid logging into any servers that you don't fully trust (i.e. you own and only the DAs can log into or manipulate).
 
Now for the regional forest... I haven't heard a good reason for one yet. I haven't heard a good reason for separate DAs for geographies. The best reasons I have heard are in relation to divisions within a company, say like a financial division of a company that's main business is manufacturing or distribution or something. The banking laws in some companies can be a bit involved and in _some_ of those cases there may be a need for a separate forest. There needs to be really good documentation of all of the why's though. A company is often better served as a whole if divisions and geographies bow down and let one group handle the overall functioning of the AD service. Assuming the group doing the work actually knows what it is doing, things will usually be much better off. Politics tends to get in the way here until someone gets sick of the politics and either makes an executive decision or stages a coup and forcefully takes control.
 
I am with James that policy and replication boundaries are valid reasons for separate domains. Perfect world is single forest domain, things from Microsoft just work better in those environments. But as James pointed out with his example, with the current replication model, a single domain forest just can't work sometimes even if the policy is the same in all domains.
 
 
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm 
 
 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Hargraves
Sent: Friday, September 15, 2006 12:22 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Elevating privileges from DA to EA

I agree with the people who are saying "Either trust all of them or none of them".  Realistically, unless you have a large environment (BTW, some people argue that all but maybe 10 Fortune 100 companies are 'medium' sized and the other 99.9999% of organizations are 'small'), there should only be a handful of people (3-7?) and some service accounts that require that level of rights.

Domain/Enterprise Admins are a tricky bunch and no matter what you do to us, we can take back whatever rights you took away from us very easily, then lock you and everyone else in the world out, destroy the on-site backups and demolish the environment to where it's going to take a major effort to get back to operational status.  This would take all take significantly less time than it would take for someone to figure out who is doing what.  I like Joe's recommendation of taking everyone that you don't need out of the admins groups and simply granting them various levels of rights with their account.  Possibly give everyone a user and admin account (user1234567 and user1234567a), heaven knows it would make troubleshooting a lot easier.

That being said, someone asking for their own regional forest?  Fine, as long as the person saying that it's necessary is willing to come up with the budget for the additional servers and additional personnel to support that forest and that they understand that they will have 0 admin level rights on anything in the 'main' forest, it wouldn't bother me, just one less thing that I have to worry about managing.  Oh yeah, and they have to pay for yearly audits to validate that they are meeting the corporate standards for security at all levels.

Then again, most of those items aren't usually my concern.  Thank God I'm not in management :D

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 -----
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