Op 14 jul 2011, om 21:30 heeft Alexander Clouter het volgende geschreven:

Serge van Namen <svnamen@snow.nl> wrote:

...

I'm working on a proof-of-concept for 802.1x and dynamic vlan's on switches.

All this works perfectly with user@realm, but now I want to read the vlan ID from a ldap attribute and then send the radius request with that value in "Tunnel-Private-Group-ID".

Reading an attribute for this is argubly silly in the context of LDAP. Better to test for a group membership otherwise you might aswell shovel everything in a relational database like SQL.

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

For us we create host LDAP objects, and then those objects are members of a LDAP group which has details regarding the VLAN in it (and subnetting, etc etc).

I am slowly cobbling bits together on my website[1]. My post-auth looks like: ---- post-auth { ....

# defaults update reply { Tunnel-Type := VLAN Tunnel-Medium-Type := IEEE-802 Tunnel-Private-Group-Id := "unauthorised"

Termination-Action := RADIUS-Request Session-Timeout := 300

Acct-Interim-Interval := 3600 }

if ((EAP-Message) && !(Ldap-UserDn)) { cache_ldap-userdn }

lanwarden_vlan if (!(control:Tunnel-Private-Group-Id) || control:Tunnel-Private-Group-Id == "") { if (Realm == "DEFAULT") { update reply { Tunnel-Private-Group-Id := "eduroam" } } # to be removed once we register personal workstations elsif (Realm == "%{config:local.MY.realm}") { update reply { Tunnel-Private-Group-Id := "users-unmanaged" } } } else { update reply { Tunnel-Private-Group-Id := "%{control:Tunnel-Private-Group-Id}" } } if (reply:Tunnel-Private-Group-Id != "unauthorised") { update reply { # Cisco only support a max of 65535 Session-Timeout := 64800 } }

.... } ----

'cache_ldap-userdn' you can find in the archives and the reasoning for it, meanwhile lanwarden_vlan lurks in policy.conf and looks like: ---- lanwarden_vlan { if ((control:Ldap-UserDn)) { if ("%{md5:%{client:secret}%{Calling-Station-Id}%l}" =~ /[0-7]$/) { update control { Tunnel-Private-Group-Id := "%{ldap_lanwarden1:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}" } if (control:Tunnel-Private-Group-Id == "") { update control { Tunnel-Private-Group-Id := "%{ldap_lanwarden2:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}" } } } else { update control { Tunnel-Private-Group-Id := "%{ldap_lanwarden2:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}" } if (control:Tunnel-Private-Group-Id == "") { update control { Tunnel-Private-Group-Id := "%{ldap_lanwarden1:ldap:///ou=Networks,ou=LanWarden,o=soas?cn?one?(&(objectClass=lanwardenNetwork)(member=%{control:Ldap-UserDn}))}" } } } } } ----

It looks horrible as xlat does *not* support failover. :(

Cheers

[1] http://www.digriz.org.uk/lanwarden

-- Alexander Clouter .sigmonster says: You are so boring that when I see you my feet go to sleep.

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

Op 15 jul 2011, om 11:26 heeft Alexander Clouter het volgende geschreven:

Serge van Namen <svnamen@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@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@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'.

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

Op 15 jul 2011, om 14:34 heeft Alexander Clouter het volgende geschreven:

Serge van Namen <svnamen@snow.nl> wrote:

...

...

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

I work for a university so we have a lot of equipment that we do not maintain but is owned by the students/staff that needs to connect. So, we have three main workstation VLANs: * unauthorised * users-unmanaged * users-staff

Unknown MAC addresses go into 'unauthorised' which is a sandpit network which does nothing more than redirect the web browser to our 'unauthorised workstation' webpage[1]. There they are permitted to get to a few websites (microsoft.com, etc) and to the instructions/tools they need to configure their computer for 802.1X.

When they are 802.1Xing, they get put into 'users-unmanaged' which gives them all the access they could want, and that I am willing to give them. One day, when I find the time, I will have a 'pre-registration' VLAN (or more likely dual-purpose 'unauthorised') for unrecognised MAC addresses that have gotten past 'unauthorised' by doing 802.1X with some user credentials.

'users-staff' is currently MAC-auth workstations that we maintain, the helpdesk would not love me if I forced them to configure each workstation for 802.1X (we are condemned with Novell and not AD...but apparently not for much longer). :)

One day, to get into 'users-staff', you will need to do EAP-TLS, but for now it is just MAC-auth.

There is no different level of access betwork 'users-staff' and 'users-unmanaged' here, we just wanted to keep equipment that we maintain and equipment we do not in different subnets. Mainly to keep the subnet's small :)

Clean solution. :) I accomplished to strip the username, it authenticates successfully against LDAP. But eventually it fails on EAP I think, because the username isn't the original from the request. rlm_realm: Looking up realm "Y" for User-Name = "userA@Y" rlm_realm: Found realm "Y" rlm_realm: Adding Stripped-User-Name = "userA" rlm_realm: Proxying request from user userA to realm Y rlm_realm: Adding Realm = "Y" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 3 users: Matched entry DEFAULT at line 7 modcall[authorize]: module "files" returns ok for request 3 rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[authorize]: module "pap" returns noop for request 3 modcall: leaving group authorize (returns updated) for request 3 Found Autz-Type LdapY Processing the authorize section of radiusd.conf modcall: entering group LdapYfor request 3 rlm_ldap: - authorize rlm_ldap: performing user authorization for userA radius_xlat: '(uid=userA)' radius_xlat: 'ou=y,ou=people,dc=example,dc=com' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=y,ou=people,dc=example,dc=com, with filter (uid=userA) rlm_ldap: Added password {SSHA}XXXXXXXXXXXXX in check items rlm_ldap: looking for check items in directory... rlm_ldap: Adding userPassword as User-Password == "{SSHA}XXXXXXXXXXXXXXXXX" rlm_ldap: looking for reply items in directory... rlm_ldap: user userA authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "Y" returns ok for request 3 modcall: leaving group LdapY (returns ok) for request 3 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 3 rlm_eap: Identity does not match User-Name, setting from EAP Identity. rlm_eap: Failed in handler modcall[authenticate]: module "eap" returns invalid for request 3 modcall: leaving group authenticate (returns invalid) for request 3 auth: Failed to validate the user. Login incorrect: [userA] (from client radius port 16797697 cli 0017-f3f2-4572) Delaying request 3 for 1 seconds Finished request 3 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 22 to 1.2.3.4 port 1024 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 3 ID 22 with timestamp 4e203537 Nothing to do. Sleeping until we see a request. Do I need to add the Suffix again to the reply? Yours, Serge

Cheers

[1] http://www.soas.ac.uk/itsupport/personal-equipment/unauthorised-workstation....

-- Alexander Clouter .sigmonster says: Where do you think you're going today?

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

Op 15 jul 2011, om 23:25 heeft Alexander Clouter het volgende geschreven:

Serge van Namen <svnamen@snow.nl> wrote:

...

I accomplished to strip the username, it authenticates successfully against LDAP. But eventually it fails on EAP I think, because the username isn't the original from the request.

[snipped] users: Matched entry DEFAULT at line 7 modcall[authorize]: module "files" returns ok for request 3

What does this do?

You must not change User-Name at all...I suspect somewhere in your configuration you are doing so to try to fix another problem. If you want the User-Name to be realmless then use Stripped-User-Name or use unlang to populate something like Tmp-String-0.

DEFAULT Suffix == "@realm", Strip-User-Name = Yes, Auth-Type = "LdapY", Autz-Type = "LdapY" Tunnel-Medium-Type = IEEE-802, Tunnel-Type = VLAN, Tunnel-Private-Group-ID = 1

...

rlm_ldap: - authorize rlm_ldap: performing user authorization for userA radius_xlat: '(uid=userA)' radius_xlat: 'ou=y,ou=people,dc=example,dc=com'

What are you xlat'ing? Can we see your configuration? Are you using ldap xlat to set User-Name? If so, don't!

I didn't configure any xlat'ing afaik, maybe default behavior from what I configured above?

Cheers

-- Alexander Clouter .sigmonster says: fortune: not found

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