radiusd core dumps on authentication (solaris 9)
Hello freeradius-users!
I am currently experiencing an authentication problem and am wondering
if anyone has run into something similar (or has an answer as to what
I'm doing wrong
I am running freeradius 1.0.5 on a Solaris 9 box. I have my users
accounts currently stored in a NIS/YP database hosted by a Linux (Suse
SLES9) server. My users - configuration file - currently looks like
this:
DEFAULT Auth-Type = Pam
Fall-Through = No
I have tried using Auth-Type = {System | Pam | unix}. No matter which I
try radiusd core dumps as soon as it comes to the Authenticate module
(see debug log below). This does not happen if I set Auth-Type = Local,
then everything works as expected. _But_ that would give me two username
/ password databases to maintain - which is not something I look forward
to Anyone have any ideas as to what's going on?
TIA,
Johan
PS. No idea if this helps but I have an old freeraidius 1.0.2 lying
around. The results (using the same config files) are the same.
debug log
---
/etc/init/freeradiusd start
Module: Instantiated realm (MIP02)
realm: format = suffix
realm: delimiter = @
realm: ignore_default = no
realm: ignore_null = no
Module: Instantiated realm (NULL)
detail: detailfile =
/opt/freeradius/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d
detail: detailperm = 384
detail: dirperm = 493
detail: locking = no
Module: Instantiated detail (detail)
Module: Loaded radutmp
radutmp: filename = /opt/freeradius/var/log/radius/radutmp
radutmp: username = %{User-Name}
radutmp: case_sensitive = yes
radutmp: check_with_nas = yes
radutmp: perm = 384
radutmp: callerid = yes
Module: Instantiated radutmp (radutmp)
detail: detailfile =
/opt/freeradius/var/log/radius/radacct/detail-combined
detail: detailperm = 384
detail: dirperm = 493
detail: locking = yes
Module: Instantiated detail (accounting_replication_log)
detail: detailfile =
/opt/freeradius/var/log/radius/radacct/%{Client-IP-Address}/pre-proxy-detail-%Y%m%d
detail: detailperm = 384
detail: dirperm = 493
detail: locking = no
Module: Instantiated detail (pre_proxy_log)
detail: detailfile =
/opt/freeradius/var/log/radius/radacct/%{Client-IP-Address}/post-proxy-detail-%Y%m%d
detail: detailperm = 384
detail: dirperm = 493
detail: locking = no
Module: Instantiated detail (post_proxy_log)
Module: Loaded eap
eap: default_eap_type = md5
eap: timer_expire = 60
eap: ignore_unknown_eap_types = no
eap: cisco_accounting_username_bug = no
rlm_eap: Loaded and initialized type md5
rlm_eap: Loaded and initialized type leap
gtc: challenge = Password:
gtc: auth_type = PAP
rlm_eap: Loaded and initialized type gtc
mschapv2: with_ntdomain_hack = no
rlm_eap: Loaded and initialized type mschapv2
Module: Instantiated eap (eap)
detail: detailfile =
/opt/freeradius/var/log/radius/radacct/%{Client-IP-Address}/reply-detail-%Y%m%d
detail: detailperm = 384
detail: dirperm = 493
detail: locking = no
Module: Instantiated detail (reply_log)
Listening on authentication *:1812
Listening on accounting *:1813
Listening on proxy *:1814
Ready to process requests.
rad_recv: Access-Request packet from host 192.168.11.249:3644, id=171,
length=121
NAS-IP-Address = 192.168.11.249
NAS-Identifier = vrr_ggsn_2
Called-Station-Id = .xxx.xx
Service-Type = Framed-User
Framed-Protocol = GPRS-PDP-Context
NAS-Port-Type = Virtual
User-Name = daniel
User-Password = secret
Calling-Station-Id =
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
modcall[authorize]: module preprocess returns ok for request 0
radius_xlat:
'/opt/freeradius/var/log/radius/radacct/192.168.11.249/auth-detail-20051229'
rlm_detail:
/opt/freeradius/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d
expands to
/opt/freeradius/var/log/radius/radacct/192.168.11.249/auth-detail-20051229
modcall[authorize]: module auth_log returns ok for request 0
users: Matched entry DEFAULT at line 152
modcall[authorize]: module files returns ok for request 0
modcall: group authorize returns ok for request 0
rad_check_password: Found Auth-Type Pam
auth: type PAM
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 0
pam_pass: using pamauth string radiusd for pam.conf lookup
Segmentation Fault - core dumped
radiusd
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Multiple accounting hosts for one realm?
On Wed, 2005-12-21 at 22:07 +0100, Nicolas Baradakis wrote: Johan Ramm-Ericson wrote: While configuring freeradius 1.0.5 on Solaris 9 I began to look at setting up different accounting hosts for users depending on which realm users orginated from. That worked fine. However; I have now come across a situation where it might be valuable to send the same accounting information to multiple accounting hosts. I am hoping to do this by changing the accthost variable in etc/raddb/proxy.conf. Does anyone on the list know if (a) this is possible, and if it is possible (b) how to do it - i.e can I add further hosts in a list to the existing variable or do I need to use some other method? You might look at radrelay, it comes with FreeRADIUS. http://freeradius.org/radiusd/doc/radrelay -- Nicolas Baradakis Ooopps, sorry about that. I thought I'd gone through the documentation, but obviously my search was not thorough enough... Thanks! /Johan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Multiple accounting hosts for one realm?
Hello Freeradius-users! While configuring freeradius 1.0.5 on Solaris 9 I began to look at setting up different accounting hosts for users depending on which realm users orginated from. That worked fine. However; I have now come across a situation where it might be valuable to send the same accounting information to multiple accounting hosts. I am hoping to do this by changing the accthost variable in etc/raddb/proxy.conf. Does anyone on the list know if (a) this is possible, and if it is possible (b) how to do it - i.e can I add further hosts in a list to the existing variable or do I need to use some other method? Thanks! /jre - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: tool for testing machine authentication
Date: Tue, 22 Nov 2005 14:20:29 -0500 From: Alan DeKok [EMAIL PROTECTED] Subject: Re: tool for testing machine authentication To: FreeRadius users mailing list freeradius-users@lists.freeradius.org Message-ID: [EMAIL PROTECTED] Brian A. Seklecki [EMAIL PROTECTED] wrote: It is time for someone to step up and start writing some serious documentation. sigh Once again, the generic someone, meaning not me. Alan DEKok. Hi, having just recently succesfully setup freeradius and being somewhat frustrated with the documentation, I felt there may be someway I could contribute to improve it. A while back there was a thread on the mailinglist to the effect of setting up a Wiki. Has this seen any progression? If not, I'll be glad to put in some effort to get this done. Also, I'm willing to pitch in on writing the documentation, however my freeradius experience is so recent that I'd probably only be able to do any good with well-defined tasks... /johan r-e - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
