Security

last person joined: 12 hours ago 

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

L2 Fail Through Deep-Dive

This thread has been viewed 17 times
  • 1.  L2 Fail Through Deep-Dive

    Posted Jul 19, 2012 02:10 PM

    Hi fellow Airheads,

     

    my goal is to get authentication either via Machine-Auth or via MAC-Auth (for devices not having a machine-account in the AD).

    RADIUS is an ACS (version 5.x). MAC-auth is working ok, certificate-based machine auth against AD via ACS is working ok, certificate and credentials-based user auth against AD via ACS is working ok.

     

    Since the two sets of devices are strictly disjunct, becaus the machine either has a machine account in the AD or it doesn't,  I can also use Aruba's way of doing this, which works exactly the other way round.

     

    Set up a MAC auth profile with appropriate formatting parameters, 802.1x profile with enforced machine auth plus already setting the appropriate default role under machine auth: user ....

    Stitched all relevant profiles together in an AAA profile, set the appropriate initial role (=logon) default roles for MAC- and 802.1x-auth and also enabled L2 auth fail through.

     

    After enabling the debug logging for authmgr I can then see the following happening:

    controller sends correct MAC address as the username to the ACS, ACS successfully acknowledges the auth request, user get's the correct MAC-auth default role assigned - and then the controller doesn't stop, but also attempts machine auth.

    I then removed the enforce machine auth in the 802.1x profile (which on the other hand would be mandatory for all other authentications) and guess what, the controller then successfully passes through MAC-auth but afterwards tries to user-auth against it's (of course empty) internal db, even though the internal server isn't configured to be used in any of the profiles involved, fails the auth and then kicks my sorry butt out.

     

    To me this rather looks like L2 authentication FALL through, but what I would need instead is real L2 authentication FAIL through.

     

    To be precise I'd like to know how to exactly configure authentication case no. 3 in table 58, page 323, ArubaOS_6.1UG.pdf, with real mixed-mode auth, i.e. if mac-auth passes, associate with static wep and assign MAC-auth default role and stop authenticating, if MAC-auth doesn't pass continue with 802.1x-auth (as configured there).

     

    Controller is running on 6.1.3.2.

     

    Any hints, help, shared insights, discussions and insults highly welcome! ;)

     

     

    Best regards,

    Mike



  • 2.  RE: L2 Fail Through Deep-Dive

    Posted Jul 19, 2012 05:42 PM

    That chart in the guide is a bit misleading.   What encryption type is the SSID?  You mention certs, so can I assume WPA2-AES?   

     

    You can enable MAC-Auth and 802.1x Auth on the same AAA profile (to ensure the device passes both), however, the 802.1x role will be applied no matter what the MAC-Auth role is.   If you enable both and MAC-Auth fails, 802.1x will never take place.   Enabling L2 fail through allows it to continue despite MAC-Auth failure.   In any configuration with 802.1x enabled, the 802.1x roles will take preceence over the MAC-Auth role.

     

    If you are trying to do WPA2-AES AND WEP on the same SSID, I don't believe that type of mixed-mode is supported.

     

    If anyone from Aruba has more insight into the flow of that table, please chime in, but that is my impression of the authenticationw workflow.

     

     



  • 3.  RE: L2 Fail Through Deep-Dive

    Posted Jul 20, 2012 02:40 AM

    @clembo: this absolutely makes sense, thanks. *thumbsup

     

    The description "L2 Authentication Fail Through" is ambiguous. It's correct insofar, as it keeps on going to 802.1x-auth if MAC-auth fails. All other cases of "fail through" on the Aruba controller though refer to going on to the next in list if *and only if* the previous option fails.

     

    I think a whitepaper containing an in-depth description plus flowchart (as opposed to a simplified table) of the entire authentication process with all possible variants would definitely help a lot.