Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

UTM and Windows RADIUS certificate

I'm guessing this might be more of Windows-related question rather than an UTM question, but I'm not 100% sure of the authentication process when using a Windows RADIUS server (via NPS).

At our small office we obviously have a DC, but the name ends in "local". That is to say, any certificates I generate won't ever be validated by a public certification authority. At the moment, we don't even have a local certification authority (as it wasn't really needed up until now).

My main question is... who validates the certificate used by the NPS? Is it the final client (laptop / phone) when it tries to connect, or the UTM, or is it just used for the NPS-DC connection?

In the first case, if I install and use a local CA to generate a certificate for the RADIUS server, I'm guessing all WiFi clients will get errors / warnings about not trusting the certificate, won't they?



This thread was automatically locked due to age.
Parents
  • Hey Mateusz.

    I take from your question that you are using Sophos Access Points managed by UTM and creating a WPA2-Enterprise authenticated SSID, right?

    The client needs to trust the NPS server certificate, the UTM will basically proxy the requests. You say you have a DC, so this makes things easier. Setup an enterprise Windows Certificate infrastructure, which will automatically propagate the enterprise CA to the domain clients, and every certificate you generate on this enterprise CA, including the one you'll use on your NPS server, will be trusted by the clients that are member of the domain. The same happens the other way around: your client certificates, which will be generated by the enterprise CA, will be trusted by the NPS server. 

    Here is a good starting point that's very rich on the Windows certificate/NPs stuff. For the Sophos UTM part, this one is a good read.

    I hope this helps.

    Regards,

    Giovani

  • What about clients which aren't connected to the DC? I assume these will get some kind of warning or error that the certificate isn't trusted?

  • Yes and no. Ir order to connect to such a secure wifi the client would also need a certificate, and when you upload a certificate you usually upload the correspondent CA as well, so in such a case no warning would be generated. But I'm wondering why a client that does not belong to the domain would need to use such a secure connection. If the client is a member of the domain you can do all this through GPOs, so it's a feasible setup. It seems a awful lot of work to do all of this manually just to allow a connection to the wifi. There are ways, but no easy way. Would you care to elaborate what you are trying to achieve?

    Regards,

    Giovani

  • To be perfectly honest I don't have any particular plan in mind. We managed to get our hands on a Sophos AP (currently for testing purposes, but we will likely end up actually buying one), and I was looking into how things work, including RADIUS - because "why not check it out"...

    I've never had the chance to work with WPA Enterprise WiFi before and I was under the impression this is "regular" WPA, but each user has their own credentials and as such, connections can be easily managed later on (if needed). Given this, I had no idea certificates play such a large role.

    As such, I was under the impression a user can come in with their DC-authenticated laptop as well as, say, their mobile phone or personal laptop, and can connect all these devices using their AD credentials. Now, given that a certificate trusted by the client is needed, the DC-laptop would work fine (given that the certificate can be easily published using a policy), but I'm not sure about the latter cases.

    In general, this isn't a big deal - as stated, I'm doing this more out of curiosity than any actual need. Still, I'd like to know how these things work. The idea that each user has their own credential to the WiFi (which is their AD login / pass) is, in the end, an enticing prospect, as it means I'll likely stop getting "what was the WiFi password again" questions. ;)

  • Oh, OK, I get it. You can do all of that using only only PEAP-EAP-MSCHAPv2 if you want to keep things simple. That way only the server needs a certificate and devices will only need an AD credential to connect. Devices that do not trust the server's certificate will usually show a warning that the certificate is not trusted but will allow the connection.

    But bare in mind this is fairly less secure and that there are footprints to an attack. It's a trade off: simplicity or security.

    Regards,

    Giovani 

  • Well, out of curiosity I managed to get this working. Installing a CA for our domain seemed like something that should have happened anyway, so there's that. My biggest issue afterwards was that the certificate generated for the NPS didn't work for some reason (NPS was on a different server than the CA) - in the end it turned out that the default NPS certificate template used by the CA doesn't register the generated certificates with AD. Once I changed the template it started to work and I'm happy with the way it is now. :)

Reply
  • Well, out of curiosity I managed to get this working. Installing a CA for our domain seemed like something that should have happened anyway, so there's that. My biggest issue afterwards was that the certificate generated for the NPS didn't work for some reason (NPS was on a different server than the CA) - in the end it turned out that the default NPS certificate template used by the CA doesn't register the generated certificates with AD. Once I changed the template it started to work and I'm happy with the way it is now. :)

Children
No Data
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?