WiFi Enterprise. FreeRadius + FreeIPA + Ubiquiti

Some examples of corporate WiFi have already been described. Here I will describe how I implemented a similar solution and the problems that I had to face when connecting on different devices. We will use the existing LDAP with the established users, raise FreeRadius and configure WPA2-Enterprise on the Ubnt controller. It seems that everything is simple. We'll see…

A bit about EAP methods

Before proceeding with the task, we need to decide which authentication method we will use in our solution.



From wikipedia:

EAP is an authentication framework that is often used in wireless networks and point-to-point connections. The format was first described in RFC 3748 and updated in RFC 5247.

EAP is used to select an authentication method, transfer keys, and process these keys with plug-ins called EAP methods. There are many EAP methods, both defined with EAP itself and those released by individual manufacturers. EAP does not define the link layer, it only defines the message format. Each protocol using EAP has its own protocol for encapsulating EAP messages.

The methods themselves:

• LEAP is a proprietary protocol developed by CISCO. Vulnerabilities found. Currently not recommended
• EAP-TLS is well supported among wireless vendors. It is a secure protocol because it is the successor to SSL standards. Setting up the client is quite complicated. Need a client certificate in addition to the password. Supported on many systems
• EAP-TTLS - widely supported on many systems, offers good security using PKI certificates only on the authentication server
• EAP-MD5 is another open standard. Offers minimal security. Vulnerable, does not support mutual authentication and key generation
• EAP-IKEv2 - Based on Internet Key Exchange Protocol version 2. Provides mutual authentication and session key establishment between client and server.
• PEAP is a joint CISCO, Microsoft, and RSA Security solution as an open standard. Widely available in products, provides very good safety. Similar to EAP-TTLS, requiring only a server-side certificate
• PEAPv0 / EAP-MSCHAPv2 - after EAP-TLS, it is the second widely used standard in the world. Used client-server relationship in Microsoft, Cisco, Apple, Linux
• PEAPv1 / EAP-GTC - Created by Cisco as an Alternative to PEAPv0 / EAP-MSCHAPv2. Does not protect authentication data in any way. Not supported on Windows OS
• EAP-FAST is a method developed by Cisco to correct LEAP deficiencies. Uses Protected Access Credential (PAC). Not fully developed

Of all this diversity, the choice is still not great. The authentication method was required: good security, support on all devices (Windows 10, macOS, Linux, Android, iOS) and, in fact, the simpler the better. Therefore, the choice fell on EAP-TTLS in conjunction with the PAP protocol.

Perhaps the question arises - Why use PAP? because it transfers passwords in clear text?



Yes that's right. Communication between FreeRadius and FreeIPA will take place in this way. In debug mode, you can track how username and password are sent. Yes, and let them go, only you have access to the FreeRadius server.



Read more about EAP-TTLS here.

Freeradius

We will raise FreeRadius on CentOS 7.6. Nothing complicated here, set in the usual way.

yum install freeradius freeradius-utils freeradius-ldap -y
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

From packages version 3.0.13 is put. The latter can be taken at https://freeradius.org/



After that, FreeRadius already works. You can uncomment the line in / etc / raddb / users

 steve Cleartext-Password := "testing"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Run into the server in debug mode

 freeradius -X
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

And do a test connection with localhost

 radtest steve testing 127.0.0.1 1812 testing123
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Got a response Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1►6081 length 20 , then everything is fine. Go ahead.



We connect the ldap module.

 ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldap
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

And immediately change it. We need FreeRadius to access FreeIPA





We restart the radius server and check the synchronization of LDAP users:

 radtest user_ldap password_ldap localhost 1812 testing123
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Editing eap in mods-enabled / eap

Add two eap instances here. They will differ only in certificates and keys. I’ll explain just below why





Next, edit site-enabled / default . Interested in the authorize and authenticate sections.





In the authorize section, we remove all the modules that we do not need. Leave only ldap. We add client verification by username. That’s why we added the above two eap instances.





Edit authorize and authenticate sections in site-enabled / inner-tunnel





Next, you need to specify in the policies which names can be used for anonymous login. Edit policy.d / filter .



You need to find lines similar to this:

 if (&outer.request:User-Name !~ /^(anon|@)/) { update request { Module-Failure-Message = "User-Name is not anonymized" } reject }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

And below in elsif add the necessary values:

 elsif (&outer.request:User-Name !~ /^(guest|client|@)/) { update request { Module-Failure-Message = "User-Name is not anonymized" } reject }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Now we need to move to the certs directory. Here you need to put the key and certificate from a trusted certificate authority, which we already have and need to generate self-signed certificates for eap-guest.



Change the parameters in the ca.cnf file.





The same values ​​are specified in the server.cnf file. We change only

commonName :





We create:

 make
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Done. The resulting server.crt and server.key are already registered above in eap-guest.



Lastly, add our access points to the client.conf file. I have them 7. In order not to add each point separately, we will only register the network in which they are located (my access points are in a separate VLAN).

 client APs { ipaddr = 192.168.100.0/24 password = password_AP }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Ubiquiti controller

On the controller we raise a separate network. Let it be 192.168.2.0/24

Go to settings -> profile. Create a new one:







We write the address and port of the radius server and the password that were registered in the clients.conf file:







Create a new wireless name. As an authentication method, select WPA-EAP (Enterprise) and specify the created radius profile:







We save, apply and move on.

Customer setup

Let's start with the most difficult!

Windows 10

The complexity boils down to the fact that Windows is still not able to connect to corporate WiFi by domain. Therefore, you have to manually upload our certificate to the trust store. Here you can use both self-signed and from a certification authority. I will use the second one.



Next, you need to create a new connection. To do this, go to the network and Internet settings -> Network and Sharing Center -> Create and configure a new connection or network:















Manually register the network name and change the type of security. After we click on change the connection settings and in the Security section we select network authentication - EAP-TTLS.















We go into the parameters, prescribe the authentication confidentiality - client . As a trusted certification authority, we select the certificate we have added, check the box “Do not give the user a prompt if the server cannot be authorized” and select the authentication method - unencrypted password (PAP).







Next, go to the additional parameters, put a checkmark on "Specify authentication mode." Select the item "User Authentication" and click on save credentials . Here you will need to enter username_ldap and password_ldap















We save, apply, close everything. You can connect to the new network.

Linux

I tested on Ubuntu 18.04, 18.10, Fedora 29, 30.



To get started, download a certificate. I did not find in Linux whether it is possible to use system certificates and whether there is such a storage there at all.



We will connect by domain. Therefore, you need a certificate from a certification authority from which our certificate was purchased.



All connection is done in one window. Choose our network:







anonymous - client

domain - domain for which the certificate is issued

Android

non-samsung

From version 7, when connecting WiFi, you can use system certificates by specifying only the domain:







domain - domain for which the certificate is issued

anonymous - client

Samsung

As already mentioned above, Samsung devices do not know how to use system certificates when connecting WiFi, and they do not have the ability to connect by domain. Therefore, you must manually add the root certificate of the certification authority (ca.pem, we take it on the Radius server). This is where it will use self-signed.



Download the certificate to your device and install it.





When the certificate is installed, you can proceed to the connection:







certificate - indicate the one that was installed

anonymous user - guest

macOS

Apple devices out of the box can only connect to EAP-TLS, but you still need to drop a certificate to them. To specify a different connection method, you need to use Apple Configurator 2. Accordingly, you must first download it to the poppy, create a new profile and add all the necessary WiFi settings.





After the profile is ready, it needs to be downloaded to the poppy and installed. During the installation process, you will need to specify the usernmae_ldap and password_ldap user:

iOS

The process is similar to macOS. You need to use a profile (you can just the same as for macOS. How to create a profile in Apple Configurator, see above).



Download the profile, install, enter the credentials, connect:



























That's all. We set up a Radius server, synchronized it with FreeIPA, and instructed Ubiquiti access points to use WPA2-EAP.

Possible questions

Q: how to transfer profile / certificate to employee?



A: All certificates / profiles I store on ftp with access via the web. Raised a guest network with a speed limit and Internet access only, except for ftp.

Authentication lasts 2 days, after which it is reset and the client is left without the Internet. T.O. when an employee wants to connect to WiFi, he first connects to the guest network, visits FTP, downloads the certificate or profile he needs, installs them, and then can connect to the corporate network.



Q: why not use a schema with MSCHAPv2? she is safer!



A: firstly, such a scheme works well on NPS (Windows Network Policy System), in our implementation it is necessary to additionally configure LDAP (FreeIpa) and store password hashes on the server. Add. settings are not advisable, because this can lead to various problems of synchronization of ultrasound. Secondly, the hash is MD4, so this doesn’t really increase security.



Q: is it possible to authorize devices by mac-addresses?



A: NO, this is not safe, an attacker can spoof poppy addresses, and moreover authorization for poppy addresses is not supported on many devices



Q: why use all these certificates at all? you can connect without them



A: Certificates are used to authorize the server. Those. the device, when connected, checks whether it is the server that can be trusted or not. If one, then authentication goes further, if not, the connection is closed. You can connect without certificates, but if an attacker or a neighbor picks up a radius server and an access point with the same name as ours, he can easily intercept user credentials (do not forget that they are transmitted in clear text). And when the certificate is used, the enemy will see in our logs only our fictitious User-Name - guest or client and an error of the type - Unknown CA Certificate