Currently they way things are configured the user logs in using Radius and is either a valid user or denied. When the user switches to a directory which is being managed using Apache's Basic Authentication model and an .htaccess file, they are not being re-prompted for a password, but rather the name is being compared against a list of people in a groups file using a method like this:
(in .htaccess file)
AuthGroupFile /usr/local/web/etc/groups
require group foo
I'm guessing that the AuthGroupFile is expecting to go look at a password file which does not exist, and that's generating the 500 error.
Perhaps the question I OUGHT to be asking is how people would handle a situation where:
1) Users should be validated using Radius so that passwords can be encrypted during transmission.
2) Users have to be permitted/denied resources on a directory-by-directory basis without doing this management in a file that has to be modified by "root" (i.e. in a manner which can be automated to accommodate a highly dynamic user/resource scenario).
On Apr 22, 2004, at 3:14 PM, Alan DeKok wrote:
Charles Thomas <[EMAIL PROTECTED]> wrote:
Problem #1: If someone logs in and then tries to access a resource for
which they do not have permission, the server is throwing out an
"Internal Server Error" (Error code 500) to the browser instead of the
proper "Unauthorized" (Error code 401).
And it's pretty much impossible to figure out why Apache is
returning 500 instead of 401.
While many people dislike the near-gigabytes of debug out FreeRADIUS
produces, those logs are *incredibly* useful. When I try figuring out
why Apache is doing, most of the time I give up in frustration.
That being said, the "Internal Server Error" *should* result in a
message being logged in the error file.
--
Charles Thomas
DoIT Network Services Programmer
University of Wisconsin - Madison
1210 W. Dayton St. Rm. B111
Madison, WI 53706
(608) 262-1649 Office
(608) 262-7561 Fax
[EMAIL PROTECTED]
