Re: Help desk support of authn/authz failures? Logging detailed messages to SQL?
if(!control:NT-Password && !control:Cleartext-Password){ update control { Reject-Reason := 'AttributeMissing' } } oops... - Arran Cudbard-Bell a.cudba...@freeradius.org Betelwiki, Betelwiki, Betelwiki http://wiki.freeradius.org/ ! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Help desk support of authn/authz failures? Logging detailed messages to SQL?
> 1) How do other people - specifically organizations with a help desk > large enough that they're distinctly separate from anyone with enough > privs to tail a log file - handle user support of authentication failures? In a former life I worked at a largish UK university. Whilst I was there I wrote a user portal application which allowed users to register their equipment and download a supplicant setup program (from CloudPath networks). It also allowed them to see the last few records from the postauth table, so they could self diagnose some faults. As the users were registering equipment Mac-Addresses, we could match them to Calling-Station-ID and pull up failed post-auth records even where the something like host based authentication was being used, and the User-Name was all funky. One of the neat features a colleague had put in a previous version was 'sudo' functionality, whether help desk advisors could sudo into a students account, fix dodgy registrations and view post-auth records. Unfortunately they own the source, as it was written whilst I was under their employment, so I can't release it. For the more fine grained stuff, we did exactly the same as you're doing with the custom Reject-Reason attributes.Though i'd recommend using an enumerated integer instead of a string, and defining a bunch of standard values. > 2) This is proving problematic with users who have EAP > misconfigurations, empty LDAP passwords, etc. that only manifest as a > module failure and only show up in the log file. I've been considering > patching the relevant modules to add/update an attribute on failure, ldap if(notfound){ update control { Reject-Reason := 'UserNotFound' } } if(!control:NT-Password || !control:Cleartext-Password){ update control { Reject-Reason := 'AttributeMissing' } } You can almost certainly do everything you want to do without touching the module source. If you *do* want to edit the source, I recommend adding more Module-Failure-Message attributes (see below), and then submitting the patches, that way you're not stuck applying your patches every update. > since currently AFAIK this information is only available in the log > file, and not anywhere that I can include in the SQL post-auth log. Has > anyone else done anything similar? Yes. We did exactly that. Empty attributes are easy to diagnose, because you can just check for the presence of the control attribute after the LDAP module has run (see above). The student records system that was meant to populate the NT-Password attribute, didn't. Spent many hours camped out on the helpdesk for that first month. This was back in 2007, we were one of the first Universities to do wired 802.1X authentication for the residences, and didn't have anything like CloudPath available :( > Or is more detailed module failure > information accessible through something that I haven't been able to > find in the docs? Module-Failure-Message is sometimes populated with more verbose failure reasons, you'll have to check which modules support this, and whether the information is relevant. I highly recommend the CloudPath dissolvable client, it works for Windows, Mac OSX, Linux and just makes so many of these configuration problems disappear. It's probably about three days to generate a configuration and deploy it (or less if you're motivated). If you wanted a custom portal and you didn't have the time to write one yourselves, Network RADIUS (http://networkradius.com/) offer commercial RADIUS support, and could probably take on the project. It all depends on how much time you have available, and how much you're willing to spend to fix the problem. -Arran Arran Cudbard-Bell a.cudba...@freeradius.org Betelwiki, Betelwiki, Betelwiki http://wiki.freeradius.org/ ! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Help desk support of authn/authz failures? Logging detailed messages to SQL?
Thanks for the quick reply! Alan Buxey wrote: > hi, > > firstly, deployment tool - such as CloudPath xpressconnect or sux1 to ensure > that the user is doing the least amount possible to mess things up (also > ensures > that all the right things such as validate server, RADIUS name etc are all > properly > defined). > We use Cloudpath, but still have issues with either devices that get gronked (iOS comes to mind) or devices that users attempt to "fix". > secondly, capture the output of the logfile (Perl Tail File module is nice) - > which > is why I wanted the radiusd.log file to be the right one - logrotate really > messes > the recent 2.1.x logfile up - so i now have a manual restart of the server > along > with log rotation.hmm.. and putting data (detail file stuff too) into a > database with > a nice web front end for 'low level access' is a must. > To put this nicely... our HD people can't deal with a logfile. They need "if the box is red, read the "Reason" column next to it, and go to that section in the wiki page." Unfortunately student labor isn't the best, and those who are technically competent generally get jobs as sysprogs. > there have been discussions in europe about way of logging the reason for a > failure and > putting it onto a sites secure web area so that users can log in and see why > things arent > working for them > Sounds like exactly what I need. Perhaps a patch to set an internal control: attribute, which could then be logged however (for me, Post-Auth Type Reject also goes to rlm_sql for logging, into such a secure page). > alan > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Help desk support of authn/authz failures? Logging detailed messages to SQL?
hi, firstly, deployment tool - such as CloudPath xpressconnect or sux1 to ensure that the user is doing the least amount possible to mess things up (also ensures that all the right things such as validate server, RADIUS name etc are all properly defined). secondly, capture the output of the logfile (Perl Tail File module is nice) - which is why I wanted the radiusd.log file to be the right one - logrotate really messes the recent 2.1.x logfile up - so i now have a manual restart of the server along with log rotation.hmm.. and putting data (detail file stuff too) into a database with a nice web front end for 'low level access' is a must. there have been discussions in europe about way of logging the reason for a failure and putting it onto a sites secure web area so that users can log in and see why things arent working for them alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Help desk support of authn/authz failures? Logging detailed messages to SQL?
We've rolled out FreeRADIUS as the authentication and authorization server for our University-wide WLAN with 30,000+ users. Our help desk (general IT, not wireless-specific) support staff is made up of student workers, with full-time second-level support and us sysadmins/wireless engineers for third-level support. As we've rolled out WPA2 and the supplicants give no useful information about authentication failures to end-users, our help desk is being inundated with "help, I can't login" calls. We do auth logging to MySQL. Help desk staff are not given access to our authentication servers, so our current solution is to use lots of unlang config kludge in authorize{} to defer any notfound or reject module responses (configurable failover), then use if statements to check the actual return of the module. If it's a "bad" user (notfound, reject, etc.) we set a locally-defined string attribute (control:Reject-Reason) and then reject the user, and Post-Auth Type Reject logs to SQL including that string reason. Which is then accessible in a read-only web tool for the help desk. 1) How do other people - specifically organizations with a help desk large enough that they're distinctly separate from anyone with enough privs to tail a log file - handle user support of authentication failures? 2) This is proving problematic with users who have EAP misconfigurations, empty LDAP passwords, etc. that only manifest as a module failure and only show up in the log file. I've been considering patching the relevant modules to add/update an attribute on failure, since currently AFAIK this information is only available in the log file, and not anywhere that I can include in the SQL post-auth log. Has anyone else done anything similar? Or is more detailed module failure information accessible through something that I haven't been able to find in the docs? Thanks for any advice/insights, Jason -- Jason Antman System Administrator Rutgers University OIT Central Systems & Services / NetOps Office: 732-445-6363 Cell: 732-983-7256 jant...@oit.rutgers.edu - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html