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