802.1X

802.1X – Enterprise WiFi for the University of Trier

In addition to running water and electricity, one could assume that Internet access has also become a basic requirement of our society. (Like: “Do you want something to drink? Do you need the Internet?”).

Here too, the possibilities range from maximum simplicity (public WiFi, everyone can connect and access everything) to maximum complexity (WiFi for connections per se open, but often access is only possible via a – in the worst case – proprietary VPN software). The latter is – for reasons not known to me – apparently the preferred option for a large number of universities. Although to be fair, the Cisco VPN, which is almost always used, can be seen as a standard rather than a proprietary solution. This solution is established, works and is relatively secure compared to open WiFis or WebAuth solutions. Only question: What if the end device does not support Cisco VPN? This is the case, for example, with small IoT devices or some smartphone solutions, and not every user is experienced or interested enough to deal with the special features of a VPN solution.

802.1X – a well defined standard

For years now (I don’t know exactly when, but the RFC document is dated September 2003) there has been a standard that offers quite comprehensive and almost everywhere supported authentication options: 802.1X is the official name, often called Enterprise WiFi.

Restructuring the University Network

As part of the restructuring work in the network of the University of Trier, we¬† now have decided that we should migrate from the VPN solution to 802.1X authentication. After some planning work and test setups, we have now decided on the following structure: Cisco AccessPoints, which are connected to a so-called Concentrator that controls both access and data traffic, serve as access points. The university’s central user directory is an Active Directory, so we had to connect Concentrator and Active Directory. Since the Concentrator did not offer a satisfactory direct integration for the Active Directory, we decided to add a FreeRadius installation (consisting of 2 servers in HA mode) in between. (Free)Radius is fully supported by the Concentrator appliance as a standard triple-A system (Authentication, Authorization and Accouting). The ntlm_auth tool provided with FreeRadius then offers a simple interface for authentication against the Active Directory.

We also implemented the connection to the Eduroam network during the conversion.

SwitchDB

The SwitchDB – a web based network management tool

My first project at the university, or rather the project for which I was originally hired, was the SwitchDB.

Requirements

The university’s network consists of over 200 switches, together with over 6,000 Ethernet ports. Each of these ports must be configured according to location and usage. Since there are different departments, each of which should have different authorizations. E. g. the representative of the IT department should only be able to configure the switches located there, but only with the VLANs belonging to the IT department – and not those of e. g. mathematics. There were also roles that should only enable/disable ports without changing any other settings, and also roles that should have global (or limited) read-only access. In short: The rights model was very extensive and complex and no known solution had the necessary functions at the start of the project to map this appropriately.

The idea: Developing the SwitchDB

Therefore the development of the SwitchDB was decided: A web-based tool written in PHP for managing the entire university network. A MySQL database served as data storage, the connection to the switches was implemented via SNMPv2 protocol.

How it works

Changes are transmitted directly to switches via SNMP, so that the success or possible errors in the configuration can be directly controlled. Extensive cronjobs scan the entire network at regular intervals in order to map the current state of the database. Later, time-based changes (for scheduled business events, for example) were implemented. The Neighbour Discovery Protocol also enabled newly connected switches to be automatically detected and integrated. A service for receiving SNMP traps even made it possible to react directly to events that have just occurred (e. g.”end device plugged in”,”switch rebooted”, etc.). The implemented rights management was able to control valid values for each property to be set per role as well as accesses that were exact down to the port.