how to setup MAC based authentication with LDAP
Alan DeKok
aland at deployingradius.com
Wed Apr 22 13:03:59 CEST 2015
On Apr 21, 2015, at 5:00 PM, Brendan Kearney <bpk678 at gmail.com> wrote:
> i have a virtual server
> configured, /etc/raddb/sites-available/mac-auth-bypass. when i link
> that file into /etc/raddb/sites-enabled and run radiusd -X, i am able to
> do some rudimentary Mac Auth Bypassing. if the mac is in the directory,
> the access is granted. but i need clarification around a couple of
> items.
OK.
> first, i am trying to have the directory reply with some items for VLAN
> assignment. the below attributes are set for the mac i am testing with:
>
> radiusservicetype: Framed-User
> radiustunnelmediumtype: IEEE-802
> radiustunnelprivategroupid: 1
> radiustunneltype: VLAN
That's nice, but did you tell FreeRADIUS to read those attributes from LDAP?
> i can only assume that because of the rudimentary state of my virtual
> server, the items are not being acted upon or given out by the virtual
> server. a plain ldapsearch returns these items. i assume there is a
> piece i am missing, to have this done. where do i find more about what
> piece i am missing?
Read the configuration again. You've configured FreeRADIUS to talk to ldap via:
a) %{ldap:...} which is a string expansion, and nothing more
b) Auth-Type ldap {}. which verifies the password in LDAP, and nothing more
If you want those LDAP attributes to be returned, you MUST list "ldap" in the "authorize" section.
Except that you've already said you don't want the MAC auth users to have a normal user entry in LDAP. And the LDAP module will look for normal user entries when run in the "authorize" section.
So... your requirements are contradictory. You DO want LDAP user entry lookups, so that it returns those LDAP attributes. But you DON'T want LDAP user entry lockups, because you don't have normal users in LDAP.
> second, when the virtual server is enabled, the authentication that i do
> to log into a switch does not work.
Probably because you're disabling normal LDAP users. i.e. you don't list "ldap" in the "authorize" section.
> if i disable the virtual server the
> auth works again. how do i setup things so that both user auth and mac
> auth bypass work at the same time?
Figure out what the differences are between the two kinds of packets. Then, write policies to key off of the differences, and do user auth for one, and MAC auth for the other.
> my switch (cisco sg500) will identify that a client does not support .1x
> and will provide the mac address as the username and password in an EAP
> message.
That's a fairly stupid thing to do, TBH.
> because it is an EAP message, i can leverage the
> Calling-Station-Id attribute, and distinguish user auth vs. mac auth
> bypass with the "if (EAP-Message)" statement.
Yes. And if there's NO EAP-Message, you should run the normal "ldap" module, to get the user entries.
> i assume the mods-available/ldap file is not appropriate for this logic,
> as i tried to add an authorize section to it and i got an error saying
> that was not an appropriate place for an "if" statement.
What did you try, and why did you think it would work? The "man unlang" documentation is pretty clear on this, as is the default configuration.
> ultimately, i am looking to have user auth, mac auth bypass and full .1x
> work side-by-side-by-side, and this is an interim step. i am not sure
> how to get user auth and mac auth bypass working at the same time, when
> both are intended to use ldap for lookups.
For one, the "if (EAP-Message)" checks will match for *both* MAC auth and normal 802.1x. So you'll have to do even more checks to separate those two kinds of packets.
The simple thing to do is this:
1) get 3 virtual servers running. One for normal users, one for 802.1X, and one for Mac auth.
2) look at the differences between the packets for those 3 cases.
3) write a "unified" virtual server which does:
if (packets from normal users) {
normal user policy
}
else if (packets from mac auth) {
mac auth policy
}
else if (packets from 802.1X) {
802.1X policy
}
There's some work to read the packets, but the solution really is that simple.
Alan DeKok.
More information about the Freeradius-Users
mailing list