Security

802.1x, Termination and Certificates

 

Hello,

 

The recent IOS 9 update brought to light some issues that we have with our current environment. While trying to address the IOS 9 issue we realized that we also have certificate issues and are trying to find our way out of them. Hoping someone can chime in with suggestions on what to do to get past the IOS 9 issue without also losing some of the features we are currently using.

 

Our environment:

Aruba OS 6.4.2.12
3600 controller (master)
7210 Controller (local1)
7210 controller (local2)

 

Open guest SSID, two separate 802.1x ssids, some special purpose PSK networks

 

The 802.1x networks are using controller side termination with two domain controllers with IAS/NPS set up as radius servers behind that. TAC told me to try having the IOS 9 clients on an SSID that did not terminate the authentication on the controller and that was successful (IOS would show the DC cert and authentication would complete properly with access). Although this works I'm not sure that other features we are currently using will continue to work if we stop terminating controller side.

 

Those features are automatic blacklisting, and machine authentication. As it stands we have our windows wireless clients perform SSO and initial connection to wifi which means users don't have to plug in in order to login for the first time on a properly configured laptop. The blacklisting helps with account lockouts as the controller will automatically ignore a client after a few failures instead of locking out their corresponding AD account. I'm concerned about those features remaining intact if we stop terminating on the controller. I tested the automatic blacklisting and was able to lock out the account and the device wasn't blacklisted.

 

Currently we have server certificate set to "none", which results in the securelogin.arubanetworks certificate being presented (which it seems IOS 9 devices will not prompt for and simply skip connecting altogether).

 

My thinking was that for our environment perhaps buying an SSL cert from an external source (digicert), then loading that server cert/trusted root cert on the master and locals, and then setting the AAA profiles to use it would be the best way to retain features we are using while bringing IOS 9 devices back into the fold with a cert they will hopefully at least prompt to acknowledge. Alternatively I wonder if we wouldn't be better off to generate a certificate from our own MS CertServ and just place that on the controllers.

 

At this point I think we are quite far beyond best practice and I'm unsure how to proceed without breaking production (the last time I installed a cert it broke many things because it automatically became the default cert and didn't allow for any testing.)

 

Any input or suggestions would be greatly appreciated.

#7210

Since you do have existing RADIUS servers in place, I would definitely terminate on the RADIUS servers.

 

In terms of certificates, there are a few considerations:

 

If you have a mix of managed and un-managed devices/operating systems, you'll want to use a publicly signed RADIUS server certificate.

 

If you only support Windows AD-joined machines, you can use your internal AD CA to sign the RADIUS server certificate and distribute the CA certificate via group policy.

Hello cappalli,

 

We do have mixed unmanaged and managed so I think the publicly singed as you suggest is the best one to use if we do not terminate controller side.  Hopefully our cert vendor has some documentation on getting that setup as changing the certs on domain controllers makes me nervous.  I almost think we'd be better off to setup some new servers on the domain to act just as radius servers rather than point directly at the DCs to be safer (unless I'm wrong about that).

 

Is there any way to retain things like machine auth pre-logon and automatic blacklisting of incorrect passwords when not terminating on the controllers?  The main headaches behind that question are (1) users changing their passwords and immediately being locked out by their tablet or phone, and (2) being able to login to a domain laptop for the first time without being plugged in.

 

I appreciate the help as I'm unfortunately nowhere near a radius or 802.1x expert and mostly inherited that portion of the infrastructure as it was.

My suggestion would be to stand up NPS servers instead of running them on your DCs. If that's not possible, using a different certificate for NPS would not affect AD functionality.

 

Just FYI. Machine authentication is not supported with termination when using NPS as a RADIUS server. I'm not sure how you have this configured today. I would work with your Aruba partner to take a look at the configs. Blacklisting and machine authentication can work with termination on NPS.

Hello cappalli,

 

Thank you for the reply, I'm a bit confused about the last paragraph:

 

1) "Machine authentication is not supported with termination when using NPS as a RADIUS server."

 

2) "Blacklisting and machine authentication can work with termination on NPS."

 

Does the second statement indicate using NPS with something other than RADIUS? 

You had asked if you'd lose functionality terminating on the RADIUS server. You won't lose either of those features. 


Thanks, 
Tim

Ah, ok thanks.  We're going to work on setting up the separate radius servers and I'll report back how we turn out.

We've got two separate radius servers setup now with certs and authentication works, however blacklisting seems hit or miss. I'm planning to open a ticket tomorrow on this as it seems that some of the time the devices properly get blacklisted before locking out AD and other times they do not once termination is disabled on the controller.

At long last I came back with the solution we arrived at, here is what I told Aruba TAC after Microsoft verified the known issue:

 

Symptoms:

 

2012 R2 Network Policy Server

802.1x failures not logged in event viewer even though they are set to do so

NPS not sending radius-reject packets, causing aruba blacklisting to fail and clients to lock out their AD accounts

 

Solution:

 

I wanted to update on what the solution was after discussion with Microsoft support since I imagine it might help with troubleshooting other customers in the future, here was their comment on the issue verbatim (it appears to be a feature limitation of NPS server):

 

"From your description, we are using PEAP-EAP-MS-CHAPV2 authentication method, wireless client, wireless control(radius client). I have verified this issue, for this specific scenario, it should be a known issue for this authentication method, and we have found the correct workaround” set "number of authentication retries" to 0”."

 

The setting discussed is within the configuration tree on network policy server as follows:

 

"Policies">"Network Polices">"Right Click Policy In Use">"Properties">"Constraints">"Authentication Methods">"Select "Microsoft: Protected EAP (PEAP)">"Click Edit">"Click Edit Again"

 

And then change "Number of Authentication Retries to 0"

 

Do the same for the other EAP types:

 

"Policies">"Network Polices">"Right Click Policy In Use">"Properties">"Constraints">"Authentication Methods">"Select "Microsoft: Secured password (EAP-MSCHAP v2)">"Click Edit"

 

And then change "Number of Authentication Retries to 0"

 

With both of these set to 0, NPS will log failed events and will transmit the radius-reject as it should, causing the Aruba blacklisting feature to properly blacklist on 3 failures.

 

Hope this helps someone down the line and thanks for your help.

I'm looking to do something similar and having some difficulty: 

I'd like to do EAP-TLS authentication of the machine to enforce company equipment-only policy followed by authentication of the user via captive portal calling to NPS (running on it's own server, not a DC). Based on the earlier statement, my understanding is that I can't terminate the EAP-TLS on the controller (7010) if I'm using NPS as my RADIUS server. Not being a Windows or certificate guy, I'm looking for a step-by-step guide on setting EAP-TLS authentication using private certs created on a Windows CA. Can anyone point me in the right direction? 

Could you please explain more why we need to use public RADIUS cert for deployment with mix of managed and unmanaged devices? I think private cert should work just fine here.

 

Thank you very much,

If you use an internal cert, you have to have the CA installed manually on all unmanaged clients. Not feasible

If security is a concern, you should be using EAP-TLS.

Ah, I think you define unmanaged clients as the devices which we cannot push the CA cert to (via QuickConnect app, for example). If that is the case, I think the devices which are owned by employees are still considered managed devices. Correct? (to be honest I'm not too familiar with the terms).

 

Thank you,

Managed means the supplicant is centrally managed. Usually BYODs do not fall into this category.

Well, in BYOD flow, users will download the CA cert to their devices (either via over-the-air provisioning or QuickConnect app) and then authenticate through EAP-TLS. Since the CA cert is automatically distributed to devices (without having to install it manually), I think using private radius cert in BYOD (or unmanaged devices) is still fine. Please correct me if I'm wrong.

 

Thank you,

Oh, so you are using EAP-TLS. As long as you're using dual SSID onboarding (which is the recommendation), then you're fine with an EAP server certificate signed by the Onboard or an internal CA.