AP Radius Proxy - Varying client VLAN's

  • 1
  • Question
  • Updated 4 years ago
  • Answered
Hi, we are a private school currently using Windows NPS 802.1x RADIUS authentication and it is working well. We have 2 NPS policies (staff and students) which assigns authenticated users to a particular VLAN based on group membership.

We are looking at moving to use one of our AP's as a RADIUS proxy seeing as we have hit the 50 client limit set on Win SRV 2008 R2 std.

My question is a bit of a double up...

Will the RADIUS proxy be able to forward the requests and replies for the NPS policies to assign the clients to the appropriate VLAN's? As the policy is expecting a request to be sent from a member of the 'student' or 'staff' domain group and not an AP device. Or is this proxying process transparent?

My other question is about certificates. In our current setup, the user will be prompted to accept the radius cert when connecting for the first time (95% OSX client base).
What is the impact to the certificate chaining when we introduce the AP as the RADIUS proxy?

Thanks in advance

Corey
Photo of Corey Kemp

Corey Kemp

  • 7 Posts
  • 0 Reply Likes

Posted 4 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Proxying is transparent, the RADIUS proxy just needs something to route on, and the certificates are handled only by the EAP-terminating RADIUS server so there is no impact there.

However, this is definitely not something I would do on an access layer device, such as an AP, due to the reliability issues it can cause.

Have you considered upgrading to Server 2012 R2 Standard? There is no such limit in that release.
FreeRADIUS under Linux would be an alternative.
(Edited)
Photo of Corey Kemp

Corey Kemp

  • 7 Posts
  • 0 Reply Likes
Hi Nick, thanks for the quick reply. Reliability is certainly a consideration for me... Its a nice little option but is it something I would like to rely on 100%?

Yes, migrating our NPS to one of our other Server 2012 Standard machines is another option (supports 2,147,483,647 IAS connections) - and likely the less configuration changes required. ANd would use a tried and tested auth method...
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
I would go down that route then. It is easy to export the configuration of NPS on the existing server to XML and then copy the file over and import it on to the new.

Then, just update the configuration of your NASes (APs and switches) as appropriate to use the IP address of the new RADIUS server.

You will also need to ensure that you import the digital certificate that you are using. Check the configuration of the TLS-based EAP type(s) that are in use to ensure that they are still using this.
(Edited)
Photo of David Simon

David Simon

  • 18 Posts
  • 1 Reply Like
Hi Corey,

you can define up to 4x APs as Radius Proxy Servers.
They will work in a failure scenario which you define in the AAA Client Settings.

Most customers are using for that APs on different Access switches.

The Radius Proxy function is a very common solution for exactly the 50x NAS Client limit on the NPS Server.

The attributes will be forwarded to the edge AP, so your VLAN mapping will work without problems.


Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
There other modes of failure though, such as:

1) The APs you have running as RADIUS proxies at times spiking at 100% CPU usage / running low or out of memory causing tangibly delayed/disrupted authentication in some deployments depending on features used, code version, bugs etc.

2) Accidentally pushing the complete config to the APs you have running as RADIUS proxies which makes them all reboot causing availability issues.

I would reiterate that this type of thing should only be done at the access layer, which is the edge of your network, as a last resort.
(Edited)
Photo of David Simon

David Simon

  • 18 Posts
  • 1 Reply Like
Normally when you push a complete config the other APs will also reboot.
Otherwise you are performing a selective rollout, which means you can care about which AP will be updated or not.

But anyway, everybody can have his own design.
It is only an advice, which works at hundreds of customers without problems.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Only the APs that you push a complete config to will reboot - it is easy to leave it set to complete by accident from a previous upload and restart just a few.

Agree it is unlikely to happen in practice that all proxies are unavailable at the same time while other APs are in service but RADIUS does not exhibit fail over that is seamless to clients, often you will see a failed or delayed authentication while it happens.

The fact that lots of people may do something doesn't make it a good idea, that's argumentum ad populum territory. It may be a good idea independently, but it logically has nothing to do with the number of people doing it.

I was just pointing out that I feel that it is a poor mans choice to use the APs as RADIUS servers in any capacity and there are better deployment choices that can normally be made. It is often done because it is 'easy', not because it is the best or right thing to do architecturally.
(Edited)
Photo of David Simon

David Simon

  • 18 Posts
  • 1 Reply Like
I agree, what everybody does needs not to be the best.

It seems that you have a very good knowledge how to migrate a Windows Server and how to design networks.
But not everybody is on the same level like you and also feels not comfortable when upgrading a Windows Server.

The Sever can be or not the primary DC and not a domain member which runs the NPS server.
So there are a lot of things where you must take a look on, before upgrading a Windows Server.

With an Aerohive AP as an Radius Proxy you have nothing to change in your environment.
 
Photo of Corey Kemp

Corey Kemp

  • 7 Posts
  • 0 Reply Likes
Migrating to a new NPS server on 2012 is not an onerous task - if you are already using 2012 servers... The NPS does not need to be on a DC - especially in smaller environments.

One consideration is that if you are migrating to a new server (not the same name and IP) then the wireless clients will likely get a prompt to install a new radius cert - or will have to have the cert installed for them - depending on your environment.

For us, its not such a bit issue as we are 95% OSX and our clients are administrators over their computers.

Thanks
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Actually, this is not correct. You should keep the certificate consistent on the RADIUS servers that you have and not use one that identifies authentication servers uniquely, rather, the certificate should be for your authentication domain/realm.

For example, a certificate for server1.example.com would be poorer practice, a certificate for example.com would be best practice.

From the client's perspective, the 802.1X authentication process is then not tied in any way to the name of the RADIUS server(s) and the presentation is the same no matter which RADIUS server is interacted with by the NAS behind the scene if you have more than one.

The IP address of a RADIUS server is only ever the concern of NASes (switches and access points), never clients.
(Edited)
Photo of Corey Kemp

Corey Kemp

  • 7 Posts
  • 0 Reply Likes
Ah... I was just following the configuration that was setup here by a 3rd party... guess that they weren't following best practices themselves.

Oh well, I guess that means that either way, the cert used by the clients will have to change anyway seeing as they were originally using the RADIUS srv cert.

Ive done a test using the ROOT CA cert by installing this into the OSX 'system' keychain and it no longer prompts to install an unverified cert.