Naming Conventions
Everything in the Active Directory must have a unique name. Since all resources in the directory are shared, the names must be distinguishable as well as unique. To accomplish this, the following naming scheme has been put into place. All objects start with the organization’s organizational code; except for the organization’s Organizational Unit (OU) which is just the organizational code. For example, the Office of Computing Service’s OU is named CSER. Additional organizational units can be set up under the organization’s OU. By default, the Active Directory team sets up an OU named COMPUTERS and an OU named USERS for each new organization’s organizational unit.
Depending on the purpose of a workstation, computer names start with the organizational code and either end with the MyLSU ID of the user or a lab designation. For example, a computer in the office John Doe at Chemical Engineering would be named CHE-JDOE1 while the computer with a designation of X in a Chemical Engineering lab in room 241 would be named CHE-241LABX.
Group names should also follow with the organizational code followed by a descriptor. For example, an available Active Directory security group called STUDENTS would not be very helpful. A security group named SR STUDENTS, however, would alert other Active Directory users that the security group was being used in the Southern Review office. By default, the Active Directory team sets up a group with the organizational code and then the word ADMINS for departmental administrators to control their OU, for example, SR ADMINS.
Group policy objects (GPO) are shared across the Active Directory and are required to follow the same scheme. GPOs should start with the organizational code followed by a description of the GPO. For example, MC LAB COMPUTER GROUP POLICY would be used by The School of Mass Communications. When an OU is set up for an organization on campus, the contact of that organization can request that the Active Directory team set up several blank GPOs for the organization to customize and use. These are generally named ORGCODE GROUP POLICY 1, ORGCODE GROUP POLICY 2, etc. Once the contact is ready to customize and apply the GPO, they can change the name as they see fit.
Louisiana State University Active Directory Project
In 1997 LSU implemented a domain model using Microsoft Windows NT 4.0. The model consisted of one master domain called LSU_NT that would be used for authentication only, along with this domain would be multiple resource domains. This plan met with limited success, some departments and colleges on campus began using LSU_NT for their users while others chose to maintain their own user database. Currently, there are over 100 domains on campus some are still active a few are remnants of past endeavors.
As technology growth on campus has outpaced budget and other resources a strain has been placed upon many departments for support and maintenance of their network assets. Increasingly more departments are turning to computing services for assistance and guidance in maintaining their local area networks. This in turn has required that the Office of Computing Services enact more efficient and innovative measures to ensure the availability of and access to departmental data.
The most important goal of the Active Directory project is to leverage our existing resources for maximum efficiency to support the demands of the LSU faculty staff and students, so that they may enjoy maximum productivity and greater satisfaction with technology on or off of campus. In order to accomplish this goal the project has four main objectives.
First, a central Active Directory of users and resources must be created for the entire campus. The users in this directory will mirror the directory of users on the LSU S/390 enterprise server along with the LSU Lotus Notes e-mail system. This centralized directory will facilitate an automated logon ID creation and maintenance process that will originate with the enterprise server thus minimizing human intervention and some of the potential for accidental mistakes. A centralized Active Directory is an essential first step in achieving the even more ambitious goal of providing all campus users with a single login experience across all platforms. This may be accomplished by using the Kerberos authentication standards now available in Windows 2000.
LSU requires a very pliable and custom model for administration to satisfy the needs of various departments and organizations on campus. The ability to have a centralized administrative structure, built around existing support infrastructures, will help to maintain external departmental resources more effectively for those departments which rely on Computing Services for technical support. Furthermore, due to the nature of certain confidential and or sensitive data along with an increasing reliance on student employees for technical support the ability to grant very specific and granular administrative control to different entities is sometimes necessary. The administrative model must also allow for the decentralization of administrative control in situations where departments have their own IT staff. Once this is accomplished then it will become feasible to collapse the majority of the existing resource domains on campus.
In the future, it may become feasible for Computing Services to embark on some centralized applications with the Active Directory. One example of such an application is a centralized storage area network of home directories for all Active Directory users. This centralized storage is already available to several thousand students in specific curriculums as mapped drives when they access their accounts on campus. The next step will be to deliver access to this data via the World Wide Web through our Internet portal.
Finally with the Active Directory becoming such an essential resource a sound infrastructure should be in place. Redundancy will be incorporated wherever possible in all hardware. This along with software precautions should provide substantial fault tolerance for the critical pieces of the Active Directory. High degrees of fault tolerance should curtail critical situations thus allowing IT staff to concentrate on supporting the end user instead of reacting to preventable problems.
-
Implementation - Hardware infrastructure
The LSU Active Directory went live in the summer of 2001. The directory exists as a single domain called LSU.EDU. AIX servers running bind 9.2 provide Domain Name Services for all clients. The LSU.EDU domain controllers all run active directory-integrated DNS for each other.
In order to promote fault tolerance and reliability four domain controllers have been placed into production. Each server has six hard drives in a RAID5 configuration with five active drives and one hot spare. The drives are segmented into three partitions. The first partition contains the operating system, the second partition contains all of the Active Directory logs as well as a backup of the system state and the third partition houses the directory itself. Two of these servers are quad-processor Pentium III Xeons and the other four are dual Pentium IV Xeons with Hyper-threading, all of the boxes have at least two gigabytes of RAM. In the interest of speed, the domain controllers are authenticating servers only.
The six servers are located in two separate locations in two different buildings on campus. All of the servers are housed in rooms with limited physical access to authorized personnel. The domain controllers LSU-DC1, LSU-DC2, and LSU-DC5 are located in the machine room in the computing services center. LSU-DC1 runs all of the single master functions for the domain making this server the most critical. LSU-DC3, LSU-DC4, and LSU-DC6 are located in the frame room in David Boyd Hall.
Each of the Domain controllers has a Gigabit network connection on the 184 subnet which is dual-homed so that they have a connection to each side of the network core. This single subnet has been implemented in the interest of blocking superfluous or malicious network traffic from the Domain Controllers.
-
Directory Services Infrastructure
In the process of exploring migration options for LSU_NT, it was noted, that while necessary at the time to have so many account operators and administrators, not having a stricter standard for ID creation and group usage complicates administrative efforts. In light of this, the idea to convert the existing domain was abandoned. It was decided that a new directory would have to be created from the ground up. At that point the most practical solution, to create thousands of user ID’s and home directories, was to use an automated process. This process ties into the current process for creating logon ID’s for LSU's other computing platforms. The account creation begins with a request either submitted from a batch routine or per individual request on the Enterprise Server. For instance, when a new employee is hired their account is created automatically when their HRM paperwork is processed. The enterprise server then creates the account name and propagates it to a queue that the Directory account creation service called Samwin checks every five minutes for new accounts and password changes Samwin then updates the active directory accordingly. In the immediate future, the enterprise server will also assign the IDs to the specific organizational units where the ID belongs. Currently, a separate batch process is issued for OU assignment and home directory creation.
As mentioned earlier the Samwin service can reset passwords. In and of itself this may not seem like a great advantage, but since Samwin interfaces with the Enterprise Server, windows users have access to LSU’s automated phone system to request a change of password, bypassing the need to contact support personnel. This feature alone may reduce significant percentages of calls to administrators.
In order to fulfill the requirement of a very pliable administration model and allow for centralized control, the Active Directory has been implemented in the form of a single domain, in a single tree. In this configuration, it is easier to keep track of Domain Administrators and other domain-wide access policies because they exist in a single location. Due to the control that the Enterprise Admins have the number of members in this group is limited to four. These five people are four active administrators, all of these are full-time employees of Computing Services and, for disaster protection, the Director of High-Performance Computing.
In order to allow for distributed administration the domain has been segmented into three primary OU’s in addition to the built-in OU’s for Active Directory. These three OU’s are called “Departments and Organizations”, “Students”, and “Computer Administration.”
Departments and Organizations contain faculty and staff ID’s as well as any departmental resources such as computers, shares and printers that are managed by the particular department. This is the primary OU for delegation of administration to departments. Computing Services also has a sub-OU under this OU that is virtually identical to all of the other departments. This is to help ensure standardization across the directory.
Each sub-OU under Departments and Organizations is created with a standard configuration. The configuration creates two sub-OU’s and one global group. The global group is the administrator’s group for that OU. This group has almost complete control of this OU and any child OU’s under it. The members are the IT staff of the particular department or a select group of support personnel from Computing Services. The two sub-OU’s are Users and Computers; each contains the implied resources.
The only tasks that the departmental administrators may not perform are the following. First, they are unable to create or delete any user IDs; the Enterprise Server handles this automatically thus preventing duplicate user IDs. Secondly, they are not able to reset a user’s password, this is due to the fact that the Enterprise Server synchronizes the user’s active directory password with their MyLSU web e-mail password. This is done so that a web interface to the user files can be provided to them via LSU’s MyLSU system (this is the Lotus Notes web portal mentioned earlier). The only other restriction for the OU administrator’s group is the administrators may not delete their departmental OU.
Departmental OU administrators will have unlimited powers to create security groups and group policies. Each OU administrators group will belong to two domain local groups, Script Managers and Add Computers. As each of these names implies, Add Computers members can add computer accounts to the domain in their OU. Script Managers have the power to edit scripts in the sysvol share. The only domain-wide group policy in place is, that passwords are required to have a minimum length of six characters, which coincides with LSU’s MyLSU password policy.
Several departments have incorporated part-time student employees to handle their technical support issues. This can be very cost-effective for the departments while giving the students valuable experience as well. Still, the fact remains that due to the fact that students come and go rather frequently, there is instability in these positions. A student may come to work for a department and leave a short time later. This creates a problem because so many hands may be involved in a department’s administration in such a short time that discrepancies inevitably arise. With Active Directory, administrative tasks, and access controls can be granted with far more granularity than with Windows NT 4 domains, thus safeguarding sensitive operations and data from access by these employees, if necessary.
A significant objective of the Active Directory project is to make available new and innovative applications to the end user. The first application incorporates the Windows domain into LSU’s multiple-platform Storage Area Network. Using technology available from IBM, LSU has expanded the Enterprise Storage Server Model 2105-F20 to provide large amounts of disk space to meet the rising storage demands of campus users. This application has already been used to provide several thousand students from multiple colleges with home directory space through a mapped network drive and Web-based access. This application is now offered to the entire campus including all students, faculty, and staff.
The implementation of the Active Directory is well underway. Hardware servers have been acquired and configured with sufficient memory and disk storage as recommended by Microsoft. Windows 2000 software has been installed, patched, and configured to create the Active Directory structures to support the entire campus structure. A centralized domain model for the deployment of the user name space, combined with the decentralized (or centralized) management of user group policies and computer resources, is ready to provide the campus users with a very robust and productive environment for them to conduct their academic, research, and administrative activities. A Storage Area Network application has been deployed to students in selected colleges with the scalability to deploy to a wide audience if resources become available.