How can I change proxy based on username?
Hello,
Using Freeradius 2.1.10 I have been trying to see if I can proxy a
request to a remote server but using a different User-Name attribute
based on the original request User-Name attribute.
For example so that:
Request 'j.blo...@plymouth.ac.uk' gets proxied to remote server with
User-Name=j.blo...@plymouth.ac.uk in the proxy request.
Request 'jblo...@plymouth.ac.uk' gets proxied to the same remote server
but uses the User-Name=jbloggs attribute (so no realm) in the proxy
request.
So basically if a username contains a dot, then proxy on the whole thing
(username and realm). But if the username does not contain a dot, then
only proxy on the username, no realm.
I have been trying in the authorize section to use:
=
if (Realm !~ /^(NULL|DEFAULT|LOCAL)$/) {
if (User-Name =~ /^([^.]+)@/) {
update control {
Proxy-To-Realm := NULL
}
}
}
=
The NULL realm will 'strip' the username, and proxy the request to the
remote server. However, testing shows that the User-Name being sent is
the original one still with the realm:
=
Tue Mar 26 12:31:07 2013 : Debug: ++? if (Realm !~ /^(NULL|DEFAULT|
LOCAL)$/)
Tue Mar 26 12:31:07 2013 : Debug: ? Evaluating (Realm !~ /^(NULL|
DEFAULT|LOCAL)$/) - TRUE
Tue Mar 26 12:31:07 2013 : Debug: ++? if (Realm !~ /^(NULL|DEFAULT|
LOCAL)$/) - TRUE
Tue Mar 26 12:31:07 2013 : Debug: ++- entering if (Realm !~ /^(NULL|
DEFAULT|LOCAL)$/) {...}
Tue Mar 26 12:31:07 2013 : Debug: +++? if (User-Name =~ /^([^.]+)@/)
Tue Mar 26 12:31:07 2013 : Debug: ? Evaluating (User-Name
=~ /^([^.]+)@/) - TRUE
Tue Mar 26 12:31:07 2013 : Debug: +++? if (User-Name =~ /^([^.]+)@/) -
TRUE
Tue Mar 26 12:31:07 2013 : Debug: +++- entering if (User-Name
=~ /^([^.]+)@/) {...}
Tue Mar 26 12:31:07 2013 : Debug: [control] returns updated
Tue Mar 26 12:31:07 2013 : Debug: +++- if (User-Name =~ /^([^.]+)@/)
returns updated
Tue Mar 26 12:31:07 2013 : Debug: ++- if (Realm !~ /^(NULL|DEFAULT|
LOCAL)$/) returns updated
Tue Mar 26 12:31:07 2013 : Debug: ++[local_mschap] returns noop
Tue Mar 26 12:31:07 2013 : Debug: [eap] Request is supposed to be
proxied to Realm NULL. Not doing EAP.
Tue Mar 26 12:31:07 2013 : Debug: ++[eap] returns noop
Tue Mar 26 12:31:07 2013 : Debug: ++[files] returns noop
Tue Mar 26 12:31:07 2013 : Debug: ++[expiration] returns noop
Tue Mar 26 12:31:07 2013 : Debug: ++[logintime] returns noop
Tue Mar 26 12:31:07 2013 : Debug: ++[pap] returns noop
...
Tue Mar 26 12:31:07 2013 : Debug: Sending Access-Request packet to host
141.163.1.180 port 1812, id=140, length=191
Tue Mar 26 12:31:07 2013 : Debug: User-Name =
jblo...@plymouth.ac.uk
Tue Mar 26 12:31:07 2013 : Debug: NAS-IP-Address = 127.0.0.1
Tue Mar 26 12:31:07 2013 : Debug: Calling-Station-Id =
02-00-00-00-00-01
Tue Mar 26 12:31:07 2013 : Debug: Framed-MTU = 1400
Tue Mar 26 12:31:07 2013 : Debug: NAS-Port-Type = Wireless-802.11
Tue Mar 26 12:31:07 2013 : Debug: Connect-Info = CONNECT 11Mbps
802.11b
Tue Mar 26 12:31:07 2013 : Debug: EAP-Message =
0x020c00261900170301001b3fb7e62a2e47d33ede49271ebc0c70dc92c4a82ac889c9b1867ddc
Tue Mar 26 12:31:07 2013 : Debug: State =
0x28af050f013700018da3c9b400035b2fcad100
Tue Mar 26 12:31:07 2013 : Debug: Message-Authenticator =
0x
Tue Mar 26 12:31:07 2013 : Debug: Realm = plymouth.ac.uk
Tue Mar 26 12:31:07 2013 : Debug: EAP-Type = PEAP
Tue Mar 26 12:31:07 2013 : Debug: Proxy-State = 0x3132
=
As the output shows 'Request is supposed to be proxied to Realm NULL',
so the authorize bit seems to be working, but the realm is not being
stripped from the username.
The proxy.conf file simply has:
=
realm NULL {
auth_pool = local_proxies
}
=
So the realm should be stripped from the username.
Anyone any ideas about this?
Thanks,
John.
--
John Horne Tel: +44 (0)1752 587287
Plymouth University, UK Fax: +44 (0)1752 587001
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How can I change proxy based on username?
On Tue, 2013-03-26 at 14:13 +, Phil Mayers wrote:
On 26/03/2013 12:50, John Horne wrote:
Hello,
Using Freeradius 2.1.10 I have been trying to see if I can proxy a
request to a remote server but using a different User-Name attribute
based on the original request User-Name attribute.
You can do this, but it might break things because you're using EAP.
Yes, it seems that just changing the 'User-Name' attribute results in
authentication failures (no doubt due to EAP breaking).
What is the upstream proxy?
Microsoft domain controller (DC).
Can you explain why you want to do this? Obviously it's possible to
manipulate the packet in many ways, but your goal may be best
accomplished via a different route.
-
The DC will recognise a users userid (e.g. 'jbloggs') provided it has no
realm. It will also recognise (what I think is the UPN?) which is of the
form 'j.blo...@plymouth.ac.uk'.
However, we have to cater for a mixed format of
'jblo...@plymouth.ac.uk', which is currently used by some users and
working. To do this we need to strip off the realm so that the DC will
recognise just the userid part ('jbloggs'). (For completeness, the
format 'j.bloggs' with no realm is not allowed by us and rejected.)
John.
--
John Horne, Plymouth University, UK
Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How can I change proxy based on username?
On Tue, 2013-03-26 at 15:35 +, Phil Mayers wrote:
On 26/03/2013 15:12, John Horne wrote:
What is the upstream proxy?
Microsoft domain controller (DC).
As in, Microsoft NPS running on a DC?
As far as I know, yes. I don't deal with the Microsoft side of this.
Just to check I understand you - you currently have an NPS instance that
will successfully authenticate:
jbloggs
j.bloggs@domain
...but fails on:
jbloggs@domain
Correct?
No. At present it will authenticate 'jbloggs' and 'jbloggs@domain'. We
want to have it authenticate 'jbloggs' and 'j.bloggs@domain', but
because 'jbloggs@domain' currently works, we need to cater for it but
have to do this by stripping the realm (so it becomes just 'jbloggs').
Don't ask me 'why', I gather that the DC can recognise a userid (such as
'jbloggs') and the UPN ('j.bloggs@domain'), but it cannot recognise
three formats. So we need to change 'jbloggs@domain' to just 'jbloggs'.
Trying to change 'jbloggs@domain' to 'j.bloggs@domain' may be possible,
but we would have to start doing LDAP lookups to dig out the info.
Secondly, of course, is that we would be changing the 'User-Name' sent
to the DC, so I assume EAP would break again.
However, we have to cater for a mixed format of
'jblo...@plymouth.ac.uk', which is currently used by some users and
working. To do this we need to strip off the realm so that the DC will
recognise just the userid part ('jbloggs').
But as you say, this ought to cause EAP failures, so it's useless?
If I can't get 'jbloggs@domain' stripped of the domain, then yes it
could all be useless.
John.
--
John Horne, Plymouth University, UK
Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How can I change proxy based on username?
On Tue, 2013-03-26 at 14:08 +0100, Olivier Beytrison wrote: You could also use the preproxy_users which allow you to rewrite the request before it is proxied. It contains the exact example for your case. Hello, Many thanks for that, I had overlooked that file. I am pleased to say that enabling the DEFAULT example in the file (and correcting it slightly), it worked fine :-) Debug output from radiusd showed that the format 'jblo...@plymouth.ac.uk' was proxied with the realm NULL and using the Stripped-User-Name attribute (which we set in the policy.conf file). This is exactly what we wanted, and it didn't break EAP. I also checked the other formats that we wanted to allow, and they all worked fine too. I'll do further testing tomorrow, but it looks good. John. -- John Horne, Plymouth University, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Policy.conf - multiple @
Hello,
Just taking a look at the FreeRadius 2.2 policy.conf file, and noticed
this section:
=
#
# reject Multiple @'s
# e.g. u...@site.com@site.com
#
if(User-Name =~ /@(.+)?@/i ) {
=
Would this not be simpler just by using '/@.*@/' ?
John.
--
John Horne Tel: +44 (0)1752 587287
Plymouth University, UK Fax: +44 (0)1752 587001
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upgrade to 2.2.0
On Tue, 2012-10-09 at 11:19 -0400, John Dennis wrote: By using a rpm spec file to build rpms from you'll get all the nasty details of correct building handled for you. There are 2.2 rpms available for Fedora. Just be aware spec files are also tuned for specific Red Hat releases, you'll need to understand the differences between Fedora and RHEL 5. All in all it can be non-trivial to get all the details of building and installing a system daemon correct, this is why we normally recommend folks use pre-build packages for their distribution. Unfortunately (?) the differences now between Fedora and RHEL, especially in terms of Fedora using systemctl rather than SysV startup scripts, means that using a Fedora SPEC file to build a package for RHEL is generally fraught with problems. However. I have this afternoon been rebuilding FreeRadius 2.2 using the latest CentOS 5.8 freeradius2 RPM SPEC file. (Basically, using a SPEC file that you know will work on the server, but replace the actual source tarball with the latest available.) In this instance the modifications to the SPEC file were minor, but one patch also had to be modified. So, again, not trivial, you need to know a bit about SPEC files and patching, but it did build. I should add that for other packages this approach hasn't been too good! The differences between code versions can mean that a lot of patches in the RPM either become redundant or need modifying. It can add up to a lot of work. John. -- John Horne Tel: +44 (0)1752 587287 Plymouth University, UK Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Logging of socket command file
Hello, Using FreeRadius 2.1.10, I am seeing a lot of logged 'Info' messages about the socket command file. A snippet shows: Mon Sep 3 11:12:41 2012 : Info: ... adding new socket command file /var/run/radiusd/radiusd.sock Mon Sep 3 11:12:41 2012 : Info: ... closing socket command file /var/run/radiusd/radiusd.sock Mon Sep 3 11:12:42 2012 : Info: ... adding new socket command file /var/run/radiusd/radiusd.sock Mon Sep 3 11:12:42 2012 : Info: ... closing socket command file /var/run/radiusd/radiusd.sock Mon Sep 3 11:12:43 2012 : Info: ... adding new socket command file /var/run/radiusd/radiusd.sock Mon Sep 3 11:12:43 2012 : Info: ... closing socket command file /var/run/radiusd/radiusd.sock Mon Sep 3 11:17:41 2012 : Info: ... adding new socket command file /var/run/radiusd/radiusd.sock Mon Sep 3 11:17:41 2012 : Info: ... closing socket command file /var/run/radiusd/radiusd.sock Mon Sep 3 11:17:42 2012 : Info: ... adding new socket command file /var/run/radiusd/radiusd.sock Mon Sep 3 11:17:42 2012 : Info: ... closing socket command file /var/run/radiusd/radiusd.sock As can be seen this occurs for a few seconds, stops, then starts again five minutes later. I am at a bit of a loss as to what is causing this. My question is, is this something to be concerned about or is it normal for these messages to appear so often? Thanks, John. -- John Horne Tel: +44 (0)1752 587287 Plymouth University, UK Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging of socket command file
On Mon, 2012-09-03 at 12:57 +0200, Alan DeKok wrote: John Horne wrote: Using FreeRadius 2.1.10, I am seeing a lot of logged 'Info' messages about the socket command file. A snippet shows: Mon Sep 3 11:12:41 2012 : Info: ... adding new socket command file /var/run/radiusd/radiusd.sock ... As can be seen this occurs for a few seconds, stops, then starts again five minutes later. I am at a bit of a loss as to what is causing this. radmin. You have configured a cron job to run radmin. My question is, is this something to be concerned about or is it normal for these messages to appear so often? It's your system. You caused this to happen. Okay, that's what I thought might be the reply. Trouble is I can't find what is running radmin. I'll keep looking :-) Thanks. John. -- John Horne Tel: +44 (0)1752 587287 Plymouth University, UK Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeRADIUS 2.1.10 regression in logging behaviour
On Fri, 2010-11-26 at 21:08 +, Alan Buxey wrote: hi, one eagle-eyed member spotted a small issue with our systems after the upgrade to 2.1.10 (which, frankly I'd overlooked because to me its more important that people can actually authenticate and we've got good accounting etc :-) ) anyway, its this. the standard radius.log file which records a few items of interest is no longer logrotated correctlyie logrotate comes along, the file gets a new number/name and a new file is created for radiusd to keep using...except it doesnt. in the end you end up with eg radius.log.5 radius.log.4 radius.log.3 radius.log.2 radius.log.1 radius.log where all the newer ones are zero bytes and radius.log.5 is several meg in size the sudden obvious fix is to add the HUP/restart part to the logrotate script but we've never ever had to do this in the past...and I'm loathe to do such a thing... In our log rotation (on CentOS) we use: prerotate /sbin/service radiusd stop /dev/null endscript postrotate /sbin/service radiusd start /dev/null endscript This occurs at around 4am. We have not had any problems with it. John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
On Thu, 2010-09-23 at 12:05 +0200, Alan DeKok wrote: John Horne wrote: So, I guess the question is why is freeradius reloading the post-proxy filter a second time after the HUP? The question is why do you have two configurations for the same module? The only bug here is that the server should complain if you have two instances of the same module defined. That would prevent the server from starting in this case, and highlight the fact that the configuration is wrong. Ah, okay our mistake. Sorry about that. As far as I remember we created the module with the same name and it seemed to work. Obviously 'seemed to work' is not the same as 'works in all cases', and not necessarily the right way to do things. We will rename our local module. Thanks, John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
On Wed, 2010-09-22 at 15:15 +0200, Alan DeKok wrote: I've put some preliminary tar files on: http://git.freeradius.org/pre/ If there are any issues, let me know now. We have an issue but I am a little lost as to where things are going wrong. If I set the uid/gid and 'mode=rw' in control-socket, and then restart the radiusd process, all is okay. However, if I then run 'radmin -e hup', the radius log file shows the re-reading of the config file and modules being reloaded, but *some* of our users cannot then authenticate. The server provides authentication for both wireless users and VPN users. For wireless users the wireless lan controller talks to the radius server, and the server proxies the request on to a backed IAS server. This works fine in all instances. The VPN users take a slightly different route in that they use a PPTP connection, which calls a PPP radius.so object. This in turn accesses the radius server (which is running on the same host), and that proxies the request off as with wireless users. The problem seems to be that although the proxy server returns a 'Yes' reply (meaning the user is authenticated) for the VPN users, the pppd process does not seem to recognise it and treats it as a failed CHAP authentication. As such what we see is the radius log saying the user has authenticated okay, but the user receives a 691 (I think) code indicating that there is a problem with their userid/password. Why this only occurs when we use 'radmin -e hup' I don't know. I can only guess that maybe something isn't being reloaded. If we do not use the control-socket then it all works fine for all our users. I have - finally - got this working (or rather failing) on a test server. So I can try to tackle the problem without affecting our live servers. A small log file snippet from the server: The radius log shows (having just issued 'radmin -e hup'): Wed Sep 22 16:41:57 2010 : Info: Received HUP signal. Wed Sep 22 16:41:57 2010 : Info: HUP - Re-reading configuration files Wed Sep 22 16:41:57 2010 : Info: HUP - loading modules Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module suffix Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module acct_log Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module attr_filter.post-proxy Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module radutmp Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module suffix Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module attr_filter.post-proxy Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module attr_filter.access_reject Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module attr_filter.accounting_response Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module radutmp Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module pap Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module files Wed Sep 22 16:41:57 2010 : Info: Loaded virtual server inner-tunnel Wed Sep 22 16:41:57 2010 : Info: Loaded virtual server default Wed Sep 22 16:41:57 2010 : Info: ... closing socket command file /var/run/radiusd/radiusd.sock Wed Sep 22 16:42:38 2010 : Auth: Login OK: [jhorne] (from client localhost port 0 cli 141.163.60.7) However, our daemon log file shows: Sep 22 16:42:37 jhvm1 pppd[27048]: rcvd [CHAP Response id=0xd3 4a95b44a8179d661b7dc7036d88274d0b309bacedf503df09b5c81ed196320a2c3a6accc68c1f70600, name = jhorne] Sep 22 16:42:38 jhvm1 pppd[27048]: Yes Sep 22 16:42:38 jhvm1 pppd[27048]: Peer jhorne failed CHAP authentication Sep 22 16:42:38 jhvm1 pppd[27048]: sent [CHAP Failure id=0xd3 Yes\n] Sep 22 16:42:38 jhvm1 pppd[27048]: sent [LCP TermReq id=0x2 Authentication failed] The 'Yes' is returned by the proxy server. For some reason pppd is logging this and treating it as a chap failure. Normally it does not log the reply as text, but instead sends a chap response: Sep 22 16:45:00 jhvm1 pppd[27176]: rcvd [CHAP Response id=0xc8 ff1620e9777e6dcb8e906e0fa61ce86d4fcd1bb474b5278994d471503893a392f3a596b66fb4532000, name = jhorne] Sep 22 16:45:00 jhvm1 pppd[27176]: sent [CHAP Success id=0xc8 S=B18D5D0EC139ECCB0D17EBADF2DE818BCD7DF55B] Although this looks like a pppd problem, it only occurs after we have issued 'radmin -e hup'. If we don't use the control-socket, or just use it without issuing a 'hup', then pppd works fine. John. -- John Horne Tel: +44 (0)1752 587287 University of Plymouth, UK Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
On Wed, 2010-09-22 at 18:53 +0200, Alan DeKok wrote:
John Horne wrote:
The problem seems to be that although the proxy server returns a 'Yes'
reply (meaning the user is authenticated)
What does that mean? There is no standard attribute to transport a Yes.
Sorry, the 'Yes' is just the reply-message from the proxy server.
Although this looks like a pppd problem, it only occurs after we have
issued 'radmin -e hup'. If we don't use the control-socket, or just use
it without issuing a 'hup', then pppd works fine.
Use tcpdump to see what the Access-Accepts look like before after
the HUP.
I ran radiusd -X instead and saw:
For a working login:
=
Login OK: [jhorne] (from client localhost port 0 cli 141.163.60.7)
# Executing section post-auth from file /etc/raddb/sites-enabled/default
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 24 to 127.0.0.1 port 59536
Framed-IP-Address = 141.163.192.64
MS-MPPE-Encryption-Types = 0x0004
MS-MPPE-Encryption-Policy = 0x0002
MS-CHAP2-Success =
0xdb533d43314635413343393031354536343336343346313837304135454345383546444545363443433432
Reply-Message = Yes
MS-MPPE-Recv-Key = 0xdbeaf9748e2221f03f521d891346d33f
MS-MPPE-Send-Key = 0xc346ea6996ae8388f9de48e0f2fa0434
Finished request 0.
=
For a failed login:
=
Login OK: [jhorne] (from client localhost port 0 cli 141.163.60.7)
# Executing section post-auth from file /etc/raddb/sites-enabled/default
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 27 to 127.0.0.1 port 53597
Framed-IP-Address = 141.163.192.64
MS-MPPE-Encryption-Types = 0x0004
MS-MPPE-Encryption-Policy = 0x0002
Reply-Message = Yes
MS-MPPE-Recv-Key = 0xa6f4391a49e2df2088d8807bd929eef6
MS-MPPE-Send-Key = 0x1d8311b17d07f5a1be38f07abe1211e3
Finished request 3.
=
The failed login has no MS-CHAP2-Success attribute being sent back.
John.
--
John Horne Tel: +44 (0)1752 587287
University of Plymouth, UK Fax: +44 (0)1752 587001
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Last call for 2.1.10
On Wed, 2010-09-22 at 18:02 +0100, John Horne wrote:
The failed login has no MS-CHAP2-Success attribute being sent back.
Okay. The problem is to do with attribute filtering, but that in turn
seems to be caused by freeradius doing something unexpected when it
receives the HUP.
We define the file /etc/raddb/attrs.post-proxy which contains the
following:
plymouth.ac.uk
MS-CHAP2-Success =* ANY,
Fall-Through = Yes
NULL
MS-CHAP2-Success =* ANY,
Fall-Through = Yes
DEFAULT
Service-Type == Framed-User,
Service-Type == Login-User,
Login-Service == Telnet,
... (other attributes/values)
We also have the file /etc/raddb/modules-local/attr_filter which
contains:
attr_filter attr_filter.post-proxy {
attrsfile = ${confdir}/attrs.post-proxy
}
So when freeradius starts up it reads this file, and uses the defined
module in preference to the one in the
file /etc/raddb/modules/attr_filter. Running 'radiusd -X' shows:
===
Starting - reading configuration files ...
...
including configuration file /etc/raddb/modules-local/attr_filter
...
including configuration file /etc/raddb/modules/attr_filter
...
Module: Checking post-proxy {...} for more modules to load
Module: Instantiating module attr_filter.post-proxy from
file /etc/raddb/modules-local/attr_filter
attr_filter attr_filter.post-proxy {
attrsfile = /etc/raddb/attrs.post-proxy
key = %{Realm}
}
===
As can be seen the correct module file is used. Now lets do a HUP:
===
... new connection request on command socket.
Listening on command file /var/run/radiusd/radiusd.sock
Ready to process requests.
radmin hup
Ready to process requests.
Received HUP signal.
HUP - Re-reading configuration files
...
including configuration file /etc/raddb/modules-local/attr_filter
...
including configuration file /etc/raddb/modules/attr_filter
...
Module: Trying to reload module attr_filter.post-proxy
attr_filter attr_filter.post-proxy {
attrsfile = /etc/raddb/attrs.post-proxy
key = %{Realm}
}
Module: Reloaded module attr_filter.post-proxy
...
Module: Trying to reload module attr_filter.post-proxy
attr_filter attr_filter.post-proxy {
attrsfile = /etc/raddb/attrs
key = %{Realm}
}
Module: Reloaded module attr_filter.post-proxy
===
As can be seen, after the HUP freeradius loads the original file, but
then reloads the default one (/etc/raddb/modules/attr_filter which uses
/etc/raddb/attrs). This default filter file has no MS-CHAP2-Success
entry, so that attribute would be filtered out.
Looking at the processing of the access accept packet shows this too:
===
rad_recv: Access-Accept packet from host 141.163.195.250 port 1812,
id=137, length=194
Framed-IP-Address = 141.163.192.64
MS-MPPE-Encryption-Types = 0x0004
MS-MPPE-Encryption-Policy = 0x0002
MS-CHAP2-Success =
0x8c533d32373939374535323141364234394141453336314337343341313436383936323043393032433045
Reply-Message = Yes
MS-MPPE-Recv-Key = 0xf6ee626fa0a9ceea0c565916916e4a5a
MS-MPPE-Send-Key = 0x12c24a8d04f33b97b786c120f155aa4f
Proxy-State = 0x3338
# Executing section post-proxy from
file /etc/raddb/sites-enabled/default
+- entering group post-proxy {...}
[eap] No pre-existing handler found
++[eap] returns noop
[files] users: Matched entry jhorne at line 213
[files] expand: %{User-Name} - jhorne
[files] expand: %{User-Name} - jhorne
[files] expand: %{User-Name} - jhorne
[files] expand: %{Calling-Station-Id} - 141.163.60.243
[files] users: Matched entry DEFAULT at line 269
++[files.authorize] returns ok
[attr_filter.post-proxy]expand: %{Realm} - NULL
attr_filter: Matched entry DEFAULT at line 103
++[attr_filter.post-proxy] returns updated
===
The 'Matched entry DEFAULT at line 103' is from the
file /etc/raddb/attrs, and so the MS-CHAP2-Success attribute is removed
and the client see a failure/reject rather than a success.
The 'radiusd -X' output when a HUP hasn't been given shows:
===
[attr_filter.post-proxy]expand: %{Realm} - NULL
attr_filter: Matched entry NULL at line 5
attr_filter: Matched entry DEFAULT at line 9
++[attr_filter.post-proxy] returns updated
===
And the lines 5 and 9 correspond to our defined file which allow for the
MS-CHAP2-Success attribute.
So, I guess the question is why is freeradius reloading the post
Radmin - hup query
Hello, Running Freeradius 2.1.10 on CentOS 5.5 I have been taking a quick look at the radmin 'hup' command. However, I am having a problem getting it to work: radmin -e hup ERROR: You do not have write permission. See mode = rw in /var/run/radiusd/radiusd.sock However, the socket file shows: ls -l /var/run/radiusd/radiusd.sock srw-rw 1 radiusd radiusd 0 Sep 10 04:02 /var/run/radiusd/radiusd.sock ls -ld /var/run/radiusd drwxr-xr-x 2 radiusd radiusd 4096 Sep 10 04:02 /var/run/radiusd If I run the radmin command as root or the radiusd user, I get the ERROR message. Additionally in the radius log file I see (when the radmin command is run): Fri Sep 10 12:59:28 2010 : Info: ... adding new socket command file /var/run/radiusd/radiusd.sock Fri Sep 10 12:59:28 2010 : Info: ... closing socket command file /var/run/radiusd/radiusd.sock I'm not sure what the first message means as the file already exists, and the second one says it is closing the socket, yet the socket file still exists (unless it literally means it is closing the socket but leaving the file there.) Any suggestions as to what is going on here? John. -- John Horne Tel: +44 (0)1752 587287 University of Plymouth, UK Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Radmin - hup query
On Fri, 2010-09-10 at 14:17 +0200, Alan DeKok wrote: John Horne wrote: Running Freeradius 2.1.10 on CentOS 5.5 I have been taking a quick look at the radmin 'hup' command. However, I am having a problem getting it to work: radmin -e hup ERROR: You do not have write permission. See mode = rw in /var/run/radiusd/radiusd.sock See the default configuration file for the control socket. Ah! Yes, it now works. The error message is a little misleading as I was looking at the actual socket file to see what the problem was (and as far as I could see it had rw access). Thanks. John. -- John Horne Tel: +44 (0)1752 587287 University of Plymouth, UK Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
On Tue, 2010-09-07 at 22:26 +0200, Alan DeKok wrote: John Horne wrote: We have been running 3 servers with 2.1.10 (taken from git a while ago) The proxy change went in August 4. for some time with no problems. They act as a proxy, receiving requests from wireless lan controllers and (mostly) proxying them on to MS IAS. Is there any particular change that you wanted feedback on? What happens when a home server is marked zombie / dead. Previously, if *one* request didn't get a response, the home server was marked zombie. If the proxy then received a response, the home server was marked alive. i.e. if a proxy was sending packets for realm A B to a home server, and the home server was responding only for realm A and not B... then the home server could be marked zombie / alive / zombie / alive in quick sequence. It now keeps track of recent replies. If the home server is responding for realm A, then it will always be marked alive, even if it's not responding for realm B. The home server is marked as zombie only when it receives *no* replies for a period of time. I hope that explanation makes sense... We don't have that exact scenario, but, for whatever reason, we were seeing the home servers being marked dead/zombie extremely frequently - usually every few minutes. With the later git version (dated 1 September in the changelog file) we are seeing much fewer changes of the home servers being marked dead/zombie. From your description above I suspect this is what you were aiming for. A simple count of messages in our (daily) log files shows: grep -c dead radius.log.1(yesterday, 24 hours) 416 grep -c Proxy: radius.log.1 1859 grep -c dead radius.log (today, 12 hours) 34 grep -c Proxy: radius.log 154 Unless we have had a sudden change in our home servers, and/or network, (we haven't) the numbers do indicate that the freeradius code is now less 'aggressive' in marking a home server dead/zombie. (Our numbers are still probably high compared to other sites; we are still investigating the cause of the problem.) John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
On Tue, 2010-09-07 at 21:19 +0200, Alan DeKok wrote: I'd like to get some feedback on the pre-release of 2.1.10, especially the changes to the proxy code. We have been running 3 servers with 2.1.10 (taken from git a while ago) for some time with no problems. They act as a proxy, receiving requests from wireless lan controllers and (mostly) proxying them on to MS IAS. Is there any particular change that you wanted feedback on? John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
On Tue, 2010-09-07 at 22:26 +0200, Alan DeKok wrote: John Horne wrote: We have been running 3 servers with 2.1.10 (taken from git a while ago) The proxy change went in August 4. Ah. Our versions date back to June. I'll see about upgrading them to a later 2.1.10 version. (Hopefully that will be tomorrow.) John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Pre release of 2.1.10
On Tue, 2010-09-07 at 22:28 +0200, Alan DeKok wrote: Alan Buxey wrote: Please test it out, and give feedback on issues / benefits. The file doc/ChangeLog contains all of the changes and new features in the server. fails to compile on older redhats with python : What version of RedHat? I have just tried the latest git 2.1.10 version on RHEL3 (update 9), and configure shows: configure: WARNING: silently not building rlm_python. configure: WARNING: FAILURE: rlm_python requires: Python.h libpython2.2. 'make' works, but skips over making anything in the rlm_python directory. Python is python-2.2.3-6.11 For RHEL4 (update 8) running both 'configure' and 'make' works fine. Python is python-2.3.4-14.7.el4_8.2 John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Marking proxy servers as zombie - odd behaviour
Hello, We have 3 backend servers which are used in a client-balance mode from our local proxy server. We are running FR 2.1.10 (from git), but have seen the following behaviour when we were running 2.1.7 and 2.1.9 for a short time. Our logs are showing that FR marks the backend servers as zombie every few minutes. Not all of them at once, just one or maybe two, and then one will be marked as alive and another marked as zombie, and so on. As far as we can see there is no general network problem, and neither the radius nor backend servers are under any particular load. Running tcpdump for a short time seemed to show that something odd was going on (I have included the actual date/time of the packets, but removed the contents. I think the packet header lines should show what I mean): = 2010-06-17 10:47:35 IP 141.163.66.101.1812 141.163.195.250.1814: RADIUS, Access Accept (2), id: 0xdd length: 278 2010-06-17 10:47:46 IP 141.163.66.101.1812 141.163.195.250.1814: RADIUS, Access Reject (3), id: 0xb2 length: 20 = At this time, our radius log showed: = Thu Jun 17 10:47:35 2010 : Auth: Login OK: [xx] (from client GRN-DVB-WISM-1 port 29 cli 7C-6D-62-63-03-8D) Thu Jun 17 10:47:46 2010 : Proxy: Marking home server 141.163.66.101 port 1812 as zombie (it looks like it is dead). Thu Jun 17 10:47:46 2010 : Proxy: Received response to status check 10959 (1 in current sequence) = So what is being seen is that backend server 141.163.66.101 has sent an accept accept packet (to the local proxy server 195.250) and the log shows a user as having authenticated. About 10 seconds later, the server is marked as zombie, but tcpdump shows that a packet (access reject - we have status-server set up with an invalid userid, so the reject is correct) is received from that server. So I think the question is why did FR think the server was zombie when it had received an access-accept just a few seconds before? Why does it think it looks like it is dead? The tcpdump shows no other packets being sent to/from the server for FR to think that. And why is it that when FR thinks the backend server is dead it receives a status check reply at the same time? Did it send the status check query (and if so why didn't tcpdump show it?) but for whatever reason immediately decide that the server had not replied? Maybe I am wrong but I would not have expected FR to even consider the backend server as zombie/dead given that it had received a packet from it 10 seconds before. Thanks, John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Marking proxy servers as zombie - odd behaviour
On Thu, 2010-06-17 at 14:16 +0200, Josip Rodin wrote:
On Thu, Jun 17, 2010 at 11:26:37AM +0100, John Horne wrote:
So what is being seen is that backend server 141.163.66.101 has sent an
accept accept packet (to the local proxy server 195.250) and the log
shows a user as having authenticated. About 10 seconds later, the server
is marked as zombie, but tcpdump shows that a packet (access reject - we
have status-server set up with an invalid userid, so the reject is
correct) is received from that server.
Can you paste the exact home_server settings you used? That might shed
some light...
For this particular server:
home_server IAS {
type = auth
ipaddr = ias.plymouth.ac.uk
port = 1812
secret = xx
# status_check = status-server
status_check = request
username = xx
password = xx
}
John.
--
John Horne, University of Plymouth, UK
Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Marking proxy servers as zombie - odd behaviour
On Thu, 2010-06-17 at 14:09 +0100, Alan Buxey wrote:
Hi,
On Thu, Jun 17, 2010 at 11:26:37AM +0100, John Horne wrote:
So what is being seen is that backend server 141.163.66.101 has sent an
accept accept packet (to the local proxy server 195.250) and the log
shows a user as having authenticated. About 10 seconds later, the server
is marked as zombie, but tcpdump shows that a packet (access reject - we
have status-server set up with an invalid userid, so the reject is
correct) is received from that server.
Can you paste the exact home_server settings you used? That might shed
some light...
expected response time?
A few seconds at most.
what are your timers? 5 seconds?
We are currently letting them default.
Running 'radiusd -XC' shows:
===
home_server IAS {
ipaddr = ias.plymouth.ac.uk IP address [141.163.66.101]
port = 1812
type = auth
secret = x
response_window = 30
max_outstanding = 65536
zombie_period = 40
status_check = request
ping_interval = 30
check_interval = 30
num_answers_to_alive = 3
num_pings_to_alive = 3
revive_interval = 300
status_check_timeout = 4
username = xxx
password = xxx
irt = 2
mrt = 16
mrc = 5
mrd = 30
}
===
whats the cleanup_delay for example?
max_request_time = 30
cleanup_delay = 5
max_requests = 262144
John.
--
John Horne, University of Plymouth, UK
Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Marking proxy servers as zombie - odd behaviour
On Thu, 2010-06-17 at 17:54 +0200, Alan DeKok wrote: John Horne wrote: Why does it think it looks like it is dead? Because the home server didn't respond to *another* request. Each request has a timer. If the home server doesn't respond within that time, then it is marked zombie. Hmm. Given that the servers are lightly loaded, I guess we are looking at packet loss over the network? I have no idea if our networking people can 'detect' something like that, but I guess monitoring traffic coming out of the proxy and going to the home server should show if a packet is lost somewhere. Many thanks for all the replies. We always have at least one home server 'alive' according to FR so this has not been a problem for our users. It just seemed a bit odd behaviour when we looked into the log messages more closely. Thanks, John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Marking proxy servers as zombie - odd behaviour
On Thu, 2010-06-17 at 20:08 +0200, Bjørn Mork wrote: I would start by looking for any such deliberately ignored request. I am told that the home server logs show nothing suspicious. I have no direct access to those servers so I cannot say for myself. However, I have asked that the logs are monitored and if some part of it can be provided to me, then I will try and correlate what I see on the proxy server with the home server logs. John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FR 2.1.9 - segfault using status server
/lib/freeradius/rlm_pap.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/rlm_pap.so Reading symbols from /usr/lib/freeradius/rlm_mschap.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/rlm_mschap.so Reading symbols from /usr/lib/freeradius/rlm_eap.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/rlm_eap.so Reading symbols from /usr/lib/freeradius/libfreeradius-eap-2.1.9.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/libfreeradius-eap-2.1.9.so Reading symbols from /usr/lib/freeradius/rlm_eap_tls.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/rlm_eap_tls.so Reading symbols from /usr/lib/freeradius/rlm_eap_ttls.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/rlm_eap_ttls.so Reading symbols from /usr/lib/freeradius/rlm_eap_peap.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/rlm_eap_peap.so Reading symbols from /usr/lib/freeradius/rlm_eap_mschapv2.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/rlm_eap_mschapv2.so Reading symbols from /usr/lib/freeradius/rlm_realm.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/rlm_realm.so Reading symbols from /usr/lib/freeradius/rlm_files.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/rlm_files.so Reading symbols from /usr/lib/freeradius/rlm_radutmp.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/rlm_radutmp.so Reading symbols from /usr/lib/freeradius/rlm_attr_filter.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/rlm_attr_filter.so Reading symbols from /usr/lib/freeradius/rlm_preprocess.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/rlm_preprocess.so Reading symbols from /usr/lib/freeradius/rlm_acct_unique.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/rlm_acct_unique.so Reading symbols from /usr/lib/freeradius/rlm_detail.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/freeradius/rlm_detail.so Core was generated by `/usr/sbin/radiusd -X'. Program terminated with signal 11, Segmentation fault. #0 0x0806c936 in received_proxy_response () (gdb) bt #0 0x0806c936 in received_proxy_response () #1 0x0805a041 in ?? () #2 0x0806b110 in ?? () #3 0x00ac1f0d in fr_event_loop () from /usr/lib/freeradius/libfreeradius-radius-2.1.9.so #4 0x0806bd26 in radius_event_process () #5 0x08063f6a in main () (gdb) q = The proxy.conf part just has: = status_check = request username = xx password = xx = Has anyone else seen this problem? At the moment we are running FR with the 'status_check = status-server' enabled, since it seems better to receive no reply at all rather than having radiusd segfaulting. Thanks, John. -- John Horne Tel: +44 (0)1752 587287 University of Plymouth, UK Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.1.9 - segfault using status server
On Mon, 2010-06-14 at 16:23 +0200, Alan DeKok wrote: John Horne wrote: We are running FR 2.1.9 on CentOS 5, and are proxying requests to MS IAS 2003 servers. However, it seems the IAS servers do not support 'status-server' requests until a slightly later version. As such, I have configured FR to send a dummy userid/pwd instead. FR seems to receive a reply, but then segfaults. It may be the same bug that was reported earlier. See http://git.freeradius.org/, and look at the v2.1.x branch. It should have a fix. Hello, Okay, thanks for that. I have the 2.1.10 code (from git) currently running, and it seems to be working okay :-) Using 'radiusd -X' shows the server-status requests going out, the reply come back, and FR recognising them and moving on to the next request. Many thanks, John. -- John Horne Tel: +44 (0)1752 587287 University of Plymouth, UK Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FR 2.1.7: Error: Failed binding to proxy address
Hello, We are running Freeradius 2.1.7 (on CentOS 5 - freeradius2-2.1.7-7.el5), and are seeing many of these messages in our log files: Fri Jun 11 11:44:19 2010 : Error: Failed binding to proxy address * port 1815: Address already in use The server is already running and so would already be bound to the port, so why is it trying to bind to it again? These seem to occur initially in ones or twos, but eventually the server stops responding completely to requests. At that point we have to restart the radiusd process. Is this known about and maybe fixed in 2.1.9? Or is something else going on here? Thanks, John. -- John Horne Tel: +44 (0)1752 587287 University of Plymouth, UK Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.1.7: Error: Failed binding to proxy address
On Fri, 2010-06-11 at 15:28 +0300, Mindaugas Riauba wrote: Hello, We are running Freeradius 2.1.7 (on CentOS 5 - freeradius2-2.1.7-7.el5), and are seeing many of these messages in our log files: Changelog from 2.1.8: * Proxying large numbers of packets no longer gives error unable to open proxy socket. I already opened new bug about another bug in Redhat version: https://bugzilla.redhat.com/show_bug.cgi?id=602567 Feel free to add your problem. :) Okay, I have added a comment. Can you change the 'priority' of the bugzilla entry to something higher than 'low'? This is a serious problem for us, and affecting our RADIUS service. It would be nice if RH could update the provided freeradius package soon. John. -- John Horne Tel: +44 (0)1752 587287 University of Plymouth, UK Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.1.7: Error: Failed binding to proxy address
On Fri, 2010-06-11 at 13:34 +0200, Alan DeKok wrote: John Horne wrote: Hello, We are running Freeradius 2.1.7 (on CentOS 5 - freeradius2-2.1.7-7.el5), and are seeing many of these messages in our log files: Fri Jun 11 11:44:19 2010 : Error: Failed binding to proxy address * port 1815: Address already in use The server is already running and so would already be bound to the port, so why is it trying to bind to it again? These seem to occur initially in ones or twos, but eventually the server stops responding completely to requests. At that point we have to restart the radiusd process. Is this known about and maybe fixed in 2.1.9? Or is something else going on here? Changelog from 2.1.8: * Proxying large numbers of packets no longer gives error unable to open proxy socket. Okay, thanks. Although we are using supplied CentOS packages, I'll see about rebuilding freeradius with 2.1.8 or later. John. -- John Horne Tel: +44 (0)1752 587287 University of Plymouth, UK Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Debug log not logging date/time/epoch
Hello,
Not sure if this is a simple request or not. I am currently running
FreeRadius 2.0.5 in debug mode ('-X') and recording all the output into
a log file. The problem is the debug output seems to show no indication
of the date/time (or epoch time) at all. I'm trying to track down a
local problem, and have users telling me when the problem occurs, but
without the date/time being logged I am not getting too far.
Is it possible to get FR to log the date/time or epoch time when using
'-X'?
Thanks,
John.
--
---
John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287
E-mail: john.ho...@plymouth.ac.uk Fax: +44 (0)1752 587001
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Debug log not logging date/time/epoch
On Thu, 2009-04-30 at 18:51 +0100, Ivan Kalik wrote:
Not sure if this is a simple request or not. I am currently running
FreeRadius 2.0.5 in debug mode ('-X') and recording all the output into
a log file. The problem is the debug output seems to show no indication
of the date/time (or epoch time) at all. I'm trying to track down a
local problem, and have users telling me when the problem occurs, but
without the date/time being logged I am not getting too far.
Is it possible to get FR to log the date/time or epoch time when using
'-X'?
-xX
Hmm, well you are right that does print the date/time! :-)
I looked in the FAQ and the Wiki, and with Google, but just didn't think
to look in the man page. Oh well.
Thanks,
John.
--
---
John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287
E-mail: john.ho...@plymouth.ac.uk Fax: +44 (0)1752 587001
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 2.1.1 - radiusd.sock - permission denied
On Fri, 2008-09-26 at 17:31 +0100, John Horne wrote: Hi, I have installed FR2.1.1 onto a test server, built using the Fedora rawhide RPM source. No problems building and installing FR, but when I start FR it seems to immediately stop. The radius.log file just shows: Fri Sep 26 17:20:58 2008 : Error: Failed to stat /var/run/radiusd/radiusd.sock: Permission denied The ls command shows: ls -l /var/run/radiusd/radiusd.sock srw-rw 1 radiusd radiusd 0 Sep 26 16:53 /var/run/radiusd/radiusd.sock I have tried disabling selinux, and iptables, but they made no difference. Changing the permissions to 666 on the socket made no difference. Running 'radiusd -C' shows nothing, and 'radiusd -X' starts up okay. If I then use a different terminal I can run 'radmin' with no problem (which I gather uses the socket). The problem is, I can't see what permissions may be wrong. Anyone any ideas on this? Sigh. It's always on a Friday afternoon that you get these problems, send the message to the list and then see what the problem is! :-) Okay, I deleted the socket and then tried starting FR; it failed but the log file showed: Fri Sep 26 17:41:37 2008 : Error: Failed binding to /var/run/radiusd/radiusd.sock: Permission denied Disabling selinux, and FR then started up okay. Strange because I had tried disabling selinux before. oh well. Setting the selinux boolean 'radiusd_disable_trans' to on, and enabling selinux, seems to allow FR to work. However, I'm not sure what these booleans actually do (or restrict). John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 2.1.1-pre
On Wed, 2008-09-17 at 11:48 +0200, Alan DeKok wrote: I've made a number of changes to fix issues in 2.1.0. Can some people please try git head? See git.freeradius.org for how to get a tar file. If there are no complaints, we can issue 2.1.1 tomorrow. FYI - Installing 2.1.1 gives this error (but doesn't stop the installation): Creating/updating files in /usr/local/etc/raddb install: snmp.conf does not exist find: /usr/local/etc/raddb/snmp.conf: No such file or directory It seems that Makefile has 'snmp.conf' listed as a file to be installed, but no such file exists. Running 'radiusd -X' shows: Write out database with 1 new entries Data Base Updated unable to write 'random state' unable to write 'random state' MAC verified OK Not sure what it means by the 'random state' messages, or even if they are important :-) John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 2.1.1-pre
On Wed, 2008-09-17 at 11:48 +0200, Alan DeKok wrote: I've made a number of changes to fix issues in 2.1.0. Can some people please try git head? See git.freeradius.org for how to get a tar file. The 'configure', 'make' and 'make test' all completed successfully on a CentOS 5.2 (64-bit) system with no problems. John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: another 2.1.0 compile error
On Tue, 2008-09-09 at 11:24 -0600, Greg Woods wrote: On Tue, 2008-09-09 at 16:53 +0100, [EMAIL PROTECTED] wrote: yep, you havent got all the required development packages installed. libtool-ltdl-devel libtool-ltdl Thanks, that was it. However, I discovered what I think is a bug in yum in the process. I tried yum list *ltdl* and this failed to show these packages; otherwise I might have found this myself. Even yum list libtool* doesn't show them, I had to actually list libtool-ltdl-devel* to see the devel package. Does something a bit more generic like 'yum list *td*' show you a list of installed and available packages? It works for me on CentOS 5.2, 64-bit. The 'list *ltdl*' worked for me on CentOS 52, 32-bit. John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Hmm... 2.1.0 radmin
On Fri, 2008-09-05 at 16:34 +0100, [EMAIL PROTECTED] wrote: Hi, Looking at this a little more, it looks like a bug crept in at the last minute that prevents radmin from working. sigh I was about to email you about this. it loads, then it doesnt do anything (hangs after eg 'help' being typed) rather than rely on knowing the radiusd.sock location, could it read the /etc/raddb/* config to find where it should look? Under CentOS 5.2 I'm having difficulty getting it to compile. It throws up errors such as 'undefined reference to `using_history''. The config.log file shows: == configure:21093: checking for readline in -lreadline configure:21128: gcc -o conftest -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS conftest.c -lreadline -lnsl -lresolv -lpthread 5 /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libreadline.so: undefined reference to `PC' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libreadline.so: undefined reference to `tgetflag' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libreadline.so: undefined reference to `tgetent' /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../libreadline.so: undefined reference to `UP' == It looks like the 'configure' test needs to include '-lcurses' as well as '-lreadline' when checking for readline. Then if the test passes set the libraries to include '-lreadline -lhistory -lcurses'. I did that and then both configure and make worked okay. John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR on CentOS 5 via yum?
On Mon, 2008-07-07 at 20:51 +0200, Jos Vos wrote: On Mon, Jul 07, 2008 at 02:27:18PM -0400, John Dennis wrote: NOTE: The Fedora src rpms's were never meant to build on RHEL (centos), you may encounter build problems as a consequence. YMMV, you're on your own :-) I have recently built the Fedora 2.0.5-1 src.rpm on RHEL4, so it will probably also build ok on RHEL5. For RHEL4 I had to comment out the following lines in the spec file: BuildRequires: libtool-ltdl-devel BuildRequires: perl-devel Furthermore, comment out the first line of %post (chown ...), as this is a bug and will be removed in the next Fedora RPM. Likewise we have CentOS 5.2 servers, but have rebuilt FR 5.0.1 from the source RPM from a Fedora 10 mirror. For that just comment out the 'perl-devel' from the spec file, run 'rpmbuild -ba freeradius.spec', then install the 'freeradius', 'freeradius-libs' and 'freeradius-utils' RPMs. It works fine. John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.0.5 MPPE problem - worked in 2.0.4
On Sun, 2008-07-06 at 00:38 +1200, Pshem Kowalczyk wrote:
Hi
We've encountered exactly the same behaviour. Basically - you're not
supposed to relay on this functionality as it is was an unsupported
feature. If you have to add some attributes to the reply from the home
server - use unlang in the post proxy section, like this:
post-proxy {
if (%{Packet-Type} == Access-Request) {
if (%{proxy-reply:Framed-IP-Address} =~ /^10\.20.*$/){
update reply {
Session-Timeout := 1
Filter-Id := redirect
}
}
}
}
Okay, thanks for this and for Alan DeKok's reply. I'll reconfigure the
server and retest when I get back to work.
Thanks,
John.
--
---
John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287
E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 587001
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FR 2.0.5 MPPE problem - worked in 2.0.4
Hello, We are running Freeradius on some VPN servers using MPPE and PPTP. I have upgraded one server this afternoon from FR 2.0.4 to 2.0.5. We are now seeing the old (?!) error messages of MPPE not being available: == Jul 4 17:40:01 betty pppd[23739]: rcvd [CHAP Response id=0x37 20f649170924934c aea705692a8495615000d7a07dae438cc630dfe93a6f147c9a031d758b8cf2d300, name = jhorne] Jul 4 17:40:01 betty pppd[23739]: sent [CHAP Success id=0x37 S=2A085F4D0A91C6832D347AF4305ED84C2ACF32E0] Jul 4 17:40:01 betty pppd[23739]: MPPE required, but keys are not available. Possible plugin problem? Jul 4 17:40:01 betty pppd[23739]: sent [LCP TermReq id=0x2 MPPE required but not available] Jul 4 17:40:01 betty pppd[23739]: rcvd [CCP ConfReq id=0x4 mppe +H +M +S +L -D +C] == None of the configuration files were changed. Our 'users' file contains a DEFAULT entry of: DEFAULT Service-Type == Framed-User MS-MPPE-Encryption-Policy = 0x0002, MS-MPPE-Encryption-Types = 0x0006 When running FR 2.0.4 using 'radiusd -X' we can see the MPPE reply items present (and FR then passes them on to the PPP daemon): == Login OK: [jhorne/via Auth-Type = mschap] (from client localhost port 0 cli 141.163.60.7) Sending Access-Accept of id 141 to 127.0.0.1 port 32769 MS-CHAP2-Success = 0x9c533d43393244394538333244413042433745324241443135463241354437354233443034394544313230 Reply-Message = Yes MS-MPPE-Recv-Key = 0x0e7596f28778d7d71a7553aadfa57e92 MS-MPPE-Send-Key = 0x41496804da30ffb8550fa9437ee6ae5e MS-MPPE-Encryption-Policy = 0x0002 MS-MPPE-Encryption-Types = 0x0006 Finished request 0. == However, with FR 2.0.5 the MPPE reply items are missing: == Login OK: [jhorne] (from client localhost port 0 cli 141.163.60.7) Sending Access-Accept of id 144 to 127.0.0.1 port 32769 MS-CHAP2-Success = 0x37533d32413038354634443041393143363833324433343741463433303545443834433241434633324530 Reply-Message = Yes MS-MPPE-Recv-Key = 0x00fbe23240bfd5a27fa70a2e32b581b3 MS-MPPE-Send-Key = 0xff5da890119101d1c08693d65bc3fc5b Finished request 0. == As said, none of the configuration files have changed at all. It seems that FR 2.0.5 is dropping the reply items from the 'users' file after proxying, rather than passing them on. Has anyone else noticed this? I cannot really see anything relevant in the Changelog that would explain this. I'm a little stumped as to how to proceed with this (other than going back to 2.0.4), and it's late on a Friday afternoon so I'm going home to think :-) Thanks, John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.0.3 gives duplicate NULL realm error
On Tue, 2008-04-08 at 10:14 +0100, John Horne wrote:
On Tue, 2008-04-08 at 08:18 +0200, Alan DeKok wrote:
John Horne wrote:
It seems that radiusd doesn't like the NULL realm after the DEFAULT. I
swapped these two around, and radiusd started up fine.
? I can start up the server fine with those realms, in any order.
Yes, with 2.0.2 I had the NULL realm in proxy.conf last. However, with
2.0.3 I have swapped these around a couple of times now, and it always
fails (duplicate realm error) if the NULL realm is last and the DEFAULT
realm is present. If I comment out the DEFAULT realm, although the NULL
realm is still last, then radiusd starts up. So it seems to be an
interaction between both the DEFAULT and NULL realms being present.
Okay, I've looked into this a bit further. The Changelog shows that a
change to realms (the 'realm_find' function in realms.c) was made in FR
2.0.2 (which explains why my FR 2.0.1 worked):
* Fall back to DEFAULT realm if no realm was found.
Based on a patch from Vincent Magnin.
I found a copy of the patch, and removed it from the 2.0.3 source code.
Starting radiusd then worked regardless of what order the DEFAULT/NULL
realms were in.
The NULL realm is configured as:
realm NULL {
auth_pool = local_proxies
}
If I comment out the 'auth_pool' line, then radiusd starts up (having
put the above patch back in). However, from the code (realms.c, line
1174 onwards) this is probably due to FR treating the NULL realm as an
old-style realm and, hence, allowing it.
I am at this point now stuck. The 'duplicate realm' message occurs
because of the result of 'realm_find' for the NULL realm. However,
realm_find (in realms.c at line 1323) shows:
===
REALM *realm_find(const char *name)
{
REALM myrealm;
REALM *realm;
if (!name) name = NULL;
myrealm.name = name;
realm = rbtree_finddata(realms_byname, myrealm);
if (realm) return realm;
/*
* Couldn't find a realm. Look for DEFAULT.
*/
myrealm.name = DEFAULT;
return rbtree_finddata(realms_byname, myrealm);
}
===
For some reason the NULL realm is not being found (using
rbtree_finddata), and so it then looks for the DEFAULT realm. But we
have already seen the DEFAULT realm.
If I change the code to look for the 'myrealm.name = DEFAULTx' realm,
then radiusd starts up okay (or rather there is no error message; it is
possible though that radiusd now thinks it has no NULL realm configured,
although 'radiusd -XC' indicates that it has seen it).
I am not sure that the above code ('realm_find') is correct though. It
changes 'myrealm.name' to DEFAULT, and then returns the
pointer/structure (I assume) of the DEFAULT realm. However, this was
called from line 1174 which is expecting the NULL realm (and has 'name2'
set to that). I don't think just looking for the DEFAULT realm is
enough, it needs to change other variables such as 'name2'. (I may be
completely wrong about all this though!)
If I change the NULL realm in proxy.conf to:
realm NULL {
# auth_pool = local_proxies
authhost = localhost
}
I then get from radiusd:
realm NULL {
/etc/raddb/proxy.conf[107]: No shared secret supplied for realm:
DEFAULT
} # realm NULL
Which seems to indicate that the DEFAULT and NULL realms are indeed
getting mixed up. The 'DEFAULT' name in the error message comes from the
'r' structure (which it got from within 'realm_find' when it couldn't
find the NULL realm); the 'NULL' parts come from the variable 'name2'.
This is as far as I have got. The 'rbtree_finddata' code (in
src/lib/rbtree.c, line 494) starts to get a bit too convoluted for me,
but as to why the NULL realm is not found seems to be the root of the
'duplicate realm' error.
Regards,
John.
--
---
John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287
E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.0.3 gives duplicate NULL realm error
On Tue, 2008-04-08 at 08:18 +0200, Alan DeKok wrote: John Horne wrote: It seems that radiusd doesn't like the NULL realm after the DEFAULT. I swapped these two around, and radiusd started up fine. ? I can start up the server fine with those realms, in any order. Yes, with 2.0.2 I had the NULL realm in proxy.conf last. However, with 2.0.3 I have swapped these around a couple of times now, and it always fails (duplicate realm error) if the NULL realm is last and the DEFAULT realm is present. If I comment out the DEFAULT realm, although the NULL realm is still last, then radiusd starts up. So it seems to be an interaction between both the DEFAULT and NULL realms being present. I'm not sure why the 'radiusd -X' output gives as the very last line '} # realm NULL'. The code shows that it always does this (replacing 'NULL' for the relevant realm name). Where in the code? That message is printed out *only* if it finds two realms with the same name. Sorry, I meant always does this if the duplicate realm error is displayed. John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.0.3 gives duplicate NULL realm error
On Tue, 2008-04-08 at 10:14 +0100, John Horne wrote: On Tue, 2008-04-08 at 08:18 +0200, Alan DeKok wrote: John Horne wrote: It seems that radiusd doesn't like the NULL realm after the DEFAULT. I swapped these two around, and radiusd started up fine. ? I can start up the server fine with those realms, in any order. Yes, with 2.0.2 I had the NULL realm in proxy.conf last. Sorry, that should be 2.0.1. I skipped 2.0.2 and went straight to 2.0.3. John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FR 2.0.3 gives duplicate NULL realm error
Hello,
I have been running FR 2.0.2 (built from source) for a short while with
no problems. I have now upgraded to 2.0.3 (built from Fedora 9 source
RPM). When I try and start radiusd (using 'radiusd -X' I get the
following error:
realm NULL {
/etc/raddb/proxy.conf[107]: Duplicate realm NULL
} # realm NULL
I have thoroughly checked the files, and there is no duplicate of the
NULL realm. The end part of proxy.conf contains the NULL realm, and it
is configured as:
home_server_pool local_proxies {
type = fail-over
home_server = IAS-1
home_server = IAS-2
home_server = ILS009
}
[other home server pools and realms defined]
realm NULL {
auth_pool = local_proxies
}
I'm not sure why the 'radiusd -X' output gives as the very last line
'} # realm NULL'. As can be seen in proxy.conf, the very last line has
no comment attached to it.
Anyone any ideas about why radiusd is complaining about a duplicate NULL
realm?
Thanks,
John.
--
---
John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914
E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR 2.0.3 gives duplicate NULL realm error
On Mon, 2008-04-07 at 15:51 +0100, John Horne wrote:
I have been running FR 2.0.2 (built from source) for a short while with
no problems. I have now upgraded to 2.0.3 (built from Fedora 9 source
RPM). When I try and start radiusd (using 'radiusd -X' I get the
following error:
realm NULL {
/etc/raddb/proxy.conf[107]: Duplicate realm NULL
} # realm NULL
Okay, I sorted this one out myself. The proxy.conf file had:
realm DEFAULT {
...
}
realm NULL {
...
}
It seems that radiusd doesn't like the NULL realm after the DEFAULT. I
swapped these two around, and radiusd started up fine.
I'm not sure why the 'radiusd -X' output gives as the very last line
'} # realm NULL'.
The code shows that it always does this (replacing 'NULL' for the
relevant realm name).
John.
--
---
John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914
E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FR2: combining round-robin and fail-over home server pools
Hello,
I am in the process of configuring FreeRADIUS 2.0.1. For some realms we
proxy the authentication request to three other servers (svr-1, svr-2,
svr-3). However, what we wanted was to, in effect, round-robin two of
the servers (svr1 and svr-2), and then only use the third server (svr-3)
if the other two were not available.
I have configured the proxy.conf 'home_server_pool's as:
home_server_pool local_IAS {
type = client-port-balance
home_server = svr-1
home_server = svr-2
}
home_server_pool local_proxies {
type = fail-over
home_server = local_IAS
home_server = svr-3
}
Note that 'local_IAS' is actually a home_server_pool name, and not an
actual home server. I was then going to configure FR to use
'local_proxies' for the relevant realms. However, starting FR gives an
error:
/usr/local/etc/raddb/proxy.conf[87]: Unknown home_server local_IAS.
Anyone any ideas how to mix round-robin servers with fail-over?
Thanks,
John.
--
---
John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914
E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Version 2 bzip file is gzip
Hi, It seems that the bzip2 file of the new version 2.0.0 is actually a gzip file: freeradius-server-2.0.0.tar.bz2: gzip compressed data, from Unix, last modified: Thu Jan 10 13:33:14 2008 I downloaded this from the main FreeRADIUS web site. Just something to be aware of :-) John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Should I use FR 2.0.0 or 1.1.6?
Hi, I expect the freeradius developers will hate me for asking this, but is there an estimate of when the final version of FR 2.0.0 will be released? I have four servers to upgrade - 3 currently run FR 1.0.1 and one is already upgraded to 1.1.6. I am at an academic site, and the students are currently taking their exams. As such, within the next few weeks most of the staff/students will have left, and I can start to get on with the upgrades and other things. This gives me a window of a couple of months at least to do the upgrades. The question is, do I install FR 2.0.0 now (even as a pre-release) so that upgrading to the final version should be relatively trivial, or do I stay with 1.1.6 knowing that at some future point, perhaps soon after the start of next term, I have to upgrade again to 2.0.0? I notice that upgrading from 1.x to 2.x requires going through the config files, and will obviously require some testing, so upgrading to 2.x may not be trivial. That is, I can't do it in a short time, but I can upgrade from 1.0.1 to 1.1.6 quickly because I already have one server done. I suppose another possibility could be to run 3 servers at 1.1.6 and one at 2.0.0 :-) Hmm, sounds interesting... I should add that all 4 servers are 'live', but I have kept the 1.1.6 server mainly out of use for the past few months. As such we can run our service on 3 servers. Anyone any comments or suggestions? Thanks, John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius = MS IAS passthrough
On Wed, 2007-05-16 at 17:12 -0400, Ian Savoy wrote: Is there anything else? Hi, Not sure if it's still relevant but with our IAS servers the sysadmin made sure it set the reply message to yes. If you test from freeradius to the IAS server using the 'radtest' command, and run freeradius as 'radiusd -X', you should then see something like this from radiusd: rad_recv: Access-Accept packet from host 10.1.2.3:1812, id=0, length=74 Proxy-State = 0x323235 Framed-Protocol = PPP Reply-Message = Yes Service-Type = Framed-User John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: HUP stops radiusd
On Mon, 2007-05-14 at 22:56 +0200, Alan DeKok wrote: John Horne wrote: ... Mon May 14 13:38:54 2007 : Info: rlm_eap_tls: Loading the certificate file as a chain Mon May 14 13:38:54 2007 : Error: rlm_eap: SSL error error:0906D06C:PEM routines:PEM_read_bio:no start line Ah I think what's happening is that OpenSSL is caching the file from the last time it was read. So the server starts, and reads 1 certificate from the file. OpenSSL leaves the file open, or remembers where it left off. When FreeRADIUS asks OpenSSL to read the file again, OpenSSL continues from where it left off, rather than starting from the beginning of the file. Well I like the explanation, but unfortunately it doesn't work. Radiusd still dies at the first HUP. However, one thing I have noticed is that if I start Freeradius up from /etc/init.d (this is a CentOS server so I used 'service radiusd start'), then I can HUP the daemon once and it stays running. HUP it a second time and it fails (this is with one certificate in the file). If I start Freeradius as '/usr/sbin/radiusd -X', and HUP it, then it fails straight away. In both cases the failure messages are the same as those originally reported. John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
HUP stops radiusd
Hello, This is a 'me too' message I'm afraid. From the list archives I saw: == Date: Mon, 02 Apr 2007 20:20:47 +0200 From: Alan DeKok aland at deployingradius.com Subject: Re: HUP in freeradius-1.1.5 + CVS results in process death. To: FreeRadius users mailing list freeradius-users at lists.freeradius.org Message-ID: 4611497F.3000500 at deployingradius.com Content-Type: text/plain; charset=ISO-8859-1 Arran Cudbard-Bell wrote: I know theres a bug report for this already, but when I HUP the process freeradius doesn't die in the same place. If it's an issue due to incorrectly free'd memory, the crashes will be random. There may be a fix in 1.1.6, but I'm not sure. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog Looks more like a bug in rlm_tls . Dies every time on HUP, deffinatly not random... == In our case, using freeradius 1.1.6, if I HUP the radiusd process it crashes/stops. Running 'radiusd -X', the tail part shows: = security: status_server = no main: debug_level = 0 read_config_files: reading dictionary read_config_files: reading naslist Using deprecated naslist file. Support for this will go away soon. read_config_files: reading clients read_config_files: reading realms Mon May 14 13:38:54 2007 : Info: rlm_exec: Wait=yes but no output defined. Did you mean output=none? Mon May 14 13:38:54 2007 : Error: radiusd.conf[230] Auth-Type PAP already configured - skipping Mon May 14 13:38:54 2007 : Error: radiusd.conf[234] Auth-Type MS-CHAP already configured - skipping Mon May 14 13:38:54 2007 : Info: rlm_eap_tls: Loading the certificate file as a chain Mon May 14 13:38:54 2007 : Error: rlm_eap: SSL error error:0906D06C:PEM routines:PEM_read_bio:no start line Mon May 14 13:38:54 2007 : Error: rlm_eap_tls: Error reading certificate file Mon May 14 13:38:54 2007 : Error: rlm_eap: Failed to initialize type tls Mon May 14 13:38:54 2007 : Error: radiusd.conf[1]: eap: Module instantiation failed. Mon May 14 13:38:54 2007 : Error: radiusd.conf[238] Unknown module eap. Mon May 14 13:38:54 2007 : Error: radiusd.conf[229] Failed to parse authenticate section. = This was running radiusd as the root user, running it as our usual non-root user caused the same output. Starting up radiusd normally shows no such error messages, so I'm not sure why it should now complain about the Auth-Type's or the certificate. Using the original radiusd.conf produces the same error messages, with a couple of extras (for the Auth-Types's system and CHAP). Any ideas? Thanks, John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: HUP stops radiusd
On Mon, 2007-05-14 at 15:22 +0200, inverse wrote: In our case, using freeradius 1.1.6, if I HUP the radiusd process it crashes/stops. Running 'radiusd -X', the tail part shows: Mon May 14 13:38:54 2007 : Error: rlm_eap_tls: Error reading certificate file on HUP the radiusd process probably tries to switch to a non-root user. That might the source of your message. No, I deliberately configured the server to run as root to check that. The same errors occurred. Secondly, if that was the case then the server shouldn't really start at all, but it does. The problem only occurs (as far as I am aware) after a HUP. John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Must set auth-type - but why?
entry bob at line 8
modcall[authorize]: module files returns ok for request 0
rlm_mschap: Found MS-CHAP attributes. Setting 'Auth-Type = mschap'
modcall[authorize]: module mschap returns ok for request 0
rlm_realm: No '@' in User-Name = bob, looking up realm NULL
rlm_realm: Found realm NULL
rlm_realm: Adding Stripped-User-Name = bob
rlm_realm: Proxying request from user bob to realm NULL
rlm_realm: Adding Realm = NULL
rlm_realm: Preparing to proxy authentication request to realm NULL
modcall[authorize]: module suffix returns updated for request 0
modcall: leaving group authorize (returns updated) for request 0
WARNING: You set Proxy-To-Realm = LOCAL, but it is a LOCAL realm!
Cancelling invalid proxy request.
rad_check_password: Found Auth-Type MSCHAP
auth: type mschap
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 0
rlm_mschap: Told to do MS-CHAPv2 for bob with NT-Password
rlm_mschap: adding MS-CHAPv2 MPPE keys
modcall[authenticate]: module mschap returns ok for request 0
modcall: leaving group authenticate (returns ok) for request 0
Login OK: [bob] (from client localhost port 0 cli 141.163.60.7)
WARNING: Cancelling proxy to Realm LOCAL, as the realm is local.
Sending Access-Accept of id 21 to 127.0.0.1 port 33137
MS-CHAP2-Success =
0x8f533d3133443030434235384431313045464334313131304241424237434145394236454443454531
MS-MPPE-Recv-Key = 0x273434105c0ed9fc6e57a499d5abffee
MS-MPPE-Send-Key = 0x98eed82e84689dc22315e6d3d83733f8
MS-MPPE-Encryption-Policy = 0x0002
MS-MPPE-Encryption-Types = 0x0004
Finished request 0
=
As can be seen the Auth-Type in the users file is seen and rlm_mschap
now does the right thing:
rlm_mschap: Told to do MS-CHAPv2 for bob with NT-Password
In the radiusd.conf file, which is basically the same from FR 1.0.1 to
1.1.6, the relevant (I hope) sections are:
=
modules {
pap {
auto_header = yes
}
$INCLUDE ${confdir}/eap.conf
mschap {
# - this line used in FR 1.0.1 authtype = MS-CHAP
use_mppe = yes
require_encryption = yes
require_strong = yes
}
[ rest of modules section snipped ]
authorize {
preprocess
eap
files
mschap
suffix
}
authenticate {
Auth-Type PAP {
pap
}
mschap
eap
}
=
So my question is, does anyone have an explanation for this behaviour?
Obviously it is great that our 'users' files entries work under
FreeRadius 1.1.6 with only a minor change. However, since generally
Auth-Type should not be required, it is a worry that we *have* to set it
to get FR to work. Since the radiusd output shows that FR sees this is
an MS-CHAP request, I would have thought it would handle it correctly.
It doesn't, but instead treats it as a 'Local' type request.
Thanks,
John.
--
---
John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914
E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Must set auth-type - but why?
On Fri, 2007-05-11 at 13:47 +0200, Alan DeKok wrote: John Horne wrote: bob Auth-Type = Local,User-Password := abc,Proxy-To-Realm := LOCAL Don't set Auth-Type. Use Cleartext-Password, not User-Password. The entry should look like: bob Cleartext-Password := abc, Proxy-To-Realm := LOCAL No, that doesn't work. I get the exact same result as if I used 'Auth-type = Local'. 'radiusd -X' output shows: = rlm_mschap: Found MS-CHAP attributes. Setting 'Auth-Type = mschap' modcall[authorize]: module mschap returns ok for request 0 rlm_realm: No '@' in User-Name = bob, looking up realm NULL rlm_realm: Found realm NULL rlm_realm: Adding Stripped-User-Name = bob rlm_realm: Proxying request from user bob to realm NULL rlm_realm: Adding Realm = NULL rlm_realm: Preparing to proxy authentication request to realm NULL modcall[authorize]: module suffix returns updated for request 0 modcall: leaving group authorize (returns updated) for request 0 WARNING: You set Proxy-To-Realm = LOCAL, but it is a LOCAL realm! Cancelling invalid proxy request. rad_check_password: Found Auth-Type auth: type Local auth: No User-Password or CHAP-Password attribute in the request = John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Must set auth-type - but why?
On Fri, 2007-05-11 at 14:24 +0200, Alan DeKok wrote: John Horne wrote: No, that doesn't work. Yes, it does. No, it doesn't (even with 'pap' last in the authorize section). Did you read man rlm_pap as I suggested? Yes, but this is an MS-CHAP request, not PAP. John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR-1.1.3 on solaris10 strange things
On Wed, 2006-11-08 at 14:56 -0500, Alan DeKok wrote: Alexander Serkin [EMAIL PROTECTED] wrote: May be someone could give an advice how to debug the problem while the server will not be in production? Attach to it with gdb, and see what it's doing. Or use the 'truss' command to see what is going on. John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Access to wiki?
Hello, Is there a problem with the freeradius wiki (http://wiki.freeradius.org)? I am trying to sort out a problem and came across a reference to the wiki page. However my browser just sits there when trying to access the page. I can resolve the DNS name and ping it; just not access it. Thanks, John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Startup message not being logged
Hello, A minor question really. I have just upgraded a server from Fedora Core 3 (freeradius 1.0.1) to FC5 (freeradius 1.0.5). I notice that when I start freeradius on FC5 (using 'service radiusd start') a message is sent to stdout: Fri Jun 16 12:06:59 2006 : Info: Starting - reading configuration files ... Should this happen? I thought this should be logged in the log file (defined in the radiusd.conf). I'm asking because I'm just wondering if this is indicative of my having misconfigured something? I couldn't find anything in the changelog about this. Thanks, John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Startup message not being logged
On Fri, 2006-06-16 at 09:16 -0400, Alan DeKok wrote: John Horne [EMAIL PROTECTED] wrote: A minor question really. I have just upgraded a server from Fedora Core 3 (freeradius 1.0.1) to FC5 (freeradius 1.0.5). I notice that when I start freeradius on FC5 (using 'service radiusd start') a message is sent to stdout: Fri Jun 16 12:06:59 2006 : Info: Starting - reading configuration files ... Should this happen? Probably not. Ah. Any ideas of what to look at? I've checked the radiusd.conf and the syslog.conf file but cannot really see anything wrong. I'll grab the RPM source and see if I can see what happens. John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Startup message not being logged
On Fri, 2006-06-16 at 09:16 -0400, Alan DeKok wrote: John Horne [EMAIL PROTECTED] wrote: A minor question really. I have just upgraded a server from Fedora Core 3 (freeradius 1.0.1) to FC5 (freeradius 1.0.5). I notice that when I start freeradius on FC5 (using 'service radiusd start') a message is sent to stdout: Fri Jun 16 12:06:59 2006 : Info: Starting - reading configuration files ... Should this happen? Probably not. From the source code it seems that the message will always appear. The message is displayed before the radiusd.conf file is read, and since neither the logdir or log_file directives are set, radiusd sends the message to stdout. However. In FC3 the /etc/init.d/radiusd startup script called a function which actually started radiusd using the 'initlog' command. This hid the stdout message I now see. In FC5 initlog is deprecated, and they just start radiusd directly. Hence I now see the message. John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Bug with dead_time and max_request_time?
On Fri, 2004-12-03 at 15:53 -0500, Alan DeKok wrote: John Horne [EMAIL PROTECTED] wrote: The problem is that if the first server fails and the local server receives a request then it tries to talk to the first DEFAULT server and fails, eventually marking it as 'dead'. This is fine but the local server also sends back to the client a reject rather than trying the second DEFAULT server. By the time the local server decides that the home server is dead, there is a 99% chance that the NAS has already given up on the request. There generally isn't much point in trying to send the request to another home server. But these aren't home servers. They are external servers used as part of the authentication process and as such are configured as two seperate DEFAULT realm servers with external 'authhost' domain names. In that respect the local server should proxy the request to the second server because it has nothing to do with the first server - they are in different locations. John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upgrade to 1.0.1 - radiusd wont start (RESOLVED)
On Fri, 2004-10-29 at 12:40, John Horne wrote:
We have a Fedora Core 2 linux server which unfortunately automatically
upgraded, using yum, from freeradius 0.9.3 to 1.0.1 last night. (I did
not intend that to happen so that I could check out the changes with
1.0.1 to ensure that it would work okay on our servers.) This morning
the server was showing that the freeradius daemon was not running.
In our radiusd.conf file in the authorize section we have:
mschap {
ok = return
}
Okay, I see that this was reported about 2 weeks ago by a user getting
the same type of error when using ldap. I also see that this has been
fixed in cvs by Alan DeKok, and should appear in freeradius 1.0.2. Many
thanks.
John.
--
---
John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914
E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Trying to set no authentication for users
On Thu, 2004-01-08 at 16:19, Alan DeKok wrote: John Horne [EMAIL PROTECTED] wrote: This seemed to make no difference. However I did notice, before and after the change, that if the user file entry has something like: User-Password != something Then if the user enters the password of 'something' they are authenticated. It's a bug. In which case I think I am somewhat lost! :-) Given that in our case MS-CHAPv2 must be used, and hence some form of encryption is going on, do the '!=', '!~' etc operators still apply? Not for passwords, for a number of reasons. Okay, thanks for this. I had a quick look at the rlm_mschap.c code and as far as I could tell the user-supplied password and the password in the 'users' file are encrypted and then compared using memcmp (line 856 from freeradius version 0.9.3). If they are not the same then the authentication fails. In that respect the '!=', etc operators are not used. Given that, I assume then that it is then not possible to create a default 'users' file entry which will allow *any* user through if we insist on using MS-CHAPv2? John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Trying to set no authentication for users
On Thu, 2004-01-08 at 16:48, Alan DeKok wrote: John Horne [EMAIL PROTECTED] wrote: Given that, I assume then that it is then not possible to create a default 'users' file entry which will allow *any* user through if we insist on using MS-CHAPv2? Auth-Type := Accept Will allow the user through, without password checking. No it doesn't - I tried that after reading the FAQ. If I use just: jhornexAuth-Type := Accept then radiusd complains that no MSCHAP password has been supplied: auth: type MS-CHAP modcall: entering group authenticate for request 0 rlm_mschap: No User-Password configured. Cannot create LM-Password. rlm_mschap: No User-Password configured. Cannot create NT-Password. rlm_mschap: No LM-Password or NT-Password attribute found. Cannot perform MS-CHAP authentication. modcall[authenticate]: module mschap returns fail for request 0 modcall: group authenticate returns fail for request 0 auth: Failed to validate the user. If I enter a User-Password attribute: jhornexAuth-Type := Accept, User-Password == anything then, because I can't use the '!=', '!~' operators I have to let every user know what the password is. Either way, use of Accept and MS-CHAP seems to still go through the password checking. John. -- --- John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914 E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Trying to set no authentication for users
# is then used to pick the apropriate module from the list below.
#
# The default Auth-Type is Local. That is, whatever is not included
inside
# an authtype section will be called only if Auth-Type is set to Local.
#
# So you should do the following:
# - Set Auth-Type to an appropriate value in the authorize modules
above.
# For example, the chap module will set Auth-Type to CHAP, ldap to
LDAP, etc.
# - After that create corresponding authtype sections in the
# authenticate section below and call the appropriate modules.
authenticate {
mschap
}
--
---
John Horne, University of Plymouth, UK Tel: +44 (0)1752 233914
E-mail: [EMAIL PROTECTED] Fax: +44 (0)1752 233839
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
