- Freeradius-Users - lists.freeradius.org

Use 2 modules to auth together.
by luckydog xf 26 Nov '18

26 Nov '18

hi, all, Any way to handle a second access request? Our user is in AD and VPN will do an MSCHAP authentication first and filter property of User-Name from access request, then call an access-challenge to verify against the other module whose logic is as simple as starting a http request via http://XXX/check/username= <http://xxx/check/username=><USER-NAME>&OTP=<xxxxxx>, if return 200, it's ok. Basically, I want to auth a single login against two modules, only both of them are successful, the auth could be deemed as OK. # site-enabled/default authorize { if (!State) { # MS-CHAP has no User-Password, so it's true. if (!User-Password ) { # If !State and User-Password is null, then goes to MS-CHAP: update { &control:Auth-Type := MS-CHAP } } else { reject } } else { # The 2nd auth module. # I DON'T KNOW HOW TO WRITE. } } } # ### authentication ##### authentication { Auth-Type MS-CHAP { mschap if (ok) { update reply { # Create a random State attribute: State := "%{randstr:XXXXXXXXXXXXX}" Reply-Message := "Please type your OTP:" } # Return Access-Challenge, goes to the 2nd auth. challenge } } } Thanks a lot.

2 2

FreeRadius 3.0.17 - outer tunnel username in accounting logs instead of inner tunnel username
by Thorsten Fritsch 23 Nov '18

23 Nov '18

Hi guys, we have recently upgraded our FreeRadius to release 3.0.17 and are now facing the issue that the accounting logs seem to contain the username provided in the anonymous (outer) identity field instead of the username used for the inner tunnel. This makes it hard to identify our eduroam users (user tracking). Has something changed in FreeRadius 3.x regarding thise behavior ? In my understanding the Radius server should provide the inner tunnel username to the NAS (in our case Cisco WLAN Controller) by parameter use_tunneled_reply = yes in the eap file under /mods-enabled which the NAS can then in turn provide to the Accounting server is that correct ? We have set this setting to yes in our config: ttls { tls = tls-common default_eap_type = mschapv2 copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "eduroam-inner-tunnel" } peap { tls = tls-common default_eap_type = mschapv2 copy_request_to_tunnel = yes use_tunneled_reply = yes virtual_server = "eduroam-inner-tunnel" } Thanks for your help. Cheers, Thorsten

3 4

No connections available and at max connection limit
by تعلم البرمجة 22 Nov '18

22 Nov '18

Hello all i have this problem and i want solve it rlm_sql (sql): No connections available and at max connection limit

2 1

Re: TXID mismatch between DHCP Request-Offer (devel version)
by Chinnapaiyan, Nagamani 22 Nov '18

22 Nov '18

It works after changing the code in my local repo... Thanks... We are storing TXID as it is(without ntohl). But while sending we are doing htonl. Corrected that also. # git diff diff --git a/src/modules/proto_dhcpv4/proto_dhcpv4.c b/src/modules/proto_dhcpv4/proto_dhcpv4.c index 465a3ea..3a80a8f 100644 --- a/src/modules/proto_dhcpv4/proto_dhcpv4.c +++ b/src/modules/proto_dhcpv4/proto_dhcpv4.c @@ -416,7 +416,7 @@ static ssize_t mod_encode(void const *instance, REQUEST *request, uint8_t *buffe } data_len = fr_dhcpv4_encode(buffer, buffer_len, - request->reply->code, original->xid, request->reply->vps); + request->reply->code, ntohl(original->xid), request->reply->vps); if (data_len < 0) { RPEDEBUG("Failed encoding DHCPV4 reply"); return -1; diff --git a/src/protocols/dhcpv4/packet.c b/src/protocols/dhcpv4/packet.c index 5460041..38790f9 100644 --- a/src/protocols/dhcpv4/packet.c +++ b/src/protocols/dhcpv4/packet.c @@ -218,6 +218,12 @@ int fr_dhcpv4_packet_decode(RADIUS_PACKET *packet) } p += len; } +//Decode message type from the option. +VALUE_PAIR *message_type = NULL; +message_type = fr_pair_find_by_da(head, attr_dhcp_message_type, TAG_ANY); +if(message_type) { +packet->code = message_type->vp_uint8; +} /* * If option Overload is present in the 'options' field, then fields 'file' and/or 'sname' Regards, Nagamani Chinnapaiyan

2 1

Getting error wile loading module during the uinttest case
by shivu prasad 22 Nov '18

22 Nov '18

Hi All, I am getting below error while loading my module during running testcase. But same module works fine as part of normal server, I can load my module, authenticate and even authorize works fine. But if I try to load the module in src/tests/modules//radiusd.conf I am getting the error. Even I verified the module.conf configuration its same as mods-enabled/mymodule_name only. Not sure what is missing here. Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "reject" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "fail" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "ok" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "handled" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "invalid" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "userlock" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "notfound" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "noop" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "updated" from file raddb/mods-enabled/always Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "pap" from file raddb/mods-enabled/pap Thu Nov 22 19:56:36 2018 : Debug: # Instantiating module "my_reject" from file src/tests/modules/always//module.conf Thu Nov 22 19:56:36 2018 : Debug: } # modules Thu Nov 22 19:56:36 2018 : Debug: radiusd: #### Loading Virtual Servers #### Thu Nov 22 19:56:36 2018 : Debug: server { # from file src/tests/modules//radiusd.conf Thu Nov 22 19:56:36 2018 : Debug: } # server Thu Nov 22 19:56:36 2018 : Debug: server default { # from file src/tests/modules//radiusd.conf Thu Nov 22 19:56:36 2018 : Debug: # Loading authenticate {...} Thu Nov 22 19:56:36 2018 : Debug: pap *Thu Nov 22 19:56:36 2018 : Error: src/tests/modules//radiusd.conf[40]: Failed to find "idcs" as a module or policy.Thu Nov 22 19:56:36 2018 : Error: src/tests/modules//radiusd.conf[40]: Please verify that the configuration exists in src/tests/modules//mods-enabled/idcs.Thu Nov 22 19:56:36 2018 : Error: src/tests/modules//radiusd.conf[38]: Errors parsing authenticate section. * # build/tests/modules/always/replace.log Regards, Shivaprasad

1 0

Does freeradius support Eap-sim/AKA module
by manjunath uthappa ponnachana 22 Nov '18

22 Nov '18

Hi All,Does freeradius support Eap-sim/aka module. Is it stable.How to configure it to interact with HLR.Thanks & regardsManjunath

1 0

Re: TXID mismatch between DHCP Request-Offer (devel version)
by Chinnapaiyan, Nagamani 22 Nov '18

22 Nov '18

Thanks for the quick fix. Now TXID is fixed. But the server responds with OFFER even for Request message. Attached the pcap for your reference. Debug output for Redis_ippool: Ready to process requests proto_dhcpv4_udp - Received DHCP-Discover XID 00000000 length 259 proto_dhcpv4_udp server 10.43.18.92 port 67 Network received packet size 259 Resetting worker 30 cleanup timer to +0s (0) running request (0) Received DHCP-Discover XID 00000000 from 127.0.0.1:67 to 10.43.18.92:67 via lo (0) &DHCP-Opcode = Client-Message (0) &DHCP-Hardware-Type = Ethernet (0) &DHCP-Hardware-Address-Length = 6 (0) &DHCP-Hop-Count = 1 (0) &DHCP-Transaction-Id = 0 (0) &DHCP-Number-of-Seconds = 0 (0) &DHCP-Flags = 0 (0) &DHCP-Client-IP-Address = 127.0.0.1 (0) &DHCP-Your-IP-Address = 0.0.0.0 (0) &DHCP-Server-IP-Address = 0.0.0.0 (0) &DHCP-Gateway-IP-Address = 127.0.0.1 (0) &DHCP-Client-Hardware-Address = 00:a1:bc:00:00:01 (0) &DHCP-Message-Type = DHCP-Discover (0) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (0) &DHCP-Client-Identifier = 0x0100a1bc000001 (0) Running 'recv DHCP-Discover' from file /usr/local/etc/raddb/sites-enabled/dhcp (0) recv DHCP-Discover { (0) update reply { (0) DHCP-Message-Type = DHCP-Offer (0) } # update reply (noop) (0) update reply { (0) &DHCP-Domain-Name-Server = 127.0.0.1 (0) &DHCP-Subnet-Mask = 255.255.255.0 (0) &DHCP-Router-Address = 10.43.18.92 (0) &DHCP-IP-Address-Lease-Time = 86400 (0) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (0) } # update reply (noop) (0) update control { (0) &Pool-Name := "local" (0) } # update control (noop) (0) redis_ippool - Allocating lease from pool "local", to "00:a1:bc:00:00:01", expires in 300s (0) redis_ippool - Reserved connection (1) (0) redis_ippool - [1] >>> Sending command(s) to 127.0.0.1:6379 (0) redis_ippool - [1] <<< Returned: success (0) redis_ippool - Released connection (1) (0) redis_ippool - Need 2 more connections to reach min connections (4) (0) redis_ippool - Opening additional connection (2), 1 of 2 pending slots used rlm_redis (redis) [1]: Connecting node to 127.0.0.1:6379 (0) redis_ippool - &reply:DHCP-Your-IP-Address := 192.168.0.122 (0) redis_ippool - &reply:DHCP-IP-Address-Lease-Time := 300 (0) redis_ippool - IP address lease allocated (0) redis_ippool (updated) (0) ok (ok) (0) } # recv DHCP-Discover (updated) (0) Sent DHCP-Offer XID 00000000 from 10.43.18.92:67 to 127.0.0.1:67 via lo (0) &DHCP-Message-Type = DHCP-Offer (0) &DHCP-Domain-Name-Server = 127.0.0.1 (0) &DHCP-Subnet-Mask = 255.255.255.0 (0) &DHCP-Router-Address = 10.43.18.92 (0) &DHCP-IP-Address-Lease-Time := 300 (0) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (0) done request (0) finished request. Ready to process requests Reply will be unicast to CIADDR from original packet. proto_dhcpv4_udp - cleaning up ID 1 Ready to process requests proto_dhcpv4_udp - Received DHCP-Request XID 00000000 length 265 proto_dhcpv4_udp server 10.43.18.92 port 67 Network received packet size 265 Resetting worker 30 cleanup timer to +0s (1) running request (1) Received DHCP-Discover XID 00000000 from 127.0.0.1:67 to 10.43.18.92:67 via lo (1) &DHCP-Opcode = Client-Message (1) &DHCP-Hardware-Type = Ethernet (1) &DHCP-Hardware-Address-Length = 6 (1) &DHCP-Hop-Count = 1 (1) &DHCP-Transaction-Id = 0 (1) &DHCP-Number-of-Seconds = 0 (1) &DHCP-Flags = 0 (1) &DHCP-Client-IP-Address = 127.0.0.1 (1) &DHCP-Your-IP-Address = 0.0.0.0 (1) &DHCP-Server-IP-Address = 0.0.0.0 (1) &DHCP-Gateway-IP-Address = 127.0.0.1 (1) &DHCP-Client-Hardware-Address = 00:a1:bc:00:00:01 (1) &DHCP-Requested-IP-Address = 192.168.0.122 (1) &DHCP-Message-Type = DHCP-Request (1) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (1) &DHCP-Client-Identifier = 0x0100a1bc000001 (1) Running 'recv DHCP-Discover' from file /usr/local/etc/raddb/sites-enabled/dhcp (1) recv DHCP-Discover { (1) update reply { (1) DHCP-Message-Type = DHCP-Offer (1) } # update reply (noop) (1) update reply { (1) &DHCP-Domain-Name-Server = 127.0.0.1 (1) &DHCP-Subnet-Mask = 255.255.255.0 (1) &DHCP-Router-Address = 10.43.18.92 (1) &DHCP-IP-Address-Lease-Time = 86400 (1) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (1) } # update reply (noop) (1) update control { (1) &Pool-Name := "local" (1) } # update control (noop) (1) redis_ippool - Allocating lease from pool "local", to "00:a1:bc:00:00:01", expires in 300s (1) redis_ippool - Reserved connection (2) (1) redis_ippool - [1] >>> Sending command(s) to 127.0.0.1:6379 (1) redis_ippool - [1] <<< Returned: success (1) redis_ippool - Released connection (2) (1) redis_ippool - &reply:DHCP-Your-IP-Address := 192.168.0.122 (1) redis_ippool - &reply:DHCP-IP-Address-Lease-Time := 300 (1) redis_ippool - IP address lease allocated (1) redis_ippool (updated) (1) ok (ok) (1) } # recv DHCP-Discover (updated) (1) Sent DHCP-Offer XID 00000000 from 10.43.18.92:67 to 127.0.0.1:67 via lo (1) &DHCP-Message-Type = DHCP-Offer (1) &DHCP-Domain-Name-Server = 127.0.0.1 (1) &DHCP-Subnet-Mask = 255.255.255.0 (1) &DHCP-Router-Address = 10.43.18.92 (1) &DHCP-IP-Address-Lease-Time := 300 (1) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (1) done request (1) finished request. Ready to process requests Reply will be unicast to CIADDR from original packet. proto_dhcpv4_udp - cleaning up ID 1 Ready to process requests Debug output for mac2ip: proto_dhcpv4_udp - Received DHCP-Discover XID 00000000 length 259 proto_dhcpv4_udp server 10.43.18.92 port 67 Network received packet size 259 Resetting worker 30 cleanup timer to +0s (4) running request (4) Received DHCP-Discover XID 00000000 from 127.0.0.1:67 to 10.43.18.92:67 via lo (4) &DHCP-Opcode = Client-Message (4) &DHCP-Hardware-Type = Ethernet (4) &DHCP-Hardware-Address-Length = 6 (4) &DHCP-Hop-Count = 1 (4) &DHCP-Transaction-Id = 0 (4) &DHCP-Number-of-Seconds = 0 (4) &DHCP-Flags = 0 (4) &DHCP-Client-IP-Address = 127.0.0.1 (4) &DHCP-Your-IP-Address = 0.0.0.0 (4) &DHCP-Server-IP-Address = 0.0.0.0 (4) &DHCP-Gateway-IP-Address = 127.0.0.1 (4) &DHCP-Client-Hardware-Address = 00:a1:bc:00:00:01 (4) &DHCP-Message-Type = DHCP-Discover (4) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (4) &DHCP-Client-Identifier = 0x0100a1bc000001 (4) Running 'recv DHCP-Discover' from file /usr/local/etc/raddb/sites-enabled/dhcp (4) recv DHCP-Discover { (4) update reply { (4) DHCP-Message-Type = DHCP-Offer (4) } # update reply (noop) (4) update reply { (4) &DHCP-Domain-Name-Server = 127.0.0.1 (4) &DHCP-Subnet-Mask = 255.255.255.0 (4) &DHCP-Router-Address = 10.43.18.92 (4) &DHCP-IP-Address-Lease-Time = 86400 (4) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (4) } # update reply (noop) (4) mac2ip - Added DHCP-Your-IP-Address: '10.1.1.3' to reply_items (4) mac2ip (ok) (4) ok (ok) (4) } # recv DHCP-Discover (ok) (4) Sent DHCP-Offer XID 00000000 from 10.43.18.92:67 to 127.0.0.1:67 via lo (4) &DHCP-Message-Type = DHCP-Offer (4) &DHCP-Domain-Name-Server = 127.0.0.1 (4) &DHCP-Subnet-Mask = 255.255.255.0 (4) &DHCP-Router-Address = 10.43.18.92 (4) &DHCP-IP-Address-Lease-Time = 86400 (4) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (4) done request (4) finished request. Ready to process requests Reply will be unicast to CIADDR from original packet. proto_dhcpv4_udp - cleaning up ID 1 Ready to process requests proto_dhcpv4_udp - Received DHCP-Request XID 00000000 length 265 proto_dhcpv4_udp server 10.43.18.92 port 67 Network received packet size 265 Resetting worker 30 cleanup timer to +0s (5) running request (5) Received DHCP-Discover XID 00000000 from 127.0.0.1:67 to 10.43.18.92:67 via lo (5) &DHCP-Opcode = Client-Message (5) &DHCP-Hardware-Type = Ethernet (5) &DHCP-Hardware-Address-Length = 6 (5) &DHCP-Hop-Count = 1 (5) &DHCP-Transaction-Id = 0 (5) &DHCP-Number-of-Seconds = 0 (5) &DHCP-Flags = 0 (5) &DHCP-Client-IP-Address = 127.0.0.1 (5) &DHCP-Your-IP-Address = 0.0.0.0 (5) &DHCP-Server-IP-Address = 0.0.0.0 (5) &DHCP-Gateway-IP-Address = 127.0.0.1 (5) &DHCP-Client-Hardware-Address = 00:a1:bc:00:00:01 (5) &DHCP-Requested-IP-Address = 10.1.1.3 (5) &DHCP-Message-Type = DHCP-Request (5) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (5) &DHCP-Client-Identifier = 0x0100a1bc000001 (5) Running 'recv DHCP-Discover' from file /usr/local/etc/raddb/sites-enabled/dhcp (5) recv DHCP-Discover { (5) update reply { (5) DHCP-Message-Type = DHCP-Offer (5) } # update reply (noop) (5) update reply { (5) &DHCP-Domain-Name-Server = 127.0.0.1 (5) &DHCP-Subnet-Mask = 255.255.255.0 (5) &DHCP-Router-Address = 10.43.18.92 (5) &DHCP-IP-Address-Lease-Time = 86400 (5) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (5) } # update reply (noop) (5) mac2ip - Added DHCP-Your-IP-Address: '10.1.1.3' to reply_items (5) mac2ip (ok) (5) ok (ok) (5) } # recv DHCP-Discover (ok) (5) Sent DHCP-Offer XID 00000000 from 10.43.18.92:67 to 127.0.0.1:67 via lo (5) &DHCP-Message-Type = DHCP-Offer (5) &DHCP-Domain-Name-Server = 127.0.0.1 (5) &DHCP-Subnet-Mask = 255.255.255.0 (5) &DHCP-Router-Address = 10.43.18.92 (5) &DHCP-IP-Address-Lease-Time = 86400 (5) &DHCP-DHCP-Server-Identifier = 10.43.18.92 (5) done request (5) finished request. Ready to process requests Reply will be unicast to CIADDR from original packet. proto_dhcpv4_udp - cleaning up ID 1 Ready to process requests Regards, Nagamani Chinnapaiyan

1 0

Load Balance FreeRadius
by oscar＠jofre.com 21 Nov '18

21 Nov '18

Hi, Actually I have a free radius on a centos connected to a mariadb database to give Access to hotspot users. I'm planning to move the freeradius to AWS and I would like to build 2 freeradius instances and 1 database instance. The idea is that when a paket is sent the balancer sends to one freeradius and the freeradius query or update the database and send response. The when a next packet is sent the balancer sends to the second freeradius and that query or update the database and send response.. So both freeradius instances uses the same database .. Maybe it does not have sense because probably the freeradius is not the slow part so build 2 instances to handle the traffic won't work . the database should be the slower part here. Is it possible Theatrically ? Does it has sense to do this schema ? What about freeradius on AWS ? Thanks a lot.

3 3

Re: Access-Accept does not "see" the attribute defined in the dictionary file
by Vafa Andalibi 21 Nov '18

21 Nov '18

Hi Alan, Sorry for the bad formatting. The code that I'm working on and I'm trying to run was previously developed on v3.1.x branch which apparently doesn't exists anymore. So I assumed the closest thing to that is the master now. The reason they used v.3.1.x instead of v3.0.x is mentioned in the comments to be "At the time of this writing, the FreeRadius 3.0.x versions have a problem with REST" and there is no further information about what was that problem. I'll try to move back to v3.0.x now. Thank you for your help, On Wed, Nov 21, 2018 at 10:55 AM Alan DeKok <aland(a)deployingradius.com> wrote: > On Nov 21, 2018, at 10:49 AM, Vafa Andalibi <vafandal(a)iu.edu> wrote: > > > > I've built the FR (master branch) > > Please don't use the "master" branch unless you are VERY familiar with > RADIUS. v4 is in heavy development, and may not even work from day to day. > > Why are you using v4? > > > on raspberry pi and I'm trying to run it > > with a custom defined attribute in Access-Accept. I have added this > > attribute at the end of */usr/local/etc/raddb/dictionary* as follows: > > > > > > *ATTRIBUTE TEST-ATTRIBUTE-1.2.3 3011 string* > > There's no need to add ** around everything. Just paste the text. > > And, why are you adding that attribute? What is it for? > > > This is the only uncommented line in the dictionary file. Then in > > */usr/local/etc/raddb/sites-enabled/default* inside the *send > > Access-Accept* block, > > I have added a very simple code: > > > > > > *send Access-Accept{* > > *...* > > *if (&session-state:TEST-ATTRIBUTE-1.2.3) {* > > * update {* > > * &Url-Data :="%{session-state:TEST-ATTRIBUTE-1.2.3}"* > > * }* > > * rest* > > *}* > > *...* > > *}* > > > > > > Then after running it with *sudo /usr/local/sbin/radiusd -X*, I'm getting > > the following error: > > > > *...* > > > > *compiling - send Access-Accept {...}* > > */usr/local/etc/raddb/sites-enabled/default[1033]: Failed resolving > > undefined attribute: Unknown protocol 'TEST-ATTRIBUTE-1'* > > Well, that seems simple enough. The name is getting truncated. Don't > use "." in an attribute name. > > Or, use v3. > > Alan DeKok. > > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html

2 1

Access-Accept does not "see" the attribute defined in the dictionary file
by Vafa Andalibi 21 Nov '18

21 Nov '18

Hello, I've built the FR (master branch) on raspberry pi and I'm trying to run it with a custom defined attribute in Access-Accept. I have added this attribute at the end of */usr/local/etc/raddb/dictionary* as follows: *ATTRIBUTE TEST-ATTRIBUTE-1.2.3 3011 string* This is the only uncommented line in the dictionary file. Then in */usr/local/etc/raddb/sites-enabled/default* inside the *send Access-Accept* block, I have added a very simple code: *send Access-Accept{* *...* *if (&session-state:TEST-ATTRIBUTE-1.2.3) {* * update {* * &Url-Data :="%{session-state:TEST-ATTRIBUTE-1.2.3}"* * }* * rest* *}* *...* *}* Then after running it with *sudo /usr/local/sbin/radiusd -X*, I'm getting the following error: *...* *compiling - send Access-Accept {...}* */usr/local/etc/raddb/sites-enabled/default[1033]: Failed resolving undefined attribute: Unknown protocol 'TEST-ATTRIBUTE-1'* */usr/local/etc/raddb/sites-enabled/default[1033]: Failed to parse "if" subsection* */usr/local/etc/raddb/sites-enabled/default[988]: Failed compiling 'send Access-Accept { ... }' section* */usr/local/etc/raddb/sites-enabled/default[80]: Could not load virtual server "default".* Could you please help me with this? what am I missing? Thank you in advance,

2 1