During the writing/reviewing of the AD Delegation whitepaper there was a considerable amount of discussion amongst those of us involved around the logic of delegating EA rights. It has been awhile but I believe that the general consensus came down to exactly what neil is describing. It is better to manage these permissions by having a very small very trusted group than trying to parse the permissions out because in the end, you will probably end up parsing those permissions out to the same few people anyway. Allowing folks not absolutely responsible for replication/etc to manipulate the sites and subnets is a pretty perverted way to get your kicks, at least in my book.
Back in the old days when I did AD ops... ;o) We had three engineers and one manager, each of whom had an admin ID in each domain of the forest. These same folks all had normal user IDs as well and preferably the passwords were not in sync. The proper ID was used for the task at hand, generally, the normal userids were used a majority of the time right up until something needed to be modified. Other than that there was VERY limited delegation for such things as setting descriptions or membership on groups and setting descriptions on server computer accounts. Most object creates was either handled by the domain admins or the provisioning system. Workstations created their own accounts during the scripted build process. As an aside, with every passing DEC which is obviously fresh in my mind right now I see delegation becoming less and less important as using provisioning becomes more and more important. The delegation model while cool, has too many other shortcomings which proper provisioning handles. I am pretty vocal in my dislike of MIIS/IIFP due to its SQL requirements (I would like black box ESE please) but during the "MVP" RoundTable at DEC even I thought the answer to the first several questions was MIIS which gave me a start. I don't see direct delegation dropping off the map tomorrow as a viable protection mechanism, but as I mention above I truly see its usefulness (and consequently, its use) in the future becoming more and more limited. The easier the provisioning gets to configure and manage, the faster this will occur. Personally I would like to see more power in AD delegation and triggering and rules but if I am honest with myself visualize IIFP/MIIS getting more closely integrated into AD and practically running itself to provide those functions. I actually told Stuart Kwan of the Ottawa Kwan Clan up on the stage that I finally realized I needed to seriously start playing with MIIS. He chuckled. But I still want ESE in the backend. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, March 15, 2006 3:09 AM To: [email protected] Subject: RE: [ActiveDir] When and how often are EA rights needed? Granted, they do not come close. My point is that if you can manage sites and subnets and replication etc, then you are acting as tho you were an EA and the custodian of the forest. I would rather have a dedicated team of EA people and that the enterprise wide components (such as the above) are managed by these folk and *no others*. That's why I consider anyone with the rights to change sites/subnets/replication to be an EA equivalent. Thanks for all the comments - even though I didn't receive too much backing and extra ammo :) neil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 15 March 2006 01:00 To: [email protected] Subject: RE: [ActiveDir] When and how often are EA rights needed? >>>IMHO, if you have rights to do all the above, you are an EA >>>equivalent any way :) These rights do not even come close to equaling EA in any sense. Sincerely, Dèjì Akómöláfé, MCSE+M MCSA+M MCT Microsoft MVP - Directory Services www.readymaids.com - we know IT www.akomolafe.com Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon ________________________________ From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED] Sent: Tue 3/14/2006 9:00 AM To: [email protected] Subject: RE: [ActiveDir] When and how often are EA rights needed? 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. So how do they manage and t.shoot their AD? 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. IMHO, if you have rights to do all the above, you are an EA equivalent any way :) Thnanks for the comments. neil ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Holme Sent: 14 March 2006 16:51 To: [email protected] Subject: RE: [ActiveDir] When and how often are EA rights needed? 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] Sent: Tuesday, March 14, 2006 9:29 AM To: [email protected] Subject: [ActiveDir] When and how often are EA rights needed? 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 : - EA not needed on daily basis - EA rights rarely needed after initial deployment 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, 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. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ 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. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
