UB Active Directory (UBAD)
Within the UBAD Active Directory structure a naming convention
has been established for Computers, Groups, Organizational Units,
Printers and Group Policy Objects to avoid name conflicts. The use
of an administrative prefix guarantees a unique namespace for OU
administrators to identify their machines, groups, OU’s,
printers, and other resources.
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
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.
Organizational Units (OUs)
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
- 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
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
“~” 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 (220.127.116.11 primary, 18.104.22.168
Printers (optional: xxxx-printername)
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
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
Distribution groups and Exchange custom recipients (xxxx_listname)
All custom e-mail groups should start with the assigned
administrative prefix and “_” (underscore) and must be
unique throughout the domain.
Group Policy Objects (xxxx~policyname)
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
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
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
Service based user accounts should probably have a
“SVC” prefix on them after the normal administrative
prefix so they can easily be identified.
Domain Controllers and Central Resource Servers
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
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
- cc = Computing Center (not Norton)
- hy = Hayes
- ls = Library Storage Facility
- 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.
• [NetBIOS domain] - [location] [numeric identifier] .
[NetBIOS domain]. buffalo.edu
UBIT Name (DCE principal name) Conventions
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
- Principal names are never re-assigned (presently).
- Principal names are not assigned if they are listed on a stop
- A long series of combinations of the name and suffix are tried
until one that is not in use is found.
DCE Group Name Conventions
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
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.