Active Directory - General Policies

UNL should establish and support a single UNL-wide Active Directory

The Windows 2000 committee recommended a single domain model for the following reasons:

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.

The root domain of the Active Directory should be an empty root, and Organizational Units should be established off of the root domain for use by the UNL community. The domain should have a minimum of restrictions and controls, with almost all policies and control being relegated to the Organizational Units.

The Windows 2000 Committee recommends only one domain be established for UNL.

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 Units.

Departments and workgroups are rightly concerned about the security and control of their resources. They will be far more comfortable with the concept of only one domain if they are assured that only they will have control over their resources.

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.

Information Services should be given responsibility to administer the Active Directory domain controllers and the domain.

Naming Conventions

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; i. e. ; 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.

Still to be determined is how requests for OUs will be handled. One suggestion is to set up OUs by department or college, much like the identifiers used for Lotus Notes.

Second-level OUs in different root OUs can have the same name.

Computer names should be determined by their respective OU. However, the OU identifier must precede each computer name.

For example: A computer for Keith Bartels in the Division of Continuing Studies, with an OU name of DCS, could be called DCSKBartels. Computers move between departments and work units much less frequently than people and renaming a computer in the Active Directory is not difficult. So, other than the OU identifier, we see no need for a strict policy on computer names.

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.

User Import

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.

If a student has the privacy flag set, a generic account will be generated for them.

Password policies should be determined by the OU.

Coming to an agreement on a single password policy would be extremely difficult in a university environment. And if an Active Directory domain sets any password policy, it overrules all OU password policies. Therefore the domain should set no password policy.

Further research determined that this policy would not work. Password policies can only be set at the domain level, and apply to all accounts in the domain, regardless of any policies set at the OU or local level. The AD committee decided on the following policies:

Enforce password history	0 passwords remembered
Maximum password age	0 days
Minimum password age	0 days
Minimum password length	5 characters
Password complexity req	none
Account lockout duration	15 minutes
Account lockout threshold	0 invalid logon attempts
Reset locked account after	15 minutes

Student Issues

Students should be located in a single root-level OU.

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.

Password resets handled by helpdesk and through WAM page.

WAM password resets on hold, due to security issues.

Student passwords will be reset to a random string and emailed to the student’s registered email address.

GPO would not be applied to the student accounts directly, but rather to the computers they log into.

GPO applied to generic accounts because they need to be located in the same OU as the policy.

Further research allows user policies to apply to any users logging into a computer, so generic accounts are unnecessary.

Licensing

OUs are responsible for purchasing Client access licenses.

(note)

Current UNL contract with Microsoft includes client access licenses, so this no longer applies.

Roaming Profiles

Roaming profiles can be stored on a local server, so the decision to implement them is up to the OU administrator.

Home Directories

Multiple drive letters should be used, assigned by OUs.

Topic revisited. No decision.