RE: [ActiveDir] Sites and Services Permissions

[GRILLENMEIER,GUIDO (HP-Germany,ex1)]

there is no need for you to change any permissions in sites & services - the defaults will usually suffice to do what you want: permissions on site, subnets, sitelinks etc. are restricted for changes by enterprise admins.   The one thing you may want to pay attention to is: who is allowed to designate a DC to be a GC (or to undesignate a GC back to a normal DC). Domain Admins are granted full control over their DC objects including write permission on the DC's NTDS settings object and it's options attribute. This allows them promote their DCs to GCs which can have a direct impact on the replication plan designed by the enterprise admin.  You could deny this permission for the child Domain Admins, but realize, that (as they have full control over the object) they could regain the permissions if they absolutely wanted (and it makes no sense to try to take away more permissions, as they could always leverage the system-account of the DC if they really wanted to do harm - Joe's comment below referrs to this "feature").  Also, as these permissions are set explicitely by default when promoting a new DC, you'll have a hard time catching up as an enterprise admin to restrict the permissions on newly promoted DCs.  The same goes for permissions connection objects...   So I would much preferr to have a clear plan for what your replication toplogy should be like, who replicates with whom and which DCs are supposed to be GCs and which are not, and to communicate the rules to the child DAs which they have to obey to prior to be granted the DA permissions for "their" domain. Then use tools to show you and monitor what your replication topology really looks like (really usefuly for troubleshooting anyways). Good suggestions here are Quest's Spotlight on AD (has an AD topology viewer) and HP's OpenView with the AD SPI (contains 3-D AD topology viewer).   And if you really want to control who can do what on the child domain DCs, then you should look into tools like NetPro's Directory Lockdown tool, which allows the Enterprise Admin to monitor and restrict any changes to the configuration + schema container of the forest.   /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Witasick Sent: Freitag, 23. Januar 2004 18:47 To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] Sites and Services Permissions Joe,   My thanks to you, and to Roger, for your responses.   Your podium point is well taken.  Unfortunately, I do not have this "one-umbrella" luxury in my environment - a domain may not function as a security boundary, but it does serve as a political boundary.  So, while I may not be able to stop the rogue admin, I'd like to make it as difficult as possible for them outside of their domain.  Any other suggestions on how to accomplish this would be greatly appreciated.   John ----- Original Message ----- From: joe To: [EMAIL PROTECTED] Sent: Thursday, January 22, 2004 10:38 PM Subject: RE: [ActiveDir] Sites and Services Permissions I'm just winging it and the answer is probably in the AD Delegation Whitepaper but I don't recall off the top of my head...   Best Practices for Delegating Active Directory Administration (2.7 MB) http://www.microsoft.com/downloads/details.aspx?FamilyID=631747a3-79e1-48fa-9730-dae7c0a1d6d3&DisplayLang=en    Best Practices for Delegating Active Directory Administration Appendices (4.2 MB) http://www.microsoft.com/downloads/details.aspx?FamilyID=29dbae88-a216-45f9-9739-cb1fb22a0642&DisplayLang=en     BUT... off the top of my head I would expect as long as they have CREATE/DELETE SERVER OBJECT rights in the sites are of the config container they would be able to do the promo's/demo's. Once the server object is created they will have full control of that so can create whatever they need under it (i.e. ntdsdsa objects, etc). I would test thoroughly in the lab though. Even if it is in black and white in the delegation paper you still need to test.   Now for the podium.... You do realize that domains are NOT security boundaries. A determined knowledgeable domain admin of a child domain, can own the forest if they get it in their head to do so. All domain admins of a forest should all be the same team under the same direct low level management. Anything else is, in my opinion, insecure.      joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Witasick Sent: Thursday, January 22, 2004 4:47 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] Sites and Services Permissions We have a multi-domain environment (empty root & 7 child domains).  Our Central Office is responsible for creating and maintaining sites, site links, subnets, connection objects, replication schedules, . . .   We'd like to restrict all child domain admins from making any modifications within Sites and Services.  If we restrict their access to read-only throughout all of Sites and Services, will domain admins still be able to promote and demote DCs?  Will we break replication?  Will we break anything?   Thanks.   John This E-mail, including any attachments, may be intended solely for the personal and confidential use of the sender and recipient (s) named above. This message may include advisory, consultative and/or deliberative material and, as such, would be privileged and confidential and not a public document. Any Information in this e-mail identifying a client of the department of Human Services is confidential. If you have received this e-mail in error, you must not review, transmit, convert to hard copy, copy, use or disseminate this e-mail or any attachments to it and you must delete this message. You are requested to notify the sender by return e-mail. This E-mail, including any attachments, may be intended solely for the personal and confidential use of the sender and recipient (s) named above. This message may include advisory, consultative and/or deliberative material and, as such, would be privileged and confidential and not a public document. Any Information in this e-mail identifying a client of the department of Human Services is confidential. If you have received this e-mail in error, you must not review, transmit, convert to hard copy, copy, use or disseminate this e-mail or any attachments to it and you must delete this message. You are requested to notify the sender by return e-mail.