Security

last person joined: yesterday 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

Attempting to authenticate against lower priority RADIUS server

This thread has been viewed 2 times
  • 1.  Attempting to authenticate against lower priority RADIUS server

    Posted Jan 24, 2013 11:46 AM

    Hi All,

     

    I've got a client who are having intermittant authentication issues.

     

    They have 1 SSID using 802.1x auth against a couple of RADIUS servers. (lets say A and B)
    The 2 RADIUS servers are in different domains.

    The RADIUS server (named A) is at the top of the list in the server group and hold 99% of the userbase and the second (named B) the remaining 1%/

    Fail through is configured in the server group.

     

    Most of the time there are no issue however occaisonally users who have accounts on server A fail to authenticate, When I'm looking at the auth-tracebuf I can see that they're only attempting to authenticate against server B. It doesn't appear that server A is down when this occurs.

     

    OS version is 6.1.2.5.


    Any thoughts?



  • 2.  RE: Attempting to authenticate against lower priority RADIUS server

    Posted Jan 28, 2013 04:37 AM

    In the end I could see that "#show aaa authentication-server radius statistics" showed the radius server uptime was rarely up for longer than a few minutes.



  • 3.  RE: Attempting to authenticate against lower priority RADIUS server

    EMPLOYEE
    Posted Jan 28, 2013 06:18 AM

    Radius Fail Through requires EAP Termination on the controller, which means -- the controller needs a server certificate and termination needs to be enabled.  

     

    Please see my HUGE mistake in the thread here: http://community.arubanetworks.com/t5/Security-WIDS-WIPS-and-Aruba-ECS/Radius-Fail-through-and-802-1x-Machine-Authentication/td-p/12183 for details.

     

     

     



  • 4.  RE: Attempting to authenticate against lower priority RADIUS server

    Posted Jan 28, 2013 07:13 AM

    Thanks Colin. They're also using "Enforce Machine Authentication" so I'm looking into dynamic server selection as a solution.



  • 5.  RE: Attempting to authenticate against lower priority RADIUS server

    EMPLOYEE
    Posted Jan 28, 2013 07:17 AM

    @jrwhitehead wrote:

    Thanks Colin. They're also using "Enforce Machine Authentication" so I'm looking into dynamic server selection as a solution.


    jrwhitehead,

     

    Probably the best solution is CPPM (Clear Pass Policy Manager).  You can add both domains as authentication sources and do failthrough on CPPM without termination on the Aruba Controller.  You would just join CPPM to both domains.  Maybe an evaluation version would be a good POC?

     

     



  • 6.  RE: Attempting to authenticate against lower priority RADIUS server

    Posted Jan 28, 2013 07:22 AM

    Thanks again. :smileyhappy:

     

    I'll pass the info onto our account manager to see if they want to go for the best solution. 



  • 7.  RE: Attempting to authenticate against lower priority RADIUS server

    Posted Feb 22, 2013 11:56 AM

    I have sucessfully got dynamic server selection working (I'm happy to say) however my server derivation rules are not working when I have enforce machine authentication enabled.

     

    With machine auth enabled it appears that the server derivation rules are ignored. There are 2 rules which look at the user-name value and if it contains certain a string put the client in one VLAN or the other.

     

    Here's what it looks like when it;s sucessful in a snippet of the auth-tracebuf. Default VLAN is 304 and the VLAN for the client in this example is 354.

     

    Feb 22 16:37:01 assg-vlan-req * 00:1c:bf:9d:c7:b6 00:24:6c:14:e6:32 304 354 assignment during station auth
    Feb 22 16:37:01 assg-vlan-resp * 00:1c:bf:9d:c7:b6 00:24:6c:14:e6:32 - 354
    Feb 22 16:37:01 station-data-ready * 00:1c:bf:9d:c7:b6 00:00:00:00:00:00 304 354

     

    When enforce machine auth is enabled there are no assg-vlan-req or assg-vlan-resp where the client changes VLAN.

     

    Has anyone else seen this?

     

    Controllers are on version 6.1.2.5.

     



  • 8.  RE: Attempting to authenticate against lower priority RADIUS server

    Posted Feb 28, 2013 04:10 AM

    if 'enforce machine authentication' is enabled and during Machine Authentication or User Authentication without passing Machine Authentication, none of the server attributes are honored. Once Machine Authentication passes, a User gets the “Machine Authentication: Default Machine Role” and if User Authentication passes without Machine Authentication passing, a User gets “Machine Authentication: Default User Role”. As far as VLAN derivation is concerned for the above two cases, the only derivations possible are the Role Based VLANs from the above two roles.



  • 9.  RE: Attempting to authenticate against lower priority RADIUS server

    Posted Feb 28, 2013 04:33 AM

    Hi Giles,

     

    Thanks for the reply.

     

    That's a shame the server derivation rules aren't honored. 

     

    I'll briefly explain what I'm trying to do as I was really hoping this done with a single SSID and a sprinkle of "Aruba magic".

     

    1. We need to authenticate 2 user groups using 802.1x from 2 different domains.
    2. The 2 user groups need to be placed on different VLANs.
    3. Non-domain machines are not allowed to connect.

    Here's how I've attempted to accomplish this:

     

    1. Use a server groups which contains a RADIUS server from each doman and use dynamic server selection to authenticate the clients against their respective RADIUS server.
    2. Server derivation rules in the server group which look for a string in the user-name attribute and assign a VLAN based on this.
    3. Enforce machine authentication

    I'm happy to hear other solutions to this if anyone wants to chip in.. :smileyhappy:

     

    I'm sure clearpass or having 2 SSIDs will work just lovely for these requirements btw. :smileywink:

     

    Cheers

    James



  • 10.  RE: Attempting to authenticate against lower priority RADIUS server

    Posted Feb 28, 2013 03:57 PM

    hi jrwhitehead,

     

    dot1x-servergroup with SDR's to derive ROLE/ VLAN/ RBV's. you can make your radius servers return a unique string based on the user-groups (say Filter-id "123" for group1 or "456" for group2) from the access-policy , and use this as matching condition in SDR. or can directly return different VSAs based on each-group ( if you dont want to use SDR) from the RADIUS server.

     

     

    ex:

     

    string matches condition1 -- derive Role-x / vlan-x 

    string matches condition 2 -- derive Role-y / vlan-y

     

    consider valn-z is vap-vlan / vlan derived from UDR or MAC auth.

     

    possible scenarios :

     

    1. when client passes machine-auth (Intermittent state) , it will be placed in default-vlan( vlan z) from VAP / vlan derived from UDR's or Mac-auth (if configured) : but not with SDR's / VSA's / MSFT-attributes returned by RADIUS server during Machine-auth.

     

    2. When client passess both machine and user-auth + hits configured ServerDerivationRule / recieves VSA or MSFT from radius server : then client is placed in respective derived user-role / derived vlan (say vlan x or vlan y)

     

    3. When client fails Machine-auth + passess user-dot1x (and hits SDR / RADIUS server returned VSA / MSFT) : client is not honored with derived user-roles / derived-vlans from SDRs / VSAs or MSFT. instead client is placed in default machine-user-role (configured in dot1x profile) , and the vlan ( vlan z) which is either VAP-vlan / vlan-derived from UDR or Mac-auth (if configured) 

     

    So the vlan z should be restricted vlan ; and non-domain clients will be placed in these vlans (the clients which are failing machine-auth)

     

    And if you want to force the clients everytime to authenticate with particular-server in a server-group ; you can very well use match-fqdn option in the server-group.