Wandering Thoughts archives


Our internal network access authentication needs

We have a few pervasive internal networks; they're open for use by anyone in the department and are present more or less everywhere through the departmental space and sometimes beyond (for our wireless network). For reasons beyond the scope of this entry, we need to associate every device on these networks that we allow to talk to the world with someone who's taken responsibility for its presence. As a corollary of this, we need to block access off the network to devices that we don't have a responsible person for.

The person taking responsibility for the presence of a device on the network and talking to the world doesn't have to be the person actually using the device. For instance, if you have a guest who needs network connectivity, you can register their device for them (usually with our 'plug in and go' portal) and then hand it back for them to use. Some devices also want or need to have network connectivity without a person sitting in front of them; people have always-on desktops on one of these networks, for instance.

These networks are spread over multiple floors of multiple buildings, and many devices can roam from floor to floor and building to building. Because we do not have a big pipe of money, all of this needs to work with relatively basic switches and other infrastructure (including OpenBSD firewalls), and it cannot fall over (either blocking access entirely or opening up access widely) just because someone connects a little generic five-port switch in their office to get extra ports (on some occasions, we need to supply such little in-office switches). Some of this must happen over sections of infrastructure we don't provide or manage, and that won't support exotic measures (although that section does support WPA2-Enterprise).

The user experience for known and registered devices needs to be as close as possible to 'plug it in and it works' (some of these networks have had more complex access control methods in the past and people in the department were not enthused). This needs to be the experience on a wide variety of devices (both computers and mobile devices), and on common platforms it should just work without people needing to install additional software. Ideally they don't need to configure anything much. We don't have the capability to build and maintain software for all of the client devices we need to support (we've been down that road for something else).

We have a system to do all of this today (and have had for years), and we're happy with it. But the combination of all of these needs, constraints, and requirements means that we don't really have many alternates that we know of (and we'd like to have more options, for various reasons). Plus, the complexity of the whole situation probably means that any migration would be a big project and a pain for everyone involved.

(Our network access authentication needs may cause us problems with IPv6. I've written before about the specific, concrete issue we face today, but never written up our general needs that led to our present solutions.)

PS: We're aware that our current system is not completely secure and could be attacked in various ways. It's good enough for our specific situation.

sysadmin/OurNetworkAuthenticationNeeds written at 23:32:44; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.