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

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.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !