UNL has established a single Active Directory domain and forest for UNL.
This will improve computing for the University in the following ways:
- Consolidation of Resources
Domain controllers are needed for each domain on campus. By reducing the number of domains from 50 to only 1, the number of Domain Controllers that need to be purchased and maintained is also reduced.
- Distributed Administration
With Active Directory, Administration can be delegated at the Organizational Unit level. The previous domain structure only allowed administrative control at the domain level.
- Trust Relationships
The previous domain structure required trust relationships to be established to enable users in different domains to share files. By moving to a single-domain model, this process is eliminated.
- Network Efficiency
Reducing the number of domain controllers reduces the replication traffic between all these DCs. This allows Domain Controllers to be located based on network need, rather than who has administrative control.
- DNS Integration
Active Directory is tightly integrated with the DNS structure. UNL's DNS structure supports a single-domain model with no sub-domains allowed.
Organizational Units will be established off of the root domain for use by the UNL community. The central domain group policies should have a minimum of restrictions and controls, with almost all policies and control being relegated to the Organizational Units.
While Information Services should maintain the domain controllers and the integration of Active Directory with DNS and DHCP, actual control and delegation of domain resources (client accounts; file, print, and application servers; groups; group policies; password policies; etc. ) should be the responsibility of the Organizational Unit managers.
While the UNL Active Directory administrator could override the OU administrator they would do so only in unusual circumstances. This should be viewed as an advantage of the single Active Directory. If security problems develop, or an OU administrator is unavailable, the UNL Active Directory administrator could come to the aid of the organizational unit.
Naming conventions should be established for account, computer, and OU names.
Within each object class (user, computer, group, etc), an object must have a unique name. Within a single OU, names must be unique regardless of class. Thus, within the IS OU, naming a computer AND a user IS-lab1 is not allowed. However, a user in the IS\users OU and a computer in the IS\computers OU could both have the name IS-lab1.
Individual accounts should be the same as an individual’s CSO short name (e.g. kbartels1). If additional individual accounts are necessary, a letter identifier will be used(e.g. kbartels1a).
This convention already exists and most UNL staff are familiar with its use. It should be easy to remember and the administration of this convention is already established. Exceptions may be necessary for special purposes such as integration with some departmental UNIX systems, but these exceptions should be few.
Organizational Units (OU) should be designated by a two-to-four character identifier corresponding to their department or workgroup name.
Some examples: The Computer Science Department OU could be CSD, Human Resources could be DHR or HR, the Institute of Agriculture and Natural Resources OU could be IANR.
An initial OU structure framework will be set up modeled after the university Vice-Chancellor/College/Department structure.
Child OUs in different branches of the AD can have the same name (e.g. an OU named Computers).
Computer names should be determined by their respective OU. However, the OU identifier prefix should precede each computer name (e.g. ianr-kbartelsdesk).
A conflict could occur even if two OUs followed the policy. Example: A computer in BF\Accounting\Acct-comp1 and one in IANR\Accounting\Acct-comp1.
The policy is amended to use the root OU prefix for all computers in the OU. So following the above example, the proper names would be BF\Accounting\BF-comp1 and IANR\Accounting\IANR-comp1. The OU administrators have the option of expanding a prefix to make names more descriptive, such as BF-Acct-comp1 and IANR-Accounting-comp1.
All staff accounts will be placed into OUs based on department. Student accounts would be located alphabetically, based on last name. Students would be placed into class groups. All sections of a class would belong to a parent class group. (Acct201sec1 and Acct201sec2 belonging to Acct201).
New employees don’t appear in the CSO immediately and thus won’t be included in the import. OU Administrators should request an account for new users from Operations and they will be included in a side-file temporarily until they are entered into the system.
If a student has the privacy flag set, a generic account will be generated for them.
Password policies can only be set at the domain level. If a password policy is set at the OU level it will fail to apply. This is a design restriction set by Microsoft, not a policy decision for UNL.
|Minimum password length
|Password complexity req
||at least 1 character from 3 of these sets: lowercase, uppercase, numbers, symbols
||can't contain username or any 3 character fragment of full name
|Account lockout duration
|Account lockout threshold
||6 invalid logon attempts
|Reset locked account after
Students will be located in a single root-level OU. Since undergraduate students enroll in classes from many departments, no policies will be set on any students.
All OU Administrators would have read access to this OU, but only Domain Administrators would have rights to change information. This allows all OU Administrators to add students to groups. OU Administrators can also use group policies applied to their computers to manage the user experience for students.
Password resets handled by helpdesk and through WAM page.
Student passwords will be reset to a random string and emailed to the student’s registered email address.
OUs are responsible for purchasing Client access licenses.
Roaming profiles can be stored on a local server, so the decision to implement them is up to the OU administrator.
Controlled by OU Admins. Can't be used on students, GPO applied to computers instead. For faculty in multiple departments, one department will be considered primary and will control the user account, but will work with other departments as needed.
Reliability will be a key for the AD. The system will have a total of 3 domain controllers: 2 on city campus, 1 on east campus. Users can connect to any available domain controller, so if a partial outage of the core network occurs, impact will be minimal.
The servers will be on a 3 year cycle to ensure hardware failure will be minimal.
The goal will be to have near 100% uptime for the service.