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

From WolfTech
Jump to navigation Jump to search
(New page: 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. == Permissions == ...)
 
 
(6 intermediate revisions by 2 users not shown)
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.
+
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.
  
== Permissions ==
+
== 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 <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.
  
 +
===Notes by Brian Fields / Daniel Henninger===
 +
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
  
 
== Likely usage scenarios: ==
 
== 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).
'''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 <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.
 
  
  
 
'''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.
 
'''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.

Latest revision as of 16:42, 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.

Notes by Brian Fields / Daniel Henninger

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

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.