Folks,
I had a chat with Barry on Friday regarding the types of tasks typically performed by his administrators, and we have a (short) list of default roles I plan to document and someday codify.
We were basically trying to ease adminstrator of three types of resources - containers, file systems, and printers.
In a new delegated OU, we would create a series of groups, and assign rights to those groups. The plan is to make it as easy as possible for folks to do routine tasks. The option to arbitrarily complex rights assignment is still available in MMC.
== Group OU_Supervisors
Membership would intially be the "Manager" associated with the organization's remedy group.
Members of this group would have the rights needed to add or remove members from any of the role/security groups. The Remedy Manager would be responsible for identifying who in their organization should control access, and place them in this group.
== Group OU_Full_Control
Membership would initially be null.
Members of this group would have full control, including create and delete object rights of the organization's AD container.
The Remedy Manager would populate this. Barry confirms that most folks who would manage AD would manage everything, but not likely delegate.
== Group GPO_Full_Control
Membership would initially be null.
Membershers of this group would have rights to create, modify, and assign Group Policy Objects. Since GPOs aren't stored in a shared container for the whole domain, it was desirable to have this seperate from GPO_Full_Control. Mistakes made with accounts in this group could potentially impact the entire campus.
The Remedy Manager would populate this.
== Group LockerName_Full_Control
== Group LockerName_ReadOnly
== Group LockerName_ReadWrite
Membership for all three groups would initially be null, and the Remedy Manager would populate them.
These groups would control basic access to a filesystem or "locker" Members of "ReadWrite" would have modify, read, write and create style access. The Full_Control group could also assign rights and take ownership. By default, no read access at all is set for new lockers. For "public" lockers, like App space, the "ReadOnly" group would need to include "Everybody"
== Group Printer_Operators
Membership would initially be null, and the Remedy Manager would populate this group.
Members can start and stop printers, see and hold the job queue, and basically control printers in the OU.
== Group Printer_Creators
With changes coming to the WolfPrint system, it may be possible to delegate the creation of new accounted printing printers directly. This group would control access if this proves viable.
This blog is intended to be used by the staff members of ITD's Microsys group at NC State University. It is an internal project management and collaboration tool to be used throughout the Unity migration project. Project updates, thoughts, suggestions, and anything else related to the migration should be included.
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| << < | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | |||||