In an attempt to handle naming conflicts, it was determined that an Administrative Prefix was needed. Institutional data was looked at for this purpose, but there was no “one to one” mapping between the way that the University is divided up organizationally and the way the IT administration is handled. It was also decided that any attempt to use the existing entity abbreviations could result in future conflicts.

For example, suppose two IT groups share the same entity code ABC but both want to manage their IT environments separately. The first group reserves “ABC” and gets an OU created using that code and starts prefixing their resource names with “ABC“. The second group cannot use the code “ABC” so they choose a prefix that is different from their entity code, e.g. “XYZ”. They must make sure there is no other group on campus that uses the entity code XYZ, but there is no way to ensure that the entity code “XYZ” will never be assigned. In fact, if it is assigned and the new group wants to join the Active Directory, they will want to use “XYZ” as their prefix. We then have a conflict.

To solve this problem, it was decided not to use entity abbreviations or any 3 character prefix. Instead, an Administrative Prefix will be four characters, unique from common four-character University acronyms, and will be used to ensure unique names for OU’s, groups and other objects within the domain.

IT departments will join UBAD as Organizational Units (OU). An OU is an administrative container used by the OU administrator to assign rights to resources and grant access privileges. All OU’s in UBAD will be created according to this naming standard:

• Department (ITOrg) OU’s:
  
  • Department IT support OU’s will be named consistent with the Department IT support organization name
  • Department OU names will be at least four characters in length and differ from common four-character University acronyms. (i.e. VPSA would not be a valid OU name at this time.)
• Department sub OU’s:
  
  • Department sub OU’s (created directly beneath the Department OU) must be a unique four character name.
    
  • This OU name is the administrative prefix and will be used to prefix groups, group policy objects, and other resources. For more information about OU structure and creation refer to the UBAD Organizational Unit Hierarchy Structure document on the project web site.

The following special characters should be used to separate the administrative prefix and the rest of UBAD names. These prefixes apply to the resource domain only.

“-“    For computers/printers
“.”    For Users
“_”   For security groups
“_”   For distribution group or custom recipient
“~”  For Group Policy Objects

Computer names in UBAD must be unique. For migrations, the DNS name and WINS name can be different. For new workstations, we recommend that the DNS Host name be the same as the WINS name. To facilitate migration to the UBAD, all Windows devices must be registered in WINS (128.205.1.31 primary, 128.205.250.24 secondary).

Printer names do not have to be unique and are therefore not subject to naming conventions. It is recommended that the office location and description fields be filled out for ease of locating the device instead of trying to put it into the name. This will make migration more seamless. If continuity is desired, printers can be named using the same convention as computers.

Usernames that exist in the “accounts” domain (UBit names) originate from the accounts system. Usernames created in the Resource Domain start with the assigned administrative prefix and a “.” (dot). All usernames must be unique throughout the domain.

All groups must start with the assigned administrative prefix and a “_” (underscore) and must be created in the Accounts Domain within an IT Organization OU. Group names must be unique throughout the domain. It should be noted that UBIT-Group names will over-write any similarly named ITOrg Groups; care must be taken to use the administrative prefix and carat to prevent collisions.

All custom e-mail groups should start with the assigned administrative prefix and “_” (underscore) and must be unique throughout the domain.

Group Policy objects can be shared and linked, so they should contain an identifier to denote where they were created originally. So group policy object names should begin with the prefix and a “~” (tilde).

Distribution List - will dovetail with group creation standards. Use AD users and computers in OU to create a Universal group that you would put other groups in. (i.e. xxxx_Managers).

Public Folders - Create root folders in Exchange System Manager for each OU (dept). Root folder must match OU name.

Administrative Group - Create a separate Administrative Group for each department with an Exchange Server, using the department’s second level OU name.

Mailbox or mail users - Use UBIT Name

Contacts – Must use administrative prefix. (i.e. xxxx_JohnDoe). Note Only Non UBIT contacts will be created in AD.

While this policy pertains to newly added objects, existing objects should be renamed eventually to avoid confusion. This should be done in a way that does not impact any production services.

Service based user accounts should probably have a “SVC” prefix on them after the normal administrative prefix so they can easily be identified.

In determining the naming standards for all of the central server resources for the Active Directory project, we found ourselves confronting two conflicting issues. We needed to ensure that each server had a distinct NetBIOS name which preferably matched the servers DNS host name while also trying to keep the names short, readable and meaningful. To help us with this, we identified a couple of key pieces of information that should perhaps be addressed by the name that we could use. These items were server function, domain name, server location and a numeric indicator to further distinguish otherwise identical servers. Once we analyzed a number of possible scenarios, we determined that the most beneficial option was to simply mimic the servers NetBIOS domain name to ensure uniqueness of names throughout all domains and append the location and a numeric identifier. For servers that are not domain controllers, which are less plentiful, we also decided to insert a unique code identifying the type of server between the location and numeric identifier. We debated abbreviating the NetBIOS domain names to reduce name lengths further but found that this made for difficult to read, cryptic names.

For this model to work, we created a key of abbreviations for locations and service types which is listed below, followed by a naming template and finally our proposed names for the identified equipment.

Location Keys:

• cc = Computing Center  (not Norton)
• hy = Hayes
• ls = Library Storage Facility

Numeric Identifier

• Simple counter that identifies the number of machines of a specific type in a specific location.
• If there are two Domain Controllers for a domain in Computing Center, the first is –cc1 and the second –cc2.

Template

• [NetBIOS domain] - [location] [numeric identifier] . [NetBIOS domain]. buffalo.edu

UBIT Names are generated algorithmically using combinations of parts of a person’s full name and an optional numeric suffix. Some rules associated with names are:

• A principal name is lower case.
• A principal name only contains letter and numbers.
• A principal name is 8 characters or less.
• The numeric suffix will not contain the number 0 or 1 because they can be
• confused with the letters ‘o’ and ‘l’.
• Principal names are never re-assigned (presently).
• Principal names are not assigned if they are listed on a stop list.
• A long series of combinations of the name and suffix are tried until one that is not in use is found.

All groups will be replicated from DCE to the Active Directory. Groups will not change common names to be consistent with DCE.  The SAM account name will be prefixed by “g-“

Besides groups generated based on entity affiliation, and the conventions mentioned above, certain administrators are granted access to create and manage groups in DCE.

First, there is no requirement in UNIX or DCE that group names be different from principal names, so there is the potential for overlap between principals and groups.

Groups created by departmental administrators will be created with of a prefix of the administrators entity abbreviation followed by a ‘-‘. In addition, groups are generally 8 characters or less and a combination of letters and numbers.

An administrator can put any user in a group, but UNIX and DFS have difficulty with users who belong to more than 15 groups which put some limits on the usefulness of groups. There is no real limit to the number of members of a group.

A number of DCE only groups also exist, and by convention, we’ve used the ‘/’ character in all of these groups so they don’t overlap with UNIX groups.