This document covers the naming convention used for objects created and managed within the Campus Active Directory Forest.
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.
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
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:
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
Each object name consists of three primary parts; Department Code (DC), Department Defined, and Function Code (FC).
Certificate Authority Server
Distributed File System (DFS) Server
Dynamic Host Configuration Protocol (DHCP) server
Domain Name Service
Network Connected Fax Machine
Network Management Server
System Management Server
Windows Internet Naming Service (WINS)
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.
Child Domains: <depart-code>.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.
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.
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
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:
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.
Site Name: CMPS
Site Description: Main Campus
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.
Site Connector Name: CMPS - AGRI
Site Connector Description: Main Campus – Agricultural and Life Sciences Farm
Each subnet should have the Site Code of the site it is assigned to populated in the description attribute to allow for easy association.
Description: CSSC Data Center
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).
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.
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 Privilege Code
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
Accounts that are delegated rights within Active Directory. These accounts may also be granted local administrative access to member servers.
Accounts that are granted local administrative access to member servers. These accounts are not delegated any rights in Active Directory
[Last Name], [First Name] [Initial] ([Privilege Code])
SMITH, JOHN A (SA)
Primary smtp email address of NetID user object (privileged accounts are not mail enabled)
[NetID]-[Privilege Code] followed by UPN suffix
Examples for user "John A. Smith":
Smith, John A
Smith, John A (DA)
Smith, John A (OU)
Smith, John A (SA)
Smith, John A (HD)
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 – 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
A Service account is a user object that provides authentication for an application or service. The naming convention for service accounts is:
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
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 – 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
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
CADS-OUADMIN-FGPP (OU Administrator Password Policy)
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:
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.
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.
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
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:
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)
Printer location field will be populated in the following format.
Example: 0155-B236-DOIT (Division of Information
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….
The following characters are not allowed in a group name:
" " / \ [ ] : ; | = + * ? < > , . $, !, ^, _
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:
Department Code for the organization
Group Type: The type of group that is created
XXXXX: Locally defined name
DoIT File Share Full Control
DoIT Systems Engineering and Operations Managers
DoIT All Full Time Employees
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> – Department Code.
<YYYYY> - Brief name that describes the purpose of the policy
DOIT Default Workstation