vlan ldap radiusd

[Serge van Namen]

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 
> layer.

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 
> authentication.

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 
> access.

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. :)

Just:

User A: VLAN X
User B: VLAN Y
User C: VLAN X

etc.

> 
> 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'.

Thanks! One of the things I was looking for.

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

Yours,

Serge

> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html