PPSK self-registration queries

  • 1
  • Question
  • Updated 5 years ago
  • Answered
Does anyone know when Aerohive are going to change the PPSK self-registration mechanism to actually be more enterprise ready??

Currently as far as I can tell, if you set this up correctly the following occurs:

A single AP becomes a PPSK server (Not good for a high availability solution) - what happens if this AP disappears etc...

The open registration SSID points the user to the single AP that is the PPSK server - Now because I want to use AD/RADIUS to authenticate the user to get the PPSK, I need to use HTTPS to secure the connection... The problem is I can not configure the AP to use a FQDN and third party SSL certificate which means the end user's first experience with self-registration is a untrusted page in their browser. However once they have authenticated I can re-direct them to my captive web portal using a certificate and FQDN that I specify!
Photo of BeeKeeper

BeeKeeper

  • 9 Posts
  • 0 Reply Likes

Posted 5 years ago

  • 1
Photo of Andrew von Nagy

Andrew von Nagy

  • 9 Posts
  • 5 Reply Likes
Hi,
I'll tackle your questions and feedback on the PPSK self-registration scenario one at a time:

Yes, currently a single AP functions as the PPSK server and it must have a static IP address. The server is required to tie the MAC address of the client to the PPSK being used for the duration that the PPSK is valid. This mapping must be performed to ensure the PPSK isn't re-used and that the maximum number of clients can use the PPSK as configured by the network administrator. The issue with using a single AP is exactly as you have described, it's a single point of failure. I agree that this is not ideal and will raise this issue again internally to see if we have any plans to address this limitation and make the solution more robust. If you have any additional examples or feedback to help illustrate how this limitation impacts your environment, I will take it and use it help me build support for enhancing this feature.

Regarding the captive web portal (CWP), the user logs in using the CWP page that is on the AP that they are connecting to. We already support HTTPS to secure the web login / registration and can import an external SSL/TLS certificate from either a public CA or an internal PKI infrastructure. This is accomplished in the CWP configuration screen in the "Optional Advanced Configuration" section (see image). Select a previously imported certificate from the drop-down list, or click the "+" icon to create a new CWP certificate object, which will lead you down the path to import a certificate if you need to. For the FQDN, you can use either the checkbox to use the CN that is in the certificate or enter your own value in the "Web Server Domain Name" text box further down.



You can also manually manage the certificates in the system from the Configuration > Show Menu > Advanced Configuration > Keys and Certificates. (You will need to make sure your HiveManager is in Enterprise Mode to see these advanced configuration features.) You can create a Server CSR (certificate signing request) and submit it to an external CA for certificate issuance. Then import the issued certificate in the Certificate Mgmt section. Finally, use the imported certificate and private key inside a CWP certificate object in the CWP Certificate Mgmt section. Also of note, is that you could use an external software package like OpenSSL to create a Server CSR as well, you don't have to use the tool within HiveManger.

I hope my explanations answer all of your questions. And I'll work on bringing your concern about the single PPSK server to resolution, because frankly we need to.

Thanks,
Andrew von Nagy
Photo of BeeKeeper

BeeKeeper

  • 9 Posts
  • 0 Reply Likes
Hi,

Thanks for the reply.

Maybe I am configuring the SSID incorectly, then...

I create an SSID and I select Private PSK Server as the authentication server. I then tick the box for Enable private PSK self-registration. This then provides a box which I enter another SSID name in which creates an open SSID to register and get the PPSK from.

I then create a CWP with a registration type of Private PSK Server and put my certificate details in as you show above.

Then I wrap the whole thing up in a Network Policy and deploy to an AP. Now here is what happens.

I join the open SSID and open my browser. The first thing that happens is I get a automatic redirect to an authentication webpage hosted on the PPSK server (The url is https:///SSID/etc...), where I login using my AD credentials. This site uses the self-signed "HiveAP" certificate on the PPSK server AP which causes me the problems. At this point if I enter invalid credentials, or valid credentials, and hit submit, the successful or unsuccessful page seems to be returned from the local AP which I am actually connected to using the CWP I configured using the certificate and domain name settings I specified.

And I do not really have any examples of the limitations the single PPSK server solution provides, it just seems to fly directly in the face of what Aerohive are stating they provide... (The whole concept of intelligence in all the AP's, rather than a single controller type scenario - which this really is). Also quite simply it scares me to think that if I opted for this solution I am basically pinning the whole wireless network system (Which for me is 100+ AP's but could obviously be 1000's all on a single AP's availability). If this AP disappears or breaks for whatever reason my whole WLAN is down. Surely information about who is connected etc. could be shared on all AP's like the ACSP or similar mechanism? I guess the key issue is if I had problems how would I explain this to Exec level staff after citing one of the main benefits of Aerohive is the no central controller concept as quoted from:

http://www.aerohive.com/products/acce...

"All Aerohive devices support the feature-rich HiveOS Cooperative Control architecture. HiveOS enables Aerohive devices to organize into groups, or “hives,” which allows functionality like fast roaming, user-based access control and fully stateful firewall policies, as well as additional security and RF networking features - all without the need for a centralized or dedicated controller."
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
BeeKeeper (I love your handle),
Andrew is pretty brilliant and often amazes me at how he can create solutions to tough problems, but even he cannot overcome physics. We and every other commercial vendor on the planet are in this business to make money. We have to offer a product that serves needs, at a price that people will pay, that still brings us a profit. That means we all have to make trade-offs when designing our hardware between code space, performance, and the features that we can offer.

We are proud of our CWP and PPSK self-registration feature, but we don't try to claim that it is suitable for all potential customers.

We have had numerous requests to enhance the PPSK self-registration feature, many of which you restated at the start of this thread. Due to the limited code space on the AP (and other factors irrelevant to this discussion), we included much of this feedback in the design of ID Manager, our cloud-based guest management tool. We *may* make further enhancements to the CWP and PPSK self-registration process, but I honestly think that you should be looking at our ID Manager given the environment you've described and the concerns you've raised.
Photo of Andrew von Nagy

Andrew von Nagy

  • 9 Posts
  • 5 Reply Likes
Hi Mike,
Thanks for the clarification! I learn something new every day :) Now I'm going to have to go lab this up.

Andrew
Photo of BeeKeeper

BeeKeeper

  • 9 Posts
  • 0 Reply Likes
Hi,

Trust me I appreciate Aerohive is here to make money, my company pay for the devices! I shall investigate the pricing of the ID Manager.

However I am sorry but let me be completely blunt with you. Aerohive should not be proud of the PPSK self-registration feature at all - Infact in many ways I think it should not even be offered as a "feature". I wonder if Aerohive has actually even thought about people using it...

A user arrives at your site with a wireless device and they connect to the open SSID which you have helpfully named registration or something. Now at this point the first thing they see is a full page of browser warnings regarding the fact the site is secured by an unknown certificate... how is that a great first impression. Should the users even trust it?

This is without the users knowing that this entire functionality is dependent on one AP being available.

As I mentioned in my other thread in the ideas section, limited code space on the AP is a poor argument. Obviously I completely agree that Aerohive is here to make money etc. but I think taking people's ideas on how to improve a very limited service and then charge them back for it as a new appliance is bit rich... especially given the whole "intelligent AP's" argument. So they are so intelligent and full of features they now "depend" on ID Manager.

Also blogs that say things like this:

"Oh wait, one more thing - like everything else Aerohive, this feature is totally, completely, 100% free with the purchase of any Aerohive access point or branch router. Now there's no excuse for insecure Wi-Fi networks - Aerohive has provided the ultimate way to get every user and every client connected with unique, revocable, and completely secure keys to the Wi-Fi Network. Didn't I mention World Domination? "

http://blogs.aerohive.com/blog/the-wi...

So is ID Manager free wth the purchase of any Aerohive access point or branch router?

Now again let me be clear... although it does not sound like it in my threads I think Aerohive is great. I selected Aerohive primarily because the AP's in my scenario gave the greatest signal strength and based on the recommendation of others. During our pilot when there were several issues (Some ours, some Aerohive firmware related), and others wanted to switch to another vendor, I said "No Aerohive is the right decision" and I stand by that.
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
On a similar thought process what is the chance that we can increase the number of APs that can act as DHCP servers? If you have a site with four buildings connected by WAN links you can't have an AP in each building acting as a DHCP server as you are limited to a primary and a secondary. I commonly use the integrated DHCP server functionality for guest users.

Making cloud-only solutions is not a fix to a number of problems as some customers, particularly customers who handle public or sensitive information, do not want any part of their wireless network in the cloud.
Photo of Amanda

Amanda

  • 396 Posts
  • 25 Reply Likes
This is a great conversation that's separate from the main topic, so I created a new topic to continue the discussion. Please reference the new topic here: Can I increase the number of APs that can act as DHCP servers?
Photo of Juha Lindström

Juha Lindström

  • 8 Posts
  • 0 Reply Likes
I understand this doesn't apply for every scenario, but one way could be to use the HiveOS VA as PPSK server? You could then make it "redundant" by using failover functions provided by VMware.

I know it's not ideal, but at least for slightly larger environments it would be of help. You can then give the HiveOS VA enough power to handle the necessary loads as well.. So it scales better for both performance and availability.
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Juha,
I will take this up with the owner of the HiveOS VA on your behalf.