LDAP authentication for Unifi wireless APs

[Alan DeKok]

On Nov 17, 2020, at 6:03 AM, Erwin Rutgers <erwin.rutgers at enshore.nl> wrote:
> Then to the plan and the problems: We are using Unifi Access points and like to switch to WPA-Enterprise authentication against our internal ldap. The ldap server is a freeipa server which contains the username and password for all of our users. After installation of freeradius, I entered a cleartext-password user in /etc/raddb/users and added the Aps as clients. In the Unifi controller, I configured a new RADIUS profile pointing to the freeradius server and added this to a test network. Wireless EAP authentication  was successful.
> After that, I went on and configured the ldap module with the filters and ldap settings that apply for our freeipa server. That worked too then with a radtest command and I got a an Accept-Accept result with the credentials from a testuser in the ldap server. I already removed the Clear-text password user from the /etc/raddb/users file.

  That's good.

> From here on, I'm not quite sure on how to get both methods to connect properly. To get the ldap to work in the above test, I mainly wanted to prove that the freeradius ldap module was able to authenticate against our ldap at all. To get this to work I uncommented the following section in /etc/raddb/sites-available:
> Auth-Type LDAP {
>                ldap
>        }
> 
> Your guides specifically stated that this should be avoided and when I ran a wireless connection test, the radiusd -X output gave a pretty clear message stating that setting Auth-Type will not work.

  It will work in *some* cases.  But if the debug output says "it won't work", then it won't work.

> So then, I disabled this section and ran another test. See the attached file: failed_attempt2.txt.
> Then I restored the /etc/raddb/mods-config/files/authorize file to it's original state and added "ldap" to the /etc/raddb/sites-available/default file instead of the Auth-Type LDAP part.
> I ran another test and added the debug information in file freeradius_debug2.
> 
> Initially I chose for the ldap module instead of the ntlm_auth method because the ldap module allowed for better directory filtering to my liking. I did try to setup a samba ntlm connection to the freeipa server though, but the guides did not seem to work for freeipa.

  You don't need Samba and ntlm_auth for freeipa.

  It's best to _read_ the debug output.  See http://wiki.freeradius.org/radiusd-X   Look for "warning" or "error".  If you're running in a terminal window, warnings will be yellow, and errors will be red.

  In this case:

(1) ldap: Performing search in "cn=users,cn=accounts,dc=enshore,dc=local" with filter "(uid=testuser)", scope "sub"
(1) ldap: Waiting for search result...
(1) ldap: User object found at DN "uid=testuser,cn=users,cn=accounts,dc=enshore,dc=local"
(1) ldap: Processing user attributes
(1) ldap: WARNING: No "known good" password added. Ensure the admin user has permission to read the password attribute
(1) ldap: WARNING: PAP authentication will *NOT* work with Active Directory (if that is what you were trying to configure)

  Fix that before doing *anything* else.

  LDAP is a database which stores passwords.  FreeRADIUS is an authentication server which implements authentication protocols.  LDAP doesn't do EAP.  FreeRADIUS does EAP.

  But the only way that FreeRADIUS can do EAP is if the LDAP database gives FreeRADIUS the users correct password.  If LDAP doesn't do that, then FreeRADIUS can't do anything.

  Also read this:  http://deployingradius.com/documents/protocols/compatibility.html

  If the passwords in LDAP are salted / hashed (i.e. not cleartext), then PEAP / MS-CHAP will not work.  And no, there is no magic setting to make it work.  The protocols were designed to be incompatible.  There's nothing _anyone_ can do to fix that incompatibility.

  You have to either (a) store passwords in a way which is compatible with PEAP / MS-CHAP.  Or, you have to use TTLS + PAP.  Those are pretty much your only two choices.

  Alan DeKok.