cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with Users connecting to Wireless SSID

Problem with Users connecting to Wireless SSID

richard_moth
New Contributor

This is a new configuration and the first time using HiveManager (NG upgraded to Select).  These are brand new Access Points and a new config, only about 4 weeks old.  The company it comes under is "EBIQUITY".

 

I have one network policy with 2 SSID's, they are EbiquityPLC and EbiquityGuest.

 

Under the EbiquityPLC I have setup the SSID as Private Pre-Shared Key and I have 4 User Groups aasigned with 4 User profiles mapping through to 4 different VLANS.

 

US-Trusted-Staff maps to VLAN 202

US-Trusted-Mobile maps to VLAN 204

US-Untrusted-BYOD maps to VLAN 205

US-Untrusted-Conf2 maps to VLAN 203

 

Each User group has one user setup.

 

Users can connect to EbiquityPLC using the PPSK for US-Trusted-Staff no problem.

 

But when a user tries to connect to the EbiquityPLC with the PPSK for US-Untrusted-BYOD they get an error Authenication Failed.  When I look at "Tools - Client Monitor" I can see the error "PPSK Rejected by Guest Access" - "ID Manager did not accept the PPSK authentication request for the EbiquityPLC SSID".  I have checked all the seeting and they look correct.  I have checked the PPSK's and again they all look corredct.

 

Can any one help?

6 REPLIES 6

richard_moth
New Contributor

Hi Brain

 

One of my engineers was testing the conference setup I have on the EbiquityPLC SSID and he could not connect to the Wifi.  Conference and Guest are the only to user groups that are using Cloud password location.

 

Could this problem be with RADSEC connecting back to the cloud instance 

 

When I run "sh idm" I get the following results.

 

IDM client: Enabled Per SSID

IDM Proxy IP: 10.22.200.22

IDM proxy: Enabled

IDM server: cloud-va2-idmauth.aerohive.com

IDM server IP: 34.202.197.20

RUN state: Connected securely to the IDM server

IDM transport mode: TCP

Server destination Port: 2083

RadSec Certificate state: Valid

RadSec Certificate Issued: 2018-09-27 09:20:35 GMT

RadSec Certificate Expires: 2019-09-27 09:20:35 GMT

 

I have just updated the AP's to 8.4R5 as they were running on 8.4R4.  After the update all three AP's are showing as RADSEC proxy servers.

 

Richard

 

richard_moth
New Contributor
Hi Brain

Yes the US-Untrusted-BYOD was set as the default profile.

I was thinking about the problem and then thought to myself for a user to authenticate with the cloud they must need access out to the Aerohive Cloud. I then had a look online and an article says for cloud authentication the AP’s need outbound tcp port 2083. So I checked this on my firewall and from the management VLAN the AP’s have access outbound via this tcp port.

So I then thought about what if I can the user groups from Cloud password DB to local password DB. Did all the hard work removing the setup, user accounts and user groups.

Added these all back on but using local password DB and everyone connects to the SSID’s as expected.

Thank you for the advice and suggestions.

Richard

Richard Moth
Senior Infrastructure Support Analyst

Richard.Moth@ebiquity.com

London

Citypoint, One Ropemaker Street, London, EC2Y 9AW, UK

Tel +44 (0) 20 7650 9780 Mobile 07525224452



[http://login.ebiquity.com/emailimages/website_navy.png]<>[http://login.ebiquity.com/emailimages/blog_navy.png]<>[http://login.ebiquity.com/emailimages/linkedin_navy.png]<>[http://login.ebiquity.com/emailimages/twitter_navy.png]<>

AnonymousM
Valued Contributor II

Richard,

 

There's a lot going on in that config file. 🙂

 

But the one thing that sticks out is - security-object EbiquityPLC default-user-profile-attr 3. That EbiquityPLC security-object ties to your EbiquityPLC (ssid EbiquityPLC security-object EbiquityPLC).

 

That default user profile attribute of 3 is also the US-Untrusted-BYOD user profile.

user-profile US-Untrusted-BYOD

user-profile US-Untrusted-BYOD qos-policy def-user-qos

user-profile US-Untrusted-BYOD vlan-id 205

user-profile US-Untrusted-BYOD attribute 3

user-profile US-Untrusted-BYOD deny-action-for-schedule ban

 

I cant help but think that those should not be the same as the default user attributes for the before mentioned user profile. That in unless your default user profile on that SSID is the US-Untrusted-BYOD, which would make it make some logical sense.

 

The PPSK User Groups don't seem to be included in the config (or I'm missing them). So I'd need to see a bit of that info, but everything else looks like it lines up.

richard_moth
New Contributor

Kind of sorted this, delete all the users account and all the config settings for the user profiles.  Then added them back on again but used local for password DB instead of Cloud.​  Had a user test and everything worked as it should.

GTM-P2G8KFN