Something that is extremely disappointing is that at the $100 AP level, these devices are not 802.3af compliant; you need the $250 UAP-PRO to get standard power over ethernet (PoE) compliance.  The UAP and UAP-LR will not work with your fancy PoE switch -- you must use the provided power injector to supply PoE to these models.  I'll be calling their extremely disappointing implementation "pretend PoE."  It should not be simply called "Power Over Ethernet" because while these devices do technically receive power on the ethernet cable, we don't want to imply compatibility with standard PoE injectors/switches.

Anyhow, to get UniFi working with Zentyal, we first need to get some packages setup.  Ubnt doesn't publish linux support alongside windows/mac support, but they do offer packages for ubuntu!  Please find the "zentyal_ubnt.sh" shell script attached at the bottom of this page.  You can review it, or just run it from your zentyal with the following command as root:

Easy enough!  Now we just need to fix up a couple things to get it running.  First off, one of the default ports UniFi listens on may already be in use by kerberos.  We can confirm this by running:

 (thanks).  If you see something like:

that tells you the kdc service (running as process 20007) is listening on port 8880 of 192.168.1.1.  To make UniFi listen on another port, we need to change the configuration found in /usr/lib/unifi/data/system.properties.  Find the line that references 8880 and change it to 8881.  When I installed UniFi, I noticed it created a superfluous configuration file at /usr/lib/unifi/etc/system.properties.  Ignore this file; UniFi uses the one in the data directory!

While we're changing UniFi's config, let's recognize that UniFi uses mongodb for storage.  UniFi recommends using 10-gen repositories to install mongo, but when they start the mongo service (when the unifi service is started), they use a custom configuration for mongo.  This configuration does not use the standard configuration found in /etc/mongodb.conf.  The problem is that UniFi's instance of the MongoDB service uses the default MongoDB port (27117) when it runs the MongoDB service.  So if you're trying to run mongo on the system, you will find that it won't start because of this conflict.  To fix this, we need to change the DB port variable in /usr/lib/unifi/data/system.properties;  Change 27117 to 27118 (or similar).

After making the change, restart the service: sudo service unifi restart

1. Create a service under the network -> services section
• unifi-https service listens for connections to TCP/8443.
• unifi-http service listens for connections to TCP/8080.
• unifi-portal-http service listens for connections to TCP/8881.
• unifi-portal-https service listens for connections to TCP/8843.
2. Enable connections to these services from the LAN.
1. Browse to Firewall -> packet filter.
2. Choose 'configure rules' under the section for packets from internal networks to zentyal.
3. Add an accept decision for each service.
3. You might also want to enable management of UniFi from outside your local network.  Do this by adjusting packet filter rules for the unifi-https service for packets from external networks to zentyal.

And that should do it.  Now you can fire up your APs, and they should see your controller, and you can set up a sweet WiFi network!

Aside:

  I had trouble converting an AP from one controller to another.  To work around this, I found you can SSH into the AP.  If the AP is provisioned for a controller, the authentication will be that of the controller administrator.  If the AP is not provisioned, the username and password are both: ubnt.  From the terminal, you can factory-default the AP, initiate a reboot, and do other awesome diagnostics.  My issue was a DNS resolution failure that I identified by reviewing /var/log/messages; I worked around it using the hosts file, and it didn't recur after re-provisioning under the new controller!  I did not fully identify the cause of this trouble, but suspect it was lingering config in the AP from when it was registered against a different server.

This FAQ alludes to the config file discrepancy (data/system.properties vs etc/system.properties).  I'd reckon this arose through cross-platform consistency.