- Freeradius-Users - lists.freeradius.org

Cisco AV Pair
by Dan Fleming 29 Jul '14

29 Jul '14

Hello, I am using daloradius with free radius 2.1.12 on Ubuntu 14.04. I have configured users and passwords and sucessfully authenticate users connecting to a standalone cisco 1142 accesspoint. I can see in the debug that the cisco-avpair is sending the ssid to the free radius server in the debug but I dont think it is being checked. No matter what I put in av pair the user gets Access-Accept. I have tried both operator == and =: but neither make a difference. Any help is greatly appreciated. Regards, Daniel

2 7

FreeRadius Client
by Levavi, Yariv 29 Jul '14

29 Jul '14

Hello, Is there a client for FreeRadius (for windows) that uses MSCHAP2 for password forwarding? Regards, Yariv Levavi SafeNet's Integration Team The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.

1 0

Re: Freeradius-Users Digest, Vol 111, Issue 79
by Rui Ribeiro 29 Jul '14

29 Jul '14

Hi Allan and Herwin, I can confirm this commit from yesterday fixed the problem. Thank you Allan for taking the time to have a look at it. Regards commit 4c00bb3adb6092e1cce335560146e85818b95981 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Mon Jul 28 12:15:09 2014 -0400 it's OK for this->server to be NULL 2. Re: control-socket bug in the last one v3.x updates? > (Herwin Weststrate) > > > > Message: 2 > Date: Tue, 29 Jul 2014 10:09:43 +0200 > From: Herwin Weststrate <herwin(a)quarantainenet.nl> > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: Re: control-socket bug in the last one v3.x updates? > Message-ID: <53D756C7.20303(a)quarantainenet.nl> > Content-Type: text/plain; charset=windows-1252 > > On 29-07-14 07:34, Rui Ribeiro wrote: > > > > Hi Alan, > > > > If it is of any use, I manage to track it down in git. I will follow the > > instructions in doc/bugs later on during the day. > > Most likely it has been fixed in commit > 14e31585bec5a3e4653c631921b9284fdab18912. The same issue was discussed > on the freeradius-devel list. > > -- > Herwin Weststrate > >

1 0

Re: Re: Some inconsistencies concerning OpenSSL include configuration in FRS 3
by rieke＠isl.de 29 Jul '14

29 Jul '14

Alan DeKok wrote: > Dr. Andreas Rieke wrote: >> I am quite sure that FRS compiles without problems on many other systems, but in those cases, the compiler takes the OpenSSL header files from the system and not from the specified directories - on my machine, I have removed the openssl-devel RPM package (CentOS), and thus, I get that failure. However, maybe the failure is better than a wrong header file... >> >> When I pass 'CPPFLAGS="-I /opt/openssl/include"' to the main configure script, the problems are solved for the headers - as an example, ec.h is found immediately. However, FRS still uses the system libraries :-( > > The issue is that the CPPFLAGS are *supposed* to be passed from the > main configure script to the lower-level ones. > > Hmm... what happens if you edit the top-level "configure" script? > > - go to the bottom, and then look backwards for "werror" > > - you should see: > > if test "x$werror" == "xyes"; then > CFLAGS="-Werror $CFLAGS" > fi > > - after that block, add: > > export CPPFLAGS CFLAGS LDFLAGS > > - then re-run configure > > That should hopefully fix it. If so, I'll commit a patch. As promised, I have now tested your suggestion and I think that I now do understand your purpose. Sorry for the misunderstanding. When you only pass the two parameters --with-openssl-include-dir=/opt/openssl/include und --with-openssl-lib-dir=/opt/openssl/lib to the main configure script (and no additional CPPFLAGS or LDFLAGS), all header files are found because with your modification "CPPFLAGS= -isystem /opt/openssl/include/" is passed to the sub configure scripts. So far, so good. However, I had expected that the library path is also passed to the sub scripts - and this is not the case, because there is no such parameter. ldd shows that all rlms are linked to the correct version 1.0.0 of openssl, and not to the (old) system version which is 0.98 on my machine. For that reason, the result is correct, and 4 rlms make use of OpenSSL: libfreeradius-radius.so, rlm_cache.so, rlm_ldap.so and rlm_otp.so. As far as I can see, libfreeradius-radius, rlm_cache and rlm_otp have no own configure scripts, so let's take a closer look at rlm_ldap. The configure script of rlm_ldap does receives the with-openssl-include-dir parameter, which it does not understand; however, it receives the header info from the environment: > ac_cv_env_CPPFLAGS_value=' -isystem /opt/openssl/include/ ' I can not see anything about the library directory, but again, the result is correct. Does this help? Can I test something else? Best regards, Andreas

1 0

Re: control-socket bug in the last one v3.x updates?
by Rui Ribeiro 29 Jul '14

29 Jul '14

Hi Alan, If it is of any use, I manage to track it down in git. I will follow the instructions in doc/bugs later on during the day. I only have the bug after applying commit 0022bf367c092d2a5843092f0dc8c68950e9e60b Author: Alan T. DeKok <aland(a)freeradius.org> Date: Fri Jun 27 09:01:14 2014 -0400 Move checks for virtual_server to listen_parse() Which is better than scattering them through the code. Regards, > Message: 2 > Date: Mon, 28 Jul 2014 08:06:17 -0400 > From: Alan DeKok <aland(a)deployingradius.com> > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: Re: control-socket bug in the last one v3.x updates? > Message-ID: <53D63CB9.20302(a)deployingradius.com> > Content-Type: text/plain; charset=UTF-8 > > Rui Ribeiro wrote: > > I have tried this with a copy of my configuration, and with a pristine > > copy of freeradius, which only got inserted the link to activate control > > socket into sites-enabled. > > Hmm... the default config works for me. Even with the control socket > enabled. > > > /etc/freeradius/sites-enabled/control-socket[23]: No such server "(null)" > > You should (a) have a default server, or (b) update the "listen" > section to point to a server. > > And the libc printing code shouldn't crash when passed a NULL pointer. > > See doc/bugs for information about how to debug it some more. I can't > reproduce it here, so that makes it difficult for me to help. > > Alan DeKok. > > >

2 1

Re: Re: Some inconsistencies concerning OpenSSL include configuration in FRS 3
by rieke＠isl.de 28 Jul '14

28 Jul '14

Am 28.07.2014 20:58, schrieb Stefan Paetow: >> I have documented everything in my email in order to help other people, I have tested everything until things worked, and for these reasons, I do not think that your statement is true. I will run the tests you requested tomorrow - although I do not understand for what purpose, > > Actually the purpose is quite clear, Andreas. :-) > > Since you were experiencing the problems, Alan would like to use your situation to improve the configure script (and FreeRADIUS) for everyone else who use FR to compile their own version (instead of using packages). > > While you may have fixed it after a fashion, if Alan can verify that his fixes in the configure script work as well, then it means everyone gains :-) There seems to be one misunderstanding after the other - is my english so bad? I do understand Alan's purpose and what you wrote, and I do agree with both. However, I do not understand the technical details of Alan's suggestion. On the one hand side, he does not like specifying parameters twice with CPPFLAGS and LDFLAGS, which I can understand. On the other hand side, he wants me to test something which is related to CPPFLAGS, LDFLAGS and so on - and this means that parameters have to be given twice??? Maybe I simply do not yet understand what exactly he is going to test - and this is why I said I do not understand for what purpose. However, as I have promised, I will test it tomorrow and come back to you with the results, thanks and best regards, Andreas

2 1

Re: Re: Some inconsistencies concerning OpenSSL include configuration in FRS 3
by rieke＠isl.de 28 Jul '14

28 Jul '14

Alan DeKok wrote: > Dr. Andreas Rieke wrote: >> They do - today I have also tested that for the LDFLAGS, and this works, too. If you pass the OpenSSL directories twice to the main configure script, everything works great: > > <sigh> The point is that people should NOT have to do that. I agree to you - however, this is what you have suggested. In your last email, you wrote > The issue is that the CPPFLAGS are *supposed* to be passed from the > main configure script to the lower-level ones. I thought that you are not sure about that and that you have asked me to test it - I tested that and the LDFLAGS, too, and it worked without any modifications. For that reason, there was no need for me to test your suggestions. >> I checked the config.log files and the shared objects with ldd - all headers are found and the correct library files are used. For that reason, everything is great for me - thank you very much for your help, > > And you didn't test the "configure" script as I requested. I did not do the tests you suggested because things already work - why should I test something which is not required? Or did I misunderstand something? > > It's nice to know you have a solution which works for you, is unusual, > undocumented, and you don't care to help other people, so that they > don't run into the same problem. > I have documented everything in my email in order to help other people, I have tested everything until things worked, and for these reasons, I do not think that your statement is true. I will run the tests you requested tomorrow - although I do not understand for what purpose, best regards, Andreas

2 1

Authorize users in different trusted Active Directory domains using LDAP group searches
by Roberto.Franceschetti＠ocfl.net 28 Jul '14

28 Jul '14

Hi there, As this is going to be a possibly long post, the brief question is: Can we use a single freeradius install to provide different type of access to Active Directory users belonging to multiple trusted domains based on their membership in Active Directory groups that located in just one of these domains? This is so that an administrator for one of the domains can provide access to his resources to users belonging in other trusted domains. The above question is expanded as follows with more details. We are using FreeRADIUS v2.1.10 installed on a Ubuntu server to authenticate and provide access for: 1. OpenLDAP users with rights based on LDAP groups 2. Dual factor authentication using Active Directory accounts in multiple trusted domains and SSL client certificates, with required membership to a specific AD group 3. Authentication and different Access for Active Directory accounts based on AD group memberships For (1) we are able to grant access in the authenticate {} section as we're using an OpenLDAP directory, not Active Directory: authenticate { Auth-Type LDAP { ldap_linux if (ldap_linux-Ldap-Group == "cn=full_client,ou=remote_access,ou=groups,dc=esu_accounts,dc=net") { update reply { Class := "ou=asa_vpn", Reply-Message = "Welcome to ASA VPN" } } # ........ a whole bunch of other ifs here..... } } For (2), as we only needed to authenticate/authorize users if they belonged to a single, specific "Domain Local" group in one of our Active Directory domains, and this group contains individual users in all the domains we support, we were able to make this happen by using ntlm_auth with the --require-membership option: exec ntlm_auth.vpnaccessfullclient { wait = yes program = "/usr/bin/ntlm_auth --request-nt-key --username=%{mschap:User-Name:-None} --domain=%{mschap:NT-Domain:-OCG} --password=%{User-Password} --require-membership-of=ocg\\VPNAccess" } This allows us to authenticate and authorize users in all the Active Directory domains we have trusts only if that account belongs in the specific Active Directory group "ocg\\VPNAccess" For (3), this is were I may have hit a wall. I can make this work for a single Active Directory domain by using ntlm_auth to *authenticate* users (without any --require-membership-of restrictions), and to then use post-auth to check group membership and provide access as needed based on Active Directory group membership: post-auth { ldap_ad if (ldap_ad-LDAP-Group == "VPNAccess2") { update reply { Class := "ou=IPICSPolicy;" Reply-Message = "Welcome to Radio VPN Restricted ACL Access" } } This works fine, but I think it can only check for group membership in the Active Directory domain defined in "ldap_ad" in the ldap module. It cannot verify group membership in other domains. Hopefully I'm wrong... but days of googling didn't turn out a solution. I cannot find a way to make this requirement work (securely) in an Active Directory environment with multiple trusted domains. Let me explain. There are resources in my domain that I have to grant to users of my domain and to users in other trusted domains. These are *my* resources, so I have Active Directory groups in my domain to which I add users (I cannot have other admins in other domains grant this access). There are some workarounds I found in the mailing list, but in my opinion they are not secure. For example, I can add additional entries in the ldap module for the other domains, but in order for the LDAP searches to work, the group in which users are being searched in would need to reside in the other domains, which are not under my control. The other admins could add anyone to those groups and this would compromise my resources. In addition, if I did the above: post-auth { ldap_ad if (ldap_ad-LDAP-Group == "VPNAccess2") { update reply { Class := "ou=IPICSPolicy;" Reply-Message = "Welcome to Radio VPN Restricted ACL Access" } } ldap_ad2 if (ldap_ad2-LDAP-Group == "VPNAccess2") { update reply { Class := "ou=IPICSPolicy;" Reply-Message = "Welcome to Radio VPN Restricted ACL Access" } noop } I could have cases where the same username "smith" can exist in both domains. If the user "smith" in ldap_ad2 above authenticates, and they are not a member of the "VPNAccess2" group, while there happens to be a user "smith" in ldap_ad who is instead a member of "VPNAccess2", then the wrong user would be granted access. Are there any solutions to my original question at the top, or am I trying to do something that is just not possible due to limitations of Active Directory (not a real LDAP server...) and the way LDAP searches work? I apologize for the long question, but hopefully it will help others who may be having the same scenario. Thanks, Roberto PLEASE NOTE: Florida has a very broad public records law (F. S. 119). All e-mails to and from County Officials are kept as a public record. Your e-mail communications, including your e-mail address may be disclosed to the public and media at any time.

1 0

Re: Re: Some inconsistencies concerning OpenSSL include configuration in FRS 3
by rieke＠isl.de 28 Jul '14

28 Jul '14

Alan DeKok wrote: > Dr. Andreas Rieke wrote: >> I am quite sure that FRS compiles without problems on many other systems, but in those cases, the compiler takes the OpenSSL header files from the system and not from the specified directories - on my machine, I have removed the openssl-devel RPM package (CentOS), and thus, I get that failure. However, maybe the failure is better than a wrong header file... >> >> When I pass 'CPPFLAGS="-I /opt/openssl/include"' to the main configure script, the problems are solved for the headers - as an example, ec.h is found immediately. However, FRS still uses the system libraries :-( > > The issue is that the CPPFLAGS are *supposed* to be passed from the > main configure script to the lower-level ones. They do - today I have also tested that for the LDFLAGS, and this works, too. If you pass the OpenSSL directories twice to the main configure script, everything works great: > ./configure --prefix=/opt/freeradius-server \ > --with-openssl-include-dir=/opt/openssl/include \ > --with-openssl-lib-dir=/opt/openssl/lib \ > CPPFLAGS="-I /opt/openssl/include" \ > LDFLAGS="-L/opt/openssl/lib" I checked the config.log files and the shared objects with ldd - all headers are found and the correct library files are used. For that reason, everything is great for me - thank you very much for your help, best regards, Andreas

3 2

control-socket bug in the last one v3.x updates?
by Rui Ribeiro 28 Jul '14

28 Jul '14

Hi, I am using the git versions of 3.x, and I *think* that maybe for a month, there has been a bug that prevents freeradius to boot it in Debian 7 if control-socket is configured. I have tried this with a copy of my configuration, and with a pristine copy of freeradius, which only got inserted the link to activate control socket into sites-enabled. Without control-socket all is well: without control socket: root@x:/etc/freeradius/sites-enabled# /etc/init.d/freeradius start [ ok ] Starting FreeRADIUS daemon: freeradius. root@x:/etc/freeradius/sites-enabled# The errors are: root@x:/home/rui# /etc/init.d/freeradius start [FAIL] Starting FreeRADIUS daemon: freeradius failed! root@x:/home/rui# /etc/init.d/freeradius restart [....] Checking FreeRADIUS daemon configuration...Trace/breakpoint trap failed (Debugger detected, raising SIGTRAP). #freeradius -X .... .... radiusd: #### Opening IP addresses and Ports #### listen { type = "control" listen { socket = "/var/run/freeradius/freeradius.sock" } /etc/freeradius/sites-enabled/control-socket[23]: No such server "(null)" Debugger detected, raising SIGTRAP Trace/breakpoint trap In /var/log/freeradius/radius.log, I only have: Mon Jul 28 12:13:35 2014 : Error: /etc/freeradius/sites-enabled/control-socket[23]: No such server "(null)" Regards, Rui Ribeiro ISCTE-IUL sysadmin

2 1