Reaching Others University at Buffalo - The State University of New York
Skip to Content

UB Active Directory (UBAD)

Directory Organization

The UBAD Active Directory is a university-wide infrastructure intended to be shared by IT administrators to provide Microsoft Windows Active Directory services to all aspects of the university enterprise.

A User-Centric Approach

The organization of the Active Directory is based on the guiding principle that is user-centric:

The provision of technology to each user is the end result of the cooperative efforts of multiple IT support organizations committed to quality End User support.

In other words, no one organization has an exclusive claim to the End User. The organizations which have an affiliation with the End User work in concert to provide a seamless support model. Proper support of an End User may often need to integrate several support services, or isolate on just one, from those organizations committed toprovide support and have the authority to do so. Typical for students, they accept the role of service integrators as they learn to use resources from multiple departments.

Organization

The UBAD Active Directory is composed of three domains (see Figure 1):

  • An empty Root domain (adroot.buffalo.edu)
  • A UBIT Accounts domain (ad.buffalo.edu)
  • A Resources domain (itorg.ad.buffalo.edu)

The empty Root domain is established to separate forest wide roles, such as the schema and naming context administrator accounts, from the rest of the forest. The root domain contains no objects (computers, users, etc.), and is accessible only by enterprise-wide administrators.

The UBIT Accounts Domain contains all UBIT accounts created via UB’s appointment systems. The Accounts Domain is organized into smaller container objects called organizational units (OU), conceptually like “buckets”. The Accounts Domain will minimally be composed of a default Accounts (OU) and at least one (optional) distributed or departmental OU. A user object name, i.e. an account, must be unique and therefore can only exist in a single OU. The Accounts OU will contain all UBIT Accounts not located in the distributed OU’s. User object attributes in the Accounts OU are manipulated only through institutional change process, or by Central AD administrators. Departmental OU’s contain user objects for departmental faculty or staff (and not student) users that require direct manipulation of user object attributes by local IT administrator, e.g. MS Exchange users, or require special handling. User objects located in a Distributed OU are the responsibility of the Departmental OU administrator(s), and may not contain student UBIT Accounts.

The Resources domain will be organized into the same departmental OU’s as the UBIT Accounts domain and contains departmental resources, e.g. workstations, printers, file servers, and Resource domain user accounts, such as those needed for guests using departmental systems.

Because of technical, support, and Policy issues, no trusts to independent forests will be established to/from UBAD.

Figure 1. UBAD Domain Organization

Figure 1. UBAD Domain Organization

Accounts and OU Affiliations

User accounts are initially created within the default Accounts OU from UB’s appointment process account’s system, the same procedure that populates UBIT accounts into the central email and other authentication systems. All appointments result in data in the Accounts OU which preserves the hierarchies and integrity of institutional data. Fields which pertains to the identity of the user can only be modified using the institutional processes extant, e.g. change of status form required to modify officially a name or permanent address. Consequently, password changes are completed by using the UBIT password change web interface.

Departmental OU’s are created under the guidance of a Service Level Agreement which ensures that the OU is the appropriate mechanism to provide user centric support for the intended users. Creating the departmental OU is just one outcome or step along the process of careful migration of domains into the Active Directory, or new departmental services. Successful migration requires planning, careful testing, and record keeping. The UBAD Project Migration Team will provide a migration checklist to help ensure success.

User Affiliation Checking

During pre-migration a list of current domain users will be created by the departmental IT support staff that examines the needs of each user, known dependencies and affiliations. Consideration must be given to the affiliations and dependencies of the user outside of the department, since manipulating the user object will have implications wider than the local environment. Some subset of users will have special needs that require moving them into a departmental OU. Those which do not have multiple affiliations or dependencies are considered unambiguous user accounts for migration purposes.

The department head approves the list of unambiguous users accounts for migration and thus accepts the responsibility for primary support of the users. Once the users are migrated, should any issues of support affiliation arise, a multiple affiliation resolution process must be followed.

For example, in table 1 the departmental IT support staff have identified each user, his or her UBIT name, appointment type, known affiliations for multiple departments, and relevant needs. Jane S., Mary W. and Kevin B. have only one known affiliation, are faculty/staff appointments, and have needs to use multiple workstations in multiple environments (considered to be a sufficient need to move them into a departmental OU).

User Name

UBITname

VPA1

DEPT2

Student

Notes

Jane S.

Jane2

X

 

 

Access to UB Business

Carla B.

CJB4

X

X

 

Roaming workstation user (not laptop)

Mary W.

Maryw

X

 

 

 

Manuel P.

MP17

 

 

X

Student: Accounts OU only

Debbie M.

DMXMP

X

X

 

Visually impaired; uses adaptive workstation

Barb R.       

RXXXTA

X

X

 

 

Satoshi H.

SatoshiH

 

X

X

Student Accounts OU only; create user account in DEPT2 OU in ITorg domain for special access

Kevin B.

KJB18

X

 

 

Teaches UB101

Rhonda F.

RhondaF

X

X

 

Workstation in both areas; primary affiliation unknown

Carol P.

CarolP

X

X

 

Also has workstation in SSS Deans office

Table 1: example User Centric affiliation analysis document

Multiple Affiliation Resolution

Users with multiple affiliations require a resolution process which involves all the IT administrators who provide relevant service to the end user. Often the end user must also be involved since they are the best source of information for organizing their support. The primary factor in the choice of whether a user is moved into a particular departmental OU (or left in the Accounts OU) is what support organization can provide services most effectively to his/her primary role or function who are authorized to do so. The IT support staff work together in collaboration to decide what works best for each “shared” user. Primary responsibility for the end user belongs to the departmental OU administrator and IT support staff, but is shared with the other affiliated IT support organizations. For this reason we do not encourage applying policy to a user unless it is absolutely necessary, i.e. it should be the exception not the rule.

For example, again from table 1, Carla B., Debbie M., and Barb R. are staff appointments who have multiple known affiliations. IT administrators for VPA1 and DEPT2 will examine what workstation support model best fits the needs of each individual. Carla B. is a roaming user on multiple workstations (not a laptop user), so she needs to be supported in a departmental OU. The decision is made to migrate her account to the VPA1 OU. Debbie M. has a special need for an adaptive workstation. The decision is to leave Debbie in the Accounts OU since her needs are focused directly at the workstation level. Barb R. has no special needs, but is primarily a DEPT2 staff member. The two IT administrators agree to support Barb R. together, but DEPT2 IT staff will take on the role of services coordinator for the user.

The Migration Process

After a domain pre-migration checklist has been completed for the source domain, a oneway trust will be created whereby the source domain (Departmental NT4 domain in Figure 1) trusts the target domain (AD domain). Using the Active Directory Migration Tool, the AD Migration Team will migrate appropriate user, group, and member server accounts to the appropriate destination OU's. The departmental NT4 domain administrator will have the delegated administrative capability to migrate workstation accounts where applicable. Once a user's workstation has been migrated they will begin logging on with their Active Directory account. A combination of the one-way trust and SID history will allow users to access resources in the NT4 domain during the migration process. For example, a user logging on to AD could access a mailbox on an Exchange server that still resided in their old NT4 domain. Once all resources have been migrated (and everything works!), the trust and SID histories will be removed. The complete process will be explained in great detail with the source domain administrators prior to the migration.

Did This Page Answer Your Question?

(Required)
 
Email, UBITName or phone number
(Required)
Enter both words below, separated by a space. If either word appears unclear, click 'Get a new challenge' to receive two new words.