|
One thing to bear in mind is that, by default, Domain Admins in
the root domain have permission to modify the membership of the EA group.
One approach to mitigate abuse is to keep the group empty and monitor changes
to membership. I suppose you could also enforce the membership by using a
Restricted Group policy. Tony From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan Holme EA
“rights”, once a forest is deployed and delegated, are needed only
for “in case of emergency break glass” – i.e. pretty much
never. When you’re talking EA, you’re pretty much talking the
Administrator account of the forest root domain (first domain installed), so
think of them one and the same—you will be locking down that
Administrator account to lock down EA. Either it’s the ONLY account
in the EA group (default) or any other account in EA should be locked down
pretty much equivalently. The
“break glass” scenario is, particularly in a multi-domain forest,
someone does some nasty delegation (ACL modification) that effectively
“locks out” an OU. Just like you could, theoretically,
“lock yourself out” of an NTFS folder. Just like an NTFS
folder, the “owner” of the folder ALWAYS can change the ACL, and
open it back up again. In AD the “owner” is EA… it owns
the forest. So, one container at a time, EA will be able to dig down and
unblock. Case
study: One client of mine (100k employees) has only three accounts in the EA
group, which in their case is in a dedicated forest root. I don’t
believe they’ve used the accounts on over a year. Another client
(global financial services company) has ONLY the default Administrator account
in EA, and that account has had a three-way password created: three
admins each entered PART of a password, the password “pieces” were
put into an envelope in a physically secure location in Europe and another in
N.America. AFAIK they haven’t used it since they locked the account
down. Read
the MS doc “Best practices for AD Delegation” to effectively
delegate your forest, PARTICULARLY if you have more than one domain in your
forest. The things that tend to get “missed” that impact
day-to-day or even occasional operations are things like delegating the
creation of sites, subnets, and site links; the ability to kick off replication
(not recommended but…); and authorize new DHCP Servers. I’m
sure that others on the list will have other tips as well. Dan From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] We're trying to understand
when EA rights are needed within a multi domain forest, where each domain
represents a fairly autonomous region. Mgmt have suggested that
the following is true : Can anyone please throw a
few reasons at me why you would need EA rights on a daily basis?
Troubleshooting? Diagnosis? How would you be impacted
if you had to request access to a EA account each time it was required? I'd like to build a case
whereby we have permanent EAs and would like some additional ammo from you guys
:) ***Feel free to argue
against my views and explain to me how/why you *could* manage a forest such as
the above, without access to an EA account on a daily basis. Thanks, 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 communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. |
Title: When and how often are EA rights needed?
- RE: [ActiveDir] When and how often are EA rights needed? Tony Murray
- RE: [ActiveDir] When and how often are EA rights needed? Dan Holme
- RE: [ActiveDir] When and how often are EA rights needed? Dan Holme
- RE: [ActiveDir] When and how often are EA rights needed? deji
- RE: [ActiveDir] When and how often are EA rights needed? deji
- RE: [ActiveDir] When and how often are EA rights needed? neil.ruston
- RE: [ActiveDir] When and how often are EA rights needed? joe
