Hey maybe Tony can post that PPT on the web site in the AD WhitePapers Section...
joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO (HP-Germany,ex1) Sent: Wednesday, October 08, 2003 4:09 PM To: [EMAIL PROTECTED] Mike, you definitely want to rethink your approach. Joe's comment was very important => don't try to grant 'EVERYTHING *except*' - rather, you should come up with exactly what you want your OU Admins to do in their OU or sub-OUs. You certainly don't want to pass out Full-Control on the level of the OUs => this is like giving them the keys to the kingdom: as soon as you grant someone the permission to manage permissions on their container object (the OU), everything else you do is useless. Not only can they change whatever you've set, but they can also block inheritance of the permissions from the parent OUs - more sooner than later you'll have an ACL mess in AD. I won't even mention GPOs now. Next, don't forget one important thing with your Delegation design: it's much easier to limit what you allow, than to handle deny ACEs (Access Control Entries). You have to understand the priority of permission evaluation: inherited ACEs come after explicit ACEs - i.e. an explicit allow on a level "closer" to the object will override an inherited deny. So you may THINK that you've still set the deny on your parent OU, while in some child OU the admin might have granted allow permissions to create, manage and delete users etc. So in general, you should preferr to grant permission on the objects that you want managed. E.g. for a "Full OU Admin" (general): Organizational Units: Allow - Read All Computer: Allow - Full Control, Create, Delete Contact: Allow - Full Control, Create, Delete Group: Allow - Full Control, Create, Delete Printer: Allow - Full Control, Create, Delete Shared Folder: Allow - Full Control, Create, Delete User: Allow - Full Control, Create, Delete In your case, you'll have to think more in detail, what you admins are supposed to be able to do on the User object - as you don't want them to create or delete users, remove these permissions from the list above. Now, instead of Full Control, sounds like you want the admins to be much more restricted on the account - I doubt you want them to do everything except renaming and resetting PW => if your this strict with your accounts, should these admins have the power to expire the account or to disable it, or simply to unlock it if it is locked? Should they be able to check the Store PW using reversible encryption flag?... What is it they're allowed to do - likely to add groups to the user - right? Well this is a group permission (you don't add groups to users, you add users to groups). And how about the address and phone information => all held in the Personal Information property set, could easily be granted as a block. In short, with some additional investigation, you may find you simply need to GRANT a few permissions instead of allowing everything and trying to DENY some. Not sure if you've had the chance to visit MEC US or IT Forum in Europe last year - you should find my session on Delegation of Admin rights quite useful (was SEC400 at MEC and SEC330 at IT forum). It contains a lot of the information which is also covered by MS in the upcoming whitepaper. If you don't have access to it, I can send you the PPT slides offline (and will make you forward it to anyone else who asks ;-) /Guido -----Original Message----- From: Thommes, Michael M. [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 8. Oktober 2003 17:10 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] OU Delegation question Hi Al (and Joe), Thanks for the responses. Al, that is correct, the OU Admin can still delete the user object. And yes, I think that is the last thing that I want to accomplish. However, Joe's previous reply gives me cause for concern about the Full Control issue. The bottom line is that I don't want to restrict what the OU admins can do in their respective OUs, except I do not want them to create a user account, nor delete an already existing user account, nor rename the user account, nor reset the password. We view our domain accounts as sacred; they are never to be deleted (disabled, yes) and the creation of domain accounts is done through a special process that is done by a single office so that the appropriate business rules are followed. The Delegation Wizard GUI poses a question. If you start getting granular for a particular permission and "uncheck" the Allow box, it would appear that the ability to do that particular operation then rests on maybe inherited permissions or some other "gray" area. By explicitly checking the Deny box, it becomes (at least to me) a very "black and white" issue, since "Deny" takes precedence. Am I missing a bigger picture here? I really am looking forward to getting my hands on Robbie's book and the MS whitepaper on delegation! Keep the comments coming! Mike Thommes -----Original Message----- From: Mulnick, Al [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 08, 2003 9:52 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] OU Delegation question Just so we have it straight, once you set the deny permission, they're still able to delete an account but not create one? Is that about it? Is that the last of what you need to accomplish as well? -----Original Message----- From: Thommes, Michael M. [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2003 3:51 PM To: Active Directory Mailing List (E-mail) Subject: [ActiveDir] OU Delegation question Hi All: At least around here, Robbie's "Tuna book" has yet to hit the shelves. And Microsoft's whitepaper on delegation is still a month away. Other references on delegation appear scant at best. So here's the problem that I have been tearing my hair out on (and I didn't have much to start with! 8-) ): We would like to delegate *almost* all rights to the various Divisional OUs we have to various OU admin groups. We'll let them do anything they want to *except*: 1) create accounts; 2) delete accounts; 3) rename accounts; and 4) reset passwords. We have other groups for #4. You'd think this is a relatively easy task. So far, my experiences show otherwise. Using the Delegation Wizard, it would see reasonable to give the OU admin groups the following permissions in the respective OU: 1) Full Control, applied to this object and all child objects 2) Create/Delete User Object, applied to this object and all child objects....then set it to Deny 3) Reset Password, applied to User Objects...then set it to Deny 4) Write Property, Write Logon Name (pre-Windows 2000)...then set it to Deny 5) Write Property, Write Logon Name...then set it to Deny So far, the admin groups cannot create a user account (good!); they cannot reset a user's password (good!); they cannot rename an account (good!); BUT they can *still* delete a user account (very bad!). Any help is certainly appreciated! Thanks. Mike Thommes List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
