none
Considerations for 802.1x Port Based and Wi-Fi Certificate Authentication

    Question

  • Lately, we have been going back and for with the thought of doing certificate authentication for Wi-Fi and Port. We have Server 2012 PKI and CA and it seems fairly straight forward to pump out a certificate to a user and have them authenticate with their certificate to a RADIUS/NPS. However, every time I mention our thoughts with consultants or others they seem to cringe saying that they've seen this deployment cripple networks.

    We have almost 50 branch retail locations (with hub-spoke topology - all have VPN tunnels to corporate and also a disaster recovery location) and their internet isn't always super stable and they absolutely need to have network access at all times because they are running Point Of Sale. Right now, if their internet fails, they can remain functional because we have the necessary pieces at all locations to keep a Windows network going but I'm afraid that if we force 802.1x certificate authentication for the switch ports and Wi-Fi that if their internet goes down, they won't be able to authenticate since the authentication server will be at corporate. I am curious as to how people deal with:

    1. Fail over to a disaster recovery authentication server if Corporate connection goes down

    and:

    2. If internet fails locally and can no longer communicate with any authentication server. Is there some sort of scale-out? It seems complicated since (if I'm not mistaken) it needs access to the CRL to validate certificates and also a Network Policy Server for the authentication and so on.

    What we're really trying to accomplish is to prevent people from bringing in a laptop or device with an Ethernet port and removing an existing device and plugging into the port in its place. MAC filtering doesn't seem like a good solution on a large scale, nor a super secure option so it seemed like 802.1x certificate seemed to be the most flexible without having to go full NAP/NAC. Anyhow, sorry for the lengthy post and I really appreciate your time in advance!

    Monday, July 28, 2014 1:55 PM

All replies

  • Have you considered using PEAP-MS-CHAP-v2 instead of EAP-TLS? In this case only the NPS server would need a certificate so deployment is a simpler. In case clients use certificates (EAP-TLS) the radius server needs to check CRLs (although you could on principle turn this off).

    If you only allow computers to authenticate any device needs to be member of the domain - which can be a disadvantage compared to certificates that could also be distributed to most devices. Given the fact that also machine certificates are only "hacker-proof" if you use the TPM chip I would consider PEAP as secure as EAP-TLs.

    A malicous employee would have to manage to extract Kerberos secrets or system state or the like from a domain machine.

    The remaining issue though is RADIUS / NPS placement. You could configure switches with a set of RADIUS servers but there is no fallback like "use any domain controller anywhere in the network".



    Monday, July 28, 2014 3:26 PM
  • Never thought about that for port based authentication but we did consider it at some time for wireless. What we ran up against is the fact that our users have bad habits of sharing passwords with each other so they could give each other Wi-Fi access on their mobile devices (it's a bit more challenging to share certificates)... I suppose it may be worth pursuing to have machine authentication rather than machine certificates? Would that work through AD authentication (such as local domain controllers) without needing to traverse the WAN in the case that the location's internet connection went down? Thanks!
    Monday, July 28, 2014 4:59 PM
  • Yes - I meant machine authentication by machine accounts and passwords: A Network Policy containing only a group containing machines, and PEAP-MS-CHAPv2 as authentication method.

    Per default a Windows client would try to authentication as a machine and then as user - but if you allow user authentication, too, you have exactly this issue of users being able to type in their AD passwords. You would also configure the machines to authenticate as computers only per GPO.

    The most straight-forward architecture is probably to use local DCs that also host local NPS radius servers... and configuring each access point with all local radius servers / DCs. In this case there should not be more authentication as you would have today if users and machines authenticate "directly" (without 802.1x) against the same local DCs.

    Monday, July 28, 2014 5:57 PM
  • That sounds like the only solution to go with considering our topology and business requirements. I'll play around with using PEAP-MS-CHAP machine authentication and make sure that they can authenticate locally if their WAN link goes down. However, I'll probably have to stick user certificate authentication for Wi-Fi access which unfortunately requires connection to at least the CRL (unless I disable it like you said). In the case that a machine has already authenticated with its certificate, what are the intervals in which it needs to re-authenticate for port or Wi-Fi certificate authentication? For example, we have a few machines at each location that connect though Wi-Fi. If they have authenticated against the corporate NPS and then mid day their internet goes down, I'm assuming that they wouldn't get immediately disconnected and would stay connected until some sort of interval passes when authentication is required once again? Thanks!
    Friday, August 1, 2014 8:22 PM
  • Re-authentication could be triggered by the NPS, the switch / AP or the client:

    NPS: There is a bunch of attributes to be configured in the Network Policy that determine the time a machine can remain connected such as Idle Timeout and Session Timeout. (When WEP was still common the session timeout had been used to enforce a change of the insecure key.) Otherwise, the machine should remain connected as far as NPS is concerned.

    Switch / AP: Depends on the configuration, e.g. re-authentication has to be triggered if the link went down. If a user plugs a cable or accidentally disable WLAN on his machine when the internet link he will not be able to reconnect.

    Then I have seen some options similar to the NPS options, and switches could have their own session timeouts or be configured for respecting the radius server's setting.

    Client: The term "re-authentication" is also used happens if you have to / want to use both machine and user authentication: When the machine starts up, the machine account is authenticated; when the user logs on the user is authenticated; when the user logs off the machine is authenticated again. Per GPO you configure the machines for this kind of re-authentication (the default) or use machine-only or user-only authentication instead.

    It might be a challenge to manage and test these settings if you have to support many different APs / switches and different WLAN devices.

    I would recommend to carefully test it with a pilot group of users.

    Would you have any chance to turn off 802.1x on the switches / APs in case of a major outage? I guess not as you would be able to manage them remotely?

    Friday, August 1, 2014 9:15 PM
  • And one more comment on the CRL:

    I believe it makes more sense to disable a machine account in case a laptop gets stolen. In this case the machine will get blocked by NPS immediately - in contrast to using a CRL that is cached until its end of life (and if the validity period is too short you might get into troubles if if you have to fix an issue with the CA very quickly.)

    The only scenario that absolutely requires CRLs is if you use smartcards for users - as you cannot disable the user accounts.

    So if accessibility of the CRL is an issue you might consider disabling it. But if the NPS server is located in a central datacenter close the CRL server that should not be a problem (?)

    The clients don't check CRLs in 802.1x - as they don't have network access yet when they validate the NPS' certificate this would not make sense.

    Friday, August 1, 2014 9:21 PM
  • Very sound advice. I'll take some time to test this out according to the tips that you've given me. Thanks!
    Tuesday, August 5, 2014 5:18 PM
  • Not sure why I didn't think of this. That DOES make a lot more sense for machine authentication. I'll check this out. Thanks!
    Tuesday, August 5, 2014 5:27 PM
  • Hi,

    Do you have any updates?

    Best Regards,

    Amy

    Thursday, August 7, 2014 9:29 AM
    Moderator
  • Not as of yet. I am still trying to schedule a testing period for this scenario.
    Thursday, August 7, 2014 1:34 PM