240 likes | 339 Views
Eduroam debugging. Gurvinder Singh and Gunnar Bøe , Campus Networks and Systems, UNINETT AMRES Wireless workshop Belgrade, 12 September 2011. Eduroam in Norway. Eduroam Architecture. Top level RADIUS. Nation A Radsec Proxy. Nation B Radsec Proxy. Inst. B 2.
E N D
Eduroam debugging Gurvinder Singh and Gunnar Bøe, Campus Networks and Systems, UNINETT AMRES Wireless workshop Belgrade, 12 September 2011
Eduroam Architecture Top level RADIUS Nation A Radsec Proxy Nation B Radsec Proxy Inst. B2 Inst. A1 Inst. A2 Inst. B1
Issues User unable to connect while roaming. How to locate the problem ? Is it at the client device, station ID, visiting institution's radius server, national proxy or home radius server ?
Challenges Distributed architecture Inter-institution/international roaming Heterogeneous environment (FreeRadius, Microsoft radius server etc..) Encrypted traffic Privacy issues
History • Radius log files are nice, BUT…. • Debugging eduroam is complicated • Lack of access to radius logs on other levels • The guys who did something about it Gurvinder Singh Tore Kristiansen Kolbjorn Barmen Gunnar Boe JardarLeira
Edudbg Design Due to the mentioned challenges, edudbg monitors the request logs at national radsec proxy level. Parse and store the information in a easily accessible and searchable way to help in finding the problem at hand.
Edudbg's Components Edudbg-logger Parse & store the radsec proxy log file in to the database. Edudbg-webservice Reads the database for search and make it easily accessible for users/administrators. Authentication plug-in Authorisation plug-in
Privacy issues • Access to RADIUS logs on higher level can expose information (who, where, when) about people from other organisations • Solution: • Supports federated security systems e.g. Feide. • Only grant access to information related to your own organisation • No more information exposed than you already have access to
Edudbg Architecture Federated login
Edudbg-webservice Reads the database and allows user to access debug information in user friendly way. Hides the complexity caused by eduroam architecture and makes debugging easy.
Edudbg Usage scenario Edudbg can be used to detect the connection failure. It can also be used by administrators for proactive maintenance e.g. detecting radius server loops.
Demo interface file:///F:/all/GigaCampus/Mobilitet/edudbg/documentation%20examle.htm http://eduroam.no
Eduroam Architecture Top level RADIUS Nation A Radsec Proxy Nation B Radsec Proxy Inst. A1 Inst. B2 Inst. A2 Inst. B1
Use cases (missing realm) Missing realm name causes the national proxy to forward the request to local radius server. Whereas the given user does not belong to this organization, where request has been rejected.
Use cases (incorrect realm) Misspelled realm name causes the national proxy to forward the request to top level servers and thus request has been rejected.
Use cases (incorrect password) The contents of request seems to be fine and request has been routed to correct home server. The reason for getting access-reject is at the home institution side and most likely is incorrect password.
Use cases (Radius Server Loop) The contents of request seems to be fine and request has been routed to correct home server. But the request comes from the same institution and routed back to the same. This should not happen, as institution should forward request to national proxy only if the user is from another institution.
Edudbg Experience Our experience from running the edudbg service till yet shows that almost 70 - 80% issues occurs due to incorrect information sent in request e.g. misspelled username, password or incorrect realm. Edudbg helps in debugging of the mentioned cases. To get more deep in to the problem, it requires log information from local institution which requires further discussion.
Discussion Should we deploy at national proxy level or institutional level. Should log information be in fixed format or default format. For how long should such information records be kept in database.
Useful links • Wireless best practice: • http://www.terena.org/activities/campus-bp/bpd.html • Slides from this workshop: • https://ow.feide.no/geantcampus:wireless_sept_2011
More information / Contact GEANT3 NA3 Task 4: Campus Best Practice • http://www.geant.net/About_GEANT/Campus_Best_Practice/Pages/home.aspx • http://http://www.terena.org/activities/campus-bp/ • gn3campus@uninett.no • Look out for more BPDs coming along… • Subscribe to announcements • campus-bp-announcements@terena.org
Thank you! Contact: campus@uninett.no