vlan ldap radiusd

[Alexander Clouter]

Serge van Namen <svnamen at snow.nl> wrote:
> 
> In our situation the user is bound to a VLAN, so on every workstation 
> in the building the user authenticates and the switchport becomes a 
> member of the correct VLAN.
>
I *strongly* recommend not mixing host and user authentication, it's 
just too much of a brain <explitive>.  What happens on a computer you 
can SSH, terminal services into...user or host authentication?  Sure you 
can generalise, but you might as well just ignore the problem 
altogether.  Another example, user A walks in and authenticates 
themselves to the network and goes into VLAN x, that user then goes to 
lunch and evil user B starts to use the machine...

Obviously we all have our own policies and needs, but I recommend you 
push the 'user authentication' (authorisation too) into a higher level 
such as the application/server and not try to do it at the network 
layer.

This does not mean you cannot use user authentication to bootstrap host 
authentication.  For example our mindset here at work is that the user 
is stating "I am responsible for this MAC address during this 
session"...they might also be authorised to register that workstation 
into a particular VLAN to create some workstation credentials.  
'un-registered' (user bootstrapped) workstations go into VLAN 
'users-unmanaged' whilst our equipment goes into 'users-staff'.

Hope that makes sense...? :)
 
> Correct me if I'm wrong but then we have to administer a separate 
> database for hosts ( and in our case users ) Now we have 2 auth-types 
> en autz-type's.
> 
> 1 connects with cn=x,dc=example,dc=com (VLANid x)
> 1 connects with cn=y,dc=example,dc=com (VLANid y)
> 
> Depending on the realm the user indicates when logging in 
> (user at realm), autheticates and puts the "Tunnel-Private-Group-Id" in 
> the reply with the correct VLAN id.
> 
Well, you could just have users members of network groups instead (do 
*not* repurpose an existing group).  I would suggest, if you have the 
time, create an enrollment page.  Unknown MAC addresses (even with a 
valid *user* 802.1X session) are redirected to a webpage to register the 
machine into a network (typically only one, maybe your helpdesk members 
would be permitted to register the equipment into a number of groups).  
This does not mean that you use MAC-auth for that machine, but the 
enrollment session could generate workstation credentials (EAP-TLS) to 
use or you could still enforce that user 802.1X credentials (not 
necessarily the original registraters one) need to be used to gain 
access.

This means you can permit users to register up to five devices for 
example.

> The problem: When using 'Login Window' based 802.1x.
> So when user puts in it's user/pass at the login window, it does it's 802.1x magic.
> 
> But with user at realm, LDAP doesnt understands this ofcourse, so the 
> @realm needs to be stripped when authenicating to LDAP.
> 
> So:
> 
> user at realm ---> radius reads the realm, strips the @realm so LDAP 
> understands, makes it's auth/autz-type.
> 
> I hope you catch my drift. :)
> 
This is covered in the FreeRADIUS documentation (and numerous 'eduroam' 
examples, it looks like you are aiming for this type of thing).  
'suffix' is what you want in your authorize section, you then pass to 
the ldap module 'Stripped-User-Name'.

Cheers

-- 
Alexander Clouter
.sigmonster says: Massachusetts has the best politicians money can buy.