UC Davis Active Directory/Unified Communications Design Whitepaper Adam Getchell, College of Agricultural & Environmental Sciences Executive Summary The budget crisis our University is in challenges us to simultaneously increase our efficiency while lowering our costs. The campus IT infrastructure can play a pivotal role in achieving these objectives. As such, a confluence of events (budget, aging infrastructure, rollout of a central Active Directory/Exchange system (uConnect) presents a once in a decade opportunity to replace aging systems with an infrastructure that serves the campus in the future, in a way that consolidates disparate silos and provides uniform, high-quality service to the students, faculty, and staff of UC Davis. We can no longer afford to run needlessly parallel systems (DNS, Kerberos, LDAP, email, calendaring, VoIP, etc.) based on different operating systems and platforms when uConnect, if implemented properly, has the potential to provide these services and more while eliminating the costs of running an entire duplicate infrastructure. Problem: UC Davis continues to operate in a distributed computing environment where each unit invests heavily on duplicate services that fail to integrate with each other. Furthermore, these aging systems were designed to solve the computing problems of the 20 th century and fail to take advantage of current computing trends, such as cloud computing, public key infrastructure, Voice-over-IP, and so forth, that can provide cost savings and enhanced services to our community. Furthermore, the staff of the current infrastructure are in the same silos as the systems they support. The costs of staffing and running these services and infrastructure as-is may exceed the costs of provisioning an updated and integrated infrastructure designed with current and future capabilities in mind. Solution: An IT Infrastructure for the entire campus that supports the goals of the Organizational Excellence initiative 1 should be constructed using the following principles: Full-featured services (easy to use for clients) Flexibility (allow room for clients to implement services not original to the design) Interoperability (support Windows, Mac, Linux) Stability/Security (follow best practices) At a minimum, the infrastructure should support the following services for the campus: A secure computing infrastructure o Reliable, integrated network services (Domain Name System, DHCP, etc.) o Secure account and password management (e.g. Kerberos)
34
Embed
UC Davis Active Directory Unified Communications Design Whitepaper
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UC Davis Active Directory/Unified Communications Design Whitepaper
Adam Getchell, College of Agricultural & Environmental Sciences
Executive Summary The budget crisis our University is in challenges us to simultaneously increase our efficiency while
lowering our costs. The campus IT infrastructure can play a pivotal role in achieving these objectives.
As such, a confluence of events (budget, aging infrastructure, rollout of a central Active
Directory/Exchange system (uConnect) presents a once in a decade opportunity to replace aging
systems with an infrastructure that serves the campus in the future, in a way that consolidates disparate
silos and provides uniform, high-quality service to the students, faculty, and staff of UC Davis. We can no
longer afford to run needlessly parallel systems (DNS, Kerberos, LDAP, email, calendaring, VoIP, etc.)
based on different operating systems and platforms when uConnect, if implemented properly, has the
potential to provide these services and more while eliminating the costs of running an entire duplicate
infrastructure.
Problem: UC Davis continues to operate in a distributed computing environment where each unit invests
heavily on duplicate services that fail to integrate with each other. Furthermore, these aging systems
were designed to solve the computing problems of the 20th century and fail to take advantage of current
computing trends, such as cloud computing, public key infrastructure, Voice-over-IP, and so forth, that
can provide cost savings and enhanced services to our community.
Furthermore, the staff of the current infrastructure are in the same silos as the systems they support.
The costs of staffing and running these services and infrastructure as-is may exceed the costs of
provisioning an updated and integrated infrastructure designed with current and future capabilities in
mind.
Solution: An IT Infrastructure for the entire campus that supports the goals of the Organizational
Excellence initiative1 should be constructed using the following principles:
Full-featured services (easy to use for clients)
Flexibility (allow room for clients to implement services not original to the design)
Interoperability (support Windows, Mac, Linux)
Stability/Security (follow best practices)
At a minimum, the infrastructure should support the following services for the campus:
A secure computing infrastructure
o Reliable, integrated network services (Domain Name System, DHCP, etc.)
o Secure account and password management (e.g. Kerberos)
o Public Key Infrastructure (e.g. SSL certificates for websites, digital certificates for email,
users, computers, etc.)
o An electronic directory of services that can be used to automatically discover new
systems and services (DDNS, web services, etc.)
o An electronic directory of people that can be used to automatically lookup attributes
and roles (e.g. email address, calendar availability, application role)
o Single-sign on to University resources such as email, Banner, DaFIS, Kuali, WhitePages,
web applications such as Timesheets and Recruitments, and partner applications such as
UCOP’s At Your Service using identity federation (e.g. Shibboleth)
o Accessibility to services from a wide variety of devices, including workstations, laptops,
mobile devices, and media consumption devices such as the iPad and tablet computers
Unified Communications
o Email
o Calendar
o Voice-over-IP telephony (with interoperability with other systems, e.g. Skype)
o Voicemail (available on email)
o Electronic FAX
o Instant Messaging (with interoperability with other systems, e.g. GoogleTalk, AIM)
o Audio/Video/Web-conferencing
o Electronic document management and collaboration (e.g. SharePoint) to make progress
towards the paperless office
Adherence of subscribers to the basic Cyber-Safety requirements
o Software patching and updates
o Anti-virus software
o Reduction of non-secure network services
o Robust authentication
o Protection of Personal Information
o Network firewalls
o Physical security for critical infrastructure
o Elimination of open mail relays
o Provision of secure off-campus access to electronic resources (e.g. Virtual Private
Networking)
o Auditing of critical infrastructure
o Disaster recovery for critical infrastructure
o Web Application Security
No solution can be complete without considering staffing. A federated approach, which combines the
efforts of folks in Information and Educational Technology with those IT staff in the colleges, schools,
departments, and organizations, would be the best option for UC Davis. The current collaboration of
ARM, CA&ES, and IET technical staff on the current uConnect project provides an example; such
collaborations should become the rule, rather than the exception. Strong collaborations and formal
working relationships between centralized units and local units allow the innovation, specialized
knowledge, and business needs of unit staff to be integrated into the operations of the critical
infrastructure balanced with best practices.
These services touch every aspect of business done at the university, and provide a platform for future
IT initiatives. The current state of the university requires that changes be made immediately to increases
efficiency. This proposed design is a significant step towards providing a common set of uniform tools
to enable productivity across all of the University’s functional domains for faculty, students, and staff.
Implementing this solution will result reduce duplicate services and save money.
Introduction
Audience
This paper is addressed to the executive decision makers, MSOs, managers, and technical staff in the UC
Davis community.
What this whitepaper is
As a whitepaper, it proposes a unified, best practices design for a campus-wide Active Directory and
Unified Communications system based on a set of principles. These principles provide guidance towards
providing a full-featured set of campus services that also provide a measure of cost-savings compared to
the existing campus technology infrastructure.
What this whitepaper is not
This whitepaper does not attempt to address comprehensively:
Total cost for client systems
Cost analysis for the large, central components of this architecture has been done elsewhere2; the
reader is encouraged to consult these and other references. Due to the nature of campus software
purchasing, and in particular the Microsoft Consolidated Campus Agreement, client software (e.g.
Client Access Licenses) have traditionally been purchased at the unit/department level3. Units have
always traditionally been able to opt into or out of such purchasing agreements, and alternative
models are not considered here. However, the campus as a whole will save the costs of purchasing
many server software components with the advent of the centralized system described in this
whitepaper.
This whitepaper is organized as follows:
Design describes the design of each of the major parts in the UC Davis Active Directory / Unified
Communications system. Many of these parts are interdependent, and require other services to
function properly.
Implementation identifies the critical path with the order of overall steps for dependent services.
Discussion recaptures the purpose of the changes in terms of services added, cost savings, and other
factors. It attempts to answer some of the questions that this project raises.
Glossary gives a brief description of the technical concepts discussed in this design. It may be skipped by
knowledgeable readers.
The Vision Consider the following use-cases that such a system might provide:
A student wishes to double major in another college. She goes online and fills out the change of major
petition and submits it to a web-based document management system using her UC Davis credentials.
The system notes that the student is an undergraduate; so it does not route them to the online
application for admission to a new graduate program, but goes instead to the Dean’s Office of the
originating college for approval. The counselor gets an email notification and logs into the document
management system to review the student’s records and other files. Noting that the student is in good
standing (on the Dean’s honor list) and on-track to graduate, he approves the request; it is then routed
to the new college (where it is checked automatically for fulfilled prerequisites), and finally to the
Registrars. Upon approval by the Registrar’s Office, the student receives an email that their change of
major has been granted, along with the contact information of the student’s new major advisor. The
student has also been automatically added to mailing lists for the department housing her new major.
A graduate student wishes to access the new compute cluster that his advisor has just recently
subscribed to. He goes to the cluster web page and fills out the access form online, which is routed to his
advisor for approval. In the background, the PI has a digital certificate associated with her email account,
so when she sends his approval the routing application can verify that she’s the originator of the
message as it goes to the help desk ticketing system for the cluster. The ticket system notes the approval
and emails the graduate student the directions for creating an SSH public/private keypair and uploading
the public key to the campus LDAP directory. After the graduate student does this, he replies to the help
desk email. The cluster admin reviews the ticket system, adds permission for the graduate student’s UC
Davis credentials to login to the cluster, and closes the ticket. Upon closure, the help desk ticket system
sends an email notifying the graduate student that he now has access to the cluster. He opens his SSH
client and logs in automatically using his Kerberos ID and SSH key.
A professor on sabbatical has a year-long adjunct appointment at a prestigious university overseas. She’s
working on a paper with collaborators back home, so she logs into the web front end of the document
management system using her UC Davis credentials, and notes that her collaborator has checked-in
changes to their paper. She compares the new changes with the previous version, and after annotating a
few comments decides a more in-depth discussion is required. She opens her email client and begins
composing a long message, but midway through her email client signals that her collaborator is online
and available to chat. They open an IM session, which becomes so productive that they decide to talk in
real-time using video and voice calling. Her collaborator wants to bring in one of his graduate students
working on a paper that illustrates one of his changes, so they invite him to the conference call and open
up an online whiteboard, where they discuss his paper with respect to hers.
These are just a sample of the possibilities that an integrated, robust IT architecture can provide to the
campus. So how do we get there while saving costs?
Design The principles behind a UC Davis Active Directory / Unified Communications system are:
Full-featured services
The services must be easy to use by the clients, requiring minimal technical configuration and time to
use.
Flexibility
While the infrastructure provides the basic services that most clients will need, it must also be flexible
enough so new features can be developed and added as needed. This approach allows room for clients
to implement services not original to the design.
Interoperability
The services should be usable across the broad range of computing platforms on campus, including
Windows, MacOS, Linux, and mobile devices. Equivalent support should be provided to a client,
regardless of choice of platform.
Stability/Security
Central systems should be reliable and dependable, with uptimes of greater than 99.9%. The systems
should be administered using industry-standard best practices, and systems security should be a top
priority. Excessive outages and security incidents hurt both the productivity and reputation of the
University.
Cost-effectiveness
The systems should be evaluated for fiscal efficiency and designed using commodity components
wherever possible. New trends in cloud computing, consumerization of IT, and mobile devices should be
evaluated with an eye towards delivering service efficiently at minimum possible cost, balanced against
the other stated principles.
The proposed design of a UC Davis Active Directory / Unified Communications system has many dynamic
components. These will be described below:
Active Directory
[Late-Breaking Note: The IT-Infrastructure Futures committee which convened May-October of 2011 to
discuss some of the suggestions in this paper, recommend that the campus pursue the Single-Forest
Single-Domain model. However, the following prescription is kept intact for discussion purposes, and
details of the Single-Forest Single-Domain model are examined below.]
The proposed model for the UC Davis Active Directory design is a single forest, multi-domain model with
the following features:
An empty root domain: to isolate critical Enterprise and Schema Administrators from all other
accounts
An account domain: to isolate user accounts from the domains that provide services, and allow
for easier scripting against a single account domain
A resource domain: to isolate services such as Exchange and Lync from member domain/OU
computers
A departmental domain?
These principles are based on the concept that a domain is a security boundary within Active Directory
intermediate between a forest and an organizational unit (OU). OUs may be a good fit for many units,
but provide less separation than domains.
Other models considered:
Multiple forests: A forest is a stronger security boundary than a domain. The tradeoff is that
services are more difficult to provision. Setting up Microsoft Lync across multiple forests
requires redundant Lync implementations for each forest4 and results in duplicated work for
Network Operations Center personnel.5 Network Authentication Control may not be workable if
hardware switches are unable to talk to multiple Network Policy Servers in different forests.
Single forest single domain: This is workable for large centralized organizations, but probably
does not mesh with the university culture. The advantage of this model is its simplicity. The
disadvantage is that there are no security boundaries protecting a unit from another rogue unit
in the domain, and it would be difficult to provision disparate security policies at the OU level. In
particular, each School/College/Organization may have different enforcement of Cyber-Safety
policies, as those decisions are delegated to the Deans and Vice-Chancellors. Finally, OUs have
disadvantages compared with domains, and some UC Davis units have already requested
separate domains. Removing this option might make the service less able to address client
needs.
The AD design as described offers some important features that specifically address the principles of
full-featured, interoperable, stable, secure, cost-effective service. As well, it enables custom
applications to be developed to address unit specific needs.
Examples of custom applications that have previously been developed but cannot be leveraged by
other units due to a lack of a flexible infrastructure are as follows:
CA&ES has developed an application which checks Banner for student enrollment, assigns
students enrolled in a particular class into an AD group, and then assigns that AD group to
the logon properties of particular computer labs. The result is that students enrolled in a
course can be automatically provisioned to have login privileges (which can be controlled by
day/time) to certain computers for a certain length of time (e.g. a quarter).
L&S has developed an application that imports/writes important administrative and
academic dates to user’s calendars to publish items such as Instruction beginning, Payroll
compute, University observed holidays, and so forth.
Integration between DavisMail (the student email system powered by Gmail) and uConnect can be
accomplished using SAML and the Google Apps APIs.6
Microsoft’s Live@Edu / Office 365 for Education service sets up federation between a user domain
(typically campus.ucdavis.edu) and the hosted services: Microsoft Office, SharePoint Online,
Exchange Online, and Lync Online.7 It allows for the possibility of going to a cloud-based service
offering on uConnect if that is deemed desirable.8
Many more applications and services of this nature are possible, and a structure which provides the
flexibility to write them should be provided.
To efficiently write such applications, user objects need to be in a central, well-known container (i.e.
the account domain) so that slow directory traversal calls are avoided.
Domain Name Service
Domain Name Service is a foundational piece of the internet. Many security issues are present which
require careful attention.9 Active Directory is based upon Dynamic DNS. Best practices with respect to
Active Directory and DNS are:
The DNS name of the forest is the DNS name of the organization (ucdavis.edu)10
DNSSEC should be implemented
DKIM should be implemented
The advantages for making the DNS name of the forest ucdavis.edu are:
A broad range of services register SRV records, including some that enable easier client
configuration, such as Autodiscover11 (which automatically connect Outlook clients to Exchange
mailboxes) and SIP (for Lync clients). Clients can automatically find these services via DNS query
Kerberos realm coincides with user logon name and the user principle name (UPN)
The Certificate Server (cf. Public Key Infrastructure) can be made authoritative for the
forest and all users therein
DNS names are so central to services populating Active Directory that one cannot do a DNS rename
operation once Exchange 2007, Exchange 2010, Microsoft Office Communications Server 2007R2, or
Microsoft Lync 2010 has been installed.12
The current uConnect root forest name is ad3.ucdavis.edu. As uConnect has Exchange 2010 and
OCS 2007R2 running, it cannot be renamed to ucdavis.edu. Therefore, a migration or some other
replication (e.g. forest-forest trust) must be done to get uConnect users into the new system.
Current migrations to uConnect, using automated tools have some tricky spots. This possibility was
noted when discussions first began on Xeda/uConnect implementation for the campus. However, given
the potential client base (~5,000 currently in uConnect versus several times that number for the campus
at large) and commitments that early adopters would be willing to tolerate disruptions for the benefit of
the campusi, the logical choice remains to continue forward with a design that benefits the entire
campus versus minimizing turmoil for early adopters. (Note that keeping the existing uConnect forest
sets up a multi-forest model, which is suboptimal (cf. Active Directory).)
To implement this change, the new Active Directory DNS servers will need to be brought up alongside
the existing Unix DNS servers. DNS zone transfers would be conducted to synchronize records between
Unix and Windows DNS, and the Infoblox tool (which is already compatible with AD13) would be
configured to write changes to Active Directory in addition to the existing Unix servers. Finally, after
sufficient use and confidence has been developed (incorporating input from Linux and MacOS users) the
Unix DNS servers would be turned off and the AD DNS servers would perform all DNS based functions.
Once this step was completed, the next exercise would be to configure AD DNS for DNSSEC, which is
straightforward.14 Units that wish to maintain their own DNS servers should be provided a mechanism to
register in DNSSEC.
Finally, DomainKeys Identified Mail should be implemented for Exchange. DKIM provides for a means of
cryptographically validating the domain name associated with an email; it allows organizations to
efficiently filter some types of spam email. It will be discussed in further detail below.
Dynamic Host Control Protocol
Campus DHCP services are currently provided by Infoblox. Some units still manually address and/or run
their own DHCP services.
Once the campus goes to IPv6, DHCP is not needed to assign addresses, as clients can automatically
configure their own IPv6 address without risk of collision (64-bits of the IPv6 address are assigned by the
clients themselves, which is twice the total count of IPv4 addresses possible in the Internet). However, it
is still useful to assign other information in DHCPv6, in particular, the IP addresses of the local DNS
servers.
Because services register with Active Directory’s Dynamic DNS servers, a DNS server becomes a catalog
of services that client computers can use to find applications, in the same way that the LDAP directory is
a catalog of people.
i Initial meetings with Xeda Steering Committee on 1/12/2010; many subsequent further discussions
Windows Vista clients and later include DHCPv6 clients, and Windows Server 2008 includes a DHCPv6
server and relay agent (used to relay DHCP messages from DHCP servers).15 A robust system of DHCP
servers scaled for campus will work together with Dynamic DNS servers to make campus applications
easy to find and use automatically by clients.
Kerberos
All faculty, students, and staff are eligible to obtain Kerberos accounts which authenticate to the central
campus Kerberos servers. A first step for using many applications developed on campus is obtaining a
Kerberos account.i
In turn, the campus has a user/password management system, more than two decades old, which
handles the provisioning and maintenance of client login accounts and passphrases to/from the
Kerberos servers to other systems needing this information. Finally, there are a variety of shadow
systems which takes direct dumps of user logins and password plain-text equivalents in order to
integrate their services with the existing Kerberos system.
The shortcomings of the existing system can be immediately addressed by taking advantage of the
Kerberos Key Distribution Center (KDC) built-into Windows AD Domain Controllers (DCs). The distributed
nature of Windows AD DCs provides reliability equal or superior to the existing system (e.g. there will be
more Windows DCs in the new system than there are Kerberos KDCs in the current system), and
Kerberos integration is automatically built-in to Active Directory clients, eliminating the necessity for
shadow systems.
Standard practice is to make the Kerberos realm the domain name.16 As this will be the case for the AD
forest ucdavis.edu, the mapping of hostnames onto Kerberos realms17 will be automatically handled
via DDNS, and AD clients will be able to automatically locate Kerberized services.18 Because Kerberized
services running elsewhere are not automatically viewable, services that are intended to be available
domain or forest-wide should use the Windows KDCs (which can be further assisted by using the
Subsystem for UNIX-based Applications in Windows Server 200819).
To implement this change, the Windows KDC would be populated with the accounts in the existing Unix
KDCs. This requires a passphrase reset, and has already been done on the uConnect DCs. It would be
done for the new Windows KDCs, avoiding the pitfalls that cropped up in the uConnect migrationii. After
sufficient use and confidence has been developed (incorporating input from Linux and MacOS users) the
Unix Kerberos servers would be turned off and the AD KDCs would perform all Kerberos login
authentications.
Active Directory Certificate Services, SSL, and Public Key Encryption
i Thanks to Megan Richmond for pointing this out. ii For example, small subsets of users were unable to login due to conflicts with previous uConnect account
information.
A Microsoft Certificate Server is a server acting as a Certificate Authority (CA) for the forest. Many
applications require a properly set-up CA.
A certificate is only as good as its chain of trust.20 The trust anchor for the digital certificate is the Root
CA.
The best practice setup for the campus CA isi:
1. Obtain an Intermediate CA certificate for the campus CA from a certificate authority such as
Verisign21 or InCommon (if they are capable of handling it)ii
2. The certificate server with the Intermediate CA certificate becomes the campus CA with a
complete Trust Chain
3. Templates are created on the campus CA to provision several Issuing CAs to perform certificate
server functions
4. The campus CA is taken offline, and optionally, locked in a safe. Because the campus CA has the
only Intermediate CA certificate, it is the only server which, if compromised, allows
impersonation of all certificates issued by the Issuing CAs for the ucdavis.edu domain.
5. The Issuing CAs perform all certificate requests
6. A separate web server/file server system is kept to store the revoke certificate list. Because
access to this system is required by the Issuing CAs before they will startup, this system should
be redundant
7. The campus CA is only ever brought online to define new templates for Issuing CAs or re-
authorize Issuing CAs when their certificates have expired (i.e. yearly)
A working example follows.
The campus CA, certroot.ucdavis.edu, has the Intermediate CA certificate for ucdavis.edu
(signed by a Root CA such as Verisign or InCommon) installed. It is now authoritative for
ucdavis.edu, and can issue digital certificates with the trust chain intact all the way to the Root CAs
(Verisign or InCommon).
Two issuing certificate servers, cert1.ucdavis.edu and cert2.ucdavis.edu, are brought
online and authorized by certroot.ucdavis.edu. Before they will successfully start, two
webservers, revokedcert1.ucdavis.edu and revokedcert2.ucdavis.edu, are also
brought online and setup with the revoked digital certificates list (initially empty).
Then certroot.ucdavis.edu is physically shut down (and locked away), and only revived to re-
authorize cert1.ucdavis.edu and cert2.ucdavis.edu when their authorizations expire
yearly.
i Special thanks go to Uwe Rossbach for sharing his research and experience on this topic. ii Experience with InCommon so far has shown some difficulties in getting SSL certificates properly issued;
InCommon seems to have marketing but limited technical support and no CA.
As revokedcert1.ucdavis.edu and revokedcert2.ucdavis.edu are up and running,
cert1.ucdavis.edu and cert2.ucdavis.edu readily startup and begin issuing digital
certificates for Exchange, Lync, VPN, and many other services.
The benefits of this system are:
The campus CA is protected from compromise
Microsoft Lync can be setup and installed
VPN and NAC/NAP can use user- or computer certificates to verify identities
Encrypting File System (EFS) can be turned on for all file servers in the campus Active Directory
Campus websites can easily request SSL certificates.
o Client web browsers with root CA certificates pre-loaded automatically fully trust
ucdavis.edu Secure Sockets Layer (SSL) websites with no additional work22
Clients can request certificates to use for email encryption.
Clients can request certificates to use for email digital signatures
o Applications can be written using workflow incorporated with digital signatures.23 A
purchasing application can be confident that an email from a buyer approving a
transaction is really from that buyer
Applications can make use of Code Signing.24 Code Signing uses digital signatures to prove the
authenticity of an application. Clients using that application can be confident of its origins
Lightweight Directory Access Protocol services
Currently, campus is provided with LDAP services integrated with a custom application which allows for
directory entries to be marked public or private, as desired. These entries are then published, subject to
these rules, on websites and used by other applications which need directory information.
LDAP is also provided by Active Directory, and is integrated into AD services in a way that a standalone
LDAP system is not, while still providing interoperabilityi with LDAP clients from multiple vendors.25 26 27
As an example, setting the “Manager” attribute in AD does several things:
In Outlook 2010, when viewing Calendars the “Team:” view automatically lists all subordinates
In Outlook 2010, the “To Manager” Quickstep automatically addresses the Manager
In SharePoint, workflow routing to supervisor makes use of the Manager attribute
The last point is significant because SharePoint contains the Windows Workflow engine, which allows
clients to create simple, graphical rules to route Microsoft Office documents amongst each other using
the built-in organizational chart that is present in AD using this attribute. Moreover, any .NET application
using Windows Workflow can also take advantage of this, as can any LDAP-aware application. An
effective, locally controlled enterprise-wide organizational chart is available just by using this property.
i A key issue is multi-value support, such as multiple addresses per user. Both Microsoft documentation and “in the field” reports indicate this is supported, see Endnotes.
Because many kinds of information can be added as additional attributes28 to LDAP, there are a variety
of additional applications29 which are opened up by the presence of an easily accessible directory of
people, the most important of which is authentication.
LDAP supports an extended operation called Password Modify.30 This, along with proper security
procedures (such as disallowing anonymous access to this and other key operations), allows LDAP to be
used as a replacement for the Central Authentication System (CAS). Note that LDAP is already being
used to handle wireless network authentication, i.e. MoobileNet/MoobileNetX.31
CAS is currently used on campus to authenticate web applications. It has a history of some instabilityi,
and moreover requires additional dedicated hardware to run in a robust, load-balanced manner. Using
the AD LDAP servers in the ucdavis.edu forest immediately provides stability and load-balancing, and
allows for CAS to be retired.
LDAP authentication is supported on a number of popular programming languages/web platforms:
.NET32 33
Java via the Java Authentication and Authorization Service34 and JaasLounge35
Cold Fusion 36
PHP 37
Perl 38
Python 39
Smartsite 40
Plone 41
Drupal 42
Hannon Hill Cascade Server 43
Atlassian Confluence 44
Oracle45 46
LDAP supports other authentication methods. Public keys can be distributed and authenticated using
LDAP.47 If a user has in their possession a USB key or hardware token with their private key, they will be
able to authenticate using SSH if the public key is published in LDAP. One use case would be for cluster
computing users; in clusters managed by Computational Science and Engineering, researchers gain
access to cluster resources (logins, batch queues, etc.) via SSH and public/private keypairs. Public-key
cryptography is robust authentication mechanism that is superior to passwords48; those services
wanting extra security would be able to use this if LDAP is correctly provisioned. As hardware tokens
become more prevalent (e.g. in smartcards) efforts would be made to support this more robust, two-
factor authentication scheme. Certain systems currently in use using hardware tokens could be migrated
to public-key cryptography.
To implement this change, a timetable should be published to the campus technical community
outlining the changeover schedule and resources available to convert existing web applications over to
i Last outage was August 18
th, 2010. Last unsuccessful upgrade was October 8
th, 2010.
LDAP or Shibboleth authentication (cf Single Sign On). Efforts should also be made to accurately
update the directory with business and other information, such as public keys and user password hashes
(LDAP stores a one-way hash of passwords to prevent compromise of the LDAP database from affecting
users49), that would be used for business process flow and authentication respectively. Value-added
projects, such as WhitePages, or applications that enable easy entry of business data, could be rewritten
to facilitate easy and accurate entry of useful directory information.
After an appropriate sunset period (no more than 2 years are recommended), CAS would be turned off
and the systems retired. Concurrently, as new services were developed based on LDAP (e.g. organization
charts, workflow, and public-key authentication) these would be released to the community along with
information on how to take advantage of these new services.
It’s worth noting that CAS can use AD/LDAP as an authentication backend.50 i Retiring CAS is not a
necessity, but it does save the infrastructure/staffing costs to run a system that is less redundant than
the backend services (LDAP) it is using.
Single Sign On
Integrating Kerberos, LDAP/Shibboleth authentication, and a public-key distribution system along with
Active Directory effectively gives users Single Sign On for services within UC Davis. Taking this a step
further to integrate with enterprise services outside of UC Davis, such as At Your Service51, involves
incorporating Shibboleth, an open-source implementation for federated identity-based authentication.52
Shibboleth 2 now incorporates interoperability with Microsoft Active Directory.53 Organizations such as
CampusEAI provide the myCampus Single Sign-On widget54 to allow users to sign into applications such
as Microsoft Exchange, Google Apps, Microsoft Live@EDU, Zimbra, Sakai and many others across
organizational boundaries one time. Regardless of which solution is chosen or developed, the existence
of these services should spur adoption of a solution as soon as feasible.
Exchange
Email and calendaring are fundamental to business operations, and should be properly resourced. What
are “proper resources”?
Exchange 2010 has raised the limit of items enumerable in a single folder to 100,00055, and reduced I/O
operations by nearly 70% with respect to Exchange 2007.56 Best practices for individual mail storage
are57:
Primary mailbox of not more than 10GB
Archive mailboxes of up to 10GB58 (as many as desired)
No use of offline personal archives (.PST)59
Based on these practices, a suggested pricing model for Exchange is:
i Thanks to Jeremy Philips for pointing this out.
Baseline usage mailbox for free (e.g. 2GB), to cover existing Cyrus users and units that find
Cyrus’ no cost and low capacity attractive
Additional mail costs not in excess of current hosted Exchange providers ($5/month/user60) 61 62
Archive mailboxes assessed at less cost than primary mailboxes
The traditional concern that large user mailboxes will make backup/recovery operations difficult is
resolved by Exchange 2010 SP1, which allows repair/recovery of individual mailboxes without taking
down the entire mailbox database.63
By making the Exchange mail service free for a certain level of service (and opening up Outlook Web
Access for web browser-based clients or IMAP/S for alternate clients such as Thunderbird; Apple’s
Mail/iCal/Address Book already ties directly to Exchange64), the current Cyrus mail users can be
migrated off of those aging systems and savings can be recouped from the staff and infrastructure
resources used to run Cyrus.
Once Cyrus users have been migrated, the rest of the campus can be moved onto the new mail system.
A proposed order of migration is listed in Implementation.
When everyone on campus has either a mailbox or a contact, the full capabilities of Exchange can be
used. Mailing list management can be moved to mail groups in Exchange. Web applications can be
developed (CA&ES, L&S, and the Law School have already written several) which leverage Exchange web
services to provide for automatic calendaring/appointments, automatic class list creation, room
scheduling, and so forth. These applications provide rich additional functionality.
Consideration should be made on whether it is worthwhile to retain mailing-list only systems such as
Sympa, which has a rich list of features65, but may or may not provide significant value-add compared to
developing applications from Exchange Web Services.66
DomainKeys Identified Mail
DKIM is actually independent of DNSSEC, but is included in this discussion because most
implementations of DKIM use DNSSEC. Several vendor solutions for DKIM on Exchange are present, such
as Axway67, which also provides a Spam filtering solution. Implementing a vendor DKIM solution such as
Axway would provide for greater email security as well as cost-savings associated with retiring the
current campus SpamAssassin system, which has some undesirable traitsi.
Microsoft Enterprise Voice ii
i Bulk-mail sent from reputable sources is almost always flagged as spam due to overly sensitive rules as currently configured on SpamAssassin. ii Special thanks go to Shuka Smith for sharing his research and experience on this topic.
The campus voice network is currently served by the Sonus network68, which provides service for
campus landlines, emergency services such as 911, and voicemail. There are also hooks for the Pinnacle
billing system, which is used by Communications Resources to bill phone use.
As of the release by Microsoft of Lync 2010 (formerly Office Communications Server), Lync provides the
capability to directly connect to a PSTN69, reducing the need for the Sonus network. In particular, the
current EVM system for electronic voice mail can be replaced by the transcription and storage
capabilities of Lync delivered to the Exchange mailbox, and it may prove simpler to use the built-in IP-
PBX capabilities of Lync.
uConnect is currently running Office Communications Server 2007 R2. There are three drawbacks of this
system, as implemented:70
1. The certificates used are self-signed (thus a broken trust chain )
2. OCS 2007 R2 does not have PSTN connectivity, and must rely on the Sonus cloud
3. The DNS SRV record for OCS on uConnect is _sip._tls.ad3.ucdavis.edu, which is not
discoverable by clients on the ucdavis.edu namespace.
The design proposed by this paper fixes the aforementioned three issues in the following ways:
1. Certificates are obtained from cert1.ucdavis.edu with a complete trust chain
2. Lync 2010, due 11/17/2010,71 is used, providing PSTN connectivity
3. The forest DNS name is ucdavis.edu, thus the SRV record is _sip._tls.ucdavis.edu,
discoverable by all clients on ucdavis.edu.
In addition, further cost-savings would be realized when Sonus is retired, as its duties are handled by
Lync.
Retiring Sonus would be a complex project, further complicated by the requirements of the Pinnacle
billing system. Analog phone service must continue to be provided until the last subscriber opts out.
Nonetheless, the way forward is to use existing and future telephony systems (including billing and
rates) based on software, SIP, and IP-based phones, and phase out older systems as soon as possible.
Document Management with SharePoint
Several document management systems already exist on campus, and document management itself can
be defined in many ways. Microsoft SharePoint 2010 provides the following capabilities72:
Accessibility, upon proper authentication, from anywhere with an Internet connection
Complete integration with Active Directory, Exchange, and Lync.
Complete integration with Microsoft Office (e.g. Word, Excel, PowerPoint, Outlook, OneNote,
Access) and Adobe PDF
Versioning, checkout, rating, and tagging for multi-user collaboration
Rule Based Submission (e.g. automatic movement of submitted documents to particular
libraries)
In Place Records Management for retention and eDiscovery
Metadata validation, indexing and management
Integration with cloud-based office suitesi
Ability to integrate with document-scanning solutions and manage electronic images of paper-
based information73 74
Ability to extend basic SharePoint functionality by programming custom web parts using
SharePoint Designer75 or .NET.76
By implementing SharePoint within the new uConnect architecture, campus units by default get a web-
based system with which to share and collaborate on documents which ties in with the rest of the
systems. For example, if Active Directory/LDAP is fully populated, SharePoint knows the supervisor and
other team members of a particular user, and a SharePoint workflow which automatically routes the
form to the supervisor can be easily built. The Presence and Availability of other people are visible in
SharePoint, so that people working on the same document can open an IM window or web/video
conference call to discuss their changes. Finally, SharePoint 2010 offers simultaneous editing of the
same file (coauthoring) and the ability to stream PowerPoint presentations over the web77, greatly
facilitating many common needs for faculty, students, and staff.
Implementation of SharePoint depends upon several items:
The Internet Connector license must be bought to allow access to SharePoint from the Internet
(estimated price, $4k)
Sufficient server and storage space must be allotted78 (typically 6-10 servers for a robust
SharePoint infrastructure plus storage for all the documents)
o If the SharePoint environment is virtualized, a number of considerations should be
addressed79
Campus subscribers to uConnect must have Enterprise CALs via MCCA
Units with a large investment in their current document management system might retain it based on
cost-benefit analysis. However, many other units will find the addition of an enterprise-wide document
sharing and collaboration system irresistible, and future web applications based on SharePoint could be
developed to provide targeted solutions to the business requirements of departments, colleges, schools
and units.ii
Cyber-Safety
i GoogleDocs, for example, as of now cannot handle complex formatting in Word documents with precise requirements, such as legal documents. However, Office Web Apps handles Office documents natively. ii In the absence of a central SharePoint solution, many units already in uConnect are working on their own
implementation, which gives an indication for potential popularity. In addition, UC Berkeley has CalShare, a SharePoint implementation. See: http://ist.berkeley.edu/services/is/calshare
Microsoft Office Communications Server 2007 Edge Server Deployment Guide, http://www.microsoft.com/downloads/en/details.aspx?FamilyId=ED45B74E-00C4-40D2-ABEE-216CE50F5AD2&displaylang=en 71
http://www.knowledgelake.com/solutions/technology-solutions/Pages/document-imaging-management-sharepoint.aspx as one example solution, others exist from Xerox 74