09-22-2015 12:05 PM - edited 09-22-2015 12:09 PM
802.1x, Termination and Certificates
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.
Aruba OS 22.214.171.124
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.
09-22-2015 12:09 PM
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.
09-22-2015 12:21 PM
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.
09-22-2015 12:26 PM
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.
09-22-2015 12:56 PM
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?
09-22-2015 01:15 PM
09-28-2015 02:09 PM
10-15-2015 07:16 AM
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:
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
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.