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
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
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?
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?
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
