screws up the current RADIUS request, I'd say go
for it; I'm happy to have the power to shoot myself in the foot. But if
it could crash the radiusd, well, I guess I'll have to be *very*, *VERY*
careful.
--
George C. Kaplan[EMAIL PROTECTED]
IST - Infrastructure Services
the answer I'll get: Write
something better and submit it. When I get time (IF I get time) I'll
do that. Until then, I'll make do with what's there.
--
George C. Kaplan[EMAIL PROTECTED]
IST - Infrastructure Services 510-643-0496
University of California
. What's inconsistent about the above behavior?
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
University of California at Berkeley
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
will select the first entry (always match), then
the authentication module will compare the supplied password 123
with the configured password 126 and the user will be rejected.
I hope I got that right; Phil can correct me if not.
--
George C. Kaplan[EMAIL PROTECTED
George C. Kaplan wrote:
I can't speak to the MySQL problems, but we've observed the same lock-up
behavior of the daemon: unresponsive to RADIUS requests, 98% CPU usage,
only a 'kill -9' will break it loose. (We're running FR 1.0.5 on
FreeBSD 5.5).
In our case, the daemon appears to get
if
that helps.
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
University of California at Berkeley
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
that got loaded at run time.
I ended up setting --with-openssl-includes and --with-openssl-
libraries in the Makefile for the port (I'm using FreeBSD 5.4), and
that solved the problem.
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services
On Apr 1, 2006, at 11:15 AM, Marc Delisle wrote:
George C. Kaplan a écrit :
I had a problem similar to this: 'ldapsearch' worked, but
Freeradius couldn't make an LDAP connection with TLS. It turns
out that my system had two versions of the openssl library, and
radiusd was linking
Bjørn Mork wrote:
George C. Kaplan [EMAIL PROTECTED] writes:
To not log passwords in the detail file, because it puts them at
unnecessary risk of exposure.
The detail module logs radius packets. If that's not what you want,
then you probably shouldn't be using the detail module (except
user-supplied passphrases in a
log file.
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
University of California at Berkeley
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
that invokes rlm_krb5 is explicitly declared in the
authenticate{} section, which is not the case for Kerberos in FR 1.0.5.
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
University of California at Berkeley
-
List info/subscribe
just the attribute value. So
you'd have to be careful if you're adding values to an attribute that
starts out with a single value, but it sounds like it should work.
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
On Mar 17, 2006, at 5:45 PM, Phil Mayers wrote:
George C. Kaplan wrote:
Or you're using an authentication method (Kerberos, in my case) that
isn't one of the standard methods assocated with the authorization
module. (As Alan points out, you have to know what you're doing
to make
this work
script to compare the retrieved LDAP
attributes according to your policy and add the appropriate reply
attributes.
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
University of California at Berkeley
-
List info/subscribe
the request or check items. So, why were %RAD_CHECK and %RAD_REQUEST
made read-only?
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
University of California at Berkeley
-
List info/subscribe/unsubscribe? See http
Phil Mayers wrote:
George C. Kaplan wrote:
I've been wondering about this, in relation to the rlm_perl module. We
see Don't set Auth-Type in the users file all over the place, but with
rlm_perl, the %RAD_CHECK hash is read-only. So if I'm using perl for
authorization, I *have to* set
) that might explain this? Any suggestions
for avoiding the problem or tracking it down in more detail?
Thanks,
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
University of California at Berkeley
Tue Mar 7 14:12:04 2006
an LDAP module during the authorization
phase, it will cause itself to be run during the authenticate phase,
too.
I assume we can still override this (or example, to authorize with LDAP,
but authenticate with kerberos) as we're doing with 1.0.5.
Is this correct?
--
George C. Kaplan
problems.
The RADIUS server is running FreeBSD 5.4-STABLE, using openssl 0.9.8a,
and openldap 2.2.29, both built from ports. (The freeradius is also
built from ports).
Any ideas on what the problem might be, or where I might look next?
Thanks,
--
George C. Kaplan
off the
reject_delay, but I'll try to dig through the source if I can find
time. (I'm wary of debugging modes, as I've already seen that -X
hides the problem).
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
University
?
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
University of California at Berkeley
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
support. I've sent my modifications to the maintainer, who says he'll
be including them soon.
--
George C. Kaplan[EMAIL PROTECTED]
Communication Network Services510-643-0496
University of California at Berkeley
(which also uses version 1.0.1). For some
reason I didn't pursue the heimdal option, but went right to fixing it
up to use MIT Kerberos.
Anyway, the freeradius port includes a patch for x99_rlm.c, so that
it'll build without problems.
--
George C. Kaplan[EMAIL
to the config_items. But only the first one
is checked against the supplied password.
It seems that it ought to be possible to restrict the authorization
based on huntgroup, but I'm not seeing how. Am I missing something
obvious?
Thanks,
--
George C. Kaplan[EMAIL
24 matches
Mail list logo
