- Freeradius-Users - lists.freeradius.org

RE: Cisco AV Pair
by Franks Andy (RLZ) IT Systems Engineer 30 Jul '14

30 Jul '14

Isn’t cisco-avpair a multivalue attribute? To do it properly, you’d have to check each instance for an ssid wouldn’t you? In V3, we do this with foreach, but I’m not sure in V2. Typically the ssid attribute sent from a cisco ap is the first one, but maybe that’s not always the case. If I’m way off track just ignore me! J From: freeradius-users-bounces+andy.franks=sath.nhs.uk(a)lists.freeradius.org [mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk@lists.freeradius.org] On Behalf Of Dan Fleming Sent: 29 July 2014 13:27 To: FreeRadius users mailing list Subject: Re: Cisco AV Pair Reading the documentation I am still at a loss. I am familiar on how to do this with Cisco ACS, but looking to do it now with free radius. I now have it working if I check the Cisco-avpair under the user in dalo Radius (Cisco-avpair =~ .*SSID$) . Is there a way to configure this so i dont have to keep typing that attribute under every user? I thought the group would work, but from what you are saying it sounds like it wouldnt. I have tried saying if it doesnt match the above regex then the Radgroupreply says ( Auth-Typ := Reject) Thank you for your time. Dan On Mon, Jul 28, 2014 at 2:15 PM, Alan DeKok <aland(a)deployingradius.com> wrote: > > Dan Fleming wrote: > > Thank you I have read through it makes sense. So how do I do something > > based on the results? > > The SQL document talks about "radreply", which lets you do something > with the results. > > > I would like to only authorize a connection if the > > users password matches and they are connecting to the correct ssid in > > the av-pair. Is there a HOWTO or other document outlining how to do that? > > No. Because that's a specific solution. The documents describe how > the server works, and lets you put it together yourself. > > For your situation, the key is to understand that the server accepts > users if their password is correct. If you add more conditional checks, > the user is still accepted. > > The solution is either to: > > a) set the "known good" password ONLY if the conditions also match. The > SQL documentation describes how to set conditions > > b) if the password is stored somewhere else (e.g. LDAP), then you need > to REJECT the user if the conditions match. > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

6 6

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

29 Jul '14

Arran Cudbard-Bell wrote: > Should work now without dumb hacks... I have tested your solution, too, and it also works well. However, there is a small difference between your an Alan's appraoch: With Alan's suggestion, the rlm_wimax shared object does not have any references to openssl, whereas in your approch, ldd says that both libssl and libcrypto are required. I do not know which one is correct, Best regards, Andreas

2 1

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