Re: Cisco WLC - Freeradius Vlan assigment problem
On 06/13/2012 11:02 PM, Martin Silvero wrote: ++- if (!Huntgroup-Name) returns ok ++? if (Huntgroup-Name == "list") (Attribute Huntgroup-Name was not found) the problem seems to be your huntgroup.. Can you post your huntgroup definitions? -- Jens Weibler IT-Services Hochschule Darmstadt www.h-da.de University of Applied Sciences Fachbereich Informatik www.fbi.h-da.de Schöfferstr. 8b D-64295 Darmstadt Tel +49 6151 16-8425 Fax +49 6151 16-8935 jens.weib...@h-da.de smime.p7s Description: S/MIME Cryptographic Signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Behavior on LDAP outage
On Wed, 2012-06-13 at 06:35 +, Alan Buxey wrote: > Ok, here is probably a use case for silently dropping rejects. That > way your NAS will behave okaybut you only want to do this if the > LDAP is down...so need to base it on that condition. That's if you > want to keep it all in the server, you could have an external cronjob > or such that checks LDAP and stops/starts the radius daemon thanks Alan, The suggestion from Alan DeKok works well for my needs at this stage, but your suggestion would be useful as a safety check to stop the radius daemon incase a miss configuration in production if it detects a known test user can't authenticate for any reason. (or maybe an iptables -j REJECT) regards, jethro -- Jethro Carr www.jethrocarr.com signature.asc Description: This is a digitally signed message part - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Behavior on LDAP outage
On Wed, 2012-06-13 at 15:46 +0200, Alan DeKok wrote:
> > Aside from "make sure your LDAP server doesn't die", ;-) can anyone make
> > any recommendations around the best approach to take, so that in event
> > of an LDAP outage on one host, FreeRadius returns a result (or nothing
> > at all) that causes the NAS to fail over to the secondary host?
>
> authorize {
> ...
> redundant {
> ldap
> do_not_respond
> }
> ...
> }
>
> That should work.
hi Alan,
That works perfectly. Thanks heaps for the advice! :-)
regards,
jethro
--
Jethro Carr
www.jethrocarr.com
signature.asc
Description: This is a digitally signed message part
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Cisco WLC - Freeradius Vlan assigment problem
Hi, >rad_recv: Access-Request packet from host 10.32.2.39 port 1645, id=199, >length=136 User-Name = "fcanales" Framed-MTU = 1400 Called-Station-Id = >"001d.4551.7da0" Calling-Station-Id = "5894.6b0d.e86c" Service-Type = >Login-User Message-Authenticator = 0x645687565f9d60e3b76f5ffac29b74a1 >EAP-Message = 0x0202000d016663616e616c6573 NAS-Port-Type = Wireless-802.11 >NAS-Port = 59460 NAS-IP-Address = 10.32.2.39 NAS-Identifier = "ap-Reco32" >The one that does not work: >rad_recv: Access-Request packet from host 10.32.2.81 port 32768, id=113, >length=232 User-Name = "fcanales" Calling-Station-Id = "58-94-6b-0d-e8-6c" >Called-Station-Id = "30-37-a6-4b-9f-90:IReconquista" NAS-Port = 1 >Cisco-AVPair = "audit-session-id=0a200251000f4eaaf051" NAS-IP-Address >= 10.32.2.81 NAS-Identifier = "Iplan_wcs" Airespace-Wlan-Id = 1 >Service-Type = Framed-User Framed-MTU = 1300 NAS-Port-Type = >Wireless-802.11 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 >Tunnel-Private-Group-Id:0 = "60" EAP-Message = >0x0202000d016663616e616c6573 Message-Authenticator = >0x77344c030301e2389311b1dde163a5b7 >The differencies in "Calling-Station-Id", "Called-Station-Id" and " >Service-Type", for example. >Is it posible that WCL is sending the information in a way that Radius >cannot process? no. its just sending them in the way its been configured...we use VLAN override with our cisco wireless controllers fine - and have done for years - even back in the FreeRADIUS 1.x days you just need to see what is different in your config between the bare AP and the wireless controller - and if you are talking about huntgroups then that might be east to spot - check the config files in FreeRADIUS config for how you have defined that AP IP 10.32.2.39 - compared to the wireless controller - 10.32.2.81 ...it might be something simple in your $RADDB/huntgroups file, for example. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Cisco WLC - Freeradius Vlan assigment problem
Hi Matthew,
I checked that out and it's configured as you suggested. The AAA Override
option is enabled.
The vlan attributes are these:
Tunnel-Type = VLAN
Tunnel-Medium-Type = IEEE-802
Tunnel-Private-Group-Id = VLAN_ID
It works fine when we use the AP against the radius server, but when we use
the WLC against the Radius server the process is not getting to the
attributes assignment part, because (I guess) it's not getting something in
the Huntgroup variable.
This is the difference. The one that works:
server inner-tunnel { +- entering group authorize {...} ++[preprocess]
returns ok ++? if (!Huntgroup-Name) ? Evaluating !(Huntgroup-Name) -> FALSE
++? if (!Huntgroup-Name) -> FALSE ++? if (Huntgroup-Name == "list") ?
Evaluating (Huntgroup-Name == "list") -> TRUE ++? if (Huntgroup-Name ==
"list") -> TRUE ++- entering if (Huntgroup-Name == "list") {...} +++? if
(Ldap-Group == "WIFI-Direccion")
"WIFI-Direccion" is the first LDAP group to check if the user is in.
The one that does not work:
server inner-tunnel { +- entering group authorize {...} ++[preprocess]
returns ok ++? if (!Huntgroup-Name) ? Evaluating !(Huntgroup-Name) -> TRUE
++? if (!Huntgroup-Name) -> TRUE ++- entering if (!Huntgroup-Name) {...}
+++[reply] returns ok ++- if (!Huntgroup-Name) returns ok ++? if
(Huntgroup-Name == "list") (Attribute Huntgroup-Name was not found)
Apart from this, I see differencies in other parts of the radius debug like
this:
The one that works:
rad_recv: Access-Request packet from host 10.32.2.39 port 1645, id=199,
length=136 User-Name = "fcanales" Framed-MTU = 1400 Called-Station-Id =
"001d.4551.7da0" Calling-Station-Id = "5894.6b0d.e86c" Service-Type =
Login-User Message-Authenticator = 0x645687565f9d60e3b76f5ffac29b74a1
EAP-Message = 0x0202000d016663616e616c6573 NAS-Port-Type = Wireless-802.11
NAS-Port = 59460 NAS-IP-Address = 10.32.2.39 NAS-Identifier = "ap-Reco32"
The one that does not work:
rad_recv: Access-Request packet from host 10.32.2.81 port 32768, id=113,
length=232 User-Name = "fcanales" Calling-Station-Id = "58-94-6b-0d-e8-6c"
Called-Station-Id = "30-37-a6-4b-9f-90:IReconquista" NAS-Port = 1
Cisco-AVPair = "audit-session-id=0a200251000f4eaaf051" NAS-IP-Address =
10.32.2.81 NAS-Identifier = "Iplan_wcs" Airespace-Wlan-Id = 1 Service-Type
= Framed-User Framed-MTU = 1300 NAS-Port-Type = Wireless-802.11
Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "60" EAP-Message = 0x0202000d016663616e616c6573
Message-Authenticator = 0x77344c030301e2389311b1dde163a5b7
The differencies in "Calling-Station-Id", "Called-Station-Id" and "
Service-Type", for example.
Is it posible that WCL is sending the information in a way that Radius
cannot process?
Thanks!
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: WING-ASN throwing error - Mandatory HA Mode parameter
Iliya Peregoudov wrote: > I've looked into the pcap file. WiMAX-HA-RK-Lifetime, WiMAX-HA-RK-SPI, > WiMAX-HA-RK-Key, and WiMAX-FA-RK-SPI attributes are there. My Wireshark > does not show their names, but they are there: Wireshark doesn't decode WiMAX attributes properly. I'm not surprised. The format is weird. > Go ask ASN-GW vendor what's going on. Exactly. Q: FreeRADIUS returned Access-Accept. Why isn't the user online? A: Go ask the NAS vendor why their product doesn't work. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: buffer overflow on mschap reject
Hi, > # radiusd -X | head -1 > FreeRADIUS Version 2.1.11, for host x86_64-pc-linux-gnu, built on Jun 11 > 2012 at 11:10:29 does it do it with 2.1.12 - which was released in september last year alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: WING-ASN throwing error - Mandatory HA Mode parameter
I've looked into the pcap file. WiMAX-HA-RK-Lifetime, WiMAX-HA-RK-SPI, WiMAX-HA-RK-Key, and WiMAX-FA-RK-SPI attributes are there. My Wireshark does not show their names, but they are there: WiMAX-HA-RL-Lifetime = 900 VSA: l=7 t=Unknown-Attribute(17): 000384 WiMAX-HA-RK-SPI = 0 VSA: l=7 t=Unknown-Attribute(16): 00 WiMAX-HA-RK-Key = 0xA2DD89C4... VSA: l=37 t=Unknown-Attribute(15): 00A2DD89C4... WiMAX-FA-RK-SPI = 2474926121 VSA: l=7 t=Unknown-Attribute(61): 0093846029 Go ask ASN-GW vendor what's going on. Rathod Subhashchandra wrote: Dear Fajar, ACCESS-ACCEPT screen logs shows following attributes but not in pcap. Screen logs: Sending Access-Accept of id 6 to 125.125.40.38 port 1812 WiMAX-MN-NAI = "u...@tataelxsi.com" Service-Type = Authenticate-Only State = 0xd2be425bd6b84f57c4a7ea648e1803b6 MS-MPPE-Recv-Key = 0xd967448623358aa2149aee72c8d59c7640ca9b7fb4c06836781533bb9ae7679d MS-MPPE-Send-Key = 0x49a17afa5f030067f31c8a3e44d14e88a312af0a90e1299e73019fa1c27e7fb3 WiMAX-MSK = 0xd967448623358aa2149aee72c8d59c7640ca9b7fb4c06836781533bb9ae7679d49a17afa5f 030067f31c8a3e44d14e88a312af0a90e1299e73019fa1c27e7fb3 EAP-Message = 0x03060004 Message-Authenticator = 0x User-Name = "u...@tataelxsi.com" WiMAX-IP-Technology = PMIP4 WiMAX-hHA-IP-MIP4 = 172.16.104.175 WiMAX-DNS-Server = 192.168.10.3 WiMAX-Accounting-Capabilities = IP-Session-Based WiMAX-Idle-Mode-Notification-Cap = Supported WiMAX-AAA-Session-Id = 0x30313032 WiMAX-Packet-Data-Flow-Id = 1 WiMAX-Service-Data-Flow-Id = 1 WiMAX-Service-Profile-Id = 1 WiMAX-Direction = Bi-Directional WiMAX-FA-RK-Key = 0xb977ed6f9bf2231bba840d7cf1c02cd1bd7f47fa Framed-IP-Address = 192.168.10.3 Session-Timeout = 172800 Termination-Action = 3 Chargeable-User-Identity = "u...@tataelxsi.com" WiMAX-HA-RK-Lifetime = 900 WiMAX-HA-RK-SPI = 0 WiMAX-HA-RK-Key = 0x2b83c9fd0e5c3e2f8af0aa4464ba27ff8372fe4b WiMAX-FA-RK-SPI = 2474926121 The content of Wireshark is attached. Wireshark ACCESS-ACCEPT message does not reflect WiMAX-HA-RK-Lifetime, WiMAX-HA-RK-SPI, WiMAX-HA-RK-Key, and WiMAX-FA-RK-SPI. Does it mean that above attributes are not added in the message and simply printed by FreeRadius server? Or Vendor specific HA mode parameters are different? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Split authorization / authentication
Le 13/06/2012 15:48, Alan DeKok a écrit : Emmanuel BILLOT wrote: What module should i use to send MAC adresses to another radius server, and getting back ok/nok before testing EAP ? That WILL NOT work. The server cannot proxy and also authenticate users. This is what a database is for. Put the MAC addresses into a database, and query that during the authorization phase. Using unlang yes, but what directive should i use ? Proxy cannot be one because MAC adresse has no suffix. If you're just going to proxy requests, you can proxy them anywhere you want, based on any criteria. Just set Proxy-To-Realm, using the realm name. The default is to proxy via domain suffixes. But other methods can also be used. There is no requirement for suffixes to be the *only* method of proxying. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Ok, that was what i wanted to be confirmed. Thanks a lot. Regards, -- Emmanuel BILLOT CATEL - Dpt. Système et Réseaux Rectorat - Académie d'Orléans-Tours 10, rue Molière - 45000 Orléans Tél : 02 38 79 45 57 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: IPv4 *and* IPv6 addresses for home_servers and failover
Hi,
> server_pool ja-net_pool {
> type = client-balance
> home_server = ja-net-roaming0_server
> home_server = ja-net-roaming0_server6
> home_server = ja-net-roaming1_server
> home_server = ja-net-roaming1_server6
> ...
> }
yes - but I wouldnt advise to do it that way - as all you are doing there is
using
one client balance - with the alternates being the same server ie roaming0
or roaming-ipv6
- if roaming0 was down/dead then the ipv6 one is too.
so, better with eg
ja-net-roaming0_server6
ja-net-roaming1_server6
ja-net-roaming2_server6
ja-net-roaming0_server
ja-net-roaming2_server
ja-net-roaming3_server
..or actually, why bother with IPv4 - just go native...
ja-net-roaming0_server6
ja-net-roaming1_server6
ja-net-roaming2_server6
you might want to look at client-port-balance or the hashed balance method as
you get more
spread through the remote proxies then.
also, keep the name in the config but add the IPv6/IP address in /etc/hosts
(also, dont forget that you'll need to add a listener to your virtual-server or
radiusd.conf
too - you cannot have ipv4 and ipv6 listener in the same statement - you just
add a second listener
alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Split authorization / authentication
Emmanuel BILLOT wrote: > What module should i use to send MAC adresses to another radius server, > and getting back ok/nok before testing EAP ? That WILL NOT work. The server cannot proxy and also authenticate users. This is what a database is for. Put the MAC addresses into a database, and query that during the authorization phase. > Using unlang yes, but what directive should i use ? Proxy cannot be one > because MAC adresse has no suffix. If you're just going to proxy requests, you can proxy them anywhere you want, based on any criteria. Just set Proxy-To-Realm, using the realm name. The default is to proxy via domain suffixes. But other methods can also be used. There is no requirement for suffixes to be the *only* method of proxying. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Behavior on LDAP outage
Jethro Carr wrote:
> The problem is, the NAS authenticating the users against FreeRadius
> considered the default authentication response (reject) to be a sign
> that FreeRadius on the server was OK and didn't fail over to the
> secondary server.
>
> I was expecting it to return unreachable or just time out, instead of
> running the default auth behavior, but maybe I've missed a configuration
> option or have incorrect assumptions.
That's the way that the server works. It's still up, and *another*
module might authenticate the user.
If you want the server to not respond, see the "do_not_respond" entry
in policy.conf.
> Aside from "make sure your LDAP server doesn't die", ;-) can anyone make
> any recommendations around the best approach to take, so that in event
> of an LDAP outage on one host, FreeRadius returns a result (or nothing
> at all) that causes the NAS to fail over to the secondary host?
authorize {
...
redundant {
ldap
do_not_respond
}
...
}
That should work.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Split authorization / authentication
Le 13/06/2012 15:14, Alan DeKok a écrit : Emmanuel BILLOT wrote: Is it possible to split authorization step as follow : - Considering we want to authorize user using EAP and MAC adresses - http://wiki.freeradius.org/Mac-Auth works fine, but is it possible to do EAP with one radius server and MAC address auth with another one ? Yes, but it's generally a bad idea. It adds complexity with no real purpose. FreeRADIUS can be configured to do whatever you want. It's best to keep everything in one server. Look at the debug output to see *how* those packets are different. Then, write down how you want them to be handled. Then, write the "unlang" to do it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Ok thanks for your answer. Possibly this is a bad idea but we have sometimes to work with obligations. What module should i use to send MAC adresses to another radius server, and getting back ok/nok before testing EAP ? Using unlang yes, but what directive should i use ? Proxy cannot be one because MAC adresse has no suffix. -- Emmanuel BILLOT CATEL - Dpt. Système et Réseaux Rectorat - Académie d'Orléans-Tours 10, rue Molière - 45000 Orléans Tél : 02 38 79 45 57 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Split authorization / authentication
Emmanuel BILLOT wrote: > Is it possible to split authorization step as follow : > > - Considering we want to authorize user using EAP and MAC adresses > - http://wiki.freeradius.org/Mac-Auth works fine, but is it possible to > do EAP with one radius server and MAC address auth with another one ? Yes, but it's generally a bad idea. It adds complexity with no real purpose. FreeRADIUS can be configured to do whatever you want. It's best to keep everything in one server. Look at the debug output to see *how* those packets are different. Then, write down how you want them to be handled. Then, write the "unlang" to do it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: IPv4 *and* IPv6 addresses for home_servers and failover
Bob Franklin wrote:
> I'd just just to check FreeRADIUS operates as I'm expecting (and have
> observed, in the limited amount of testing I've been able to do, before
> plugging things into the real world). I'm trying to get our FreeRADIUS
> 2.1.12 servers ready to handle IPv4 and IPv6 and, in particular,
> IPv6-accessible home_servers (e.g. the UK JANET Roaming NRPS ones).
It supports IPv6...
> If I do:
>
> home_server ja-net-roaming0_server {
>
> ... I have to put ONE of:
>
> ipaddr = roaming0.ja.net
> ipv6addr = roaming0.ja.net
>
> ... which one I put will control whether IPv4 or IPv6 is used to contact
> that host.
Yes. That's how it works.
> If so, does this mean that, if I want to allow the possibility of
> talking to the servers over IPv6 as well as IPv4 (and failing between
> one and other, if either are unavailable), I have to configure two
> distinct servers and set them up in the pool? e.g.
Yes.
> server_pool ja-net_pool {
> type = client-balance
> home_server = ja-net-roaming0_server
> home_server = ja-net-roaming0_server6
> home_server = ja-net-roaming1_server
> home_server = ja-net-roaming1_server6
> ...
> }
>
> This will mean that, when everything in the pool is up, some clients
> will always get an IPv4 home_server and some an IPv6 one.
That's a limitation of the current design. There are no "tiered" pools.
> I just want to confirm there's no way to configure a single home server
> that can use both IPv4 and IPv6, or have ones that use IPv6 unless it's
> available, then fail back to IPv4, and that what I'm proposing above is
> the recommended way of doing this.
There's really not many ways of doing this simply.
> [I realise that, if I configure them separately like this, I have to
> manually manage whether individual home servers have IPv4 or IPv6
> registrations.]
That has to be managed manually. Home servers in RADIUS are tied to
IP addresses.
It *may* be possible to automatically create multiple home servers
when the hostname resolves to multiple IPs. But that would require code
changes.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Split authorization / authentication
Hi, Is it possible to split authorization step as follow : - Considering we want to authorize user using EAP and MAC adresses - http://wiki.freeradius.org/Mac-Auth works fine, but is it possible to do EAP with one radius server and MAC address auth with another one ? BR, -- Emmanuel BILLOT CATEL - Dpt. Système et Réseaux Rectorat - Académie d'Orléans-Tours 10, rue Molière - 45000 Orléans Tél : 02 38 79 45 57 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: buffer overflow on mschap reject
On 06/13/12 13:04, alan buxey wrote: > Hi, > >> I did have a retry_msg which was left as the default value of >> >> retry_msg = "Re-enter (or reset) the password" >> >> After I commented out this line the problem went away. >> >> Thanks for your help. I'm guessing this shouldn't crash with the example >> config? maybe the mschap stuff bloats the reply too much? > > doesnt crash here - what code release are you using? # ntlm_auth -V Version 3.5.15 # radiusd -X | head -1 FreeRADIUS Version 2.1.11, for host x86_64-pc-linux-gnu, built on Jun 11 2012 at 11:10:29 > > 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
IPv4 *and* IPv6 addresses for home_servers and failover
Hello,
I'd just just to check FreeRADIUS operates as I'm expecting (and have
observed, in the limited amount of testing I've been able to do, before
plugging things into the real world). I'm trying to get our FreeRADIUS
2.1.12 servers ready to handle IPv4 and IPv6 and, in particular,
IPv6-accessible home_servers (e.g. the UK JANET Roaming NRPS ones).
If I do:
home_server ja-net-roaming0_server {
... I have to put ONE of:
ipaddr = roaming0.ja.net
ipv6addr = roaming0.ja.net
... which one I put will control whether IPv4 or IPv6 is used to contact
that host.
If so, does this mean that, if I want to allow the possibility of talking
to the servers over IPv6 as well as IPv4 (and failing between one and
other, if either are unavailable), I have to configure two distinct
servers and set them up in the pool? e.g.
home_server ja-net-roaming0_server {
ipaddr = roaming0.ja.net [or the IPv4 address]
...
}
home_server ja-net-roaming0_server6 {
ipv6addr = roaming0.ja.net [or the IPv6 address]
...
}
...
server_pool ja-net_pool {
type = client-balance
home_server = ja-net-roaming0_server
home_server = ja-net-roaming0_server6
home_server = ja-net-roaming1_server
home_server = ja-net-roaming1_server6
...
}
This will mean that, when everything in the pool is up, some clients will
always get an IPv4 home_server and some an IPv6 one.
I just want to confirm there's no way to configure a single home server
that can use both IPv4 and IPv6, or have ones that use IPv6 unless it's
available, then fail back to IPv4, and that what I'm proposing above is
the recommended way of doing this.
[I realise that, if I configure them separately like this, I have to
manually manage whether individual home servers have IPv4 or IPv6
registrations.]
Thanks for your help,
- Bob
--
Bob Franklin +44 1223 748479
Network Division, University of Cambridge Computing Service
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: buffer overflow on mschap reject
Hi, > I did have a retry_msg which was left as the default value of > > retry_msg = "Re-enter (or reset) the password" > > After I commented out this line the problem went away. > > Thanks for your help. I'm guessing this shouldn't crash with the example > config? maybe the mschap stuff bloats the reply too much? doesnt crash here - what code release are you using? alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-PEAP + Windows 7 with SSO and Password change
Phil Mayers wrote: > src/modules/rlm_eap/types/rlm_eap_mschapv2/rlm_eap_mschapv2.c: > > about line 741, maybe this: > >pairmove2(&response, &handler->request->reply->vps, > PW_MSCHAP_ERROR, 0); > > ...should be: > >pairmove2(&response, &handler->request->reply->vps, > PW_MSCHAP_ERROR, VENDORSPEC_MICROSOFT); > > ? > > I don't understand though; I tested this as working, so > > Unfortunately my testbed is no longer assembled :o( That is likely it. I've committed a fix both for that, and for the "Must change password" checks. It's now up on github. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP processing again
Emmanuel BILLOT wrote: > I will not understand all, but i think (i hope) i can roughly follow the > mechanism. I often try to known what a product do for configuring it. > Maybe it is a mistake... It's often a mistake. Explanations complex ideas often means getting deep into secondary topics. It's simpler and faster just to believe that it works. > Here are the last lines of a successful connexion. It begins with the > last outside tunnel authenticate section, just before entering > inner-tunnel parsing. > I obviously believe you about all what you said, but i can't find an > explicite authenticate section between * ldap authorization and * > entering LDAP. The LDAP group it's entering is in the authenticate section. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Auth-Type :- Reject in users file matches inner tunnel request but sends Access-Accept
On Tue, Jun 12, 2012 at 03:21:22PM -0700, Michael Gorven wrote: > On 12/06/2012 14:08 PDT, Alan DeKok wrote: > > Note that everything BUT the Reply-Message belongs on the first line > > with the "DEFAULT". The Reply-Message belongs on the second line. > > *sigh*, moving the Auth-Type :- Reject to the first line fixed this. I > thought that Auth-Type was a reply item and therefore went on the second > line. Thank you for your assistance. Rather than test FreeRADIUS-Proxied-To == "127.0.0.1", you might also want to consider having a separate 'files' module instance just for the inner tunnel instead. Then you won't be checking this stuff for the anonymous user in the outer anyway. Matthew -- Matthew Newton, Ph.D. Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: buffer overflow on mschap reject
On 06/12/12 15:20, Alan DeKok wrote: > Matt Richards wrote: >> Hello, >> >> I have got radius setup to authenticate wireless clients using MS-CHAP >> and everything works correctly if the entered user / pass is correct. >> >> If the password is wrong, however, I get a buffer overflow error and >> radiusd dies. > > You probably set the "retry_msg" to a very long string. I did have a retry_msg which was left as the default value of retry_msg = "Re-enter (or reset) the password" After I commented out this line the problem went away. Thanks for your help. I'm guessing this shouldn't crash with the example config? maybe the mschap stuff bloats the reply too much? > >>> *** buffer overflow detected ***: radiusd terminated >>> === Backtrace: = > > Reading doc/bugs would help here. > >> I can replicate this issue with radtest. > > Do you have a minimal config which could help? > >> Does anybody know why this might be happening? If you require any >> additional info please let me know. One thing I was thinking about >> trying it going back a few versions of ntlm_auth and tring again. Its >> interesting how I don't seem to be able to find any information relating >> to this on the Internet. > > The error path here is very small. i.e. ~15 lines of code. > > Running the server under "valgrind" would help, too. But first build > it with debugging symbols. > > 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: Re : Re: EAP processing
On Tue, Jun 12, 2012 at 08:11:17PM +0200, Billot wrote:
> It begins with a a complete request, and the authorize section.
> Parsing each authorize mechanism, only eap doesn't return "noops".
>
> A first question : the default file says
>
> eap {
> return ok
> }
>
> EAP request comes with EAP message and is so captured by the eap authorize
> section, right ?
> It returns an update of the original request with Auth-Type = EAP
>
> I can't understand why there is then one second authorize check.
You seem to be misunderstanding two things.
EAP (in the case of PEAP/TTLS anyway) sets up an encrypted tunnel,
within which a *second* EAP session happens. So you get the first
EAP, which does not authenticate the user, it just encrypts data.
Then the decrypted data is a second, "inner", EAP session, which
actually has the authentication.
In the case of PEAP/MS-CHAPv2, it's actually two EAP sessions with
different types - EAP-PEAP, which is the "outer", and
EAP-MS-CHAP-V2, which is the "inner".
So you have the outer "default" file, which calls the EAP module
to set up the encrypted tunnel. That then passes the data from
inside the tunnel to the "inner-tunnel" configuration, which runs
through in a similar way but authenticates the user. Depending on
the outcome of the inner-tunnel, the outer "default" then returns
Accept or Reject.
The other thing is that EAP has multiple round trips of packets
going backwards and forwards between the client and the server.
The "eap { return ok }" bit is for saving time - it means that the
server quits processing the rest of the other modules when the eap
module is setting up the tunnel. For example, if you're doing LDAP
lookups, you don't want them happening every time the EAP module
sends another challenge to the client - it's a complete waste of
time and resources. This config stops that happening. In short,
you generally just need to leave it alone and not worry about it.
Matthew
--
Matthew Newton, Ph.D.
Systems Architect (UNIX and Networks), Network Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253,
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP processing again
90b911054432b3a14f9
MS-MPPE-Send-Key =
0xc56881775c6929ffb64a59e4f9cbac06d99eb03ab5925f182555d2ec3af2b91e
EAP-Message = 0x03080004
Message-Authenticator = 0x
User-Name = "user1"
Finished request 6.
Going to the next request
Waking up in 4.6 seconds.
rad_recv: Accounting-Request packet from host 172.30.145.70 port 32769,
id=249, length=192
User-Name = "user1"
NAS-Port = 2
NAS-IP-Address = 172.30.145.70
NAS-Identifier = "wifi-admin"
Airespace-Wlan-Id = 1
Acct-Session-Id = "4fd83d9f/00:1d:e0:21:7b:31/94"
Acct-Authentic = RADIUS
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = "164"
Acct-Status-Type = Interim-Update
Acct-Input-Octets = 16133
Acct-Output-Octets = 21904
Acct-Input-Packets = 458
Acct-Output-Packets = 238
Acct-Session-Time = 47
Acct-Delay-Time = 0
Calling-Station-Id = "192.168.234.10"
Called-Station-Id = "172.30.145.70"
# Executing section preacct from file /etc/raddb/sites-enabled/default
+- entering group preacct {...}
++[preprocess] returns ok
[acct_unique] Hashing 'NAS-Port = 2,Client-IP-Address =
172.30.145.70,NAS-IP-Address = 172.30.145.70,Acct-Session-Id =
"4fd83d9f/00:1d:e0:21:7b:31/94",User-Name = "user1"'
[acct_unique] Acct-Unique-Session-ID = "9fcc14215b25e276".
++[acct_unique] returns ok
[suffix] No '@' in User-Name = "user1", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
++[files] returns noop
# Executing section accounting from file /etc/raddb/sites-enabled/default
+- entering group accounting {...}
[detail]expand:
/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d ->
/var/log/radius/radacct/172.30.145.70/detail-20120613
[detail] /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d
expands to /var/log/radius/radacct/172.30.145.70/detail-20120613
[detail]expand: %t -> Wed Jun 13 09:14:29 2012
++[detail] returns ok
++[unix] returns noop
[radutmp] expand: /var/log/radius/radutmp -> /var/log/radius/radutmp
[radutmp] expand: %{User-Name} -> user1
++[radutmp] returns ok
++[exec] returns noop
[attr_filter.accounting_response] expand: %{User-Name} -> user1
attr_filter: Matched entry DEFAULT at line 12
++[attr_filter.accounting_response] returns updated
Sending Accounting-Response of id 249 to 172.30.145.70 port 32769
Finished request 7.
Cleaning up request 7 ID 249 with timestamp +40
Going to the next request
Waking up in 4.6 seconds.
Cleaning up request 0 ID 224 with timestamp +39
Cleaning up request 1 ID 225 with timestamp +39
Cleaning up request 2 ID 226 with timestamp +39
Cleaning up request 3 ID 227 with timestamp +39
Cleaning up request 4 ID 228 with timestamp +39
Waking up in 0.3 seconds.
Cleaning up request 5 ID 229 with timestamp +40
Cleaning up request 6 ID 230 with timestamp +40
Ready to process requests.
--
Emmanuel BILLOT
CATEL - Dpt. Système et Réseaux
Rectorat - Académie d'Orléans-Tours
10, rue Molière - 45000 Orléans
Tél : 02 38 79 45 57
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-PEAP + Windows 7 with SSO and Password change
On 13/06/12 10:44, Alan DeKok wrote:
CD DD wrote:
i changed the source src/modules/rlm_mschap/rlm_mschap.c, recompiled and
re-installed it.
But it still not working.
Why the passchange part will not handled ?
...
(8) mschap :expand: --nt-response=%{%{mschap:NT-Response}:-00} ->
--nt-response=e3426708aea6af13c9ba6ca1af31212f460cd1a834482660
Exec-Program output: Must change password (0xc224)
Exec-Program-Wait: plaintext: Must change password (0xc224)
Exec-Program: returned: 1
(8) mschap : ntlm_auth says password must change
(8) [mschap] = reject
rlm_eap_mschapv2: No MS-CHAPv2-Success or MS-CHAP-Error was found.
That's the problem. Find out why the rlm_mschap module is *not*
setting MS-CHAP-Error. From reading the code, it should be doing that.
Unfortunately, figuring that out will take C debugging skills.
src/modules/rlm_eap/types/rlm_eap_mschapv2/rlm_eap_mschapv2.c:
about line 741, maybe this:
pairmove2(&response, &handler->request->reply->vps,
PW_MSCHAP_ERROR, 0);
...should be:
pairmove2(&response, &handler->request->reply->vps,
PW_MSCHAP_ERROR, VENDORSPEC_MICROSOFT);
?
I don't understand though; I tested this as working, so
Unfortunately my testbed is no longer assembled :o(
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-PEAP + Windows 7 with SSO and Password change
CD DD wrote:
> i changed the source src/modules/rlm_mschap/rlm_mschap.c, recompiled and
> re-installed it.
>
> But it still not working.
> Why the passchange part will not handled ?
...
> (8) mschap : expand: --nt-response=%{%{mschap:NT-Response}:-00} ->
> --nt-response=e3426708aea6af13c9ba6ca1af31212f460cd1a834482660
> Exec-Program output: Must change password (0xc224)
> Exec-Program-Wait: plaintext: Must change password (0xc224)
> Exec-Program: returned: 1
> (8) mschap : ntlm_auth says password must change
> (8) [mschap] = reject
> rlm_eap_mschapv2: No MS-CHAPv2-Success or MS-CHAP-Error was found.
That's the problem. Find out why the rlm_mschap module is *not*
setting MS-CHAP-Error. From reading the code, it should be doing that.
Unfortunately, figuring that out will take C debugging skills.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-PEAP + Windows 7 with SSO and Password change
Hi Phil, Alan,
>Ok. ntlm_auth is returning something different to what I saw in testing.
>Have you set the "must change password at next login" bit, as opposed to
>"expired" bit?
>
>Try this:
>
> 1. Edit src/modules/rlm_mschap/rlm_mschap.c about line 1100, where it
>says:
>
> if (strstr(buffer, "Password expired")) {
>
>...to read:
>
> if (strstr(buffer, "Password expired") ||
> strstr(buffer, "Must change password")) {
>
> 2. Re-compile and re-install
>
> 3. Test again
>
>There's no great way to parse the output of ntlm_auth. I guess we could
>make the string a regexp comparison against the output, and at least
>make it an item in the config file (with a sensible default) so that if
>more such cases come up, or Samba change their output, it can be fixed
>without a recompile.
i changed the source src/modules/rlm_mschap/rlm_mschap.c, recompiled and
re-installed it.
But it still not working.
Why the passchange part will not handled ?
Here is the debug output:
FreeRADIUS Version 3.0.0, for host x86_64-portbld-freebsd9.0, built on Jun 13
2012 at 10:06:56
Copyright (C) 1999-2009 The FreeRADIUS server project and contributors.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License v2.
Starting - reading configuration files ...
including configuration file /usr/local/etc/raddb/radiusd.conf
including configuration file /usr/local/etc/raddb/proxy.conf
including configuration file /usr/local/etc/raddb/clients.conf
including files in directory /usr/local/etc/raddb/mods-enabled/
including configuration file /usr/local/etc/raddb/mods-enabled/wimax
including configuration file /usr/local/etc/raddb/mods-enabled/always
including configuration file /usr/local/etc/raddb/mods-enabled/attr_filter
including configuration file /usr/local/etc/raddb/mods-enabled/attr_rewrite
including configuration file /usr/local/etc/raddb/mods-enabled/chap
including configuration file /usr/local/etc/raddb/mods-enabled/checkval
including configuration file /usr/local/etc/raddb/mods-enabled/counter
including configuration file /usr/local/etc/raddb/mods-enabled/cui
including configuration file /usr/local/etc/raddb/mods-enabled/detail
including configuration file /usr/local/etc/raddb/mods-enabled/detail.log
including configuration file /usr/local/etc/raddb/mods-enabled/digest
including configuration file /usr/local/etc/raddb/mods-enabled/dynamic_clients
including configuration file /usr/local/etc/raddb/mods-enabled/eap
including configuration file /usr/local/etc/raddb/mods-enabled/echo
including configuration file /usr/local/etc/raddb/mods-enabled/exec
including configuration file /usr/local/etc/raddb/mods-enabled/expiration
including configuration file /usr/local/etc/raddb/mods-enabled/expr
including configuration file /usr/local/etc/raddb/mods-enabled/files
including configuration file /usr/local/etc/raddb/mods-enabled/inner-eap
including configuration file /usr/local/etc/raddb/mods-enabled/linelog
including configuration file /usr/local/etc/raddb/mods-enabled/logintime
including configuration file /usr/local/etc/raddb/mods-enabled/mschap
including configuration file /usr/local/etc/raddb/mods-enabled/ntlm_auth
including configuration file /usr/local/etc/raddb/mods-enabled/pap
including configuration file /usr/local/etc/raddb/mods-enabled/passwd
including configuration file /usr/local/etc/raddb/mods-enabled/preprocess
including configuration file /usr/local/etc/raddb/mods-enabled/radutmp
including configuration file /usr/local/etc/raddb/mods-enabled/realm
including configuration file /usr/local/etc/raddb/mods-enabled/replicate
including configuration file /usr/local/etc/raddb/mods-enabled/soh
including configuration file /usr/local/etc/raddb/mods-enabled/sradutmp
including configuration file /usr/local/etc/raddb/mods-enabled/unix
including configuration file /usr/local/etc/raddb/mods-enabled/utf8
including configuration file /usr/local/etc/raddb/mods-enabled/acct_unique
including configuration file /usr/local/etc/raddb/policy.conf
including files in directory /usr/local/etc/raddb/sites-enabled/
including configuration file /usr/local/etc/raddb/sites-enabled/default
including configuration file /usr/local/etc/raddb/sites-enabled/inner-tunnel
main {
security {
allow_core_dumps = no
}
}
including dictionary file /usr/local/etc/raddb/dictionary
main {
name = "radiusd"
prefix = "/usr/local"
localstatedir = "/var"
sbindir = "/usr/local/sbin"
logdir = "/var/log"
run_dir = "/var/run/radiusd"
libdir = "/usr/local/lib/freeradius-3.0.0"
radacctdir = "/var/log/radacct"
hostname_lookups = no
max_request_time = 30
cleanup_delay = 5
max_requests = 1024
pidfile = "/var/run/radiusd/radiusd.pid"
checkrad = "/usr/local/sbin/checkrad"
debug_level = 0
proxy_requests = ye
Re: EAP processing again
Emmanuel BILLOT wrote: > Ok i read all of the debug output, and i think i can understand > mechanism. However could you confirm (or not) what i understand ? I'm trying to figure out why you need to understand it. The details of the EAP flow are complex. You don't need to understand them. You just configure the server. > In case of an EAP/TTLS connexion : > > - Freeradius get a request, with a particular attribut : EAP-Message > - Entering authorize section, only EAP one matches because of EAP > attribut => Auth-Type is set to EAP > - Entering authenticate section, Freeradius sent a challenge to client If you're going to be technical, the *EAP* module creates an EAP-Message, a State, and then tells the server to send a challenge to the client. You can't go halfway on the details. Either ignore the details entirely, or understand them fully. Any intermediate step is a disaster. > - Client answer > > - Freeradius get a new request with attribut EAP-Message, State and a > new Message-Authenticator *All* Message-Authenticators are unique to the packet. It's used to sign packets. It is *not* used for anything in EAP. The State attribute is used to match a challenge. The EAP module uses it to match the packet to an ongoing EAP conversation. > - Entering authorize section, EAP matches > - Entering authenticate section. EAP matches (Auth-Type = EAP). > Freeradius sent response to client (negociating ?) Again, the EAP module runs. It finds an EAP sub-module to run, and hands over control to it. > - Client answer > > - Freeradius get a new request with attribut EAP-Message, State and new > Message-Authenticator > - Entering authorize section, EAP matches, tunnel setup is set > - Entering authenticate section. EAP matches (Auth-Type = EAP). TTLS > type found, beginning with TLS. SSL working, sending response to client > > - Client answer > > - Freeradius get a new request with attribut EAP-Message, State and new > Message-Authenticator > - Entering authorize section, EAP matches, tunnel continues > - Entering authenticate section. EAP matches (Auth-Type = EAP). > Negociating SSL, sending response to client > > - Client answer > > - Freeradius get a new request with attribut EAP-Message, State and new > Message-Authenticator > - Entering authorize section, EAP matches, tunnel continues > - Entering authenticate section. EAP matches (Auth-Type = EAP). SSL > tunnel negociated, sending response to client > > - Client answer > > - Freeradius get a new request with attribut EAP-Message, State and new > Message-Authenticator > - Entering authorize section, EAP matches, tunnel continues > - Entering authenticate section. EAP matches (Auth-Type = EAP). SSL > tunnel negociated, session establisshed, sending response to client That's all largely correct. But again, I have to question *why* you care. > - Client answer > > - Freeradius get a new request with attribut EAP-Message, State and new > Message-Authenticator > - Entering authorize section, EAP matches, tunnel continues > - Entering authenticate section. EAP matches (Auth-Type = EAP). Session > establisshed, entering inner-tunnel section. > A this time, no more EAP request/send, only new authorise/authenticate > in the tunnel. No. As I said before, the TLS tunnel contains authentication data. That data is used to create a "fake" request. That fake request is run through the "inner-tunnel" virtual server. The purpose of the "inner-tunnel" virtual server is to virtualize the configuration. PEAP and TTLS can share the same "inner-tunnel". You can treat the "inner-tunnel" just as if it received a normal RADIUS packet. The other RADIUS servers do *not* have this feature. The "inner-tunnel" authentication is handled by various special-purpose magic. That makes the configuration more complex and hard to understand. > - Entering inner-tunnel authorize section, LDAP matches No. The *entire" authorize section is processed. Whatever modules are their do things to the request. > - Entering LDAP section : bind successful, login is authenticated No. After authorize, the "authenticate" section is called. This used whatever Auth-Type was set in the "authorize" section. > - Access-Accept is send to client Absolutely not. You've missed a LARGE part of the debug output. The inner-tunnel returns "Access-Accept". The default (outer) virtual server then continues it's work. This often means a number of more EAP exchanges with the client. Once the outer EAP session is done, the server returns an Access-Accept to the client. > If i'm right, i'm asking some questions : > - in the first step of the connexion, what is exactly the job of > authorize section ? Does it only set auth-type when finding any "clue" > in the request ? That's the job of the authorize section. It sets Auth-Type, and *anything else* you need it to do. > - when connexion is in the tunnel step, a "reduced" request is sent ( > without EAP
EAP processing again
Hi, Ok i read all of the debug output, and i think i can understand mechanism. However could you confirm (or not) what i understand ? In case of an EAP/TTLS connexion : - Freeradius get a request, with a particular attribut : EAP-Message - Entering authorize section, only EAP one matches because of EAP attribut => Auth-Type is set to EAP - Entering authenticate section, Freeradius sent a challenge to client - Client answer - Freeradius get a new request with attribut EAP-Message, State and a new Message-Authenticator - Entering authorize section, EAP matches - Entering authenticate section. EAP matches (Auth-Type = EAP). Freeradius sent response to client (negociating ?) - Client answer - Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel setup is set - Entering authenticate section. EAP matches (Auth-Type = EAP). TTLS type found, beginning with TLS. SSL working, sending response to client - Client answer - Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel continues - Entering authenticate section. EAP matches (Auth-Type = EAP). Negociating SSL, sending response to client - Client answer - Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel continues - Entering authenticate section. EAP matches (Auth-Type = EAP). SSL tunnel negociated, sending response to client - Client answer - Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel continues - Entering authenticate section. EAP matches (Auth-Type = EAP). SSL tunnel negociated, session establisshed, sending response to client - Client answer - Freeradius get a new request with attribut EAP-Message, State and new Message-Authenticator - Entering authorize section, EAP matches, tunnel continues - Entering authenticate section. EAP matches (Auth-Type = EAP). Session establisshed, entering inner-tunnel section. A this time, no more EAP request/send, only new authorise/authenticate in the tunnel. - Entering inner-tunnel authorize section, LDAP matches - Entering LDAP section : bind successful, login is authenticated - Access-Accept is send to client If i'm right, i'm asking some questions : - in the first step of the connexion, what is exactly the job of authorize section ? Does it only set auth-type when finding any "clue" in the request ? - when connexion is in the tunnel step, a "reduced" request is sent ( without EAP attributes). This request is checked by the inner-tunnel authorize section which will set the auth-type, right ? Here the auth-type found is LDAP. If i follow the entire log, i can see - entering authorize - finding Ldap Auth - entering LDAP section, and then bind... But i can't see entering authenticate section as we can see in the firt step with EAP It's quite hard to explain, but * Outside tunnel : request -> authorize section -> Foudn type EAP -> authenticate section -> EAP working * Inside tunnel : request -> authorize section -> Foudn type LDAP -> LDAP working Why is there an "authenticate section" for EAP and a direct use of LDAP section for LDAP ? -- Emmanuel BILLOT CATEL - Dpt. Système et Réseaux Rectorat - Académie d'Orléans-Tours 10, rue Molière - 45000 Orléans Tél : 02 38 79 45 57 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Eduroam PRoblem
radiusd -X ?? alan -- This smartphone uses free WiFi around the world with eduroam, now that's what I call smart. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
