365 Architecture

 

UConn’s transition to a cloud-based email system marks a significant move to improve email services for faculty and staff. In order to take full advantage of the increased availability and accessibility of the system, UITS is proposing the following architecture for the systems involved in delivering email:

365Architecture

Authentication Systems will remain onsite at Storrs. These servers (UConn Active Directory Domain Controllers) provide validation of a user’s identity and act as a gateway to use the Office 365 services. Although allowing Microsoft to provide authentication services provides more potential availability, there are risks with trusting a third party with authentication data, in this case NetID and passwords. The effect of this design is that users accessing Microsoft’s login page will be directed to a Storrs-hosted authentication system. Once successful authentication takes place, Microsoft’s Office 365 authorizes access to mailboxes and data within accounts. This functionality is achieved through Microsoft’s Active Directory Federation Service (ADFS). The recommended plan is to host 2 ADFS servers at Storrs.

The vulnerability of this design is that if UConn’s campus resources are unavailable then the Office 365 services will become inaccessible. Therefore, UITS is planning on building geographic diversity into the design by implementing authentication servers at a partner site (such as UCHC or BEST) or a cloud-based system (such as Azure or Amazon). At least one ADFS server should be planned for an offsite location.

Directory Services are provided by Microsoft. However, in order for Microsoft to provide meaningful and up-to-date data, we must provide data to integrate into the Office 365 director. Account information (username, phone number, department, etc.) are sent to Microsoft through a service named DirSync. As changes to local identities are made, DirSync will ensure the changes are reflected in Office 365.

Mail routing¬†will require some traditional services to be hosted at Storrs. SMTP services and the University’s Personal Name service will be hosted at Storrs. A major constraint driving this recommendation is that UConn email does not have a single destination – Student email is hosted at Google, and some University departments and units maintain dedicated email services. To ensure proper routing for these various systems all University mail will need to be routed through Storrs.
In order to build redundancy in to this system, SMTP services will be hosted offsite.

Hardware required to provide these services is expected to be 2 DirSync servers – 1 offsite and 1 onsite. In addition, DirSync requires MS SQL, so an additional server will be installed alongside of the DirSync servers. In addition to our existing SMTP infrastructure, 2 additional SMTP servers are planned to be installed in our offsite location. 2 ADFS servers will be provisioned, 1 onsite, 1 offsite. In total, the hardware required to run these services is approximately 10 CPU’s, 40 GB’s of memory, and under 1 Terabyte of storage total, including the off site servers.

In order to maximize diversity and availability of our onsite authentication systems and mail routing, Active Directory domain controllers and SMTP servers will be installed at the MSB and HBL data centers.

Ultimately, if this design is realized, the expected outcome of a Storrs-based power or service outage will result in a short amount of downtime as the offsite systems are moved into an active state.