On 802.1x... The idea of 802.1x traffic NOT passing through the AP - it seems to me a bit vague. I mean, as a part of protocol the traffic is being exchanged/proxied (via AP) between the supplicant and the Radius server, therefore it does "pass" through the AP. There is simply no other way. I believe there is no difference in that sense between 802.1x on ethernet versus wireless (switch vs. AP). It would be possible to have gateway be 802.1x authenticator, but that would defeat the purpose of denying access to a user with failed authentication as far on the edge as possible (i.e. AP). That is if you (really) care about where you block it that much! (The effectiveness would be not so much different than let's say a VPN.)
On the issue of roles... Phillipe has talked (sometime ago)about what we do here at U of TN. (We're still evaluatin Bluseocket, Vernier, ReefEdge, 802.1x and such.). As far as roles go, one thing we're sure of is that with 1200 or so AP we're not going to go in a bussines of doing these kind of "favors" to faculty. If they are worried of students being bored in class, they should make classes more interesting. No kidding! We had some requests about shutting down wireless during exams, but there is this thing called peer-to-peer wireless and also those AP can serve other areas, not just the classroom. Managment of those requests is a nightmare. In addition one cannot assume that just because a student enrolls in a class, that he/she cannot opt to study in the library instead, but based on role couldn't access resources due to "being expected to be in classroom". So, assigning roles based on that might bite you back. Similar situation if you make your LDAP "too fancy". Roles should be more generic like: general user (students, faculty, staff), visitors (perhaps rate limit, perhaps no access to mail server, etc.), users who are required to encrypt (people accessing student records and such), devices authenticated based on MAC only (we have some robots on campus), etc. You can put bandwidth abusers in a group and rate limit them, nachi infected users cannot ping, etc. One should not get too excited about this functionality though! It is a management nightmare! Keeping things relatively simple made our wireless network very successfull. Cheers, Predrag --------------------------------------------------------------------- Predrag Radulovic Phone: (865) 974-0301 OIT - Network Services Fax: (865) 974-8655 2339 Dunford Hall University of Tennessee, E-mail: [EMAIL PROTECTED] Knoxville, TN 37996 http://web.utk.edu/~prerad --------------------------------------------------------------------- ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/cg/.
