> granting "Full Control" on any object is not enough to also allow creation of the object.
With a couple of exceptions... Containers and OU's. Once you grant full control of an OU or container you have lost control within that OU or container. Additionally if you allow creation of OU's and containers you have also lost control of that portion of the tree. Once you allow someone to create OU's/containers, they can create any object type they want. Cool on that whitepaper. Guido is PSS,MCS, or the product team working on it? I would like to chase it down through my TAM. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO (HP-Germany,ex1) Sent: Sunday, September 21, 2003 9:04 AM To: [EMAIL PROTECTED] Rick, let me add one more detail: granting "Full Control" on any object is not enough to also allow creation of the object. You also have to grant the "Create Object" permission for the specific object (and the "Delete Objects", if you also want this group to be able to delete objects, which the users of the group didn't create themselves) So, to manage Computers, you'll want to grant a group (e.g. MyClientAdmins) the following permissions for Computer objects on the respective OU: Allow - Full Control Allow - Create Allow - Delete As Joe already pointed out, the computers will still not be added to the OU automatically by simply adding them to the domain via the System Properties UI of the computer => this one always tries to add the computers to the "default" Computers container of the domain. Instead you'll have to "direct" them to the correct OU e.g. by adding them with the NETDOM command (2000 version have an OU switch). Alternatively, you can pre-create the computer account in the OU, grant your ClientAdmin group permissions to join this computer to the domain and then add the computers to the domain via the UI - they will then bind to the pre-created account. At the same time you'll either want to set the ms-ds-machineAccountQuota of the domain to 0 or replace Authenticated Users from "Add workstations to Domain User Right" with Domain Admins in the Default Domain Controller Policy... Your ClientAdmins do not need these user-rights as they are implicitely granted, when you allow to create computer objects to an OU. And now you're also keeping them from accidentally adding computers to the domain without either creating an account in an OU or directing the computer to the correct OU via NETDOM. BTW, although I would also recommend reading all the good books mentioned in this thread, you'll also want to look out for the upcoming Microsoft Whitepaper on AD Delegation. It will contain most answers to these types of scenarios. It's currently in review-phase and I expect it to be released in the October/November timeframe. /Guido -----Original Message----- From: Rick Kingslan [mailto:[EMAIL PROTECTED] Sent: Freitag, 19. September 2003 23:41 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Add computers to domain permissions Every now and then this mass of e-mail I keep around has value. I'd responded to a similar question a few months ago - so here is the response to that question: <SNIP> What you will likely need to do is to proceed along the following lines: 1. Right click on the OU of your choice and go to Security. 2. Select Advanced / Add / Select the group that you want to accomplish the task 3. By default, they should have READ, etc. Scroll down and select Allow Create / Delete Computer Objects 4. In the 'Apply on to:' dialog, select This Object and All Child Objects. Hit 'Apply' to save what we have so far. 5. Click 'Add' again in the Advanced Security dialog UI. Select the group for the task (same group as above). 6. In the 'Apply on to:' select 'Computer Objects' and grant Full Control 7. Click 'OK' until you completely exit This should do the following: Allow the selected group to Create and Delete Computer Objects within the OU in which this delegation was done (yep - still delegation - not done through the Delegate Control selection, but this *IS* what goes on behind the scenes anyway....), then we delegated the permission to fully control Computer Objects - allowing the ability to create the various attributes that make up a computer object - but only computer objects, and nothing else. As you go through this exercise, it's interesting to note how many permissions are associated with these objects. Notice that there is a properties tab, too! This is what allows one to change the name, etc., of an object as this is a property of the object. Take your time as you go through this. If you get a grasp of what happens in this delegation, then the rest of your permissions tasks will be much easier. Good luck! </SNIP> BTW - you CAN delegate prmissions to the Computer Container much in the same manner. Rick Kingslan MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ Sent: Friday, September 19, 2003 3:16 PM To: '[EMAIL PROTECTED]' Subject: [ActiveDir] Add computers to domain permissions We have many remote sites and an OU for each remote site. We're delegating our site admins permissions to their site Ous, and creating security group restriction policies to grant them local admin permissions on their user's desktops. The problem we're having is the site admins can't join new PCs to the domain. A Microsoft TS told us that AD will automatically add a PC to an OU that you have rights to, but this doesn't seem to be the case. It appears it's trying to add it to the builtin computers container instead, and the site admins don't have rights to that. How do we solve this? Is there some type of a script that we need to be using to do this? We don't want to use RIS. We want all our remote sites to be able to join computers to their OU at will. Thanks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This e-mail is confidential, may contain proprietary information of the Cooper Cameron Corporation and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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/
