Policies for CalNetAD OU Administrators

Version 1.0

Updated: 10/24/2003

1. Introduction
2. How to Join the CalNetAD Forest
3. Joining as an Organizational Unit (OU)
4. Joining as a Domain
5. Computer Accounts
6. User Accounts
7. Group Policy Objects (GPOs)
   7.1 GPO Naming Conventions
   7.2 GPO Processing
   7.3 GPO Delegation
   7.4 GPO Security
8. Authentication
9. Passwords
10. Software License Compliance
11. Network Services
12. Internet Information Server IIS
13. Distributed File System (DFS)
14. Encrypted File System (EFS)
15. Enterprise Administration Responsibilities
16. Local Administration Responsibilities

1. Introduction

We anticipate that many departments and units, large and small, on the Berkeley Campus will elect to join the CalNetAD forest. Most of the administrative responsibilities in the forest will be delegated to local administrators in these departments and units. Being a local administrator in the CalNetAD forest carries certain responsibilities and expectations. These policies are meant to delineate appropriate standards within the CalNetAD forest.

All local administrators in the CalNetAD forest must read and agree to the following policies, prior to being given an administrative account. Any local administrator who creates an administrative account for another local administrator must make sure the new administrator has read and agreed to these policies.

All CalNetAD local administrators (or their proxy) are expected to participate in the CalNetAd Planning Committee and attend its meetings.

2. How to Join the CalNetAD Forest

• Familarize yourself with these policies and the CalNetAD Naming Standards.
• Schedule a meeting with the CalNetAD team by sending e-mail to calnetad-info. The CalNetAd team will discuss your requirements with you.
• Agree to the CalNetAD policies and complete a Service Level Agreement (SLA)
• Provide the CalNetAD project team with the name of a mailing list for your local administrators that can be added to the CalNetAD Administrative Contact List.
• Provide the CalNetAD project team with the CalNetID of the first administrator for the new OU.
• Provide the CalNetAD project team with the DNS name of the first computer that will join the new OU.
• Participate in the CalNetAD Planning Committee.

3. Joining as an Organizational Unit (OU)

Departments and units are encouraged to join the CalNetAD as an Organizational Unit (OU). OUs are directory containers for directory objects (i.e., user, computer, and policy objects). The primary purpose of an OU is to make administration easier in terms of management and delegation. Control of an OU in the CalNetAD forest will be delegated to an OU administrator group who shall have the ability to manage users, computers, local security groups, and Group Policy Objects (GPOs) in their OU and sub-OUs. GPOs are a set of common configuration settings, like distributing software or changing the user environment, to help manage directory objects such as computers and users. OU administrators will only be allowed to apply GPOs for their OU.

4. Joining as a Domain

Joining as a domain is discouraged. Special circumstances may require this option, but in general it leads to no significant advantage for the joining group. Joining as a domain requires agreement to the policies contined in this document as well as to the additional responsibilities and limitations contained in Policies for CalNetAD Domain Administrators.

5. Computer Accounts

In general, people who experience problems with a particular service should speak to their local CalNetAD administrator first. If the issue can’t be resolved, then the local administrator can raise the issue to the appropriate support group. (See 16 Local Administration Responsibilities below).

CalNetAD naming standards are recommended for computer account names. Naming conflicts are left to local administrators to resolve. Priority will generally go the OU that first used the name in the forest.

All workstations should keep "berkeley.edu" or other existing domain suffixes as their primary domain suffix. All workstations must be registered properly in the campus DNS. Use the existing DNS names (if legal Windows names). All workstations must have an Active Directory DNS name that matches their registered campus DNS name. The hostname component of the FQDN becomes the legacy short-name alias. Workstations in the forest must be configured to turn off DDNS registration. This is enforced by a site GPO which should not be blocked.

6. User Accounts

CalNetAD naming standards are recommended for user account names.

Local administrators are responsible for the local support of their user accounts. As a local administrator, it is up to you to educate your users on a regular basis so as to avoid common problems. The majority of issues you deal with will probably concern failed logins and security in the distributed Windows environment. For example, remembering to specify the correct domain during login (or the full UPN, "calnetid@BERKELEY.EDU", on the userfield) is something most people will not be familiar with because they are accustomed to a single domain environment, where there is only one domain to choose from. To troubleshoot:

1. Have them try logging into another Windows Workstation (this should tell them their computer has an issue).
2. Have them try using the Try CalNet web page to login with exactly the same credentials to the KDC (if it fails, then the password they are using is wrong). Make sure they know that the password changes must be done via the Change CalNet Passphrase web page. In addition, XP users will be able to change their CalNet passphrase using the standard windows change password utilities.

Establish which security group (other than "Everyone") the members of your department should always use for access to local shared folders. Document the process step-by-step, so users can follow it easily.

Data replicated into the CalNetAD campus domain from the CalNet Directory (e.g., name fields, address fields, phone numbers, etc.) will be subject to automatic updating and should not be altered locally. Local administrators must take appropriate security precautions to protect user account data.

Local administrators should make every effort to delete expired or unused user accounts in their OUs.

7. Group Policy Objects (GPOs)

Group Policy Objects are directory objects used to apply common configuration settings on computers and user objects. GPOs are associated with directory containers, and are thus applied indirectly to all user or computer objects within that container. Using GPOs, local dministrators can perform tasks such as assigning a particular software installation to a set of computers, enforce security settings, or assign configuration options.

7.1 GPO Naming Conventions

CalNetAD naming standards are recommended forGPOs.

7.2 GPO Processing

• Group Policy template settings should be configured to process unchanged Group Policy settings.
• Be sure that a GPO has fully replicated before making further changes to it.
• Use of the No Override and Block Inheritance options should be minimized.
• Filtering of permissions on GPOs is generally not recommended.
• Even if local administrators are exempt from a GPO affecting normal users, they should be subject to some specialized GPO that governs security settings.
• Synchronous processing of Group Policy is recommended over asynchronous processing.
• The default Group Policy refresh rates should not be significantly decreased or increased.

7.3 GPO Delegation

• Use caution when delegating Group Policy to groups other than Administrators.
• Assign Group Policy permissions to security groups and not individual users.
• Full Control is not necessary to manage links or modify GPOs; assign the fewest permissions needed.
• Limit the use of sensitive snap-ins, such as the Group Policy, Security Templates, and Security Configuration and Analysis snap-ins.
• In the case of non-administrative users, define GPOs that deny access to all snap-ins except those deemed necessary and explicitly listed as permitted.
• At a minimum, it is recommended that normal, non-administrative users not be allowed access to the Security Templates and Security Configuration and Analysis snap-ins. Access to these templates could allow a user to view all of the intended security settings of a system and perform an analysis to determine if the system is vulnerable to attack.

7.4 GPO Security

• It is recommended that computers within a Windows 2000 domain be grouped into separate OUs based on their role in the domain. For example, workstations will be in their own OU, member servers in another OU, and domain controllers in the Default Domain Controllers OU. Within this type of organization, GPOs containing security settings individualized for each type of computer can be easily applied.
• Group related settings in a single GPO.
• Set a strong Local Group Policy for computers that are not part of a domain. For domain computers, a good LGPO can compensate for holes in subsequently applied Active Directory GPOs.
• Use loopback processing only when necessary. Place all computers affected by loopback in the same OU.
• Do not use legacy clients in a Windows 2000 network. However, if maintenance of these clients is necessary, it is important to understand that Windows NT and 9x clients residing in a Windows 2000 domain cannot use Group Policy. However, a system policy can be pushed out to these clients from Windows 2000 domain controllers.
• Enable Group Policy diagnostic logging temporarily when troubleshooting is required.

8. Authentication

Cleartext authentication is not allowed in the CalNetAD infrastructure. Cleartext authentication will be turned off on all domain controllers. Clear text authentication is not allowed for IIS, Mac File and Print Services, Samba, or FTP.

9. Passwords

All accounts must have a robust password that meets certain basic requirements for strength, complexity and form. Please refer to the required passphrase characteristics contained on the CalNet Change Passphrase web page.

10. Software License Compliance

Participation in the CalNetAD forest does not entitle departments to licenses for operating systems or other software for departmental systems. The CalNetAD service includes only licenses for software required to operate the CalNetAD forest and Domain Controllers. Departments should ensure that systems participating in the CalNetAD forest are properly licensed for software running on their systems, including operating system or server software.

11. Network Services

Windows DNS Server Services must NOT be installed on any computer within the CalNetAD forest without prior consultation with IST-CNS and the CalNetAD Enterprise Administrators. Windows machines using IST-CNS for DNS services must be configured to turn off DDNS registration. IST-CNS does not generally support DDNS for security reasons. A site-wide GPO automatically disables DDNS registration for members of the forest. This policy should not be blocked. All UC Berkeley computers in the CalNetAD forest must have their primary DNS suffix name correctly entered, and must be registered in DNS to communicate properly in the forest. To conform to campus networking standards, all computers must have a DNS name that matches their registered node.

DHCP services must be coordinated with IST-CNS and CalNetAD Enterprise Administrators before joining the forest.

12. Internet Information Server (IIS)

By default, IIS services are turned off through CalNetAD Group Policy. This helps to ensure that local workstations cannot start 'rogue' IIS web servers. Local administrators can override the CalNetAD GPOs governing IIS in order to implement a well-managed IIS web service. "Well-managed" means that all security patches and fixes have been applied; all unnecessary IIS services have been turned off; and IIS is configured to not allow cleartext authentication.

The CalNetAD Security Subcommittee recommends putting IIS in a separate, dedicated domain where feasible and establishing appropriate security groups to control access.

13. Distributed File System (DFS)

DFS is supported in the CalNetAD forest. Please contact the CalNetAD Enterprise Administrators if you wish to run this service.

14. Encrypted File Services (EFS)

By default, EFS services are turned off through CalNetAD Group Policy. Please be sure to understand the risks relating to lost encryption keys if you choose to override this policy.

15. Enterprise Administration Responsibilities

The CalNetAD Infrastructure is composed of many different computing, administrative and consulting services. This section provides a brief description of these services and specific contact information for each. In general, people who experience problems with a particular service should speak to their local CalNetAD administrator first. If the issue can’t be resolved, then the local administrator raise the issue to the appropriate support group.

The IST-CCS-SDA Systems Group installs and maintains the server and support machines which run Active Directory for the UC and CAMPUS domains. A group within IST-CCS serve as Enterprise Administrators (EA). They install, configure, and maintain the Active Directory domain controllers for the UC and CAMPUS domains that support the CalNetAD infrastructure. Urgent problems related to domain controllers or infrastructure services should be reported by calling the IST Trouble Desk at 642-4920. For general discussion, this group can be contacted via e-mail at calnetad-info.

The responsibilities of the Enterprise Administrators are:

• Install and maintain the Active Directory domain controllers in the UC and CAMPUS domains that support the CalNetAD infrastructure.
• CalNetAD Enterprise Administrators are currently on duty Monday-Friday, from 8 a.m. to 5 p.m.
• Manage the flow of information from the CalNet Directory to CalNetAD. The EA group also manages the replication of directory information within the Active Directory, and makes any enterprise level changes to the AD directory, such as schema modifications.
• Communicate all enterprise-wide changes to domain and OU administrators via the CalNetAD Change Management System. The CCMS serves as the primary vehicle for the notification, coordination, authorization, and archiving of notable changes. The CalNetAD Administrative Contact List of local administrators will also be used as an email communication tool.
• Have administrator privileges on all domain controllers and OUs, in order to support and maintain the infrastructure's domain controllers and directory services.
• Assume a "hands-off" approach to local domain and OU administration. The EA group is not responsible for the administration of local user accounts (other than providing shadow CalNet ID accounts). Only when faced with an enterprise-wide emergency, where no adequate alternative exists and every attempt has been made to contact appropriate support personnel and relevant managers first, will an Enterprise Administrator take action at the domain or OU level.

16. Local Administration Responsibilities

The responsibilities of local administrators are:

• Agree to the policies and guidelines for CalNetAD OU Administrators.
• Provide support for local users and services. In general, people who experience problems with a particular service should speak to their local CalNetAD administrator first. If the issue can't be resolved, then the local administrator can raise the issue to the appropriate central support group.
• The local administrator that requested the top-level CalNetAD OU for their unit will be the person responsible for designating which administrators will be added to this local administrative group account. Local OU administrators are required to maintain a mailing list for administrators who are active in their OU and provide the Enterprise Administrators with the name of the mailing list. Local OU administrator mailing lists will be added to the CalNetAD Administrator Contact List web page.
• Local OU administrators must keep themselves informed about domain-wide changes via the CalNetAD Change Management System.
• Local CalNetAD administrators must join and participate in the CalNetAD Planning Committee.
• The local CalNetAD administrator will designate which administrators have "account operator" access to the Windows user accounts for people in their department. These account operators will have privileges that let them make changes to a subset of attributes for the accounts in their OU. This subset of attributes includes Windows-centric information like home directory location, profile location, terminal server settings and other kinds of user data that isn't replicated from the CalNet Directory. Replicated user data such as account name (CalNetID), department, and affiliation -- and any future extensions of other personal data replicated to the Active Directory - are subject to being over-written by the CalNet Directory synchronization process. The authoritative CalNet Directory is the only place where these non-writable attributes can be changed, and then only by the user.
• Local administrators should make every effort to delete expired or unused user accounts in their OUs.