Wireless Access

Hello everyone!

Hopefully somebody out there has seen this. I recently deployed 2 ap 105's at a remote office (connected via MPLS) put the ap's in split tunnel and they seem to be working properly, however then they set up the wireless connection to the ssid they receive a windows security alert stating the following:

the credentials provided by the server could not be validated. We recommend the you terminate the connection and contact your administrator with the information provided in the details. You may still connect but doing so exposes you to security risk by a possible rogue server.

Details:

Radius Server: securelogin.arubanetworks.com

root ca: addtrust external ca root

The server "securelogin.arubanetworks.com" presented a valid certificate issued by "addtrust external ca root", but "addtrust external ca root" is not configured as a valid trust anchor for this profile.

Any thoughts? I'm still looking thru logs to see if I can see anything.

Lirria

You need to get a real certificate for 802.1X. You really shouldn't use the one that ships with the controller, it's there for demos and PoC testing. Your clients don't trust it because things don't match up, it's a generic cert that ships with every controller. Please take a look at the series on digital certificates over in the learn section: http://community.arubanetworks.com/t5/Community-Knowledge-Base/tkb-p/tkb%40tkb 

-awl

Is that when the user is connecting to a dot1x SSID? Sounds like you've accidently enabled local termination on the linked 802.1x profile for the VAP being used, and maybe it's not in your normal 802.1x profile?

Are you using different VAPs and/or dot1x profiles? If so, look in the linked dot1x profile. If it's on, that's likely your problem as it will use the controller's internal certificate (hence the error, as the PC doesn't trust it).

It either that, or the wireless profiles on the PCs using the RAP are setup to validate the server certificate, where as the other ones using your other APs aren't.

Good luck.

Sorry, I meant to say I'm assuming you've got other APs and clients not doing this? If the RAPs are the only thing you're using, you still need to look at the termination setting in the VAP, and use a proper certificate on your RADIUS server (highly advisable), rather than the controller one.

We actually don't authenticate to the aruba (which is what's got me here) we use a radius server/local db

Yes it is when the user is connect to the dot1x ssid. I'll look at local termination. It's a copy of the original but you know how things get changed when you have issues - that may be one of the things the engineer changed when we were trouble shooting the connection problems we were seeing - and since all my rap people are seeing it, it's a good bet it's in the configuration of the system.

I'll compair the main office config to the remotes and try to spot the errant setting - thank you for giving me a direction to look in.

Ill post the results when I know more.

Lirria

Not having much luck finding the differences in the profiles - still looking - we have a lot of "fluff" in the config so I'm trying to figure out what is associated with what.

I did make one change but it didn't make a difference yet - I plan on getting a reboot of the ap in one of the remote offices after hours to see if it's better tomorrow.

Lirria

Look in the 802.1x profile (configuration> security> authentication> L2 authentication) and make sure Termination is unchecked.

The message you are getting means that the Windows 7 laptop does not trust the certificate of the radius server it is connecting to.  When you have termination enabled, the 802.1x process on the controller submits the built-in certificate as the radius server certificate and your Windows 7 laptop probably does not trust it.  When you uncheck Termination, the radius server needs to have a certificate attached to the remote access policy used to authenticate your client, if you are using PEAP.

Thank you cjoseph - that was it - now if I can just figure out why it's still using the incorrect l2 authentication I would be in business.

Lirria

You could post an attachment of your config on here so it can be checked? If you're not paranoid about security that is!

I was prepping to do just that -but,  looks like when I cloned the configuration created when working with the engineers, not quite everything got changed from "test" to the real thing - yup I missed one little l2 auth group - go figure. I have it working with the proper auth groups now and am just in monitor mode.

I hate not having the time to fully finish a project anymore.... :)

Thank you all - now I just have to clean up the config and get the garbage out of it.... That is in my copious amount of free time...

Lirria

One other thing I would highly recommend is using the wizards in the WebUI, it will help you avoid some of those misses and adds the SSID name to all the profiles which makes it easier to trace your profiles. Glad you got it sorted out in the end. 

-awl

I do love the wizards - we had some issues with the RAP config and to sort it all out the engineer made a new profile - once it was all working we cloned it to a proper name (test really doesn't help when trying to figure out what it does 6 months down the road) so I did that but it seems that some of the pieces didn't come thru as I expected - I way prefer using the wizard but this was a special case.

:)

Lirria

That makes sense, just wanted to make sure you were aware they were there. A lot of users haven't been using them, but I personally find it saves me a lot of time and keeps me from missing things in the config when I'm in a hurry. Good luck on your config cleanup :)

-awl

Thank you! I think I'll need it.

:)

Lirria

Interesting how opinions vary. I hate the wizards. I have chronic OCD with my configs and profile names though! Good to know some people like them!

Glad you're all sorted!