`AD NAMING STANDARDS – February 5, 2003`

A Naming Standard is essential for two reasons.

To maintain an organized and predicable naming convention for all objects created in Active Directory (AD) so that administrators can effectively manage and troubleshoot network resources and services.
To avoid naming collisions (duplicate names) that could adversely affect the integrity of Active Directory, causing network problems throughout campus.

Active Directory is responsible for managing all of the objects created in the sfu.ca and ad.sfu.ca domains. There is only one Active Directory and it services all the SFU campuses , in their entirety. Every time a new object is created (e.g. user, group, computer) it becomes an Active Directory object and every AD object must have a unique name throughout all of SFU.

This unique name is referred to (in Microsoft parlance) as the Fully Qualified Domain Name of the object. The Domain referred to here is a Microsoft Server domain, as opposed to our more familiar UNIX-style DNS domains, which Microsoft (usually) refers to as Fully Qualified DNS Domain Names. The FQDN of an object is comprised of the object's domain, OU hierarchy and object name. For example, a computer named UCS-APPSRV1, created in a Child OU named Servers, in the UCS Organizational Unit in the ad.sfu.ca domain has an Object FQDN name as follows:

ad.sfu.ca/UCS/Servers/UCS-APPSRV1

It is imperative that we develop and adhere to naming standards that will ensure naming collisions do not occur. Naming collisions will cause Active Directory to become unstable, stop replicating appropriately and eventually make access to AD unpredictable or impossible.

Further complicating the naming issue is the fact that certain objects possess two types of names; an Active Directory object name and a Netbios name. The inclusion of the Netbios name is significant because not only do we have to worry about duplicate FQDN names but we also need to avoid duplicate Netbios names. Netbios names must also be unique throughout all of SFU.

Moreover, Netbios names follow a different convention than FQDN names. There is no hierarchical naming structure for Netbios names. Instead, Netbios names use a name space where only one object can be given a specific name in each name space.

For example, only one computer may be called RED throughout campus.

(However, as computers and users live in different name spaces, you may have a user called RED and a computer called RED. Remember that in order to avoid duplicate FQDN names the computer called RED and the User called RED must be created in different Organizational Units. )

In addition, Netbios names have different limitations on length and characters allowed for each object type. (In Active Directory, the Netbios name is referred to as the Pre-Windows 2000 name. The Netbios name is used to provide backwards compatibility for Pre-Windows 2000 clients.)

There are three Netbios name types we need to concern ourselves with; Account names, Machine names and Group names.

Account Names:

CCN Account names from the existing Amaint (UNIX ) system will be duplicated in AD and placed in the SFUUsers OU. As the Amaint system that generates these CCN Accounts keeps them unique, there will be no duplication problem for these names. However, local Lan Administrators may need or wish to create accounts themselves, either for some short term use where the user will not have an auto-generated CCN account, or for an administrative purpose. TestUser is one account that comes to mind, and one that is likely to be duplicated throughout campus.

For locally generated accounts, the policy will be that the account name must be preceded by the OU and a space. That is, the TestUser account for use in ACS will be named ACS TestUser

This policy will be strictly enforced.

Note that such accounts will be created in the relevant OU, never in the SFUUsers OU.

Machine Names:

Machine names present more of a problem. While there is a unique database of machines, the existing DNS, “dots” are not allowed as part of the Netbios name. So, while pc1.math.sfu.ca and pc1.acs.sfu.ca are different names as far as DNS is concerned, AD considers them both to have the same Netbios name of PC1 Thankfully, the current convention of naming machines by either HS number or room number provides us with a high degree of AD Netbios uniqueness. (An examination of the DNS shows the number “AD name collisions” to be small) Troubleshooting of network problems is greatly eased if there is close consistency between the two services that deal with names, DNS and AD.

Therefore, the SFU DNS will be the basis for all Active Directory Netbios computer names.

One of the implications of this policy is that all new requests to register a machine name in the DNS will now have to meet the additional requirement of AD Netbios name uniqueness.

New machine name standard:[1]

Where the use of the room number as the basis of a name is appropriate, the room number should be used, as is currently done throughout most of the campus.
Alternately, where an HS number is acceptable, the HS number be used as the basis of a name, again, as is currently done.
Where neither of these are appropriate and/or desired, OU<dash>CCN ID or OU<dash>FUNCTIONmay be used as the basis of a name [2] .
Finally, a unique Asset ID Tag alpha-numeric may be used.

OU<dash>randomly picked word or simply randomly picked word will no longer be allowed.

Existing machine names:

When there is a NETBIOS name collision (as in the example of PC1 cited above), at least one of the machines will need to be renamed. The standard for that renaming will be, as a minimum, to prepend the OU and a dash to the beginning of the machine name. So, pc1.acs.sfu.ca would become acs-pc1.acs.sfu.ca.

However, it is highly recommended that a whole new machine name be given, based upon the convention listed above.[3]

Group Names:

Locally created groups (by OU Administrators) will have the form of

OU<space>Groupname

For example, all of the PC Eudora users in ACS may be placed in a group named ACS EudoraUsers.

This policy will also be strictly enforced.

Finally, it is also strongly recommended that when creating groups and assigning permissions to those groups, Microsoft’s strategy be followed. That is, Accounts are added to Global Groups, Global Groups are placed in a Domain Local Group and Permissions are assigned to the Domain Local group.

In the above example, another group would be created, a Domain Local group, named ACS Local EudoraUsers. Any relevant permission would be applied to this "local" group.

This group strategy, while cumbersome and seemingly requiring a duplication of groups, yields us performance [4] improvements in the current AD topology, particularly during initial user login. Also, it is expected that Active Directory will likely be with us for a very long time and it is difficult to predict how things might change in the years to come. Therefore, doing it correctly “right off the bat” seems like a sound policy.

Table 1: Constraints Imposed by Netbios

Object	Netbios Name Space	Object Length	Example – Red
Users	Shared with Groups	20 characters	User called Red created in a Child OU called Users
Groups	Shared with Users	No practical Limit	No Group can be called Red regardless of the OU in which it is created because Users and Groups share a name space
Computers	Separate Name Space	15 characters	Computer called Red created in the Child OU Computers

Table 2: The SFU AD Name Standard

Object	Standard	Example	Exceptions
Domain		sfu.ca	None
Child Domain		ad.sfu.ca
OU	Standard department prefix as noted in the Registrar’s calendar	FIN PSYC ACS	If a prefix for a department has not been defined in the Registrar’s calendar or a clear preference is stated, the OU name will be negotiated. SFUUsers: This is a container that holds all of the unique user accounts for all departments.
Child OU	<desired name>	Computers Users Servers
Site	Physical Location of Site	Surrey
Site Links	Physical Locations Being Linked	BurnabytoSurrey
Machine Name (Netbios)	Option 1: Machine names are derived from the HS number, as is our current standard. Option 2: Machine names are derived from room number, as is our current standard. Option 3: OU + dash +<CCN ID> or OU + dash +<function> The name may not contain spaces.The total length of a computer name must not exceed 15 characters. Note: For existing entries in the DNS, the computer name stays as it is on a first-come, first-served basis provided that the name does not exceed 15 characters. When a name conflict arises, the computer name is modified by placing the OU prefix before the desired computer name, or better still, a whole name based on Options 1-3 is created.	HS87654 SH1015 ACS-REO ACS-RECEPTION SPRUCE MATH-SPRUCE	In the specific case of servers providing a necessary service where that service requires a machine named outside of the OU-name standard for proper functioning, exceptions to the naming standard may be allowed. There are at this time no known cases where this might apply. In the case of multiple machines - in a room, or connected via hub to an HS port or in use by a single user, an appropriate suffix will be applied. This suffix may be in the form of a letter, number, or other identifier, perhaps separated by a dash.[5]
User (system created)	Eight character or less user ID, as created by the Amaint system, and placed in the SFUUsers container. Notes: 1. User objects created in this container do not use an OU Prefix and must be 8 or fewer characters. 2. A user account for each student, faculty and staff member has been or will be created in the SFUUsers container.	alan rob	None
User (locally created)	OU + space + <desired name>.	FIN Administrator FIN <service> FIN TestUser	None
Group	OU + space + <desired name>.	FIN Admins MATH Admins ACS Admins	None
Printer	OU + space + Physical Location + <desired name>. Note: Length of total path, including prefixed UNC and filename must be less than 260 characters.	FIN AQ3300 HP4SI MATH AQ873 Tech840 ACS SH1100 Lex9000	The physical location is not required, but its inclusion in the name is highly recommended.
Published Share	OU + space + <desired name>. Notes: 1. Length of total path, including prefixed UNC and filename must be less than 260 characters. 2. Shares not published in Active Directory have no name restrictions.	FIN Reports MATH Templates ACS SetupDocs	None
Contact	OU + space + <desired name>.	FIN Help MATH Dr. Rob ACS MSConsultant	None
Logon/Logoff Startup/Shutdown Scripts	OU + space + <desired name>. Note: The login script is a file not an object. However, scripts may be stored in a central location and therefore it is prudent to enforce a naming policy upon these items as well.	FIN Users MATH Admins ACS Admins	None
Group Policy	OU + space + <desired name>.	FIN General MATH Software ACS BaseDC	None

Notes:

1. Troubleshooting of network difficulties and future migration to UPN (User Personal Networking) were a major consideration in determining an appropriate naming standard, as the Network Operations group and Lan Administrators are the primary users of the DNS.
2. CCN ID is also known as UNIX ID.
3. Eventually, this flexibility will be removed and all new names must meet the new standard.
4. See the Microsoft recommendations here.
5. The room names throughout the campus are not entirely consistent, sometimes ending in a dot number, a dash number, a dot letter, a dash letter, and extra letter or an extra number. The exact extra identifier will be determined by OTS-NOC, as has always been the practice. In the case where an admin wishes to name a machine using a CCN ID and there are multiple machines in use by that person, a dash and an identifier is permissible. That identifier can be a dash and a number, or a dash and some combination of letters and numbers. An example of this would be Reo with a PC and a Mac, the PC would be named ACS-REO-PC. The dash after the CCN ID is required, the dash between REO and PC is optional.