- Freeradius-Users - lists.freeradius.org

Re: Re: radius client / send NAS IP ?
by Michael Arndt 25 Sep '10

25 Sep '10

Alan, thx for answering at least the radclient of the installed version does not allow to add those attributes according to manpage if i read your hint right i should download an actual version and compile to get an radclient with enhanced abilities :-) TIA Micha ----- ursprüngliche Nachricht --------- Subject: Re: radius client / send NAS IP ? Date: Sa 25 Sep 2010 15:01:49 CEST From: Alan DeKok<aland(a)deployingradius.com> To: FreeRadius users mailing list<freeradius-users(a)lists.freeradius.org> Michael Arndt wrote: > is there a radtest client where i can send those attribute / value pairs > intentionally ? $ man radclient Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ---- ursprüngliche Nachricht Ende ----

2 1

radius client / send NAS IP ?
by Michael Arndt 25 Sep '10

25 Sep '10

Hello *, at the time beeing i have to use an old radius version for different reasons. freeradius-client-1.1.5-36 freeradius-devel-1.1.6-47 freeradius-1.1.6-47 freeradius-client-devel-1.1.5-36 freeradius-client-libs-1.1.5-36 for real logins at WLAN Hot Spot the DEFAULT NAS-IP-Address == "192.168.123.45" or DEFAULT Called-Station-Id =~ ".*:MYSSID" are part of the check ( via criteria in users ) is there a radtest client where i can send those attribute / value pairs intentionally ? else in my traces i will always see a refused as test result, since from localhost those parameters will not match Prio low, would just be nice for testing TIA Micha

2 1

rlm_exec: Wait=yes but no output defined
by Michael Arndt 25 Sep '10

25 Sep '10

Hello *, radiusd -X in different places announces rlm_exec: Wait=yes but no output defined. Did you mean output=none? Will freeradius fall back internally to output=none without inserting this attribut / value in the config ? Or should i mandatory add output=none ? TIA Micha

1 0

Last call for 2.1.10
by Alan DeKok 25 Sep '10

25 Sep '10

I've put some preliminary tar files on: http://git.freeradius.org/pre/ If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday. The changelog is *extensive*. There are a large number of minor bugs fixed, and a lot of minor new features added. But the result is that the server has taken a significant step ahead in usability and functionality. Thanks to everyone for testing intermediate releases. Alan DeKok.

10 23

Multiple Databases
by sekchel lee 24 Sep '10

24 Sep '10

I want Multiple databases group1 ==> databases1 group2 ==> databases 2 .. .. Please Help me

2 1

Radius proxy - kind of
by Matija Levec 24 Sep '10

24 Sep '10

Hi everyone! First a little bit of explaining... - auth_server 1 client - fr_proxy -[ - auth_server 2 (client=random NAS, fr_proxy=freeradius, auth_server=two-factor auth server(s)) Currently we have clients authenticating directly to auth_server 1. We would like to gradually (and transparently) move users to new authenticators which use auth_server 2 Question What I would like to accomplish is: If auth_server 1 returns notfound or reject or fail, proxy request to auth_server 2 Is it possible to use 'configurable module fail over'-like syntax for configuring proxy (home)servers? I hopes this makes sense. Anyway... all ideas appreciated! Regards, Matija

1 0

Re: Session Resumption fails
by Alexander Clouter 24 Sep '10

24 Sep '10

Hi, * Panagiotis Georgopoulos <panos(a)comp.lancs.ac.uk> [2010-09-24 04:17:16+0100]: > > I am afraid your suggestion though to add the above in my inner-tunnel > virtual server didn't solve the problem. After having searched the archives > of the list, I found out that this is an OpenSSL bug and there is a fix in > FreeRadius 2.1.10 for it. > A quick history lesson of this... That bug was more linked to OpenSSL actually authenticating sessions it should not if I remember correctly. https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=15 https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=21 As a result, as the OpenSSL folk were being awkward and claiming without explaination that FreeRADIUS was at fault, Alan added a check to only accept session resumption if there is some cached information returned. Then, along came Andreas Hartmann, who in spite of us all saying "give up, it's openssl at fault and no one is helping out" stumbled upon: http://lists.freeradius.org/mailman/htdig/freeradius-users/2010-June/msg001… > I just compiled 2.1.10 and I verify that I don't see resuming sessions > failing with this no information in the cache : > > Info: [ttls] Skipping Phase2 due to session resumption > Info: [ttls] WARNING: No information in cached session! > > However, I am not seeing the correct behaviour either :-/ > > [snipped] > > Does anyone have any pointers/suggestions? Anyone who managed to do session > resumption with 2.1.10? > > Fri Sep 24 03:03:10 2010 : Debug: Module: Linked to module rlm_eap > Fri Sep 24 03:03:10 2010 : Debug: Module: Instantiating module "eap" from file /usr/local/etc/raddb/eap.conf > Fri Sep 24 03:03:10 2010 : Debug: eap { > Fri Sep 24 03:03:10 2010 : Debug: default_eap_type = "md5" > Fri Sep 24 03:03:10 2010 : Debug: timer_expire = 60 > Fri Sep 24 03:03:10 2010 : Debug: ignore_unknown_eap_types = no > Fri Sep 24 03:03:10 2010 : Debug: cisco_accounting_username_bug = no > Fri Sep 24 03:03:10 2010 : Debug: max_sessions = 4096 > Fri Sep 24 03:03:10 2010 : Debug: } > [snipped] > Fri Sep 24 03:03:10 2010 : Debug: Module: Linked to sub-module rlm_eap_ttls > Fri Sep 24 03:03:10 2010 : Debug: Module: Instantiating eap-ttls > Fri Sep 24 03:03:10 2010 : Debug: ttls { > Fri Sep 24 03:03:10 2010 : Debug: default_eap_type = "md5" > Fri Sep 24 03:03:10 2010 : Debug: copy_request_to_tunnel = no > Fri Sep 24 03:03:10 2010 : Debug: use_tunneled_reply = no > Fri Sep 24 03:03:10 2010 : Debug: virtual_server = "inner-tunnel" > Fri Sep 24 03:03:10 2010 : Debug: include_length = yes > Fri Sep 24 03:03:10 2010 : Debug: } > use_tunneled_reply = yes > Fri Sep 24 03:03:10 2010 : Info: Ready to process requests. > rad_recv: Accounting-Request packet from host 2001:db93::2 port 37783, > id=15, length=102 > Acct-Status-Type = Accounting-Off > Acct-Authentic = RADIUS > NAS-IPv6-Address = 2001:db93::2 > NAS-Identifier = "panosAP-MR2" > Called-Station-Id = "00-1C-F0-9D-22-FF:panos_secure2" > Acct-Terminate-Cause = NAS-Reboot > Fri Sep 24 03:03:21 2010 : Info: # Executing section preacct from file > /usr/local/etc/raddb/sites-enabled/default > Fri Sep 24 03:03:21 2010 : Info: +- entering group preacct {...} > Fri Sep 24 03:03:21 2010 : Info: ++[preprocess] returns ok > Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute NAS-Port was not found in request, unique ID MAY be inconsistent > Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute Client-IP-Address was not found in request, unique ID MAY be inconsistent > Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute NAS-IP-Address was not found in request, unique ID MAY be inconsistent > Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute Acct-Session-Id was not found in request, unique ID MAY be inconsistent > Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute User-Name was not found in request, unique ID MAY be inconsistent > Fri Sep 24 03:03:21 2010 : Info: [acct_unique] Hashing ',,,,' > Fri Sep 24 03:03:21 2010 : Info: [acct_unique] Acct-Unique-Session-ID = "bfabf462b52fda97". > As a non-SSL resumption issue, this is going to cause you pain. I recommend in your 'acct_unique' module, the value of 'key' is changed to something like (obviously change to what you think is best): ---- acct_unique { key = "User-Name, Acct-Session-Id, NAS-IP-Address, NAS-Port, NAS-IPv6-Address, Packet-Src-IP-Address, Packet-Src-IPv6-Address, Called-Station-Id, Calling-Station-Id" } ---- The use of 'Client-IP-Address' is actually a bug...in FreeRADIUS (as it is a depreated attribute). > Fri Sep 24 03:03:58 2010 : Debug: Going to the next request > Fri Sep 24 03:03:58 2010 : Info: Ready to process requests. > rad_recv: Access-Request packet from host 2001:db94::2 port 53023, id=1, > length=189 > User-Name = "anonymous" > NAS-IPv6-Address = 2001:db4::2 > NAS-Identifier = "panosAP-TD4" > NAS-Port = 1 > Called-Station-Id = "00-1B-2F-2C-AE-45:panos_secure" > Calling-Station-Id = "00-1B-2F-2C-AD-D9" > Framed-MTU = 1400 > NAS-Port-Type = Wireless-802.11 > Connect-Info = "CONNECT 54Mbps 802.11g" > EAP-Message = 0x02c6000e01616e6f6e796d6f7573 > Message-Authenticator = 0xbc939da0f8f0ae045e3b34aacc8b8f4e > A non-SSL issue again, you *MUST* make your username 'user@realm' (or for TTLS '@realm' for the outer layer, and you should *force* Reject now, before it is too late, 'realm-less' logins. I guess this is works-in-progress for an eduroam deployment? If you do not force a realm on the outer layer, your users locally will be able to use 'eduroam' but the moment they leave the campus it stops working. The simpliest solution and only solution is to reject realmless (NULL) EAP authentications *now*. > Fri Sep 24 03:05:03 2010 : Info: # Executing section post-auth from file > /usr/local/etc/raddb/sites-enabled/inner-tunnel > } # server inner-tunnel > Fri Sep 24 03:05:03 2010 : Info: [ttls] Got tunneled reply code 2 > Reply-Message = "Hello, bob" > MS-MPPE-Encryption-Policy = 0x00000001 > MS-MPPE-Encryption-Types = 0x00000006 > MS-MPPE-Send-Key = 0x0e862e8c86b378eefa940cf437a147f8 > MS-MPPE-Recv-Key = 0xd701a18f6107c06a01b07b6dd677f587 > EAP-Message = 0x03030004 > Message-Authenticator = 0x00000000000000000000000000000000 > User-Name = "bob" > Fri Sep 24 03:05:03 2010 : Info: [ttls] Got tunneled Access-Accept > Fri Sep 24 03:05:03 2010 : Info: [ttls] Saving response in the cache > Fri Sep 24 03:05:03 2010 : Info: [ttls] WARNING: No information to cache: session caching will be disabled for this session. > Fri Sep 24 03:05:03 2010 : Debug: SSL: Removing session 1d6029bbddba233cd443d692b968df093237d9ad982f9ccc8a2defcd3edeb243 from the cache > Yes, editing your 'eap' module so that 'use_tunneled_reply = yes' should solve all this. Cheers -- Alexander Clouter .sigmonster says: fortune: cpu time/usefulness ratio too high -- core dumped.

1 0

Configuring LDAP lookups for EAP and inner-tunnel
by Jeffrey Collyer 24 Sep '10

24 Sep '10

Using freeradius 2.1.7 to authenticate wireless users via eap, checking against an ldap server. Its working fine, but I'm seeing an ldap lookup for each part of the eap conversation. This leads to something like 13 LDAP lookups for each valid eap authentication sequence. I did check the archives and found one thread about this same topic from a user of freeradius 1.x, and the comments there were that it would be much better in 2.x. via the inner-tunnel stuff. And I see in the eap_modules_changes page on the wiki, that Autz caching should resolve this for me. So I moved my ldap lookup configuration from the authorize section of the sites-enabled/default file into the inner-tunnel file. But I still see the same number of ldap queries per eap session. Next I tried to enable the cache section in the eap.conf for tls, but I have not seen that make any difference in the ldap calls. And from the comments I assume that just for session resumption, not initial authentication. Could someone give me a pointer/hint as to how to configure eap/ldap to cut down on the number of ldap queries. Any help greatly appreciated. Jeff

3 4

Re: Freeradius-Users Digest, Vol 65, Issue 105
by Sander van Loosbroek 24 Sep '10

24 Sep '10

What I'm trying to do is retrieve the user group from the OpenDirectory instead of setting a static one. There is only one NAS and the Mac OS X Server runs a standalone OpenDirectory Master so I don't need any huntgroups then? On 24 sep 2010, at 05:42, freeradius-users-request(a)lists.freeradius.org wrote: > Date: Fri, 24 Sep 2010 08:02:38 +1200 > From: Peter Lambrechtsen <plambrechtsen(a)gmail.com> > Subject: Re: Pushing group attribute from OpenDirectory to Cisco > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Message-ID: > <AANLkTik16Nrmbb1OmrVWcFuhTFKnLEDYwvPFs5FydrbT(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > In the "users" file is where you specify the reply attributes in my example. > > So using your example: > > DEFAULT Huntgroup-Name == CiscoVPN, Ldap-Group == > "cn=CiscoVPN,ou=Roles,ou=Radius,DC=ACME,DC=COM" > Service-Type = "NAS-Prompt-User", > Idle-Timeout = 600, > Cisco-AVPair = > "webvpn:user-vpn-group=whatevervpngroupyouwanttoaddtheuserto" > > Then you can either use the huntgroup file and set the IP addresses of the > Routers (NAS's) you're using: http://wiki.freeradius.org/Huntgroups > > Or you can have the Huntgroups in ldap as per my e-mail, and that would be > if you have a more dynamic environment or want to move the NAS between > different huntgroups easily. > > > > On Fri, Sep 24, 2010 at 2:03 AM, Sander van Loosbroek < > sander(a)vanloosbroek.com> wrote: > >> Hello Peter and Alan, >> >> Thank you for your reply. I've given the documentation of Peter a look but >> I'm not that familiar with LDAP or how its underpinnings work in OS X >> Server. >> >> When the Cisco router now authenticates against the FreeRADIUS server all >> works fine except for the fact that the group name is not returned with the >> webvpn:vpn-user-group attribute. What is unclear to me is how I instruct >> FreeRADIUS to include that attribute when it returns the authorization >> message. I have made the following addition to my clients file: >> >> client 192.168.13.1/32 { >> secret = xxx >> shortname = vpn >> nastype = cisco >> } >> >> I have added a policy to the Cisco router to pick up the attribute but it >> doesn't seem to get through. Can you suggest what to try next? >> >> Thanks, >> Sander >> - >> List info/subscribe/unsubscribe? See >> http://www.freeradius.org/list/users.html

1 0

Re: users match list criteria and vendor identification
by Cameron Wood 24 Sep '10

24 Sep '10

Does Freeradius have a way for me to see the packet sent to it? I've already tried running it with the -X flag, but that isn't showing enough detail. Cheers Cam. -- On 22/09/2010 4:38 PM, "Alan DeKok" <aland(a)deployingradius.com> wrote:

2 5