Pages

▼

Thursday, September 29, 2011

Cisco H-REAP Local Authentication Improvements

A while back I wrote about Cisco H-REAP, how it works, and some considerations and feature limitations.

As a follow-up, I'd like to briefly cover some recent changes in how H-REAP access points perform client authentication, specifically with the H-REAP Local Authentication features since this topic is confusing for most engineers (in-part because of the name).

H-REAP Local Authentication in code version 7.0.116.0 encompasses three distinct options for authentication of clients when "connected" to a WLC or "standalone".

Backup RADIUS Servers (AP as NAS)
This is the long-standing H-REAP feature that allows the AP to source RADIUS authentication to external 'backup' RADIUS servers when in standalone mode and the WLC in unreachable. In this scenario, the AP is the authenticator which forwards requests to the authentication server (RADIUS server). The authentication server must have the APs defined as a NAS.

This permits the APs to accept new clients and successfully complete authentication without reliance on the WLC. This is really a high availability feature for the WLAN to prevent an outage if one or multiple controllers fail.

Define the H-REAP backup RADIUS servers from the H-REAP Group:

H-REAP Backup RADIUS Servers


Update - Based on feedback in the comments, it should be pointed out that the AP and RADIUS server must use the same shared secret as configured on the wireless LAN controller. The AP inherits the RADIUS server definition and configuration from the controller, and it cannot be configured separately. This applies to both AP as a NAS situations.

Local Authentication (AP as RADIUS)
This feature allows the H-REAP access point to assume the role of both the authenticator and the authentication server (RADIUS server). The AP is required to have local users defined and only support a few EAP types, notably EAP-FAST and LEAP.

This feature is what most engineers describe this feature as meaning, without knowledge of the 3rd option below. Having locally defined users and restricted EAP types makes this option not all that attractive for most organizations, but there are some who have obviously requested it from Cisco. It beats static pre-shared keys for security, but creates administrative burden on network administrators to define and manage local users on the H-REAP APs.

Many organizations already have user accounts stored in corporate directory systems such as Active Directory, and definition of users in an alternate database is not preferred or allowed. That said, this feature doesn't make a lot of sense for user accounts tied to real people since corporate security policies usually dictate that passwords are rotated regularly and support personnel don't have access to those passwords, preventing them from being replicated on H-REAP APs. However, it may make sense for non-user IDs attached to embedded devices such as IP phones, Vocera badges, or handheld scanners.

Enable H-REAP Local Authentication (AP as RADIUS) in the H-REAP Group:

Enable H-REAP Local Authentication by the AP

Additionally, define local users and configure EAP-FAST and LEAP:

H-REAP Local Auth User Definition

Local Authentication (AP as NAS)
Historically, when the H-REAP AP was connected to a WLC, all authentication flowed through the controller. In code version 7.0.116.0 this changed. Now administrators can configure H-REAP APs to source client authentication and bypass the WLC, even in connected mode. This is beneficial when the AP is logically closer to the RADIUS server than the WLC and should source authentication itself to improve performance. A remote site that contains both H-REAP APs and a RADIUS server, with a centralized controller across the WAN is one example.

Enable H-REAP Local Authentication (AP as NAS) in each WLAN:

Enable H-REAP Local Authentication in the WLAN

When this option is enabled, the AP sends client authentication requests to servers in this order:
  1. WLAN AAA Servers
  2. H-REAP Group Backup RADIUS Servers (primary/secondary)
  3. AP Local Authentication (local users on the AP)
One other quick note is that the H-REAP APs also support RADIUS fallback. So if a primary RADIUS server fails and subsequently comes back online, the AP will recognize this and begin sending client authentications back to the preferred server.

Hopefully this clarifies some of these new features that aid both high availability and performance.

Cheers,
Andrew
at

7 comments:

  1. Travis BughNovember 20, 2011 at 4:48 AM

    I have been putting H-REAP through the paces in my lab getting NPS, IAS, ACS and ISE up and going correctly with it. I immediately noticed something - when you enable local auth on the WLAN and put the access point in an HREAP group; the accounting port on the RADIUS configuration switches to port 1000. Although it doesn't effect the functionality of the network per se, it does effect how you are tracking remote site clients via the RADIUS server, or any other log server for that matter. Have you noticed this as well? If you have - do you know a workaround that doesn't involve changing the port on the RADIUS server? Thanks for the nice article as well Andrew.

    ReplyDelete
  2. Andrew von NagyNovember 25, 2011 at 11:08 AM

    Hi Travis,
    I have not experienced what you describe. Can you provide additional details on what you are seeing? Does the WLC configuration change for the RADIUS accounting port, or are you seeing it in your server logs?

    I am not seeing the WLC configuration change on my equipment.

    Thanks,
    Andrew

    ReplyDelete
  3. DaveFebruary 15, 2012 at 3:28 PM

    This was a great read for someone working on locally switched H-REAP RADIUS authentication. A quick note which required a TAC case for me...when you add the local AP into the RADIUS server as a client, (mine was a Windows 2008R2 SU1) you need to make the shared key the same as the shared key for the WLC client entry. The APs get the shared key from the WLC and there is no place to enter that on the AP directly nor can it be blank.

    ReplyDelete
    Replies
    1. AnonymousMarch 26, 2012 at 10:08 AM

      Dave, thanks for sharing your experience. You probably saved us from having the same problem.

      Delete
    2. Andrew von NagyMarch 26, 2012 at 10:57 AM

      Good point Dave. Thanks for mentioning that, I seemed to have omitted that detail in my post. I'll add it into the article based on your feedback!

      Thanks,
      Andrew

      Delete
  4. AnonymousApril 26, 2012 at 1:05 AM

    Thanks for the good article. One question though.

    Under "Local Authentication (AP as NAS)", you mentioned that when "H-REAP Local Auth" is ticked, the authentication sequence is WLAN AAA Servers > H-REAP Group Backup RADIUS Servers (primary/secondary) > AP Local Authentication (local users on the AP). Can I know which documentation can I find this?

    From what I see from my logs, as long as "H-REAP Local Auth" is ticked, the AP will always perform the authentication, even if the WLC is up and reachable. This was verified from the ACS Logs. Please advice.

    ReplyDelete
  5. Andrew von NagyApril 27, 2012 at 11:09 AM

    I had to verify this operation through testing and asking Cisco directly. I couldn't find documentation on it.

    And yes, when "H-REAP Local Auth" is checked the AP always performs the authentication. That's what I meant by "AP as NAS". The AP inherits the RADIUS server configuration from the WLC and then uses it to perform authentication directly with the RADIUS servers itself. Make sure all of your H-REAP APs are added as NAS entries in the RADIUS servers.

    Cheers,
    Andrew

    ReplyDelete