Serge van Namen <svna...@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@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@realm, LDAP doesnt understands this ofcourse, so the > @realm needs to be stripped when authenicating to LDAP. > > So: > > user@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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html