Welcome • Services • Getting Started • Support and Tools • Documentation  
 
 

Policies for CalNetAD Domain Administrators

Version 1.0

Updated: 08/06/2002

1. Joining as a Domain
    1.1 Child Domains
    1.2 Domain Controllers
    1.3 Domain Trusts and Migrations
    1.4 Domain Schema Changes
    1.5 Domain Security
    1.6 Backups
    1.7 DNS
2. Local Administration Responsibilities

1. 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. Domains are subject to the same policies as outlined in the document Policies for CalNetAD OU Administrators. However, joining as a domain requires agreement to the additional responsibilities and limitations listed below:

1.1 Child Domains

Creating subdomains, sometimes referred to as child domains, below your domain will not be allowed. Creating a hierarchy of OUs is an approved option.

1.2 Domain Controllers

  • At least two (2) Domain Controllers (DCs) are required for a domain. The domain controllers should be installed on appropriately configured, fault-tolerant server-class machines. For example, the central domains are on Dell 2550 servers with redundant power supplies, RAID and mirrored disks.
  • OS support for patches, fixes, upgrades, etc., are expected to be applied in a timely fashion to maintain forest security and OS consistency among domain controllers.
  • The DCs are expected to be in operation at all times except for scheduled maintenance. Shutdowns of DCs for any reason must be coordinated in advance with the CalNetAD Service.
  • Cleartext passwords are not allowed to be used for services that authenticate using standard user principals, in particular, CalNetID-based shadow principals.
  • Keep servers in a locked, access controlled room. Access should be limited and should be logged for auditing purposes.
  • Disable the removable media based boot option if available.
  • Remove removable media drives if not required or install a locking device.
  • The CPU case should be secured by a key stored safely away from the computer.
  • Refer to system documentation to implement a system BIOS password.
  • A Windows 2000 platform should be configured to prevent booting into other operating systems.
  • By default, Windows 2000 allows any program to access files on CD-ROM drives. In a highly secure, multi-user environment, only allow interactive users to access these devices.
  • By default, Windows 2000 allows any program to access files on floppy drives. In a highly secure, multi-user environment, only allow interactive users to access these devices.
  • By default, Windows 2000 autoruns any CDROM that is placed in the drive. This could allow executable content to be run without any access to the command prompt.

1.3 Domain Trusts and Migrations

Domain migrations should occur in a timely manner to reduce a prolonged security risk via the trust, and the trust relationship will not be allowed for an indefinite period of time.

1.4 Domain Schema Changes

The schema defines the potential objects and their associated attributes in Active Directory. Changes to the schema affect Active Directory across the entire CalNetAD forest. For this reason, all Domain administrators will be involved in the schema change authorization process. Schema changes will have to meet several requirements including privacy, appropriateness, and potential for conflict. Schema changes will first be implemented and tested in the test environment. After successful testing, normal change management procedures sill be followed to move the schema change into production. Changes to the production schema will only be implemented by IST during maintenance blocks following a prearranged notification with domain administrators.

1.5 Domain Security

Joining the CalNetAD forest requires an extra level of security. Domain administrators must take steps to establish and restrict access on their domain controllers and their local workstations in order to prevent security problems. The following precautionary measures must be implemented:

  • All volumes must use NTFS in order to achieve the highest level of security. Windows 2000 introduces NTFS Version 5, which provides disk quotas and file encryption in addition to the features of previous NTFS versions.
  • The "least privilege" principle should be used when deciding how to implement ACLs. In other words, grant permissions to those users that need to have access and then allow those users only the access levels they absolutely require.
  • The OS/2 and Posix subsystems in Windows 2000 can introduce security vulnerabilities to the operating system. Therefore, it is recommended that these subsystems be removed.
  • Data remanence relates to images of data remaining on a Windows 2000 platform after the data should no longer be available. This includes data left in the system page file and the recycle bin. Each of these areas could have sensitive data that is open to being read by unauthorized or malicious users.
  • Take steps to ensure that unauthorized hidden OU objects do not exist within the directory structure.
  • Okena Intrusion Detection Software software should be installed on Domain Controllers and coordinated with the CalNetAD Service Administrators.

The default permissions on a share give the Everyone group Full Control. As local administrator, you must explicitly edit security permissions on shared resources to limit share access. For shared resources, the following security precautions must be implemented:

  • Ensure that the Everyone group is not given permissions on any shares.
  • Use the Authenticated Users or Users groups in place of the Everyone group.
  • Give users and/or groups the minimum amount of permissions needed on a share.
  • To protect highly sensitive shares not for general use, hide shares by placing a $ after the share name when creating a share. Users can still connect to hidden shares, but must explicitly enter the full path to the share (i.e. the share will not be visible in Network Neighborhood).
  • Restrict the ability for anonymous logon users (also known as NULL session connections) to list account names and enumerate share names.

On Windows 2000 systems, auditing is not enabled by default, and audit policies are set on a per-system basis via the Security Configuration Tool Set and the Security Templates snap-in. The following file auditing measures must be implemented:

  • Because of the importance of the Security Event Log in recording unauthorized accesses to the system, control of it should be limited to a select few. It is recommended that an “Auditors” group be created and given Full Control permissions to that log. Only individuals without administrator duties should be members of this group. This group should be given the User Right to “Manage auditing and security log” and the Administrators group should be removed from that right.
  • Auditing can consume a large amount of processor time and disk space. It is highly recommended that local administrators/auditors check, save, and clear audit logs daily/weekly to reduce the chances of system degradation or save audit logs to a separate machine. It is also recommended that logs be kept on a separate partition

1.6 Backups

Domain administrators are responsible for safeguarding the data on their domain controllers by periodically backing up the data and state information on the DCs to some alternate media so that the DC can be restored in the event of software problems, hardware malfunctions, or disaster situations. The following procedures must be implemented:

  • It is critical to perform regular backups of the operating system, application files, and user data. Back up privileges should be limited to Administrators and Backup operators.
  • Backup operators are able to read and write to any file in the system, regardless of the rights assigned to it. Backup and restore rights permit users to circumvent the file access restrictions present on Windows NTFS disk drives for the purpose of backup and restore.
  • Users who have the right to backup and restore files and directories can gain access to sensitive files, even though file permissions may normally prevent them from doing so, by restoring them to a different location. Auditing the use of this user right gives security administrators the ability to identify suspicious file activity that may be outside of normal backup duties.
  • The Emergency Repair Disk (ERD) feature helps you repair problems with system files, your startup environment, and the partition boot sector on your boot volume.
  • Store the ERD in a safe and secure place. It contains system security information that may be vulnerable to cracking.

1.7 DNS

A fully qualified domain name (FQDN) consists of a hostname and a DNS domain suffix, including top-level DNS domain. For example, machinename.uc.berkeley.edu is a fully qualified DNS domain name: "machinename" is the hostname and "uc.berkeley.edu" is the domain suffix. CalNetAD domains require a FQDN to support LDAP, Kerberos, PKI certificates, and other new technologies which are now integrated within the FQDN of the Windows domain. A CalNetAD domain cannot use "berkeley.edu" as its root domain suffix, because there would be collision with existing infrastructure services. Because of this requirement, the CalNetAD forest has the DNS subdomains "uc.berkeley.edu" and "campus.berkeley.edu" for domain controllers. Only domain controllers have this requirement. All workstations should keep "berkeley.edu" or other existing domain suffixes as their primary domain suffix. Use the existing DNS names (if legal Windows names). The hostname component of the FQDN becomes the legacy short-name alias.

  • Windows DNS Services must NOT be installed on any system within the CalNetAD forest without prior consultation with IST-CNS and the CalNetAD Enterprise Administrators.
  • Workstations in the forest must be configured to turn off DDNS registration. This is enforced by a site GPO which should not be blocked.
  • All workstations must have 'berkeley.edu' as their primary DNS suffix name and must be registered properly in the campus DNS.
  • All workstations must have a DNS name that matches their registered campus DNS name.

2. Local Administration Responsibilities

In general, people who experience problems with a particular service should speak to their local Windows administrator first. If the issue can’t be resolved, then the local administrator raise the issue to the appropriate support group.

  • Local domain administrators are responsible for communicating domain-wide changes to the OU administrators in their domain via the CalNetAD Change Management System. Every CalNetAD domain has a corresponding domain in the CalNetAD Change Management System to facilitate this practice.
  • Local domain administrators are encouraged to document their domain architecture (i.e. OUs, policies, etc.), as well as their administrative policies. Domain administrators should also develop and document naming policies for local accounts.
 
Contact Us