The Active Directory is a central repository for authenticating users and providing access to network resources. By centralizing core support functions, departmental IT staff have more time for proactive maintenance, which directly translates into a higher level of service for the users they support.
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 an 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 official identities will be created in the people OU and cannot be moved. Ad-hoc accounts may be created in the local/department OU, but are discouraged.
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||8 characters|
|Password complexity req||at least 1 character from 3 of these sets: lowercase, uppercase, numbers, symbols|
|can't contain the username or any 3 character fragment of the full name|
|Account lockout duration||30 minutes|
|Account lockout threshold||10 invalid login attempts|
Roaming profiles can be stored on a local server, so the decision to implement them is up to the OU administrator.
GPOs must be used to provide login scripts and must be applied to computers instead of users.
Reliability will be a key for the AD. The system will have redundant infrastructure to ensure high-availability. Users can connect to any available domain controller, so if a partial outage of the core network occurs, the impact will be minimal.
The goal will be to have near 100% uptime for the service.