Introduction 

Distributed organizations need the ability to fully delegate management of devices and personnel by organizational unit. Large higher education organizations tend to be highly decentralized.  Deans of colleges and department leaders control their own budgets, staffing, and resources.  While working within the framework of the whole organization, they need administration authority over the management and security of people and devices within their group. 

IT Environments in Higher Education

Higher Education organizations operate within three basic models across the United States:  

1. Centralized IT that runs/controls most, if not all, the technical environment for the campus.  This is most found in community colleges, small state universities and private colleges. 
2. Central Services with some independent IT departments within campus, focused on Research and other unique practices.  Larger State Universities tend to fall into this category. 
3. Highly Distributed IT.  Department and college operate as their own Operational Unit (OU).  OUs generally rely on a combination of centralized and OU computing resources. This situation is like a corporate environment where central IT operates the physical network and computing infrastructure components like e-mail, web services, directory services, DNS, DHCP, etc. The OU itself may handle a local file server, desktop support, software deployment, and/or some of the services that central IT provides. Each OU relies on a different number of central services based on their IT support resources and needs; a wealthy or well-staffed department may provide more services than its peer OUs. On some campuses, the central IT group provides more services to OUs including desktop and file server support. The model of two independent organizations providing complementary IT service is present on most campuses, although less common in smaller universities. Central and distributed IT services also exist between campuses within a multi-campus system (e.g. a state university system). Typically, multi-campus central IT services are limited and more likely to come in the form of IT planning or interoperability of campus-level central IT services (e.g. directory services interaction). Large R1 Universities and/or Universities with Academic Medical practices fall into this category. 

Academic Freedom impact to IT standardization.  

The primary duty of any academic institution is the education of its students, coming a close second to the pursuit of academic research. Institutes of higher education work to accommodate the needs of faculty in the pursuit of these goals, making academic freedom a priority in higher education. With academic freedom comes the right to employ technology in whatever way faculty and students find most appropriate. This results in the presence of a wide variety of software and platforms on a given campus. Another result of academic freedom is the potential for research partnerships between faculty and IT vendors that may lead to the use of their products within a department. This academic freedom also leads to outcomes where you may have multiple instances of a given technology to satisfy the need for academic freedom. As a result of the distributed IT environment and a desire to preserve academic freedom, there is little enforcement authority of IT standards or practices at an institution of higher education. The standards and practices a campus deploy depend on many factors which must incorporate both the department and central IT decision makers. Departments relying on minimal central services may employ very different technologies than others on campus. One strategy higher education central IT employs to deal with this IT diversity is to encourage open standards. Another strategy is to try to delegate control within a larger access management framework where possible.

Central IT infrastructure decision making

Central IT has a difficult role in this environment–having responsibility to provide broadly useful solutions, but facing a diversity of technologies deployed by individual operating units. This often means the central infrastructure and services provided are limited in number but can also mean that for a high need technology area, multiple solutions are provided centrally. For example, it is common for many email technologies to be provided centrally allowing the university customers to choose what works best for them.

When significant decisions or change to central IT infrastructure are required, a very common pattern is consensus building. A proposal will be drafted by a smaller team. This proposal is then socialized to an increasing number of individuals who are perceived to be stakeholders to refine and gain support. During this consensus building process, funding sources, delegation, and other recurring issues are often explored. For those proposals where sufficient consensus is gathered, central IT will launch a project to implement the proposal. An example of this consensus building process were present in the following:

• the central AD deployment at the UW in 2006
• decision to adopt both Google Apps and Office 365 as collaboration platforms at the UW in 2011-2013

There is an alternate common pattern behind some central IT infrastructure changes. In this pattern, an alternate competing solution is launched. Over some long period of time, the competing solution is increasingly adopted by customers to the point where it is painfully obvious that the older solution should be retired, and the newer solution labeled as the preferred infrastructure.

Diversity of Roles and Access

All campuses share at least three common classes of users: students, faculty, and staff. While all schools also have several other classes, these constitute the major groups leveraging computing resources. Each of these groups has specific characteristics that are generally common across higher education (distance education institutions may be outliers).

Students have a consistent, rapid annual turnover rate, are often affiliated with multiple academic departments (e.g. double major or major with a minor). They tend to be nomadic users of IT services, using multiple institutionally owned machines on campus and one or more personally owned computers. 

Faculty represent a smaller, but vocal, group of computer users. Faculty rely on technology for academic pursuits, including the creation and presentation of course material, conducting research, communication with students and colleagues, and administrative duties (though these are typically handled by staff). Unlike students, faculty often stay at a single institution for long periods of time but interact and collaborate with colleagues at other institutions.  Faculty may also be affiliated with multiple departments or research centers on their home campus or on other campuses. Professional researchers are frequently grouped with faculty due to their common status as professionals pursuing academic endeavors and their tendency to work under faculty members. Researchers typically have computing needs like faculty members but are even more likely to have funding from grants.    

Staff represent a group comparable in size to faculty, but with non-academic computing needs. They generally use technology for administrative purposes like communication, interfacing with administrative systems, scheduling, and accounting. In academic departments, staff support comes from the same service provider as for the faculty in their department. Non-academic departments (e.g. human resources or admissions) consist primarily of staff with few or no faculty. Such departments typically operate more like departments in the private sector, thus are more likely to have organized IT support. They may also operate or exercise decision-making control over key pieces of the campus IT infrastructure like the HR and student information databases.   

Other potential user classes at institutes of higher education include alumni, parents of students, affiliated research agencies or centers (e.g. National Renewable Energy Lab, Center for Policy Research in Education, or a university hospital), retirees, vendors and contractors, conference attendees, etc. Resources at public institutions, like libraries, are often available to the public as well. The wide variety of other “affiliates” can represent several logistical challenges to providing computing services, especially determining when access to resources should be removed.  

It is common to have users who occupy multiple roles or affiliations. Some examples include: a biology student working for the student union, a staff member working for both the admissions and financial aid departments, a professor with academic appointments to departments in two different institutions, or a physics researcher instructing an undergraduate math class. Users cannot be cleanly subdivided by a hierarchy or their roles at an institution, posing additional challenges to providing IT resources.   

Almost all universities track these common user classes. For scenarios where just that information is sufficient, they can grant access to IT services based on that information. But those scenarios are infrequent, with a variety of more complex groupings and intersectional constraints that require more fine-grain access management (e.g. all Staff & Faculty in the Biology department + any dual-appointment Biology faculty). Some universities track finer-grain user classes (e.g. Student Employee, Hospital Workforce, Medical Resident, Faculty Emeritus, Extension Student, Graduate Student, etc.) which broadens the centrally-provided ability to either grant the right set of identities access or scope delegated permissions more accurately, but in many cases, departments are left with adhoc access management groupings.  

Multi-dimension access control technologies are needed in this environment. For example, RBAC approaches which provide both a scoping function (grouping which resources are controlled) and a custom role (grouping some number of permissions) are ideal because the combination allows an appropriate level of delegation given the specific scenario that is present. These kinds of RBAC approaches still require building appropriate access groups, but they have the additional ability to address the reality that a university has many IT groups which must co-exist.

Microsoft cloud product design often leaves higher education stuck  

With Microsoft cloud-based products, lack of sufficient delegated management and only allowing a single instance per tenant are the most common blockers to higher education embracing these Microsoft products. Intune is a classic example. Intune allows only one instance per tenant, and there was no delegated management provided initially. At the most recently reviewed time, there are still significant questions about how to appropriately delegate Intune in higher education. It’s rare to find universities which have deployed Intune, and most have a minimum of the complicating factors noted. Other MS product examples with these issues include Defender for Endpoints and Defender for Cloud. One of Microsoft’s oldest cloud-based products, Azure Active Directory has insufficient delegation capabilities for one of higher education’s common scenarios—providing security groups for students in a given course which do not violate FERPA (or equivalent regulatory requirement), i.e., the ability to not show the membership of course groups to everyone in the Entra ID tenant. This means a large set of academic use cases are blocked. In contrast, this use case can be safely implemented with on-premises Active Directory.

There are other unfortunate Microsoft design trends which can present hurdles. These include education-specific license SKUs (e.g., Office 365 for Students), and poor integration from one Microsoft tool/product to another (e.g., if I delete a device in this product, why can’t it get removed everywhere?).  

While higher education historically has a long track record of adopting (or inventing) new IT technologies before any other sector (e.g., IMAP was invented at the UW, universities were the pilot group for Exchange Online, etc.), over the last 5 years higher education institutions trail their counterparts in other sectors in adopting new Microsoft products. The product design is a significant factor why this is the case.