Design Metrics

Active Directory Sizing Metrics

The table below is what was used to size and scale the number of domain controllers and AD database/GC size:

Estimated Active Directory Database Size

Disk capacity is not an issue - with a fully populated AD of 60,000 users and a global catalog approximately 500 MB, server configurations are more than enough to handle storage needs.

Recommended Domain Controller Configuration

DC Configuration (Child Domains and Domain Trees)

Security

Environment

IST-IS provides a highly-available, secure environment for its servers, with UPS, RAID storage, climate control, and multiple locations. This environment is monitored 24 hours a day, ensuring that Domain Controllers in the CalNetAD forest always available. IST-IS provides a physically secure environment for domain controllers, thus relieving departmental administrators of the responsibility to conduct security audits in this area. IST-IS maintains the Domain Controllers for the uc.berkeley.edu (UC) and campus.berkeley.edu (CAMPUS) domains. Physical security is a high priority for all Domain Controllers. All Domain Controllers should be locked in a secure, access controlled room. Please see Policies for CalNetAD Domain Administrators for additional information.

Administrative Logons

The following administrative logons are maintained by IST-IS:

• Enterprise Administrator
• Schema Administrator
• UC Domain Administrators
• CAMPUS Domain Administrators

The built-in accounts for these functions have been renamed and given strong passwords. Each CalNetAD administrator has their own administrative account for auditing purposes. CalNetAD Domain Administrators only use their administrative accounts for administrative purposes. They use their normal CalNetID user account for all other purposed.

Schema

Schema modifications must be approved and implemented by a Schema Administrator. 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.

Forest Group Policy Objects

The CalNetAD Forest Group Policy Objects (GPOs) page contains information and a link to configuration files for the forest GPOs that have been implemented.

User Accounts

Over 60,000 CalNetID user accounts are automatically synchronized in CalNetAD. This frees local administrators from having to perform these mundane account tasks for the CAlNetID single sign-on accounts. The CalNetAD Directory Integration: Using Metamerge Integrator and ADSI page offers more information on the integration process. OU administrators can request that the faculty, staff, and affiliate user accounts they administer be moved to their OU.

Student accounts are placed in a special, default Students OU container so that the user account information meets the campus FERPA guidelines and so they can be shared among campus units. The Assigning a Logon Script to Student Accounts page offers information on how to assign user settings to students through loopback processing.

OU administrators may create 'local' user accounts in their OU. Please refer to the CalNetAD Naming Standards page for policies to avoid name conflicts.

Member Machines

It is strongly recommended that workstations be upgraded to Windows 2000 or Windows XP before joining CalNetAD.

All member machines must be configured for Kerberos and NTLM V2. See the Kerberos Member Server and Workstation Setup and CalNetAD Configuration Files pages for more information.

Additional, general security guidelines for Windows 2000 are available at National Security Agency Security Recommendation Guides for Windows 2000.

DNS

The Domain Name System (DNS) protocol on the Berkeley Campus is provided by IST’s Communication and Network Services (CNS). CNS controls all campus DNS namespace. (See the Integration with Campus Services section below).

• IPSec is required for updates to the DDNS servers serving the forest. This may be implemented further to encompass more services.

• For domains in a separate tree, CNS must approve your namespace.

• A centrally-managed WINS server is not be provided for legacy clients. Department administrators may establish their own WINS server.

• DHCP is not allowed anywhere within the forest unless approved by CNS and enabled by a CalNetAD Enterprise Administrator.

• DDNS for clients is not supported and should be turned off (this is implemented via a domain-linked GPO). CNS handles all SRV records for the campus.

Integration with Campus Services

DNS Services

Support for the standard internet Domain Name System (DNS) protocol on the Berkeley Campus is provided by IST’s Communication and Network Services (CNS). CNS is charged with the ongoing maintenance of the campus network, its connection to offsite providers (Internet2 and the Commodity Internet), and the operation of its DNS servers. There are a few departmental exceptions with respect to DNS and overall network support, but because DNS is tightly linked with the functioning of a given network, the support of the network becomes more feasible when the DNS is controlled by the same group that supports the network. In addition, CNS has generally regarded the delegation of DNS services to individual departments, with few exceptions, to be unnecessary and counter-productive, and to significantly interfere with their support of the network and their ability to complete new network requests in a timely manner. CNS’s DNS operations are entirely UNIX-based. Because CNS has designed a highly-redundant "anycast" DNS system around a set of open-source UNIX-based software (BIND) tools, CNS will likely continue to provide all DNS services from UNIX platforms for the foreseeable future.

The Active Directory solution for advertising network services is to use the standard internet DNS protocol to provide a registry of its services and allow clients to access those services. Unfortunately this registry can get complicated and it is difficult to configure into a manual DNS service. Moreover, since the services and servers are subject to change, Active Directory has the potential to require significant ongoing support resources with respect to DNS.

Fortunately, there is a solution to this problem: Dynamic DNS (DDNS). DDNS allows a set of trusted servers to make automatic updates to specific records in a DNS zone. This greatly reduces the need for manual configuration, but it does introduce both security and policy issues. Allowing other servers to make changes to the berkeley.edu DNS address space can pose a significant security risk. In addition, the campus has a DOMAIN NAME SYSTEM (DNS) SERVICE POLICY regarding IP address and DNS name assignments.

CNS has implemented a DDNS service for campus Active Directory users, while taking reasonable security and policy precautions. CNS has integrated the DDNS service into its existing BIND-based DNS support model as efficiently as possible, while still maintaining adequate security. DDNS updates are not allowed in the top-level berkeley.edu zone, but rather, two separate subdomains are delegated for dynamic Active Directory use, 'uc.berkeley.edu' and 'campus.berkeley.edu'. In addition, only a certain set of servers, most notably the centrally-supported Active Directory Domain Controllers, are permitted to make SRV record updates to the two zones. Communications between Active Directory Domain Controllers and the BIND-based DDNS zone are secured via IPSec.

CalNet LDAP Services

Support for the standard internet CalNet Lightweight Directory Access Protocol (LDAP) service on the Berkeley Campus is provided by IST’s Infrastructure Services. LDAP provides a unified directory service that is capable of providing an extensible suite of information attributes about each member of the campus community. In addition to providing contact information, thereby making it easier to communicate with campus individuals, LDAP is also capable of providing authorization information. While authentication establishes and verifies the identity of a person seeking to access resources, authorization provides information as to which resources a given individual should be given access, given that his/her identity has already been established. This can be a key component to numerous applications on campus, including the central Active Directory service.

The CalNet LDAP service based on the Sun/Netscape iPlanet (v4.12) LDAP (v3) server running on a Sun server using the Solaris operating system. This service currently powers the web based directory lookup service, as well as a number of other services formerly provided by the Community Profile Dataset (CPD).

Basic user account information is synchronized nightly between the CalNet directory and Active Directory as detailed here. This means that local system administrators will be able to spend less time managing user identities and accounts.

References

• Designing and Implementing an Organizational Unit Structure

• Step-by-Step Guide to Understanding the Group Policy Feature Set

• How to delegate authority for editing a GPO

• Implementing registry-based Group Policy for Applications (Microsoft white paper)

• Answers to Frequently Asked Kerberos Questions

• Guide to Kerberos 5 (krb5 1.0) Interoperability

• Microsoft Research University IT Pro Community

• Microsoft Active Directory