Hello,
Thanks for the reply...
> On 4 Sep 2023, at 07:55, James Potter <[log in to unmask]> wrote:
>
> I've never had much luck with machine-then-user auth. There are a few issues I've found:
> - the user needs to get a certificate first. You could make ADCS visible from the VLAN the machine auth puts the device in, so the first login it does machine only auth, the user can then enrol for a cert (eventually), then next login the user will do machine then user auth
I think that's we're thinking and, I assume, how most people use machine auth: as a mechanism to provide basic access to the network to allow things like updates and policies to be pushed, as well as the user to logon.
I'm unclear what should be done on things like shared public machines but probably it just all happens automatically and we don't need to do anything special.
No one's mentioned TEAP here, but maybe I should. It seems a little new to me right now, though. Is anyone using it?
> - the radius auth is pretty stateless I think - I'm not sure how you'd differentiate a user auth on a trusted device (that has just done machine auth, now switching to user auth during login) and user auth on a BYOD device. Unless you can differentiate by certificate somehow (eg if cert issued by CA1 then its ADCS, if its CA2 then its BYOD).
I think one of the key parts here is we see managed devices and BYOD as being two separate problems to solve. We want both to work with eduroam but, with managed devices, we're going to deal with getting the device set up; with BYOD, we're expecting the user to use some sort of platform to create/sign a certificate and install it via an agent. This latter one probably would use its own CA that the RADIUS server would trust.
We certainly see a need to differentiate between these two devices (and between different devices which are managed, for that matter) as we might have a controlled Cyber Essentials zone the user is permitted into but only on certain managed devices. We don't want the same user putting their own tablet or unmanaged device into that zone just because the username is the same.
> - ADCS cert issuing can be slow/erratic
That's helpful to know -- certainly if we're querying AD upon each connection, we need it to be reliable and responsive (or, at least, have some sort of caching layer or sensible fallback).
For people using AD for group checking, do you find this is a problem or not? Maybe the answer is "just make sure your AD is well-specced"!
> There are alternatives to ADCS - openSSL, various open source options, I've used AWS KMS which appears to work well + is really cheap (~£1 per month per CA on a shared HSM, gets v expensive if you want a dedicated HSM though).
Certainly -- those could be explored and it's part of my question here. I think for BYOD "something else" is a good answer - CloudPath could be one such system.
We don't have an intrinsic hatred of Windows or any other platform: we really just want the one that is the smoothest experience for the user and for us (so we don't have to fight the operating system) so, if AD with a Windows client just smoothly works (and Macs, etc.) then I would go with it. We do have to think what to do with Linux clients, though (but then so do our Desktops team!).
- Bob
--
Robert Franklin <[log in to unmask]> / (+44 1223 7) 48479
University Information Services: Network Systems, University of Cambridge
########################################################################
To unsubscribe from the EDUROAM-UK list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=EDUROAM-UK&A=1
This message was issued to members of www.jiscmail.ac.uk/EDUROAM-UK, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
|