- Freeradius-Users - lists.freeradius.org

What proxy features does the freeradius server support?
by work vlpl 20 Oct '17

20 Oct '17

Hello, I want to implement the following proxy scenario: 1. User send request with eap-ttls or eap-tls or peap-mschapv2. 2. Proxy freeradius server analyze this requeset 3. If username from these request has custom radius attribute which determines whether the request should be sent to. 4. Send original or new request with the same type as original, to the home server 5. If home server return Accept, Accept- user, if no - reject. And I want to know is this possible or not ? If yes please give me some example. The protocols are eap-tls; eap-ttls; peap-mschapv2;

2 5

pam_radius_auth.so authentication algorithm
by Oussama BOUNAIM 20 Oct '17

20 Oct '17

Hello, I want to setup a centralized authentication on all my Linux servers. To do so, I'am trying to setup Radius authentication on a Windows Active Directory (with the NPS role) using the PAM module pam_radius_auth.so https://freeradius.org/sub_projects/. The authentication works, however, the NPS (Radius Server) is complaining about the authentication method used by pam_radius_auth.so. It says that the client is using PAP insecure PAP protocol. I didn't find any parameter on the module documentation <https://github.com/FreeRADIUS/pam_radius> to change this behavior. Does pam_radius_auth.so support other secure protocol like CHAP ? Thanks in advance for your help. Best Regards,

3 4

Default vs Inner-tunnel concepts
by Tom Yard 20 Oct '17

20 Oct '17

Dear, I want to use eap with TLS authentication in Freeradius. At this moment, I've setup both default and inner.-tunnel files, and everything works OK. Am I right or do I have to use just inner-tunnel file? Please can you help me in this concept? Because I think if I have to use eap with TLS, I have to edit default and inner tunnel files, but maybe I'm wrong and I just have to edit inner-tunnel file and let default file as it comes from package installation. Special thanks, TOM

2 5

Authentication against the Unix password database?
by Stefan Bruda 18 Oct '17

18 Oct '17

Hello, I am running freeradius-3.0.14 (stable Gentoo, USE="pam python readline ssl -debug (-firebird) -iodbc -kerberos -ldap -mysql -odbc -oracle -pcap -postgres -sqlite"). I would like my radius server to authenticate users against the Unix password database. Direct authentication is preferred but PAM authentication will do just as well. With the 2.x version I succeeded in doing this by forcing Auth-Type = System in the users file and using the "unix" module, but this no longer works (apparently justifiably so) in the 3.x version. Now I have the following for my default site: authorize { ... unix # files ... } authenticate { ... pam ... } I then get the following somehow puzzling result (with a certified valid Unix user name and password): (2) # Executing section authorize from file /etc/raddb/sites-enabled/default (2) authorize { ... (2) [chap] = noop (2) [mschap] = noop (2) [digest] = noop (2) suffix: Checking for suffix after "@" (2) suffix: No '@' in User-Name = "<del>", looking up realm NULL (2) suffix: No such realm "NULL" (2) [suffix] = noop (2) eap: No EAP-Message, not doing EAP (2) [eap] = noop (2) [unix] = notfound (2) [expiration] = noop (2) [logintime] = noop (2) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (2) pap: WARNING: Authentication will fail unless a "known good" password is available (2) [pap] = noop (2) } # authorize = ok (2) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject What I am puzzled about is the "notfound" result provided by the unix module. Next I tried to do PAM authentication by uncommenting the "files" line in the authorize section and forcing "Auth-Type = Pam" in the users file. This one at least communicates with the PAM system: (0) # Executing section authorize from file /etc/raddb/sites-enabled/default (0) authorize { ... (0) [unix] = notfound (0) files: users: Matched entry DEFAULT at line 7 (0) [files] = ok (0) [expiration] = noop (0) [logintime] = noop (0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (0) pap: WARNING: Authentication will fail unless a "known good" password is available (0) [pap] = noop (0) } # authorize = ok (0) Found Auth-Type = pam (0) # Executing group from file /etc/raddb/sites-enabled/default (0) authenticate { (0) pam: Using pamauth string "radiusd" for pam.conf lookup (0) pam: ERROR: pam_authenticate failed: Authentication failure (0) [pam] = reject (0) } # authenticate = reject (0) Failed to authenticate the user I get the following in the logs (login name redacted): Oct 18 10:23:40 localhost unix_chkpwd[26318]: check pass; user unknown Oct 18 10:23:40 localhost unix_chkpwd[26319]: check pass; user unknown Oct 18 10:23:40 localhost unix_chkpwd[26319]: password check failed for user (<del>) Oct 18 10:23:40 localhost radiusd: pam_unix(radiusd:auth): authentication failure; logname=<del> uid=107 euid=107 tty= ruser= rhost= user=<del> The file /etc/pam.d/radius looks fine to me: auth include system-auth account include system-auth password include system-auth session include system-auth PAM authentication works well with my other subsystems (e.g., sshd). Should more information be needed just ask. If anybody have any idea about what I am doing wrong I would very much appreciate to hear about it. Many thanks in advance! Best regards, Stefan

2 2

EAP Auth-Type Error
by Byron Jeffery 18 Oct '17

18 Oct '17

Hi All I am currently building a Freeradius (Version 3.0.15) on Ubuntu 16.04 in an Azure environment authenticating to an Active Directory server using eap-peap-mschap. I also have a Freeradius version 3.0.12 currently running and have replicated all the settings across to the new build, however, I am unable to successfully authenticate and have noted the error "eap: No EAP-Message, not doing EAP" in the debug as follows particularly when moving from default to inner-tunnel: eap: Continuing tunnel setup (6) [eap] = ok (6) } # authorize = ok (6) Found Auth-Type = eap (6) # Executing group from file /etc/freeradius/sites-enabled/default (6) authenticate { (6) eap: Expiring EAP session with state 0xa70318b8a2020d85 (6) eap: Finished EAP session with state 0xa70318b8a2020d85 (6) eap: Previous EAP request found for state 0xa70318b8a2020d85, released from the list (6) eap: Peer sent packet with method EAP TTLS (21) (6) eap: Calling submodule eap_ttls to process data (6) eap_ttls: Authenticate (6) eap_ttls: Continuing EAP-TLS (6) eap_ttls: Peer indicated complete TLS record size will be 69 bytes (6) eap_ttls: Got complete TLS record (69 bytes) (6) eap_ttls: [eaptls verify] = length included (6) eap_ttls: [eaptls process] = ok (6) eap_ttls: Session established. Proceeding to decode tunneled attributes (6) eap_ttls: Got tunneled request (6) eap_ttls: User-Name = "omitted" (6) eap_ttls: User-Password = "omitted" (6) eap_ttls: FreeRADIUS-Proxied-To = 127.0.0.1 (6) eap_ttls: Sending tunneled request (6) Virtual server inner-tunnel received request (6) User-Name = "omitted" (6) User-Password = "omitted" (6) FreeRADIUS-Proxied-To = 127.0.0.1 *(6) WARNING: Outer and inner identities are the same. User privacy is compromised.* (6) server inner-tunnel { (6) # Executing section authorize from file /etc/freeradius/sites-enabled/inner-tunnel (6) authorize { (6) policy filter_username { (6) if (&User-Name) { (6) if (&User-Name) -> TRUE (6) if (&User-Name) { (6) if (&User-Name =~ / /) { (6) if (&User-Name =~ / /) -> FALSE (6) if (&User-Name =~ /@[^@]*@/ ) { (6) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (6) if (&User-Name =~ /\.\./ ) { (6) if (&User-Name =~ /\.\./ ) -> FALSE (6) if ((&User-Name =~ /@/) && (&User-Name !~ /(a)(.+)\.(.+)$/)) { (6) if ((&User-Name =~ /@/) && (&User-Name !~ /(a)(.+)\.(.+)$/)) -> FALSE (6) if (&User-Name =~ /\.$/) { (6) if (&User-Name =~ /\.$/) -> FALSE (6) if (&User-Name =~ /(a)\./) { (6) if (&User-Name =~ /(a)\./) -> FALSE (6) } # if (&User-Name) = notfound (6) } # policy filter_username = notfound (6) [mschap] = noop (6) update control { (6) &Proxy-To-Realm := LOCAL (6) } # update control = noop (6) eap: No EAP-Message, not doing EAP (6) [eap] = noop (6) [expiration] = noop (6) [logintime] = noop (6) } # authorize = noop *(6) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject* (6) Failed to authenticate the user (6) Using Post-Auth-Type Reject (6) # Executing group from file /etc/freeradius/sites-enabled/inner-tunnel (6) Post-Auth-Type REJECT { (6) attr_filter.access_reject: EXPAND %{User-Name} (6) attr_filter.access_reject: --> omitted (6) attr_filter.access_reject: Matched entry DEFAULT at line 11 (6) [attr_filter.access_reject] = updated (6) update outer.session-state { (6) &Module-Failure-Message := &request:Module-Failure-Message -> 'No Auth-Type found: rejecting the user via Post-Auth-Type = Reject' (6) } # update outer.session-state = noop (6) } # Post-Auth-Type REJECT = updated (6) } # server inner-tunnel (6) Virtual server sending reply (6) eap_ttls: Got tunneled Access-Reject *(6) eap: ERROR: Failed continuing EAP TTLS (21) session. EAP sub-module failed* (6) eap: Sending EAP Failure (code 4) ID 1 length 4 (6) eap: Failed in EAP select (6) [eap] = invalid (6) } # authenticate = invalid (6) Failed to authenticate the user (6) Using Post-Auth-Type Reject (6) # Executing group from file /etc/freeradius/sites-enabled/default (6) Post-Auth-Type REJECT { (6) attr_filter.access_reject: EXPAND %{User-Name} (6) attr_filter.access_reject: --> omitted (6) attr_filter.access_reject: Matched entry DEFAULT at line 11 (6) [attr_filter.access_reject] = updated (6) [eap] = noop (6) policy remove_reply_message_if_eap { (6) if (&reply:EAP-Message && &reply:Reply-Message) { (6) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (6) else { (6) [noop] = noop (6) } # else = noop (6) } # policy remove_reply_message_if_eap = noop (6) } # Post-Auth-Type REJECT = updated (6) Delaying response for 1.000000 seconds I am a bit stumped as to where I might be going wrong as I have set the default_eap_type = peap in the /mods-enaabled/eap file as well as have the following enabled in the authorise and authentication in the sites-enabled/inner-tunnel file: authorize { filter_username update control { &Proxy-To-Realm := LOCAL } eap { ok = return } expiration logintime } authenticate { Auth-Type ntlm_auth { ntlm_auth } # # MSCHAP authentication. Auth-Type MS-CHAP { mschap } # # For old names, too. # mschap # Allow EAP authentication. eap >From the debug log I posted above, it seems that the eap message is not being passed through to the inner-tunnel. As a side note, testing ntlm_auth responds with a "NT_STATUS_OK: Success (0x0)" message. I have even rebuilt the server leaving many of the default settings, but am still getting the error. I hope I am not missing the obvious and would appreciate if someone could point me in the right direction. In addition, my other question is why do I get the "*WARNING: Outer and inner identities are the same. User privacy is compromised."* warning and how may I make it more secure? - Kind Regards - Byron Jeffery -

2 2

Re: Accounting Relay to Fortigate - Issue with accounting file
by Hitesh Vinzoda 17 Oct '17

17 Oct '17

Hi Alan et al, Apologies for the cluttered email. Detail listener /var/log/freeradius/radacct/detail state unopened signalled 0 waiting 1.086950 sec Waking up in 1.0 seconds. Polling for detail file /var/log/freeradius/radacct/detail Detail listener /var/log/freeradius/radacct/detail state unopened signalled 0 waiting 0.762697 sec Waking up in 0.7 seconds. ^C root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct# ls -lrt total 4 drwxr-xr-x 2 freerad freerad 4096 Oct 18 05:08 192.168.1.2 root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct# root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct# root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct# ls -lrt total 4 drwxr-xr-x 2 freerad freerad 4096 Oct 18 05:08 192.168.1.2 root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct# cd 192.168.1.2/ root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct/192.168.1.2# ls -lrt total 8 -rw------- 1 freerad freerad 141 Oct 17 18:14 auth-detail-20171017 -rw------- 1 freerad freerad 1267 Oct 18 05:41 auth-detail-20171018 root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct/192.168.1.2# FreeRADIUS Version 2.1.12 Hi, I am setting up freeRADIUS to forward accounting requests to Fortigate. I have done the configuration but i am observing messages as below; Detail listener /var/log/freeradius/radacct/detail state unopened signalled 0 waiting 1.086950 sec Waking up in 1.0 seconds. Polling for detail file /var/log/freeradius/radacct/detail Detail listener /var/log/freeradius/radacct/detail state unopened signalled 0 waiting 0.762697 sec Waking up in 0.7 seconds. ^C root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct# ls -lrt total 4 drwxr-xr-x 2 freerad freerad 4096 Oct 18 05:08 192.168.1.2 root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct# cd 192.168.1.2/ root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct/192.168.1.2# ls -lrt total 8 -rw------- 1 freerad freerad 141 Oct 17 18:14 auth-detail-20171017 -rw------- 1 freerad freerad 1267 Oct 18 05:41 auth-detail-20171018 root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct/192.168.1.2# FreeRADIUS Version is 2.1.12 I have modified the modules/detail file to log all accounting packets to a single detail file as below Comment the line below by adding the # in front: # detailfile = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/detail-%Y%m%d detailfile = ${radacctdir}/detail I can see that it is not creating detail file and above log messages keeps on repeating for polling the detail file. I m not sure if should be seeing those messages during debug. Currently i dont have clients to simulate but will be made available tomorrow hence i m trying to be more proactive that the relay should work. Any pointers are appreciated. I am going through the documentation but any interim help is appreciated. Cheers Hitesh Vinzoda On Tuesday, 17 October 2017 10:48 PM, Alan DeKok <aland(a)deployingradius.com> wrote: > On Oct 17, 2017, at 12:24 PM, Hitesh Vinzoda via Freeradius-Users <freeradius-users(a)lists.freeradius.org> wrote: > > Cluttered Email - Resending again Fix your mailer to post text, not HTML. That way it won't mangle the debug output. The text you posted is incomprehensible, so I won't bother trying to figure it out. Instead, I'll suggest that you follow the documentation. See the file sites-available/decoupled-accounting. That contains examples and documentation for how to configure detail file relaying. Or, see sites-available/copy-acct-to-home-server. That contains more examples and documentation. i.e. instead of giving a partial summary of what you did and asking "what went wrong?", you should follow the existing documentation and examples. If it doesn't work, you can then explain what you did, and what happened. And post messages which aren't mangled. That makes it much easier to help you. Alan DeKok.

2 1

Proxy EAP-TLS request after successful authorization with eap module
by work vlpl 17 Oct '17

17 Oct '17

Hello, I am using v3.0.x branch and want to know is it possible to make proxy request to another freeradius/radius server after proxy radius server successfully handle request in eap module? In general I want to know is it possible to implement the next scheme: [user request eap-tls] | [freeradius proxy server] (check certificate; if certificate is good, read certificate values; proxy call home radius server, if not reject) | [freeradius home server] (home server set additional attributes like port speed) My simplified configuration looks like this server test_virtual_site { authorize { eap debug_all #:Need-Remote-Call - custom radius attribute added to dictionary file if (&reply:Need-Remote-Call = 'yes'){ update control { &Proxy-To-Realm := LOCAL } } } authenticate { eap } post_auth { debug_all } } and inner eap-tls virtual site looks like this server check-eap-tls { authorize { update config { &Auth-Type := Accept } } } In this configuration after check-eap-tls virtual site accept request, test_virtual_site jump to post-auth section, and debug_all and update control instructions are not executing. If I not set Auth-Type := Accept in check-eap-tls virtual site, eap module in debug log inform me what eap virtual site reject user certificate. And if I set Proxy-To-Realm attribute inside check-eap-tls virtual site proxy request to home server does not happen.

3 5

Accounting Relay to Fortigate - Issue with accounting file
by Hitesh Vinzoda 17 Oct '17

17 Oct '17

Hi, I am setting up freeRADIUS to forward accounting requests to Fortigate. I have done the configuration but i am observing messages as below; Detail listener /var/log/freeradius/radacct/detail state unopened signalled 0 waiting 1.086950 secWaking up in 1.0 seconds.Polling for detail file /var/log/freeradius/radacct/detailDetail listener /var/log/freeradius/radacct/detail state unopened signalled 0 waiting 0.762697 secWaking up in 0.7 seconds.^Croot@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct# ls -lrttotal 4drwxr-xr-x 2 freerad freerad 4096 Oct 18 05:08 192.168.1.2root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct# root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct# root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct# ls -lrttotal 4drwxr-xr-x 2 freerad freerad 4096 Oct 18 05:08 192.168.1.2root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct# cd 192.168.1.2/root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct/192.168.1.2# ls -lrttotal 8-rw------- 1 freerad freerad 141 Oct 17 18:14 auth-detail-20171017-rw------- 1 freerad freerad 1267 Oct 18 05:41 auth-detail-20171018root@user-To-be-filled-by-O-E-M:/var/log/freeradius/radacct/192.168.1.2# FreeRADIUS Version 2.1.12 I have modified the modules/detail file to log all accounting packets to a single detail file as below Comment the line below by adding the # in front:# detailfile = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/detail-%Y%m%d detailfile = ${radacctdir}/detail I can see that it is not creating detail file and above log messages keeps on repeating for polling the detail file. I have to prep this and the set up will be tested in next day. Any pointers are appreciated. Best Regards Hitesh Vinzoda

2 2

logrotate question
by Zenon Mousmoulas 17 Oct '17

17 Oct '17

Hi, a question about the logrotate script: I understand that, upon SIGHUP, freeradius will reopen the main log file (radius.log). I also understand this does not extend to files written by linelog/detail modules; these need to be handled separately (with `radmin -e "hup xxx"'). However the logrotate script does not use such signalling, it rather opts for the copytruncate option. I wonder why that is the case. Is it the complexity of sending a signal to all modules (and all potential instances thereof)? Is it that, apart from re-opening the log file, SIGHUP will also cause the server to reload the (potentially broken) configuration? The copytruncate option avoids all that, but it is obviously slower/less efficient for rotating large log files. Or maybe is there a different reason behind this? Cheers, Z.

2 1

Re: FreeRADIUS Thread Behaviour
by Arran Cudbard-Bell 17 Oct '17

17 Oct '17

> The motivation for looking into this is that I have occasions where freeradius > reports “Could not start TLS: Can't contact LDAP server” > which seems to only occur when a new thread fires up and tries to start TLS > to the LDAP server. This happens randomly for a few seconds a couple times a month. > Regardless of whether or not this indicates a problem > with my LDAP server or the connection to it, I would like to know why > I have threads continuously dying and spawning every few minutes even > though my config, as I understand it, is set so that the threads should not die. That's simply not how the rlm_ldap module and the threading code interact. It will be in v4.0.x because we'll be binding (very tightly) LDAP connections to worker threads, but it is not how the code works in v3.0.x, v2.0.x or v1.0.x. What you're seeing is threads being killed because the load on the server does not require that number of threads. i.e. The server is self-pruning threads to free up resources. If there's an uptick in load, new threads will be created, and new connections may be created to service those threads. The connection pool for LDAP is in no way tied to the threading code. The connections do not get closed because a backend thread is killed, they get closed because the LDAP module is similarly detecting that it has spare connections, and is freeing them to concentrate requests on the smallest subset possible. The reason why these events occur around the same time is because the start/mac/min_spare/max_spare parameters are shared between the thread pool and connection pool. start = ${thread[pool].start_servers} min = ${thread[pool].min_spare_servers} max = ${thread[pool].max_servers} spare = ${thread[pool].max_spare_servers} Alan's example config: start_servers = 32 max_servers = 32 min_spare_servers = 0 max_spare_servers = 32 Will indeed prevent threads and connections being pruned, but be sure to adjust your idle timeouts appropriately so you don't end up with stale connections. Regarding the OpenLDAP API. There's an issue with ldap_initialize where it does some global initialisation the first time it's called. We work around that by calling it once when the server starts up before we spawn worker threads. I don't think that's the issue here. > In multi-threaded software with a persistent connection (pool) I usually > use a lock to ensure that ldap_initialize() and bind (simple or SASL) > were successfully done before the connection can be used by another > thread. That's also the reason why I usually avoid a code path with > anon-search-without-bind because I want to provoke a connect error with > an explicit bind right from the beginning. If you're experiencing the same issue as us, you can just call ldap_initialize with a zero length string as the host argument. https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/src/lib/ldap/li… There are multiple other issues with libldap and lazy connections. Almost all can be worked around, but it makes the calling code more complex. The major issue we currently have with libldap is even with all the magic flags set to invoke async behaviour, TLS negotiation is still blocking. -Arran Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

2 1