UC Berkeley has extended the CalNet System to include integration with Microsoft Windows Active Directory (AD), bringing CalNet services for single sign-on and directory information to Windows computers on campus. AD is Microsoft's implementation of a unified directory service and authentication system for Windows-based computers. In many ways, AD is like CalNet itself, using many of the same technologies as CalNet to form a basis for the AD system. Because AD uses common standard technologies like LDAP3, DNS, and Kerberos 5, we are more easily able to integrate AD into the CalNet system and existing campus DNS infrastructure.
The CalNet Active Directory (CalNetAD) is a campus-wide service provided by IST-IS. There are no charges for the CalNetAD service. University departments typically participate by becoming an Organizational Unit (OU) within the CalNeAD forest. Since departmental system administrators are given full control of all objects within their OU, it is no longer necessary for departments to maintain their own Windows Domain infrastructure as a security boundary. This can lower a department's overall computing costs by reducing the staff time and equipment required to maintain Windows domain controllers. In CalNetAD, a department can maintain complete control and security over the computing services within its OU by using group policy Access Control Lists (ACLs) and security groups. Departmental system administrators can prevent access to sensitive departmental information by anyone without permission.
CalNetAD Forest Topology
PDC Emulator Infrastructure Master Relative ID Master Schema Master Domain Naming Master Global Catalog Network Time Protocol
PDC Emulator Infrastructure Master Relative ID MasterDomain Naming Master Global Catalog
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. Administrative Logons
The following administrative logons are maintained by IST-IS:
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 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.
Over 500,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 concept on how to assign user settings to students is through loopback processing more information can be found in this microsoft KB http://social.technet.microsoft.com/wiki/contents/articles/2548.windows-server-understand-user-group-policy-loopback-processing-mode.aspx.
OU administrators may create 'local' user accounts in their OU. Please refer to the CalNetAD Naming Standards page for policies to avoid name conflicts.
The domain password policy closely aligns its self with the Calnet system
The default domain password policy is as follows:
Minimum password length = 9Password history = 5 (number of times before a password can be reused)The password must meet the complexity requirements. (As listed at https://technet.microsoft.com/en-us/library/hh994562(v=ws.10).aspx)The lockout policy will lockout the account after 10 failed attempts in the last 15 minutes. The account will be locked out for 15 minutes.
Minimum password length = 9
Password history = 5 (number of times before a password can be reused)
The password must meet the complexity requirements.
(As listed at https://technet.microsoft.com/en-us/library/hh994562(v=ws.10).aspx)
The lockout policy will lockout the account after 10 failed attempts in the last 15 minutes.
The account will be locked out for 15 minutes.
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.
Integration with Campus 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).