Scope

This document applies to all centrally provisioned Active Directory forests for the University of Wisconsin - Madison. This document covers how AD objects are named and what data is used to populate the object's attributes. Any objects, or categories of objects, not covered are to be added to this document when approved by the Campus Active Directory governance.

Owners of AD objects are responsible for the security of any attribute data that is populated. Failure to properly populate and secure data though the use of access control lists may result in disciplinary action from OCIS and/or DoIT Security

Objectives

The objective of the naming standards is to ensure uniqueness and facilitate easy recognition, while maintaining the ability to work well both manually and programmatically. Standardization of naming conventions and strict adherence are important to achieve these objectives. 

The following are additional objectives from this naming conventions document:

• Assist users, both customers and administrative support staff, to quickly locate network resources or users.
• Provide network and system administrators, and registration personnel guidance in naming Active Directory objects.
• Support directory interoperability and reduce configuration management tasks.
• Identify authoritative sources and provide the ability to manage data to the greatest extent possible. These authoritative sources, listed in the various Annexes of this document, mostly consist of standards adopted from international standards groups or authoritative University departments.

Name Restrictions

It is important to note that here are certain naming convention restrictions imposed upon Active Directory objects in addition to the standards outlined in this document. Those restrictions in some cases include a maximum limit to the number of characters used, types of characters, and reserved words. Those restrictions are outlined in the following Microsoft TechNet article:

Naming conventions in Active Directory for computers, domains, sites, and OUs http://support.microsoft.com/kb/938447

Name Components

Each object name consists of three primary parts;  Department Code (DC), Department Defined, and Function Code (FC).

• The Department Code is a three to five character code that is selected by the department.
  • Used to identify objects as belonging to a particular department
  • Prevent name collisions between departments
• Department Defined: This component allows the department to assign a meaningful name to the object that identifies its purpose, associated service, or sub department.
• The function code is a two character that is associated with a function or service provided by a host

Domain Names

Two names will be associated with each domain, DNS and NetBIOS. The DNS name for each domain consists of the host and network names. When these two names are put together they make a unique reference to each domain. The host portion of the name should match the NetBIOS name selected for the domain. The network portion of the DNS name should be a sub domain of a domain name registered to the organization. NetBIOS names will have to be unique within a forest and are most often seen and used by users when authenticating to a particular domain. 

Root Domain:

• NetBIOS Name - AD
• DNS Name - ad.wisc.edu

Child Domains: <depart-code>.ad.wisc.edu

• NetBIOS Name - <DEPT>
• DNS Name - <DEPT>.ad.wisc.edu

The creation of child active directory domains is not currently allowed under the CADS. If they are determined essential by the operating agency, Active Directory Team will conduct a technical review and validation to authorize any appropriate modifications and naming changes that may be required. That information will then be added to this document and any other appropriate architecture documents.

Organizational Units (OUs)

OUs are general-purpose containers that can group most other object classes together for administrative purposes. OUs represent and group functions and objects that resource domains provided under NT 4.0. There is no concept of a resource domain in the Active Directory model as there was in NT 4.0. In Active Directory the OU has become the central container to logically group users and the services as required. OUs are used to provide an administrative hierarchy and a means to group users, computers, groups and resources (such as printers, applications, published folders), as well as other OUs.

Organizational Units should be created for the delegation of administration and the application of Group Policy. The Organizational Unit structure is not a reflection of the organization, but rather a reflection of how the Active Directory objects are managed.

OUs will typically not be used as a navigational guide for users locating resources; searching the directory is much more efficient. Since the OU namespace is not reflected in the DNS structure, naming will not conflict nor have to adhere to DNS standards. OU names should reflect the functional purpose and may also contain an organizational identifier if needed. The functional name should be as descriptive as possible so the purpose of the OU is easily identified.

Top level customer Organizational Units

The top level OU is where the delegation of administrative rights begin for Department level delegated administrators and will be created directly under the orgUnits OU. Top level customer OU names will abide by the following naming format:

Name: [ DEPARTMENT CODE]
Description: [UDDS NAME]

DEPARTMENT CODE: Three to five upper-case alpha character Department code selected by the department when service is established. (No special characters, no numbers, all upper-case)  Upper-case alpha characters only.
UDDS NAME: Name of the School or Department as it appears in UDDS

Leaf OUs

The leaf OUs are created under each top level OU and contain specific object types and other OUs that are created for the application of Group Policy. Each CADS customer OU will have the following sub-OUs:

• Users
• Computers
• Servers
• Groups

Sites, Site Connectors, and Subnet Names

Sites

A site is a specific geographic location that is typically defined by having good LAN connectivity between all devices. By Microsoft definition a site must have LAN connectivity to function. Therefore all Domain Controllers in a site must be connected to the same LAN and have at a minimum a consistent 10mb connection.

Site information consists of a long name and a four to five character site code. The site code will be used for the Site Name and the long name will be used for the Site Description.

Example:

Site Name: CMPS

Site Description: Main Campus

Site Connectors

Site connectors will be named for the two sites that are being connected using the site codes that are created for each and separated by a dash. The site connector's description field will include the long name of the two sites that are being connected separated by a dash.

Example:

Site Connector Name: CMPS - AGRI

Site Connector Description: Main Campus – Agricultural and Life Sciences Farm

Subnet

Each subnet should have the Site Code of the site it is assigned to populated in the description attribute to allow for easy association. 

Example:

Subnet: 192.168.10.0/24
Description: CSSC Data Center

User Object

A User Object is a directory service object that is a security principal. A user can log on to the network with credentials and access permission can be granted to the user. The User Object can be used to represent an individual identity, as organizational accounts (shared), or to represent resources (conference room, projector, etc).

NetID User Objects

NetIDs are centrally managed user objects that represent the identity of a person (Student, faculty, staff, or affiliate). The NetID user object will be named after the NetID of the individual that the object is assigned to.

Administrative User Objects

The information given below describes the naming convention to be used in creating user objects for administrative purposes.

System Administrator Accounts (SA)

All helpdesk and workstation admin staff should have an administrative (NetID-sa) account.* Administration conducted on workstations or servers is to be conducted only with the SA account. The SA account name matches the user's NetID account with "-sa" added to the end.

SA accounts are to be used strictly for workstation elevation purposes. This account is NOT to be used for day-to-day (normal) business, e.g. e-mail accounts are not to be tied to this account. All administrators will use their NetID account to logon to their workstations and use the Run As command to run or install applications that require administrative privileges.

* LAPS (Local Administrator Password Solution)

Whenever possible orgUnit admins should consider using LAPS instead of SA accounts. LAPS is more secure than using SA accounts but requires a process change and additional training for workstation admin elevation. More information on implementing LAPS can be found here: Campus Active Directory - Configuring Windows Local Administrator Password Solution (LAPS)

OrgUnit Admin Accounts (OU)

OU Account (NetID-ou) are distinct and separate from SA accounts. They have the ability to create SA accounts and modify an orgUnit. Within any given OU there should be fewer OU accounts than SA accounts. OU accounts are used to manage all aspects of the OU. Including new organizationalUnit creation, GPO creation and editing, computer joining* and group management.**

*If workstation admins need the ability to join computers consider using a provisioning service that uses a service account for joining computers instead of requesting an OU account for each IT staff member. 

**If IT staff or department administrative staff need the ability to edit access on a small number of file shares, consider delegating access to specific directories to their NetID(s). If there is a need for non-OU account management of a large or wide number of directories, then using the Manifest service to sync Manifest group to Campus AD is the recommended method to accomplish that goal. More info here: Manifest and Active Directory Group Guidelines

Examples for user "John A. Smith":

Resource Accounts 

A Resource account is a mail enabled user account needed for resource mailboxes to enable scheduling in MS Exchange. These user objects will represent things like conference rooms and projectors. These user objects will have a complex password assigned and are disabled. Access to the user object's mailbox is allowed through delegating access. The naming convention for resource accounts is:
RES-<ResourceName>-<DEPT>

RES – Prefix for all resource accounts
<ResourceName> - A simple three to six letter code to identify the resource. There will be no spaces in the utility account name.
<DEPT>– Department code for suffix

Example – DoIT conference room  RES-CR3207-DOIT

Service Accounts

A Service account is a user object that provides authentication for an application or service. The naming convention for service accounts is:
SVC-<ServiceName>-<DEPT>

SVC – Prefix for all resource accounts
<ServiceName> - A simple three to five letter code to identify the service. There will be no spaces in the utility account name.
<DEPT> – Department code for suffix

Example – SQL Service SVC-SQL-DOIT

Shared Accounts

A Shared account is an account that is used by more than one person for logon or access to an organizational mailbox. These user objects will have a complex password assigned and are disabled. Access to the user object's mailbox is allowed through delegating access. The naming convention for standard utility accounts is:
ORG-<ServiceName>-<DEPT>

ORG – Prefix for all resource accounts
<Shared Resource> - A simple three to five letter code to identify the shared resource. There will be no spaces in the utility account name.
<DEPT> – Department code for suffix

Example – Shared DoIT Helpdesk mailbox ORG-HDMB-DOIT

Fine-Grained Password Policies

The overall password policy for the Campus Active Directory will be the same as the NetID service. User accounts that are not part of the NetID service may be assigned different password policies through the use of Fine Grained Password Policies. These FGPPs will be applied to the user objects through membership in global security groups.

FGPP names will abide by the following naming format: [DEPT]-[XXXXX]-FGPP

DEPT: Department Code for the organization

XXXXX: Description of the intended purpose of the FGPP

Example:

CADS-OUADMIN-FGPP (OU Administrator Password Policy)

Workstation and Server Objects

The Computer Object name character limit is 15 characters and should conform to the following standard(<DEPT><FF>-<YYYYYY>)

• Every computer object name will begin with DEPT (Department Code) 
  • Department Code = orgUnit Name
• (Optional) <FF> will use the Computer Object Primary Function Codes, see above in the Name Components section.
• <YYYYY> will be determined by local department policies. Using the Service Tag here is also a common practice

Example without Function Code: DOIT-0A1B2C

with Function Code: DOIT-WK-0A1B2C

Description Field - This field contains all function codes associated with the host. When a host supports multiple functions, the primary function will be indicated as part of the host name. Primary and additional function codes will be listed here separated by a hypen.

Location Field - Computer location field will be populated in the following format.
<XXXX><YYYY><ZZZZ>

• <XXXX> The FP&M assigned facility number of the building the Computer resides in. (Facility Number list: http://www.fpm.wisc.edu/smoasp/FacilityName.asp)
• <YYYY> Room number for the location of the computer. If there is not a number assigned to the room two zeros will be entered instead.
• <ZZZZ> Department Code (DEPT).

Example:

Name: DOITWS-SDH-01
Description: WS-DB-FS
Location: 0155-B263-DOIT

Printers Overview

Active Directory provides a simple, intuitive way for users to search for and map to printers. Unlike the cryptic nature of NT 4.0's naming structure, with Active Directory, users can search by the printer's common name, physical location within their building, model name, or features – such as whether the printer can print duplex copies, print color, or print at a specific resolution. To map to the selected printer, the user can double click the printer name – or click Connect on the File menu.

Printer Objects

To ensure that any shared printer is published in Active Directory, the "List in the Directory" box should be checked under the Sharing tab found on the printer's property page.

Standardization of the search fields is necessary to help users efficiently find printers. Wildcards may be used to search for information in any of the fields defined.
Printer names can be up to 15 characters in length. Printer and printer queue names are assigned by the owning organization following the established naming conventions. The required format for a printer name is as follows:

<DEPT>PR-<YYYYY>

Each printer name will begin with the Department Code (DEPT) followed by PR, which is the code for printers, and <YYYYY> is defined by local department policy.

Example: DOITPR-LANIER-03 (Department of Information Technology Printer number 3)

Location Field
Printer location field will be populated in the following format.
<XXXX><YYYY><ZZZZ>

1. <XXXX> The FP&M assigned facility number of the building the printer resides in. (Facility Number list: http://www.fpm.wisc.edu/smoasp/FacilityName.asp)
2. <YYYY> Room number for the location of the printer. If there is not a number assigned to the room two zeros will be entered instead.
3. <ZZZZ> Unit Identification Code (UIC) or Directorate office symbol.

Example: 0155-B236-DOIT (Division of Information Technology printer at 1210 Dayton St. in Room B236)
Comment Field - Comment field will be populated with the School or Department name as it appears in UDDS.

After this initial work has been completed, users will find the Location field populated according to the building, room, and school/department name to which the printer belongs when a search for printers is performed.
When a printer is published in Active Directory, the model and features fields will be automatically populated based on the printer's driver information, and users can begin searching based on these properties immediately. These properties include duplex, color, size, speed, etc….

Character Restrictions

The following characters are not allowed in a group name:
" " / \ [ ] : ; | = + * ? < > , . $, !, ^, _

Groups

As access permission becomes more essential to managing a secure UW-Madison Enterprise network environment and to protect organizational data, users will need to locate interest and business groups and then apply access permission to objects using these groups. Additionally, because Windows Active Directory permits security groups to also function as Microsoft Exchange DLs, the structure and consistency of these groups will become more essential to their successful implementation. The following rules will be observed in creating and managing global groups.
Group names will abide by the following naming format:

 [DEPT]-[Group Type]-[XXXXX]

DEPT: Department Code for the organization
Group Type: The type of group that is created

• Domain Local Security Group = DS
• Global Security Group = GS
• Universal Security Group = US
• Distribution Group = DL

XXXXX: Locally defined name

Group Policy Names

A group policy object is a grouping of related policies that can be applied to user and computer objects. Group policy object names should provide information about who manages the object and what its purpose is. Group Policy names will be in the following format:

<DEPT> <YYYYY>

<DEPT> – Department Code.
<YYYYY> - Brief name that describes the purpose of the policy

Example:

DOIT Default Workstation