Active Directory Organizational Unit Policies for the College of Engineering

Introduction

As a part of the ongoing re-organization of College of Engineering IT and in conjunction with the campus move to Unified Communications, it has been determined that the College will consolidate existing unit-level OUs from the campus ad.uiuc.edu domain into a single college-level OU in the new university ad.uillinois.edu domain. This consolidation process, if performed properly, should ultimately result in less duplication of effort by all Engineering IT staff as well as increased consistency across all supported units.

This document outlines the policies governing the creation and maintenance of objects in the new college-level OU, ad.uillinois.edu/Urbana/Engineering. Overall design and implementation of the OU structure will be documented separately. This document was created through discussions involving the Next Generation Active Directory Project Team and Active Directory Migration Project Team. Any questions, comments, or concerns regarding the policies can be directed to the Active Directory Migration Project Team.

Policies

Policies applying to all OU objects

All objects must contain documentation of its purpose and how the object is used.

• This documentation should be included in the “Description” field on all objects and should contain a brief description of the object’s usage. Object-specific documentation can be found under the corresponding object class. If the object is temporary, then temporary should be listed as the first word in the description.
• Exception: For any groups that are bulk auto-created and populated via an automated or scripted process (such as the My. portal directory-populated “Personnel” groups), the name will be a sufficient description of the group.

Minimize duplication of objects.

• Where appropriate, the use of personnel groups for securing resources is strongly encouraged, while reuse of other objects is allowable. However, objects should not be reused in cases where the use may allow for greater than appropriate privileges for some or all of the members of the object.
• Example: The reuse of a generic Unit HR group for securing access to a print queue in a specific office area – while not all users in that group may need to print documents to that printer, the inclusion of all members does not represent a risk. However, the reuse of a generic Unit HR group for securing a privileged file share where data is meant only to be shared amongst a specific subset of users of the group is not appropriate.
• Duplication may not be able to be avoided in cases where current technology limits the usage of certain items (such as *NIX support of groups nested within groups), and in such cases would be allowable provided that the use case is documented.

Object names may not contain spaces.

• To ensure compatibility across systems, object names may not have spaces; instead, use delimiters and naming conventions suggested for each type of object.

Objects belonging to Engineering IT staff members should live in appropriate Engineering IT OU

• Objects belonging to Engineering IT, such as IT staff desktops, mobile devices, groups, etc. should be created under the applicable EngineeringIT OUs and not under the unit OUs for which the staff member is serving, unless a clear reason for deviation is demonstrated.

All Engineering AD objects must reside within the Engineering OU hierarchy and only Engineering AD objects may reside within the Engineering OU hierarchy

• AD assets for all units, groups, and departments in the College of Engineering must be created under the top level Engineering organizational unit
• Groups, units, and departments which are not part of Engineering may not store their AD assets under the Engineering OU
• AD assets of non-Engineering units, groups, or departments used for my.dot portal applications may not be copied, shadowed, or otherwise stored in the Engineering OU hierarchy

All Engineering AD objects must have the attribute “sAMAccountName” properly filled in.

• Different tools may allow you to set a longer sAMAccountName attribute (pre-Windows 2000 name), but if you cannot set one longer, then you need to ensure that the sAMAccountName is unambiguous.
• The maximum length of the sAMAccountName appears to differ depending on the type of object being created:

object Class	maximum length of sAMAccountName
Computer	15 bytes (Active Directory will append a dollar sign ($) to the end of the machine name
User	64 bytes
Group	64 bytes

Organizational Units

Organizational unit names must be in camel-case.

• Multiple words should be joined without spaces with each words initial letter capitalized, such as “UsersAndGroups” or “MobileDevices”.

Organizational unit names may only contain upper and lower case letters, and numbers.

• To ensure compatibility across systems, the only allowed characters in an OU name are upper and lower case letters and numbers.

Organizational units should be protected from accidental deletion.

User Objects

All user objects should be populated with a minimum of a Username

• All user objects should be created with as much identifying information as possible, and include a description of the object’s usage.

All service accounts are strongly recommended to have the display name be the username

User Objects – Guest IDs

Access to campus level services requires an official university NetID. Guest IDs created in AD will only be used locally in a department/unit.

Official university NetIDs should be used instead of department/unit Guest IDs whenever possible.

• Department/unit guest IDs are not intended to shortcut proper University account creation processes, and are only intended to provide limited access to department/unit resources.

Guest IDs will conform to proper naming convention and stored in a GuestIDs OU under the UnitsAndGroups OU.

• The proper naming convention for guest IDs is engr-temp-name.

Unit HR should be responsible for creating guest IDs through an automated process (such as My.Portal app)

Guest IDs must have an expiration date.

• Guest IDs will expire after 90 days but may be renewed once for an additional 30 days. Anything longer needs to be an official university NetID. Guest IDs can be used to fill the time gap while the official NetID is established.

Contact and sponsor information must be recorded.

• The following information should be collected and documented in the appropriate user object fields or Notes field for each guest ID:
  • Full legal name
  • Email address
  • Phone number
  • Address
  • Faculty/Staff sponsor
  • Description of how this person is connected to the university

Guest IDs may not be mail-enabled

Groups

Group names may only contain lower case letters, numbers, and hyphens.

• To ensure compatibility across systems, the only allowed characters in a group name are lower case letters, numbers, and hyphens.

Group names must begin with a prefix that indicates the group’s unit affiliation followed by a hyphen.

• Example: “engr-” for Engineering, “engradm-” for Engineering Administration, “ece-” for Electrical and Computer Engineering, etc. Please see below for a complete list of unit acronyms.
• Example: For research groups or other sub unit-level groups, naming convention should follow “unit-researchgroup-” or “engr-researchgroup-” where unit affiliation is unclear.

Use Personnel groups where possible.

• Engineering IT staff should use the HR-maintained unit-level portal groups under UsersAndGroups/Personnel where appropriate to secure access to resources. If an existing Personnel group is inadequate, an additional Personnel group may be created by the WAIS group upon request (the preferred method), or a unit-level (or ad-hoc) group can be created within the UsersAndGroups/Units OUs. Ad-hoc groups are not intended to replace existing personnel groups and should only be used when existing groups are either a) not restrictive enough (need to exclude one or more accounts) or b) not permissive enough (need to add one or more accounts). When the existing personnel group is not permissive enough, an ad-hoc “plus” group can be created that contains all of the additional members not included in the personnel group, and then both groups can be used to grant access to a resource.

Computers

Computer names should not exceed 15 characters in length.

• Due to limitations in some client software packages’ use of the computer object’s sAMAccountName attribute, computer names should not exceed 15 characters in length.
• If a computer object name must exceed 15 characters in length to conform with naming conventions or other reason, then the object’s sAMAccountName will be truncated in AD to 15 characters. See earlier policy on ensuring that the sAMAccountName is unambiguous in this case.

Desktop computers should follow the naming convention building-room-computer#

• Examples: evrt-328-01 for machine 1 in Everitt Lab 328, eh-406b8-02 for machine 2 in Engineering Hall, etc. Please see below for a complete list of building codes.
• The NetID of the primary user and any other information regarding use should be placed in the description field and should be updated as changes are made. For shared systems, a primary user may not be applicable.
• For those individuals who want to use “vanity” naming schemes for their systems that do not match the stated conventions (or exceed 15 characters), these names can be entered into the corresponding entries in DNS as hostnames. This hostname must be added to the description field.
• Optional description information: IP address or any other special usage characteristics.

Mobile devices should be named as unit-netid.

• Optional identifiers can be used, such as “-computer#” (as in desktop convention if user has multiple devices) or a shortened version of the device type, like “nb” or “lt” for notebook/laptop, “tab” for tablet computer, etc.
• For units with long names, such as “engradm”, shortened versions of 8 character NetIDs may be required, and last name, first name, or nickname could be substituted, provided that the user’s NetID appears in the description.

Exchange Resources

Exchange resource objects should be named according to their usage.

• Building related resources should be named “building-room-” and unit related resources should be named “unit-“.

Exchange resource objects should be created with appropriate “resource-sendas” and “resource-fullcontrol” groups to secure access.

• These groups should not be reused for controlling permissions to other resources such as file shares or print queues.

Group Policies

All Group Policies should begin with ENGR and include a name applicable to policy scope.

• All GPOs should begin with Engineering and include a concise descriptive name referencing the policy’s usage, such as “ENGR Administrative Desktops” or “ENGR Folder Redirection”.

All Group Policies should be secured using appropriate permissions.

• All GPOs should be secured using appropriate security groups so that only those responsible for administering the GPOs can edit them.

Addendums

Unit Abbreviations

Unit Name	Abbreviation
Aerospace Engineering	AERO
Agricultural and Biological Engineering	AGBE
Bioengineering	BIOE
Chemical and Biomolecular Engineering	CHBE
Civil and Environmental Engineering	CEE
Computer Science	CS
Computational Science and Engineering	CSE
Coordinated Sciences Lab	CSL
Division of Biomedical Sciences	DBS
Electrical and Computer Engineering	ECE
Engineering	ENGR
Engineering Administration	ENGRADM
Engineering Shared Administrative Services	ESAS
Engineering IT	ENGRIT
Industrial Engineering	ISE
Information Trust Institute	ITI
Mechanical Engineering	MECHSE
Materials Science and Engineering	MATSE
Micro and Nanotechnology Lab	MNTL
Materials Research Lab	MRL
Nuclear, Plasma, and Radiological Engineering	NPRE
Physics	PHYS
Technology Entrepeneur Center	TEC

Building Abbreviations (based on EDW BLDG_CD)

The Abbreviations/Prefixes listed here are the values stored in the Enterprise Data Warehouse. The authoritative list of these is kept by Facilities Management Services and can be found at http://www.fms.uiuc.edu/Facilities/ClassroomManual/index.asp?report=BANNER%20Building%20Codes%20with%20Descriptions.xml

Building Name	Abbreviation
Ceramics Building	CB
Computing Applications Bldg	CAB
Coordinated Sciences Lab	CSL
Digital Computer Lab	DCL
Engineering Hall	EH
Engineering Sciences Building	ESB
Everitt Lab	EVRT
Grainger Engineering Library	GELIB
Hydrosystems Lab	CEHL
Kiln House	KH
Loomis Lab	LMS
Materials Research Lab	MRL
Materials Science Engineering Building	MSEB
Mechanical Engineering Building	MEB
Mechanical Engineering Lab	MEL
Micro and Nanotechnology Lab	MNTL
Newmark Lab	NCEB
Nuclear Engineering Lab	NEL
Nuclear Radiations Lab	NRAL
Optical Physics Engineering Building	OPEB
Siebel Center	SIEBL
Talbot Lab	TL
Transportation Building	TB