I seem to be misunderstanding how authentication and authorization works under FreeRadius. In the default site configuration, I have enabled unix under both the authorize and authenticate sections, and ldap only under authorize. I am using a test client to send an authentication request with a valid User-Name, User-Password, and Calling-Station-Id attributes set. I can see the in logs that the bind is successful and that the search does not return any object matching the filter criteria, as expected. However, an access-accept is still returned to the test client. I am expecting that unix type will only be used for authentication, and that authorization depends on the ldap search being successful, but this does not appear to be the way the configuration is functioning. If I comment out unix from the authorize section of the default site, then access-reject is returned even when the password is valid and the search is successful. Thoughts? rad_recv: Access-Request packet from host 192.168.1.63 port 55161, id=3, length=63 User-Name = "*****" User-Password = "*****" Calling-Station-Id = "5C-95-AE-15-C9-92" # Executing section authorize from file /etc/freeradius/sites-enabled/default +group authorize { ++[preprocess] = ok ++[chap] = noop ++[mschap] = noop ++[digest] = noop [suffix] No '@' in User-Name = "*****", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] = noop [eap] No EAP-Message, not doing EAP ++[eap] = noop ++[unix] = updated ++[files] = noop [ldap] performing user authorization for ***** [ldap] expand: (&(wiFiMAC=%{Calling-Station-Id})(deviceCompliance=0)) -> (&(wiFiMAC=5C-95-AE-15-C9-92)(deviceCompliance=0)) [ldap] expand: CN=Managed Devices,CN=Device Directory,O=DiBella Consulting -> CN=Managed Devices,CN=Device Directory,O=DiBella Consulting [ldap] ldap_get_conn: Checking Id: 0 [ldap] ldap_get_conn: Got Id: 0 [ldap] attempting LDAP reconnection [ldap] (re)connect to *****:389, authentication 0 [ldap] bind as CN=scout,CN=Users,CN=Device Directory,O=DiBella Consulting/***** to *****:389 [ldap] waiting for bind result ... [ldap] Bind was successful [ldap] performing search in CN=Managed Devices,CN=Device Directory,O=DiBella Consulting, with filter (&(wiFiMAC=5C-95-AE-15-C9-92)(deviceCompliance=0)) [ldap] object not found [ldap] search failed [ldap] ldap_release_conn: Release Id: 0 ++[ldap] = notfound ++[expiration] = noop ++[logintime] = noop ++[pap] = updated +} # group authorize = updated Found Auth-Type = PAP # Executing group from file /etc/freeradius/sites-enabled/default +group PAP { [pap] login attempt with password "*****" [pap] Using CRYPT password "*****" [pap] User authenticated successfully ++[pap] = ok +} # group PAP = ok # Executing section post-auth from file /etc/freeradius/sites-enabled/default +group post-auth { ++[exec] = noop +} # group post-auth = noop Sending Access-Accept of id 3 to 192.168.1.63 port 55161 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 3 with timestamp +31 -----Original Message----- Date: Thu, 24 Oct 2019 11:39:22 +0100 From: Matthew Newton <mcn@freeradius.org> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Authorize access by MAC Address Message-ID: <0d97da45933a66ee5e2c46e9845e621eaa08145d.camel@freeradius.org> Content-Type: text/plain; charset="UTF-8" On Wed, 2019-10-23 at 23:44 +0000, Mike DiBella wrote:
The access request authorization policy should allow access if the device object is found in the directory by MAC address, and deviceCompliance is 0.
I've looked over the documentation for LDAP backend configuration, but it is heavy biased towards the authorize-by-user-identity use case.
The defaults check for the username, because that's what most people do.
Are there any configuration examples for mapping identity using MAC address? Any examples for adding custom LDAP attributes for access- adjudication?
It's all in mods-available/ldap. Update the user filter to match on something other than uid and %{Stripped-User-Name}, e.g. "(&(wiFiMAC=%{Calling-Station- Id})(deviceCompliance=0))" You can change the update{} section to copy any LDAP attributes into RADIUS attributes if you need them. -- Matthew