Wireless Access

last person joined: 4 hours ago 

Access network design for branch, remote, outdoor and campus locations with Aruba access points, and mobility controllers.
Expand all | Collapse all

Different RADIUS servers for EAP-PEAP vs. EAP-TLS

  • 1.  Different RADIUS servers for EAP-PEAP vs. EAP-TLS

    Posted Jan 30, 2013 04:44 PM

    Does anyone know of a way within ArubaOS to pass authentication requests to different RADIUS servers based on the EAP type used? Assumptions are that all users are using the same 802.1X SSID and that no users have a domain/suffix/etc as part of their username.

     

    In other words:

    • if the user sends their username/password via EAP-PEAP authentication, send the RADIUS request packet to Server#1
    • if the user sends a certificate via EAP-TLS authentication, send the RADIUS request packet to Server#2.

     

    I'm thinking this is not possible, as the server delineation within AOS server-groups seems based on FQDN or auth-string only.

     

    If anyone has insight on this, I'd appreciate it!



  • 2.  RE: Different RADIUS servers for EAP-PEAP vs. EAP-TLS

    Posted Jan 30, 2013 04:52 PM

    You are correct.  There is no way to make a decision based on EAP Type in the controller.



  • 3.  RE: Different RADIUS servers for EAP-PEAP vs. EAP-TLS

    Posted Jan 30, 2013 05:12 PM

    You cannot do this in the controller.  You'd need to setup a RADIUS proxy server to be the intial point of contact for RADIUS clients (the controllers).   The proxy could then evaluate the request and pass it along to the appropriate RADIUS server based upon authentication type (or other conditions).

     

    You can also setup the RADIUS server to support both types of authentication (assuming it can access appropriate directories for both types of auth).



  • 4.  RE: Different RADIUS servers for EAP-PEAP vs. EAP-TLS

    Posted Jan 30, 2013 05:29 PM
    We have Microsoft IAS, and it doesn't seem it supports the needed attributes in order to determine EAP type. :-(


  • 5.  RE: Different RADIUS servers for EAP-PEAP vs. EAP-TLS

    Posted Jan 30, 2013 05:41 PM

    Did you want to put users in a different role, based on EAP Type or you wanted to have separate servers doing PEAP vs. TLS..?



  • 6.  RE: Different RADIUS servers for EAP-PEAP vs. EAP-TLS

    Posted Jan 30, 2013 06:21 PM
    The latter. Different servers.


  • 7.  RE: Different RADIUS servers for EAP-PEAP vs. EAP-TLS

    Posted Jan 30, 2013 07:03 PM

    This is nowhere near a complete solution, but if the usernames on your TLS certificates present themselves differently than your PEAP usernames, you can do this;  https://arubanetworkskb.secure.force.com/pkb/articles/HowTo/R-623

     

    For real PEAP/TLS differentiation of course, you would need a full-featured radius server...  If only we had one... ;)



  • 8.  RE: Different RADIUS servers for EAP-PEAP vs. EAP-TLS

    Posted Jan 30, 2013 07:10 PM

    IAS is limited in its forwarding conditions; NPS has some added capabilities around authenticaiton methods.

     

    can you give us a little more info on your setup....for example....

     

    The users who have certs; is there any commonality to the Subject name of the cert that might differentiate them from the other users?  Any domain names or anything?

    The two remote sources; are they both AD?  Different domains?

     



  • 9.  RE: Different RADIUS servers for EAP-PEAP vs. EAP-TLS

    Posted Jan 30, 2013 08:08 PM
    Colin, I know about ClearPass, and that is part of this. The idea is to have only a subset of users (my department) using CP for EAP-TLS and have the rest of the population continue to use IAS for EAP-PEAP.

    These users can associate from anywhere, so can't use geography (ap groups) to differentiate.
    Can't use arubaOS to differentiate between TLS/PEAP.
    Usernames are the same on PEAP and TLS so can't differentiate there.
    No domains are used, so can't separate based on realms.

    The point is to trial ClearPass without having all auth go through there. But, doesn't look like there's another option, given the requirement to continue having mobility for the TLS users.