Re: linelog and rlm_eap
Kolbjørn Barmen wrote: What I meant to ask for, is some way of having more usefull information from failed logins. Today we're using ldap backend, and the only error message that comes in the log is rlm_ldap: User not found, regardless of what the real cause is. There may be *multiple* real causes. Which ones do you want? Typically the only way I have found today is to run debugging and read through the entire session to see what the output from the various rlm_eap_*-modules is. Would be excellent if one could use linelog to create a log of how the eap-negotiation progresses for every login. As always, patches are welcome. The EAP module will have to export an attribute describing it's current state. This will likely have to be done for every EAP sub-type, too. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: linelog and rlm_eap
On Fri, 11 Mar 2011, Alan DeKok wrote: Kolbjørn Barmen wrote: What I meant to ask for, is some way of having more usefull information from failed logins. Today we're using ldap backend, and the only error message that comes in the log is rlm_ldap: User not found, regardless of what the real cause is. There may be *multiple* real causes. Which ones do you want? I cannot remember to have seen multiple causes in play at once, but if that is the case, why not all of them? What I typically see is only one issue being the cause of a Reject. Of course there may be more, so that if you sort out one issue, it will just fail at the next one. But for any given attempt to authenticate, there is only one. Right? Typically the only way I have found today is to run debugging and read through the entire session to see what the output from the various rlm_eap_*-modules is. Would be excellent if one could use linelog to create a log of how the eap-negotiation progresses for every login. As always, patches are welcome. The EAP module will have to export an attribute describing it's current state. This will likely have to be done for every EAP sub-type, too. Aha, so linelog can only deal with attributes? Then I suppose the answer to my original question is just no. That's ok, I just wanted a clear answer before I attemped to do something that would not work anyways. It would be nice if there was a way for a module to pass on error messages, if any, from child module instead of just printing its own, so that if a user is rejected due to wrong password for mschapv2, the error message from the rlm_eap_mschapv2 module would be printed instead of that from rlm_ldap, for example. Just wishfull thinking. -- Kolbjørn Barmen UNINETT Driftsenter - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Virtual Server
Thanks Phil. That worked great.
On Mar 10, 2011 10:53 AM, Phil Mayers p.may...@imperial.ac.uk wrote:
On 10/03/11 16:46, Rob Yamry wrote:
Im running FreeRadius 2.1.8 to allow wireless access and that is working
great. I now want to have the vpn auth against the freeradius server for
access, but checking for a different ldap attribute on the user. I read
the virtual servers wiki and it says that all modules are global across
virtual servers. Do I need to set up another install of freeradius so I
can check for the other ldap attribute or is there a better way to get
this accomplished?
You can also setup a 2nd LDAP module e.g.
ldap ldap_vpn {
...ldap config items
}
...then:
server vpn {
authorize {
ldap_vpn
}
}
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: linelog and rlm_eap
Kolbjørn Barmen wrote: I cannot remember to have seen multiple causes in play at once, but if that is the case, why not all of them? What I typically see is only one issue being the cause of a Reject. Of course there may be more, so that if you sort out one issue, it will just fail at the next one. But for any given attempt to authenticate, there is only one. Right? There may be more than one, but there is usually only one. Aha, so linelog can only deal with attributes? Yes. It would be nice if there was a way for a module to pass on error messages, if any, from child module instead of just printing its own, so that if a user is rejected due to wrong password for mschapv2, the error message from the rlm_eap_mschapv2 module would be printed instead of that from rlm_ldap, for example. Just wishfull thinking. See Module-Failure-Message. Many modules (but not all) update that attribute. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: FR 2.1.7 Exits for no reason
Well, at the very least, I'm going to START there and see what happens. It's maddening, since it goes for weeks with no problems, and then suddenly two or three will die within hours. :( --J -Original Message- From: freeradius-users-bounces+mcnuttj=missouri.edu@lists.freeradius .org [mailto:freeradius-users-bounces+mcnuttj=missouri@lists.fr eeradius.org] On Behalf Of Alan Buxey Sent: Wednesday, March 09, 2011 3:28 AM To: FreeRadius users mailing list Subject: Re: FR 2.1.7 Exits for no reason hi, 2.1.7 has many little quirks/bugs that caused daemon deaths. 2.1.10 is the answer alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Access Accept vs Tunneled reply
Hi, I am trying to work out where I would be putting attributes for Access Accept. add them at the post-auth stage...or add them in the inner-tunnel and copy inner-tunnel to the reply.. thats 2 standard ways alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Access Accept vs Tunneled reply
These values are unique per user. Is there an elegant way to copy this to the post-auth section? David -Original Message- From: Alan Buxey [mailto:a.l.m.bu...@lboro.ac.uk] Sent: Friday, March 11, 2011 8:36 AM To: David Peterson-WirelessConnections; FreeRadius users mailing list Subject: Re: Access Accept vs Tunneled reply Hi, I am trying to work out where I would be putting attributes for Access Accept. add them at the post-auth stage...or add them in the inner-tunnel and copy inner-tunnel to the reply.. thats 2 standard ways alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Access Accept vs Tunneled reply
David Peterson dav...@wirelessconnections.net wrote: These values are unique per user. Is there an elegant way to copy this to the post-auth section? The following might help? http://lists.freeradius.org/mailman/htdig/freeradius-users/2011-January/msg00353.html Cheers -- Alexander Clouter .sigmonster says: What garlic is to food, insanity is to art. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Proxy Request to Virtual Server using EAP
Hello Guys
I need a help to use proxy request to virtual_server using EAP-TTLS and
EAP-PEAP
I have the following scenario:
I have a Radius Sever (version 2.1.10), this server on a Linux Debian 6
This server must authenticate users of my wireless network. But my network
is interconnected with several educational institutions, and users of these
institutions are in my network.
For users who are in my company, I want to authenticate them in my radius
server, for users who are from other institutions to do routing or proxy
server.
I already have configured the authentication of my users using LDAP as a
backend.
My users will be divided into groups, each group has its own realm, each
realm and forwards the authentication to a virtual server.
If my users try to authenticate without entering the realm, it works OK.
If users try to authenticate other institutions stating the realm of the
institution, my radius is usually the proxy, and it works OK.
if my users try to authenticate informing realm, I see in debug mode the
virtual server is invoked, but the authentication does not happen, he
accuses the following error:
# Executing group from file /etc/freeradius/sites-enabled/inner-tunnel
+- entering group authenticate {...}
[eap] Multiple levels of TLS nesting is invalid.
[eap] Failed in EAP select
++[eap] returns invalid
Failed to authenticate the user.
} # server inner-tunnel
Apparently he often wraps the request with TLS, and can no longer
decapsulation.
If you do a test without using EAP authentication (via radtest)
authentication with realm works.
Apparently he often wraps the request with TLS, and can no longer
decapsulation.
Enough already researched on the internet but have not found a solution.
I need to make a proxy for virtual_server using EAP.
If any can help me thank you.
Sincerely John
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Access Accept vs Tunneled reply
I am wondering if it's a misconfiguration of a group reply. I have those attributes listed as a group-reply. Would putting the attributes in the normal vs the group reply put them in a different portion of the response? David -Original Message- From: freeradius-users-bounces+david.peterson=acc-corp@lists.freeradius.org [mailto:freeradius-users-bounces+david.peterson=acc-corp.net@lists.freeradiu s.org] On Behalf Of Alexander Clouter Sent: Friday, March 11, 2011 10:28 AM To: freeradius-users@lists.freeradius.org Subject: Re: Access Accept vs Tunneled reply David Peterson dav...@wirelessconnections.net wrote: These values are unique per user. Is there an elegant way to copy this to the post-auth section? The following might help? http://lists.freeradius.org/mailman/htdig/freeradius-users/2011-January/msg0 0353.html Cheers -- Alexander Clouter .sigmonster says: What garlic is to food, insanity is to art. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Access Accept vs Tunneled reply
Please correct my assumption if I am off I have been working on getting reply attributes sent out to define VLAN's etc on a WiMax NAS. I see the following in radiusd -X: (3495) [ttls] Got tunneled reply code 2 WiMAX-VLAN-ID := 192 WiMAX-Classifer-Direction = Bi-Directional WiMAX-Classifer-Priority = 1 WiMAX-ClassifierID = 1 WiMAX-Downlink-QOS-Id = 1 WiMAX-Uplink-QOS-Id = 1 WiMAX-Transport-Type = Ethernet WiMAX-Direction = Bi-Directional WiMAX-Packet-Data-Flow-Id = 1 WiMAX-QoS-Id = 1 WiMAX-Schedule-Type = Best-Effort WiMAX-Maximum-Sustained-Traffic-Rate = 31457289 WiMAX-R3-IF-Name = vpws WiMAX-PDFID = 1 MS-CHAP2-Success = 0x1f533d38324436443835383335433145344237364441413938463137364443453038334643 374646363245 MS-MPPE-Recv-Key = 0xaaa52b27b269158aa25a2c3c36612ec4 MS-MPPE-Send-Key = 0xfd2e2270200bf84a3c9e34afe8eed5c1 MS-MPPE-Encryption-Policy = Encryption-Allowed MS-MPPE-Encryption-Types = RC4-40or128-bit-Allowed (3495) [ttls] Got tunneled Access-Accept Which would suggest that I am sending those TLV's in a radius packet. However, I ran Wireshark and do not see these TLV's in any radius packet. What would stop freeradius from creating these TLV's in the packet. I am thinking my dictionary.wimax additions are to blame or perhaps I need to use different operators. Any thoughts would be greatly appreciated. David -Original Message- From: freeradius-users-bounces+david.peterson=acc-corp@lists.freeradius.org [mailto:freeradius-users-bounces+david.peterson=acc-corp.net@lists.freeradiu s.org] On Behalf Of David Peterson Sent: Friday, March 11, 2011 11:55 AM To: 'FreeRadius users mailing list' Subject: RE: Access Accept vs Tunneled reply I am wondering if it's a misconfiguration of a group reply. I have those attributes listed as a group-reply. Would putting the attributes in the normal vs the group reply put them in a different portion of the response? David -Original Message- From: freeradius-users-bounces+david.peterson=acc-corp@lists.freeradius.or freeradius-users-bounces+g [mailto:freeradius-users-bounces+david.peterson=acc-corp.net@lists.freeradiu s.org] On Behalf Of Alexander Clouter Sent: Friday, March 11, 2011 10:28 AM To: freeradius-users@lists.freeradius.org Subject: Re: Access Accept vs Tunneled reply David Peterson dav...@wirelessconnections.net wrote: These values are unique per user. Is there an elegant way to copy this to the post-auth section? The following might help? http://lists.freeradius.org/mailman/htdig/freeradius-users/2011-January/msg0 0353.html Cheers -- Alexander Clouter .sigmonster says: What garlic is to food, insanity is to art. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: CHAP-Challenge Question
Yes. Unless the user entered the wrong password. Or, the NAS does the CHAP algorithm incorrectly. Thanks .. we were able to track down an issue with the way the NAS was getting the password. Jeremiah - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Access Accept vs Tunneled reply
David Peterson wrote: Please correct my assumption if I am off I have been working on getting reply attributes sent out to define VLAN's etc on a WiMax NAS. I see the following in radiusd -X: (3495) [ttls] Got tunneled reply code 2 These are the attributes *inside* of the tunnel. Did you set use_tunneled_reply = yes ? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Access Accept vs Tunneled reply
I have set: use_tunneled_reply = no copy_request_to_tunnel = no Set for both TTLS and PEAP sections. Should I be setting those to yes? David -Original Message- From: freeradius-users-bounces+david.peterson=acc-corp@lists.freeradius.org [mailto:freeradius-users-bounces+david.peterson=acc-corp.net@lists.freeradiu s.org] On Behalf Of Alan DeKok Sent: Friday, March 11, 2011 1:41 PM To: David Peterson-WirelessConnections; FreeRadius users mailing list Subject: Re: Access Accept vs Tunneled reply David Peterson wrote: Please correct my assumption if I am off I have been working on getting reply attributes sent out to define VLAN's etc on a WiMax NAS. I see the following in radiusd -X: (3495) [ttls] Got tunneled reply code 2 These are the attributes *inside* of the tunnel. Did you set use_tunneled_reply = yes ? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Access Accept vs Tunneled reply
Perhaps I have broken my install. I see that I have in my radiusd.conf file
the following:
$INCLUDE ${confdir}/modules/
# Extensible Authentication Protocol
#
# For all EAP related authentications.
# Now in another file, because it is very large.
#
$INCLUDE eap.conf
However, under /raddb/ I have eap.conf and under modules I have a file
called eap. Both look to be identical or nearly so.
Should I be getting rid of my eap.conf file?
David
-Original Message-
From:
freeradius-users-bounces+david.peterson=acc-corp@lists.freeradius.org
[mailto:freeradius-users-bounces+david.peterson=acc-corp.net@lists.freeradiu
s.org] On Behalf Of David Peterson
Sent: Friday, March 11, 2011 1:47 PM
To: FreeRadius users mailing list
Subject: RE: Access Accept vs Tunneled reply
I have set:
use_tunneled_reply = no
copy_request_to_tunnel = no
Set for both TTLS and PEAP sections. Should I be setting those to yes?
David
-Original Message-
From:
freeradius-users-bounces+david.peterson=acc-corp@lists.freeradius.or
freeradius-users-bounces+g
[mailto:freeradius-users-bounces+david.peterson=acc-corp.net@lists.freeradiu
s.org] On Behalf Of Alan DeKok
Sent: Friday, March 11, 2011 1:41 PM
To: David Peterson-WirelessConnections; FreeRadius users mailing list
Subject: Re: Access Accept vs Tunneled reply
David Peterson wrote:
Please correct my assumption if I am off I have been working on
getting reply attributes sent out to define VLAN's etc on a WiMax NAS.
I see the following in radiusd -X:
(3495) [ttls] Got tunneled reply code 2
These are the attributes *inside* of the tunnel. Did you set
use_tunneled_reply = yes ?
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Access Accept vs Tunneled reply
David Peterson dav...@wirelessconnections.net wrote: I am wondering if it's a misconfiguration of a group reply. I have those attributes listed as a group-reply. Would putting the attributes in the normal vs the group reply put them in a different portion of the response? As you have the User-Name/whatever-wimax utilises now movable from the inner-layer to the outer you can just do you policy on the outer layer instead. Do authentication on the inner-tunnel, whilst authorisation keep to the outer layer... Cheers -- Alexander Clouter .sigmonster says: Stay the curse. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Access Accept vs Tunneled reply
Progress at last guys! Thanks for all the help!Now seeing this both
outside the tunnel as well as in the pcap. Now to make my attribute conform
with the NAS.
(175) ++[wimax] returns updated
Sending Access-Accept of id 103 to 172.16.4.2 port 1812
WiMAX-VLAN-ID = 192
WiMAX-Classifer-Direction = Bi-Directional
WiMAX-Classifer-Priority = 1
WiMAX-ClassifierID = 1
WiMAX-Downlink-QOS-Id = 1
WiMAX-Uplink-QOS-Id = 1
WiMAX-Transport-Type = Ethernet
WiMAX-Direction = Bi-Directional
WiMAX-Packet-Data-Flow-Id = 1
WiMAX-QoS-Id = 1
WiMAX-Schedule-Type = Best-Effort
WiMAX-Maximum-Sustained-Traffic-Rate = 31457289
WiMAX-R3-IF-Name = vpws
WiMAX-PDFID = 1
EAP-Message = 0x03080004
Message-Authenticator = 0x
User-Name = {sm=1}3FF9EF10336DD9EF3892DC1ED1EF2696
WiMAX-IP-Technology = CMIP4
WiMAX-FA-RK-Key = 0x8287ac45d467483a74dadc2337a59574b7e49e0f
WiMAX-MSK = 0x
WiMAX-MSK =
0x3d0788c7f457fdbb4b69dffbfba26496064025dce735232348d8d76397faf1e2644b33e0cf
27ffe7a0953a0a8180fd58b8286b3d3caaf2f215f88b054b11171b
WiMAX-FA-RK-SPI = 1832484922
(175) Finished request.
-Original Message-
From:
freeradius-users-bounces+david.peterson=acc-corp@lists.freeradius.org
[mailto:freeradius-users-bounces+david.peterson=acc-corp.net@lists.freeradiu
s.org] On Behalf Of Alexander Clouter
Sent: Friday, March 11, 2011 1:34 PM
To: freeradius-users@lists.freeradius.org
Subject: Re: Access Accept vs Tunneled reply
David Peterson dav...@wirelessconnections.net wrote:
I am wondering if it's a misconfiguration of a group reply. I have
those attributes listed as a group-reply. Would putting the
attributes in the normal vs the group reply put them in a different
portion of the response?
As you have the User-Name/whatever-wimax utilises now movable from the
inner-layer to the outer you can just do you policy on the outer layer
instead. Do authentication on the inner-tunnel, whilst authorisation keep
to the outer layer...
Cheers
--
Alexander Clouter
.sigmonster says: Stay the curse.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Dictionary question`
I have to define a TLV which has a description of: TLV ID 1 for Classifier ID Description An identifier of the classifier that uniquely identifies the classifier in the scope of the Packet Flow Descriptor irrespective of whether or not the classifier is an uplink or downlink classifier. Length 2+1 Value 1 to 256. Would this be integer, short, byes? David - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Help migrating from 1.1.7 to 2.1.10 - clear text password being lost
Hi Radius Fans,
I am trying to move our current environment from 1.1.7 to 2.1.10 and are
having a problem getting things to work.
We have a Novell NDSLdap server which provides clear text passwords for
Novell users.
We are using peap-mschapv2.
What might be causing the request-config to be at a different location
between when the clear text password is stored and when it is needed to
authenticate?
What happens is that when a packet is sent from the server to the client
radius discards the request-config which contains the password on the identity
reply.
In the inner-tunnel you need to have ldap specified (as well as the
default) so that it will look up the password (again). (my mistake)
I was surprised that it appears that in the current environment for both
default and inner-tunnel:
# The example below uses module failover to avoid querying all
# of the following modules if the EAP module returns ok.
# Therefore, your LDAP and/or SQL servers will not be queried
# for the many packets that go back and forth to set up TTLS
# or PEAP. The load on those servers will therefore be reduced.
#
eap {
ok = return
}
That there are 3 queries to the ldap server and 3 queries to the sql
server (which is a lot better than the 12 of each which occur without
this option)
I assumed that if radius looked up the password via ldap or sql in default
it might have them for inner - but i guess the identity could be different
for inner vs default.
johnh...
johnh...
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Trying to get my sql configuration right.
Hi Radius People, I am getting the message from sql authentication: !!! !!! Please update your configuration so that the known good !!! !!! clear text password is in Cleartext-Password, and not in User-Password. !!! !!! From other posts the solution is to update the configuration to replace the attribute User-Password to be Cleartext-Password in the radcheck table. In the radcheck table I actually have Password which probably get mapped to User-Password and then the warning occurs. If I change an entry in radcheck table to actually have Cleartext-Password in the radcheck table I get: [pap] WARNING! No known good password found for the user. Authentication may fail because of this. and it fails to authenticate (but does not produce the warning message ;-) What might be causing the attribute Password from the table to get mapped to User-Password and what is suggested that I change to have radius be happy? johnh... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
