Skip Ribbon Commands
Skip to main content
Sign In
Last modified at 6/6/2016 4:28 PM by Kevin Burney Windows System Admin

CalnetAD Design

 

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

 

Infrastructure Components

Domain Controllers

DCDomainRolesLocation
uc-pdc01.berkeley.edu [169.229.217.165]UC

PDC Emulator
Infrastructure Master
Relative ID Master
Schema Master
Domain Naming Master
Global Catalog
Network Time Protocol

 

Hearst
uc-pdc02.berkeley.edu [192.58.221.171UCGlobal CatalogSDSC
 uc-pdc03.berkeley.edu [169.229.217.168] UC Global CatalogSDSC

campus-pdc01.campus.berkeley.edu [169.229.217.164]

Campus

PDC Emulator
Infrastructure Master
Relative ID Master
Domain Naming Master
Global Catalog

Hearst
 campus-pdc02.campus.berkeley.edu [192.58.221.165]

 Campus

 

​Global Catalog​SDSC

campus-pdc03.campus.berkeley.edu

CAMPUS

Global Catalog

SDSC
campus-pdc04.campus.berkeley.edu [169.229.217.171]CAMPUS

Global Catalog

Hearst
campus-pdc05.campus.berkeley.edu [169.229.217.179]CAMPUSGlobal Catalog

Hearst

​HCS-AD-A.haas.uc.berkeley.edu [128.32.67.157]​HAAS​Global Catalog​HAAS
​HCS-AD-B.haas.uc.berkeley.edu [128.32.67.118]​HAAS​Global Catalog​HAAS
​HCS-AD-C.haas.uc.berkeley.edu [128.32.222.5]​HAAS​Global Catalog​HAAS
​HCS-AD-D.haas.uc.berkeley.edu [169.229.215.73]​HAAS​Global Catalog​HAAS
​HCS-AD-E.haas.uc.berkeley.edu [132.249.243.14]​HAAS​Global Catalog​SDSC

 

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

User Accounts

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

(https://net-auth.calnet.berkeley.edu/cgi-bin/krbcpw)

The default domain password policy is as follows:

 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.

 

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.

  • 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).

 

 Updated 6/6/2016