Dynamic VLAN assignment depending on LDAP user group and MAC address

[Fabrizio Vecchi]

Hi Alan and thanks for the reply.


On 12 October 2013 13:42, Alan DeKok <aland at deployingradius.com> wrote:


> > So far, I managed to do the dynamic VLAN assignment, but cannot seem to
> > get it to work together with the MAC checking.
>

Get them working independently.  Then, put the pieces together.


I managed to get them to work independently, it's the putting together
phase that I can't quite crack... :)


> > I can get an auth to be refused if the MAC is not listed in the
> > authorized_macs file, but can't quite put the two things together.
> > Perhaps I am a bit confused with regards to where to put the MAC check.
>
>   Put it into "authorize".
>
> If I put the MAC check in the authorize section, then I can allow users to
use only the devices in the authorized_macs file (unless I am missing
something). I would like the users to use any device, but just have a
limited access to the network if the device isn't listed in the
authorized_macs file...


> > For now, I just managed to get the check to work only on the
> > authorization phase in sites-enabled/default, but then the VLAN
> > assignment, which is done in the internal-tunnel, seems to overwrite my
> > changes.
>
>   That can be fixed.
>
> > So I tried to put the MAC check in the post-auth section in the default
> > file, but the MAC check doesn't seem to ever work.
>
>   Because the "users" file works differently there.
>

Can you point me to some part of the docs that explain what is different,
please?


>
> > Here are the relevant config files:
>
>   Which seem to use a reasonable approach.
>
> > As you can see, the device wasn't listed in the file, the authentication
> > went fine, saying that the tunnel that I should get has ID 40, but that
> > wasn't overwritten by the authorized_macs check...
>
>   I think part of the problem is you're juggling a lot.  You also
> mentioned MACs and VLANs... and then halfway through the message "Oh,
> there's an inner-tunnel, too".
>
>   Stop with all of your solutions.  Instead, write down exactly what you
> have.  Write down what you want to happen in plain English.  Write down
> what should happen, and when.  Then, convert it to the configuration.
>
>   Your system is using TTLS.  OK... I'll ignore the question of *why*
> you're authenticating unknown MACs.  That seems weird.
>

What I am trying to achieve is the following:
1. Authenticate the users through LDAP
2. IF the user is using a device listed in the authorized_macs file, then
assign a VLAN which depends on the user's LDAP group.
3. IF the user is using another (their own), allow them to access an
"isolated" VLAN, which doesn't allow the device to talk to our servers.

This will allow my colleagues to connect to the Internet with their
devices, but not to mess around with our servers in case there is malware
installed on them.

Does this make sense?


>   The debug log shows this:
>
> [ttls] Got tunneled reply code 2
>     Tunnel-Type:0 = VLAN
>     Tunnel-Medium-Type:0 = IEEE-802
>     Tunnel-Private-Group-Id:0 = "40"
>
>   Where did that VLAN come from?  Why is it there?  If you don't know,
> that's a huge problem.
>

SO SORRY! I pasted twice the sites-available/default file!

It comes from the post-auth section in the inner-tunnel file.
In inner-tunnel, I check if the user belongs to the dept_tech_corporate_it
group, and if so, I update the outher request by assigning a VLAN with ID
40.

This part of the config works properly, as showed by the following few
lines of debug output:

rlm_ldap::ldap_groupcmp: User found in group cn=dept_tech_corporate_it,ou=
Groups,c=gb,dc=mindcandy,dc=com
  [ldap] ldap_release_conn: Release Id: 0
? Evaluating (LDAP-Group ==
"cn=dept_tech_corporate_it,ou=Groups,c=gb,dc=mindcandy,dc=com") -> TRUE


>
>   Generally, the policies should be arranged like this:
>
> authorize: allow only known kinds of authentication
>            decide which authentication method to use
>            grab "known good" passwords
>
> authenticate: run authentication methods
>
> post-auth: return attributes for a successfully authenticated user
>
>
>   In your case, I'd say return to a default configuration.  Then, get
> the MAC address filtering working in post-auth.  Once that's working,
> add VLAN assignment.
>

That seems to be an approach similar to the one I am trying to use. I would
like to do the check of the MAC address for last, so that I can associate
the right VLAN to the user. But for some reason this check doesn't seem to
work.

I guess at the end of the day my question boils down to the following:
where should I put the MAC check, so that the user gets assigned to the
right VLAN?
If I put it in the authorize part of sites-enabled/default, the VLAN update
request will get overwritten by the post-auth part of
sites-enabled/inner-tunnel; and if I put it in the post-auth of the file
sites-enabled/default file (which gets executed after inner-tunnel), the
authorized_macs function always returns noop.

If I could get any pointers towards a working solution, I'd be really
grateful.

Thanks,
Fabrizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20131012/bfc44076/attachment-0001.html>