Campus Active Directory - Naming Convention

Overview

All organizations within the Campus Active Directory Service (CADS), or wishing to join the CADS, must strictly adhere to the domain naming conventions outlined below. Where possible, these naming standards were adopted from existing naming standards to foster standardization across the University.

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

Name Components

Function Code	Server Usage
AS	Application server
DC	Domain Controller
GC	Global Catalog
CA	Certificate Authority Server
DB	Database Server
DC	Domain Controller
DF	Distributed File System (DFS) Server
DH	Dynamic Host Configuration Protocol (DHCP) server
DN	Domain Name Service
FE	Federation Server
FS	File Server
FX	Network Connected Fax Machine
GC	Global Catalog
LS	List Server
MC	Multi-function Copier
MS	Mail Server
NB	Notebook computer
NM	Network Management Server
PR	Printer
PS	Print Server
PX	Proxy Server
SM	System Management Server
SS	Security Server
TS	Terminal Server
VH	Virtual Host
WK	Workstation/Desktop
WN	Windows Internet Naming Service (WINS)
WS	Web Server

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.

All helpdesk and system management staff must have two accounts – a normal UserID which has e-mail rights and an administrative account. Administration conducted on workstations or servers is to be conducted only with the second, separate administrative account. The administrative account name matches the user's non-privileged account with the Administrative Privilege code appended to the end. The Administrative Privilege Code will correspond to the highest level of privileges held by the user and will be changed when the level of privileges change.

This administrative account is to be used strictly for administrative 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 regular account to logon to their workstations and use the RunAs command to connect to administrative applications, such as ADUC whenever possible.

A Domain Administrator account will be elevated to Enterprise Administrator or Schema Administrator only when needed. Once the task requiring these advanced privileges are complete the user object will be removed from the Enterprise Admin or Schema Admins group. Domain Administrator accounts should only be used when logging onto Domain Controllers or hosts that have been sufficiently secured for the use of these highly valuable credentials. Daily Active Directory tasks should be conducted with an OU Owner/Administrator account whenever possible.

OU Owner/Administrator and System Administrator accounts different only in that the OU Owner/Admin accounts are delegated rights within the Campus Active Directory and System Administrator accounts are not. Both of these accounts may also be added to the local administrators group of hosts within the department's OU. In the event that an administrator is to be delegated rights to managed Active Directory for a department and that administrator already has a System Administrator account, that account will be renamed and the group membership adjusted appropriately.

Administrative User Objects

Administrative Role		Administrative Privilege Code
Domain Administrator		DA	Account is used for tasks that require Domain Administrator rights. These accounts will be limited to only those that absolutely need them.
Organizational Unit Owner/Administrator		OU	Accounts that are delegated rights within Active Directory. These accounts may also be granted local administrative access to member servers.
System Administrator		SA	Accounts that are granted local administrative access to member servers. These accounts are not delegated any rights in Active Directory
Attribute				Example	Source
cn	[NetID]-[Privilege Code]			jsmith	PH
displayName	[Last Name], [First Name] [Initial] ([Privilege Code])			SMITH, JOHN A (SA)	PH
mail	Primary smtp email address of NetID user object (privileged accounts are not mail enabled)			john.smith@doit.wisc.edu	WM
samAccountName	[NetID]-[Privilege Code]			jsmith	PH
userPrincipalName	[NetID]-[Privilege Code] followed by UPN suffix			jsmith@wisc.edu	PH

 

Examples for user "John A. Smith":

Examples for user "John A. Smith"

User Privilege	User Name	Display Name
User	jsmith	Smith, John A
Domain Administrator	jsmith-da	Smith, John A (DA)
OU Administrator	jsmith-ou	Smith, John A (OU)
System Administrator	jsmith-sa	Smith, John A (SA)
Helpdesk Technician	jsmith-hd	Smith, John A (HD)

 

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

A computer object provides a security context for computers joined to Active Directory. The computer name should provide information as to who manages the computer and what its purpose is.
The Computer Object names will conform to the 15-character standard (<DEPT><FF>-<YYYYYY>), where:

1. Every computer object name will begin with DEPT (Department Code).
2. <FF> will use the Computer Object Primary Function Codes, see above in the Name Components section.
3. <YYYYY> will be determined by local department policies.

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>

1. <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)
2. <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.
3. <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 Names

Group Name	Organization
DOIT-DS-FSFC	DoIT File Share Full Control
DOIT-GS-SEOMGRS	DoIT Systems Engineering and Operations Managers
DOIT-DL-ALLFTE	DoIT All Full Time Employees

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

See Also:

• Campus Active Directory - How to Identify Workstation Fully Qualified Domain Name (FQDN)