Difference between revisions of "Active Directory/Documentation/Computer Migrators Group"

From WolfTech
Jump to navigation Jump to search
Line 1: Line 1:
The overall purpose of the <Root OU>-Computer Migrators groups was to be able to delegate ability for more users than just the OU admins to add machines to the domain.  Please be aware that this is '''NOT''' the same thing as joining a pre-staged computer to the domain.  See pre-staging below for an explanation of how to make use of the computer migrators group for that.
+
The overall purpose of the <Root OU>-Computer Migrators groups was to be able to delegate ability for more users than just the OU admins to add machines to the domain.  Joining a computer to the domain that has been pre-staged is treated slightly differently from non-pre-staged, but setting up the permissions as listed below will allow the migrators group to perform both types of joins.
  
 
== Setting Up Permissions ==
 
== Setting Up Permissions ==
Line 8: Line 8:
 
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/activedirectory/stepbystep/ctrlwiz.mspx
 
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/activedirectory/stepbystep/ctrlwiz.mspx
  
Right click on your OU, then [delegate control] Add your tex-computer migrators group.
+
Right click on your OU, then [delegate control] Add your <OU>-computer migrators group (ex: CHASS-Computer Migrators).
  
What I wound up doing is selecting Custom Tasks, Only these objects, Computer Objects Then checked read, write and create all child.
+
When you get to the Tasks to Delegate section, you'll want to choose the custom task option, then the "only these objects" option.  Under that choose only Computer objects, and check the Create selected objects in this folder, and Delete selected objects in this folder.
  
I believe those are the minimum rights required.  Any AD gurus can correct me if I'm wrong.
+
On the next page I checked to show all of the types of permissions, and then enabled:
 +
Read
 +
Write
 +
Create All Child Objects
 +
Delete All Child Objects
 +
Change Password
 +
Reset Password
 +
Allowed to Authenticate
  
Brian Fields
+
I don't know for certain that -all- of those are needed, but they definitely did the trick.  Allowing to Microsoft's docs the minimum required are:
 +
    Allowed to Authenticate
 +
    Change Password
 +
    Reset Password
 +
    Create Computer Objects
 +
    Delete Computer Objects
 +
 
 +
Brian Fields / Daniel Henninger
 
</pre>
 
</pre>
 
== Caveat for Pre-Staged Computers ==
 
 
Pre-staged computers do not fall into the above permissions scheme.  During computer object creation, there is an option to choose who is allowed to join this computer to the domain.  This is a security feature of sorts to prevent "the wrong people" from joining another computer to your object.  By default it is set to Domain Admins.  OU admins already have access to join pre-staged computers to the domain as explained above.  With it being set to Domain Admins, only OU Admins and Domain Admins can join this computer to the domain.  You should click the Change button and enter in your OU's Computer Migrators group.  <OU>-Computer Migrations  ---- CHASS-Computer Migrations for example.  There is unfortunately no way to change this after the fact so if you forget to do it at creation time, you'll need to either delete and recreate the computer object, or have an OU/Domain admin join that computer.
 
  
 
== Likely usage scenarios: ==
 
== Likely usage scenarios: ==

Revision as of 14:54, 22 April 2009

The overall purpose of the <Root OU>-Computer Migrators groups was to be able to delegate ability for more users than just the OU admins to add machines to the domain. Joining a computer to the domain that has been pre-staged is treated slightly differently from non-pre-staged, but setting up the permissions as listed below will allow the migrators group to perform both types of joins.

Setting Up Permissions

The <Root OU>-Computer Migrators groups have been delegated "Add workstations to domain" user right, and the ability to create computer objects under the Computers container. This allows any members of this group the ability to add a computer to the domain. All of the <Root OU>-OU Admins groups already had these rights. The intention is for each unit to then grant their <Root OU>-Computer Migrators group access to their OU.

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/activedirectory/stepbystep/ctrlwiz.mspx

Right click on your OU, then [delegate control] Add your <OU>-computer migrators group (ex: CHASS-Computer Migrators).

When you get to the Tasks to Delegate section, you'll want to choose the custom task option, then the "only these objects" option.  Under that choose only Computer objects, and check the Create selected objects in this folder, and Delete selected objects in this folder.

On the next page I checked to show all of the types of permissions, and then enabled:
Read
Write
Create All Child Objects
Delete All Child Objects
Change Password
Reset Password
Allowed to Authenticate

I don't know for certain that -all- of those are needed, but they definitely did the trick.  Allowing to Microsoft's docs the minimum required are:
    Allowed to Authenticate
    Change Password
    Reset Password
    Create Computer Objects
    Delete Computer Objects

Brian Fields / Daniel Henninger

Likely usage scenarios:

1. Helpdesk staff - A given college or department might have junior staff that need to handle the addition of computers to the domain, but are not going to have full AD rights over the OU. Generally, an OU admin would then grant the pre-created <Root OU>-Computer Migrators group the ability to create computer accounts under the OU. This would then allow the junior staff member to add the computer to the domain, and then move the computer object from the Computers container to the appropriate OU (or preferably to create within the correct OU to start).


2. Faculty/Staff - If a unit was migrating a large amount of faculty/staff from a non-managed (or Workgroup) environment to the domain, the given college or department might want to add all of their faculty/staff to the <Root OU>-Computer Migrators group. This would allow the faculty/staff to add their own machines to the domain using their Unity username/password. The OU Admin might then move all of the computer objects to the appropriate OU's where GPO settings would then configure the machines. This would allow for a very quick migration. The faculty/staff would later be removed from the group to reduce permissions down to an appropriate level.