vlan ldap radiusd
Serge van Namen
svnamen at snow.nl
Fri Jul 15 14:04:53 CEST 2011
Op 15 jul 2011, om 11:26 heeft Alexander Clouter het volgende geschreven:
> 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?
Host authentication is already dealt with on a higher level.
Unknown hosts already cannot join the network, ever. :)
> 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...
Isn't that a problem of user awareness?
That is possible in every situation if the user doesn't lock their screen.
Or am I confused now?
> 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
That is already dealt with, this Proof of Concept is just a network security extension, not a whole new implementation.
> This does not mean you cannot use user authentication to bootstrap host
Exactly, the purpose is just for bootstrapping and to create 'flexible-workplaces'
> 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.
Don't quit understand this part. :)
> 'un-registered' (user bootstrapped) workstations go into VLAN
> 'users-unmanaged' whilst our equipment goes into 'users-staff'.
> Hope that makes sense...? :)
Do you mean: unauthorized, user be put in default (jailed) vlan?
>> 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
We don't want to manage complex device lists, we just don't want unwanted hardware in our network.
MAC address / device management is not in the scope of the Proof of Concept. :)
User A: VLAN X
User B: VLAN Y
User C: VLAN X
> This means you can permit users to register up to five devices for
>> 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.
>> 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'.
Thanks! One of the things I was looking for.
> Alexander Clouter
> .sigmonster says: Massachusetts has the best politicians money can buy.
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
More information about the Freeradius-Users