WiFi authentication with FreeRADIUS and Google LDAP



  • Hello,

    I'm having issues in using pfSense 2.4.4p2 and its FreeRADIUS package to implement 802.1x authentication on wired and wireless networks with dynamic VLAN allocation, with users declared in Google Cloud Identity.

    I've defined a LDAP client in Google's console, given it the correct right to read user and group informations and verify user credentials, and I've imported the certificates in pfSense's Certificate Manager.

    I've tried several different configurations in FreeRADIUS, but no matter what I configure I'm unable to authenticate my client and I'm not getting an IP address. I've checked Google's LDAP audit logs and I see FreeRADIUS successfully binding and executing a search for the user I'm trying to log on as.

    I've looked at https://docs.netgate.com/pfsense/en/latest/usermanager/google-gsuite-auth-source.html but that page is for a different use case than the one I'm trying to implement.

    I've managed to implement 802.1x with the same pfSense + FreeRADIUS setup and Unifi UAP-AC-PRO access points, but I had to configure users and password in FreeRADIUS itself.

    Has anyone managed to make it work with Google LDAP?

    Thanks in advance for any help.


  • Rebel Alliance Developer Netgate

    I don't think that FreeRADIUS+LDAP supports using LDAP client certificates, which is required by Google LDAP. Maybe try the stunnel method explained in the doc, but point FreeRADIUS at the local end of the stunnel connection.



  • I've tried the stunnel method, it successfully binds to Google LDAP but I get the same kind of errors:

    Feb 22 16:19:45 	radiusd 	68008 	rlm_ldap (ldap): Opening additional connection (9), 1 of 2 pending slots used
    Feb 22 16:19:45 	stunnel 		LOG5[12]: Service [Google LDAP] accepted connection from 127.0.0.1:20026
    Feb 22 16:19:45 	stunnel 		LOG6[12]: s_connect: connecting 216.239.32.58:636
    Feb 22 16:19:45 	stunnel 		LOG5[12]: s_connect: connected 216.239.32.58:636
    Feb 22 16:19:45 	stunnel 		LOG5[12]: Service [Google LDAP] connected remote server from 192.168.4.133:20553
    Feb 22 16:19:45 	stunnel 		LOG6[12]: SNI: sending servername: ldap.google.com
    Feb 22 16:19:45 	stunnel 		LOG6[12]: Peer certificate not required
    Feb 22 16:19:45 	stunnel 		LOG6[12]: TLS connected: previous session reused
    Feb 22 16:19:45 	stunnel 		LOG6[12]: TLSv1.2 ciphersuite: ECDHE-RSA-AES128-GCM-SHA256 (128-bit encryption)
    Feb 22 16:19:46 	radiusd 	68008 	Need 1 more connections to reach min connections (5)
    Feb 22 16:19:46 	radiusd 	68008 	rlm_ldap (ldap): Opening additional connection (10), 1 of 1 pending slots used
    Feb 22 16:19:46 	stunnel 		LOG5[13]: Service [Google LDAP] accepted connection from 127.0.0.1:64932
    Feb 22 16:19:46 	stunnel 		LOG6[13]: s_connect: connecting 216.239.32.58:636
    Feb 22 16:19:46 	stunnel 		LOG5[13]: s_connect: connected 216.239.32.58:636
    Feb 22 16:19:46 	stunnel 		LOG5[13]: Service [Google LDAP] connected remote server from 192.168.4.133:9142
    Feb 22 16:19:46 	stunnel 		LOG6[13]: SNI: sending servername: ldap.google.com
    Feb 22 16:19:46 	stunnel 		LOG6[13]: Peer certificate not required
    Feb 22 16:19:46 	stunnel 		LOG6[13]: TLS connected: previous session reused
    Feb 22 16:19:46 	stunnel 		LOG6[13]: TLSv1.2 ciphersuite: ECDHE-RSA-AES128-GCM-SHA256 (128-bit encryption)
    Feb 22 16:19:47 	radiusd 	68008 	(98) Login incorrect (eap_md5: Cleartext-Password is required for EAP-MD5 authentication): [myuser@example.com] (from client ap01 port 0 cli 3C-28-6D-27-66-34 via TLS tunnel) myuser@example.com
    Feb 22 16:19:47 	radiusd 	68008 	(99) eap_peap: This means you need to read the PREVIOUS messages in the debug output
    Feb 22 16:19:47 	radiusd 	68008 	(99) eap_peap: to find out the reason why the user was rejected
    Feb 22 16:19:47 	radiusd 	68008 	(99) eap_peap: Look for "reject" or "fail". Those earlier messages will tell you
    Feb 22 16:19:47 	radiusd 	68008 	(99) eap_peap: what went wrong, and how to fix the problem
    Feb 22 16:19:47 	radiusd 	68008 	(99) Login incorrect (eap_peap: The users session was previously rejected: returning reject (again.)): [myuser@example.com] (from client ap01 port 0 cli 3C-28-6D-27-66-34) myuser@example.com
    Feb 22 16:19:55 	radiusd 	68008 	(108) Login incorrect (eap_md5: Cleartext-Password is required for EAP-MD5 authentication): [myuser@example.com] (from client ap01 port 0 cli 3C-28-6D-27-66-34 via TLS tunnel) myuser@example.com
    Feb 22 16:19:55 	radiusd 	68008 	(109) eap_peap: This means you need to read the PREVIOUS messages in the debug output
    Feb 22 16:19:55 	radiusd 	68008 	(109) eap_peap: to find out the reason why the user was rejected
    Feb 22 16:19:55 	radiusd 	68008 	(109) eap_peap: Look for "reject" or "fail". Those earlier messages will tell you
    Feb 22 16:19:55 	radiusd 	68008 	(109) eap_peap: what went wrong, and how to fix the problem
    Feb 22 16:19:55 	radiusd 	68008 	(109) Login incorrect (eap_peap: The users session was previously rejected: returning reject (again.)): [myuser@example.com] (from client ap01 port 0 cli 3C-28-6D-27-66-34) myuser@example.com
    Feb 22 16:19:56 	radiusd 	68008 	(118) Login incorrect (eap_md5: Cleartext-Password is required for EAP-MD5 authentication): [myuser@example.com] (from client ap01 port 0 cli 3C-28-6D-27-66-34 via TLS tunnel) myuser@example.com
    Feb 22 16:19:56 	radiusd 	68008 	(119) eap_peap: This means you need to read the PREVIOUS messages in the debug output
    Feb 22 16:19:56 	radiusd 	68008 	(119) eap_peap: to find out the reason why the user was rejected
    Feb 22 16:19:56 	radiusd 	68008 	(119) eap_peap: Look for "reject" or "fail". Those earlier messages will tell you
    Feb 22 16:19:56 	radiusd 	68008 	(119) eap_peap: what went wrong, and how to fix the problem
    Feb 22 16:19:56 	radiusd 	68008 	(119) Login incorrect (eap_peap: The users session was previously rejected: returning reject (again.)): [myuser@example.com] (from client ap01 port 0 cli 3C-28-6D-27-66-34) myuser@example.com
    

    The password is definitely OK, since in Diagnostics > Authentication the same login and password work perfectly.

    I've also tried to add a user in the User Manager whose login is the same as the uid in Google LDAP, but without any password, and I get the following error:

    Feb 22 16:24:35 	radiusd 	57636 	rlm_ldap (ldap): Opening additional connection (1), 1 of 4 pending slots used
    Feb 22 16:24:35 	stunnel 		LOG5[23]: Service [Google LDAP] accepted connection from 127.0.0.1:17158
    Feb 22 16:24:35 	stunnel 		LOG6[23]: s_connect: connecting 216.239.32.58:636
    Feb 22 16:24:35 	stunnel 		LOG5[23]: s_connect: connected 216.239.32.58:636
    Feb 22 16:24:35 	stunnel 		LOG5[23]: Service [Google LDAP] connected remote server from 192.168.4.133:59393
    Feb 22 16:24:35 	stunnel 		LOG6[23]: SNI: sending servername: ldap.google.com
    Feb 22 16:24:35 	stunnel 		LOG6[23]: Peer certificate not required
    Feb 22 16:24:35 	stunnel 		LOG6[23]: TLS connected: previous session reused
    Feb 22 16:24:35 	stunnel 		LOG6[23]: TLSv1.2 ciphersuite: ECDHE-RSA-AES128-GCM-SHA256 (128-bit encryption)
    Feb 22 16:24:36 	radiusd 	57636 	(6) Login incorrect (eap_md5: Cleartext-Password is required for EAP-MD5 authentication): [myuser@example.com] (from client ap01 port 0 cli 3C-28-6D-27-66-34 via TLS tunnel) myuser@example.com
    Feb 22 16:24:36 	radiusd 	57636 	(6) Login incorrect (eap: Failed continuing EAP TTLS (21) session. EAP sub-module failed): [myuser@example.com] (from client ap01 port 0 cli 3C-28-6D-27-66-34) myuser@example.com
    

    I can't see what I'm doing wrong, it seems like I'm close to a solution but there are some missing steps which I'm not getting.



  • Were you able to get this to work?

    We are using Google Cloud Identity to authenticate with the pfSense and OpenVPN but we would like to add two-factor authentication. Thinking if we could point FreeRADIUS to Google Cloud Identity, we could then layer on 2FA.

    Any help or suggestions would be appreciated.



  • Unfortunately I couldn't get this to work, and I've since then left that company so I don't know if they've managed to make it work.


Log in to reply