MAC authorisation (but not authentication) via LDAP

Markus Krause krause at
Sun Feb 25 02:00:39 CET 2007

Zitat von Phil Mayers <p.mayers at>:

> Markus Krause wrote:
>> don't no if it is a good solution, but i just do this by setting the
>> following in radiusd.conf:
>> authenticate {
>>      ...
>>      Auth-Type LdapMAC {
>>         ok
>>      }
>>      ...
>> }
>> the Auth-Type is set in users file depending on huntgroups:
>> DEFAULT  Huntgroup-Name == switch, Autz-Type := LdapMAC, Auth-Type   
>> := LdapMAC
>> i assume there are better/smarter sollutions as one can read "don't
>> set Auth-Type" on many places but it works here ;-)
> Sorry, but it's an awful suggestion. Don't do it, and certainly don't
> recommend others do it. There's no need to go setting Auth-Type to
> random values.
no need to say sorry, and i did not meant this as a suggestion but  
just show how i did it, along with the "warning" that it is not a good  
solution. and i am really open for any suggestions/corrections!

> The correct way to do this is to reject unknown, not blindly accept known.
hmm, maybe i should have been more precisely on what i am doing, at  
least i am not thinking to blindly accept known.
let me describe the scenario and what i am doing:
we have a radius server which is contacted by a vpn-concentrator, a  
wlan-router and several switches which have dynamic ports (with vlan  
based on mac) and 802.1x ports (vlan based on users).
depending on the huntgroup (chosen via nas-ip-address) i am setting  
auth-type and autz-type. i read on several places that this is  
commonly a very bad idea but i could not think of another way to solve  
it and it works for me (at least it seems so). again, i am open for  
any suggestions/corrections!
the users for vpn and wlan are authenticated/authorized via ldap user  
entries (&(uid=..)(objectclass=posixaccount)), some accounts for wlan  
are also stored in sql (for guests, only valid for a fixed amount of  
days after first usage). the vlans for users and devices are stored in  
radiusprofiles. then finally the mac addresses are stored in a way a  
dhcpd server can understand also, so i do not have redundant entries  
(easier to maintain), all known mac addreses are therefor accepted,  
unknown are rejected (i am using an ldap query 'filter =  
"(dhcpHWAddress=ethernet %{Stripped-User-Name:-%{User-Name}})"' and  
base 'base_filter =  
"(|(objectClass=dhcpHost)(objectClass=ipNetwork))"' to verify in the  
autz section).
and here again: any suggestions/corrections are really appreciated!

since now (just in testing, not yet fully in production) this solution  
does what it should, but there are certainly better ways to do this!

> Example - you could modify the ldap group membership query to find
> groups based on both the username and callingstationid:
> groupmembership_filter = "(|
>    (&(objectClass=GroupOfMacaddrs)(member=%{Calling-Station-Id}))
>    (&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))
>   )"
> Then in "ldap":
> dn: cn=GoodMacs,dc=example,dc=com
> objectClass: top
> objectClass: GroupOfMacadds
> member: 00:11:22:33:44:55
> member: 66:77:88:99:aa:bb
> Then in the "users" file:
> DEFAULT	Ldap-Group == "GoodMacs"
> 	Fall-Through = No
> DEFAULT	Auth-Type := Reject
> 	Reply-Message = "your mac is unknown"
> There are lots of variations of this scheme.

i am not sure if your approach could really fullfill my needs (no  
redundancy, serving different types of "requests") ... but i would  
really like to know ;-)

with best regards

| Markus Krause, Mogli-Soft                                       |
| Support for Mac OS X, Webmail/Horde, LDAP, RADIUS               |
| by order of the                                                 |
|    Computing Center of the Max-Planck-Institute of Biochemistry |
| E-Mail: krause at  |  Tel.: 089 - 89 40 85 99       |
|         markus.krause at  |  Fax.: 089 - 89 40 85 98       |
|  Skype: markus.krause          | iChat: markus.krause at   |

      This message was sent using
If you encounter any problems please report to rz-linux at

More information about the Freeradius-Users mailing list