Help desk support of authn/authz failures? Logging detailed messages to SQL?

Arran Cudbard-Bell a.cudbardb at freeradius.org
Tue Sep 27 16:34:18 CEST 2011


> 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 at freeradius.org

Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !





More information about the Freeradius-Users mailing list