Re: Rejecting EAP-TLS based on cert Subject field [RESOLVED]
On 1/28/2011 3:48 AM, Alan DeKok wrote: > Put the "unlang" in the "authenticate" section, after "eap": > Auth-Type eap { > eap > if (...) { > ... > } > } Thank you!! That did the trick. The entirety of my authenticate section is now: authenticate { Auth-Type Kerberos { krb5 } Auth-Type eap { eap if ( "%{TLS-Client-Cert-Subject}" =~ /\/OU=Evil\// ) { reject } } } And it works perfectly. Thank you! As for Windows XP dealing with the rejection > You're sending a *radius* reject. It doesn't include an EAP-Message > with an *EAP* reject. So you need to create a fake one: > update reply { > EAP-Message := 0x > } > That can work sometimes... Ah, thanks for the tip. I added this in the "Post-Auth-Type REJECT" section: if ( "%{control:Auth-Type}" == "EAP" ) { update reply { EAP-Message := 0x04010004 } } The code seems to work as expected, but Windows XP still doesn't seem to handle it sensibly. But I can live with that. Thank you, Alan! -Matt - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Rejecting EAP-TLS based on cert Subject field
On 1/27/2011 3:03 PM, Phil Mayers wrote: >> I've met this need (using 2.1.11 from git) with a simple bit of unlang >> in post-auth{}: >> if ( "%{TLS-Client-Cert-Subject}" =~ /OU=Evil/ ) { >> reject >> } > > Just put this in the "authorize" section? If it's early in the EAP > conversation, TLS-Client-* won't be set so won't match, meaning this > will succeed as soon as yo uget that far. I'm not sure I follow you here. Are you saying that there is a place in the authorize section where TLS-Client-* _would_ be accessible to unlang? I've tried it in a few places (before eap, after eap, at the top of the section, at the bottom of the section) and it seemed to have no effect. But it's entirely possible that I missed something during these tests. > Correct. Unlang is only processed in authorize-like steps, not arbitrary > bits of the config. I can understand that. But given that the eap module has access to some client cert fields during authentication (e.g. check_cert_issuer and check_cert_cn), it would be nice to be able to access these and other client cert fields with unlang (or something similar) at that stage. But, admittedly, I'm way over my head here :-) so I'll make do with one of the methods described earlier in this thread. Thanks, -Matt - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Rejecting EAP-TLS based on cert Subject field
On 1/27/2011 3:41 PM, Matt Garretson wrote: > The XP client still tries three times (duh), but at least radius.log reflects > a failure: > > Error: TLS_accept: error in SSLv3 read client certificate B > Error: rlm_eap: SSL error error:140890B2:SSL > routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned > Error: SSL: SSL_read failed in a system call (-1), TLS session fails. > Auth: Login incorrect (TLS Alert write:fatal:certificate unknown): [snip] *sigh* I left out the first (and most useful) logging line in the above: Auth: rlm_eap_tls: Certificate CN (eviluser) fails external verification! So, again, it's better than what I'd had before, but not as elegant as I was hoping. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Rejecting EAP-TLS based on cert Subject field
On 1/27/2011 1:24 PM, Matt Garretson wrote: > Thanks. That's actually my goal. But unlang isn't allowed in > authenticate{}, and my attempts to sneak it into the authentication > phase via the tls{} section in eap.conf didn't seem to work. > Any other ways to do it? Replying to myself here I got a bit closer to my goal by putting this in the verify{} subsection of tls{} : tmpdir = /tmp/radiusd client = "/usr/local/bin/checkcert %{TLS-Client-Cert-Filename}" Where /usr/local/bin/checkcert contains: #!/bin/sh if /usr/bin/openssl x509 -in "$1" -noout -text | \ /bin/grep -q " Subject:.* OU=Evil," ; then RC=1 else RC=0 fi exit $RC The XP client still tries three times (duh), but at least radius.log reflects a failure: Error: TLS_accept: error in SSLv3 read client certificate B Error: rlm_eap: SSL error error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned Error: SSL: SSL_read failed in a system call (-1), TLS session fails. Auth: Login incorrect (TLS Alert write:fatal:certificate unknown): [snip] Still, it would be nice if I could use unlang (or something) to match against %{TLS-Client-Cert-Subject} during the authenticate stage somehow. Is there a way that I'm missing? Thanks, -Matt - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Rejecting EAP-TLS based on cert Subject field
On 1/27/2011 1:14 PM, Alan Buxey wrote: > you are authenticating...and then rejecting in the post-auth > stage. you really need to break the process in the authentication > stage. Thanks. That's actually my goal. But unlang isn't allowed in authenticate{}, and my attempts to sneak it into the authentication phase via the tls{} section in eap.conf didn't seem to work. Any other ways to do it? I'd thought of using rlm_perl, but couldn't see that the cert fields are passed to the module. Thanks, -Matt - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Rejecting EAP-TLS based on cert Subject field
For years, we've been doing simple EAP-TLS with various versions of FreeRADIUS. Now, a new requirement has come down to me such that radius will have to reject certain valid client certs based on a string in the Subject field of the client cert. I've met this need (using 2.1.11 from git) with a simple bit of unlang in post-auth{}: if ( "%{TLS-Client-Cert-Subject}" =~ /OU=Evil/ ) { reject } It works, but there are two non-ideal things about the way it works: 1) Windows XP doesn't seem to notice the rejection and keeps retrying for a minute or two, ultimately failing to show any failure/error message to the user. 2) The rejection is not logged in radiusd.log; rather, three "Auth: Login OK" lines are logged (the repetition is due to XP's retries) Is there any way I can address these two issues? I did try putting the above unlang into eap.conf's tls{} section (where check_cert_issuer and check_cert_cn would be), in hopes that the rejection would occur during the auth rather than after it, but the code doesn't seem to have any effect there. Thanks in advance for any clues... -Matt - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Pre-release of 2.1.7
Builds okay on Fedora 7 and Fedora 10: ./configure --with-system-libtool --prefix=/opt/radius --localstatedir=/var "make tests" also passes on both, FWIW. But I won't be able to actually install it for a week or two. Alan, thanks for all of your hard work on FreeRADIUS! -Matt - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: POP3
Alan DeKok wrote: > Slava wrote: >> Could anyone tell me if there exists a solution to integrate FR with a >> POP3 server > Look for patches to let cucipop do RADIUS authentication. If there > are none, maybe cucipop does PAM authentication. You could then use the > PAM RADIUS module. FWIW, Qpopper also can use PAM, although I haven't tried it myself: http://www.eudora.com/products/unsupported/qpopper/faq.html#PAM - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Can't compile on Centos 5.1 x86_64
Sergio Belkin wrote: > I can't compile freeradius-2.0.2 on Centos 5.1 x86_64. It outputs: > /usr/lib/libltdl.so: could not read symbols: File in wrong format > collect2: ld returned 1 exit status You might try using your system's own libtool. Try these configure options: --with-system-libtool --disable-ltdl-install It might not help, but it's probably worth a shot. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 2.0.0 has been released
Alan T DeKok wrote: > January 10, 2007 - Version 2.0.0 has been released. Congratulations, and thanks for all your hard work on FreeRADIUS! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: randomly crashing
Hi... Matt Ashfield wrote: > We're running FR to authenticate users on our wireless network. It appears > that radius is randomly stopping/crashing. I have checked logs, but have > been unable to locate the problem and am wondering if someone could point me For what it's worth (probably not much!)... a month ago, I was having "random" segfaults with a new installation of 1.1.7 on Fedora 7 x86_64. In most cases, the crash seemed to correspond with this log entry you've mentioned: > Mon Sep 17 00:31:30 2007 : Error: rlm_eap: Either EAP-request timed out OR > EAP-response to an unknown EAP-request My segfault would typically occur right after the above log entry. Analyzing with gdb usually gave a serpentine backtrace into threading libraries and SSL-related functions -- well beyond my ability to debug. I was about to give up, when an openssl package update was issued by Fedora (0.9.8b-14.fc7, around August 14). The changelog wasn't very descriptive, but ever since updating the openssl RPMs, freeradius hasn't segfaulted at all. Was it an SSL bugfix that fixed it? Beats me. Maybe it was simply the running of ldconfig after the update. Maybe it was something else entirely. But the point is, it might pay to make sure your libraries are in order. :) (Previously I'd also had seeming 64-bit library issues with Kerberos which were causing Freeradius crashes.) -Matt PS: I do still see the "Either EAP-request timed out OR EAP-response to an unknown EAP-request" rlm_eap error maybe 5-10 times a day, but the Freeradius daemon no longer crashes from them. And the client auth succeeds on the retry ~30 seconds later. Never saw this behavior with Freeradius 1.1.2, but I wouldn't be surprised if it was happening back then, and that 1.1.7 simply has more verbose logging of such occurrences now. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: building RPM from source
Fred Zinsli wrote: > I have got a copy of 1.1.7 source but my issue is that I don't know how > to enable mysql in the spec file. The spec file that comes in the Fedora source RPM I suggested shows you exactly how to do it. In fact, it's done for you. :) > Also, do I have to have mysql installed on the build machine to enable > mysql suppport? Yes, both the mysql and mysql-devel packages would be required. You don't need mysql-server installed, unless of course you want to run the MySQL server on that machine. (The spec file also requires some other packages, which you can easily snip out if you don't actually need to build/use the stuff which depends on them.) > But /usr/include/mysql doesn't exist on the machine. I'm guessing none of the MySQL packages are installed. Try: "yum install mysql mysql-devel". -Matt - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: building RPM from source
Fred Zinsli wrote: > I am attempting to build an RPM from source on my FC5 box. Try to get a more recent source RPM from a repository, and then tweak the spec file to fit your needs. The Fedora builds will support MySQL by default. It'd be easier than trying to write your own spec file from scratch. The current version in Fedora 7 is 1.1.6, and 1.1.7 is available in the development repo. (I am running 1.1.7 built from the devel source RPM.) -Matt - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Segfault with -X and rlm_krb5 under Fedora 7 x86_64
Alan DeKok wrote: > That would seem to be the case, yes. But it's very weird. Doubly so > since there's no code in rlm_krb5 that depends on debug_flag >= 2. > > So... the culprit is likely elsewhere. Exactly where it is located is > difficult to say. Thanks, Alan. Just a quick update... upon looking deeper, it looks like it might be an autoconf/libtool issue with x86_64 under Fedora 7. If I come up with any potentially useful info, I'll post it here. Sorry for the noise. -Matt - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Segfault with -X and rlm_krb5 under Fedora 7 x86_64
This may be a Fedora/Kerberos issue rather than a Freeradius issue, but... Has anyone experienced "radiusd -X" segfaulting when using rlm_krb5? This is under Fedora 7 (x86_64), with freeradius 1.1.6 and 2.0.0-pre1 built from source tarballs. (I am trying to migrate to this environment from a working freeradius-1.1.0 / Fedora Core 2 / i686 installation.) The segfault is actually occurring in the Kerberos libraries, which means that Freeradius might not be the issue, however the segfault occurs only when radiusd is given "-X" or "-sfxx" options. I.e. "radiusd -sfx" and "radiusd" work as expected, and do not segfault. (One thing off the top of my head: Does this point to something possibly happening when debug_flag is >= 2 ?) The killer request: radtest testuser testpass localhost 1 testing123 Below are my users and radiusd.conf files. Full gdb output from a segfault case follows. So, this isn't a bug report... i'm just hoping for tips on how to proceed... thanks in advance for any clues. -Matt ### begin complete users file ### DEFAULT Auth-Type:=Kerberos ### end complete users file ### ### begin partial radiusd.conf ### # stuff that was changed from the default 1.1.6 radiusd.conf : prefix = /opt/radius localstatedir = /var user = radiusd group = radiusd log_auth = yes proxy_requests = no modules { krb5 { keytab = radius-krb5.keytab service_principal = radius } } authenticate { Auth-Type Kerberos { krb5 } } ### end partial radiusd.conf ### ### begin gdb output ### [EMAIL PROTECTED] raddb]# gdb radiusd GNU gdb Red Hat Linux (6.6-15.fc7rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"... Using host libthread_db library "/lib64/libthread_db.so.1". (gdb) run -X Starting program: /usr/local/sbin/radiusd -X [Thread debugging using libthread_db enabled] [New Thread 46912517212928 (LWP 25560)] Starting - reading configuration files ... reread_config: reading radiusd.conf Config: including file: /opt/radius/etc/raddb/clients.conf Config: including file: /opt/radius/etc/raddb/snmp.conf Config: including file: /opt/radius/etc/raddb/eap.conf Config: including file: /opt/radius/etc/raddb/sql.conf main: prefix = "/opt/radius" main: localstatedir = "/var" main: logdir = "/var/log/radius" main: libdir = "/opt/radius/lib" main: radacctdir = "/var/log/radius/radacct" main: hostname_lookups = no main: max_request_time = 30 main: cleanup_delay = 5 main: max_requests = 1024 main: delete_blocked_requests = 0 main: port = 0 main: allow_core_dumps = no main: log_stripped_names = no main: log_file = "/var/log/radius/radius.log" main: log_auth = yes main: log_auth_badpass = no main: log_auth_goodpass = no main: pidfile = "/var/run/radiusd/radiusd.pid" main: user = "radiusd" main: group = "radiusd" main: usercollide = no main: lower_user = "no" main: lower_pass = "no" main: nospace_user = "no" main: nospace_pass = "no" main: checkrad = "/opt/radius/sbin/checkrad" main: proxy_requests = no security: max_attributes = 200 security: reject_delay = 1 security: status_server = no main: debug_level = 0 read_config_files: reading dictionary read_config_files: reading naslist read_config_files: reading clients read_config_files: reading realms radiusd: entering modules setup Module: Library search path is /opt/radius/lib Module: Loaded exec exec: wait = yes exec: program = "(null)" exec: input_pairs = "request" exec: output_pairs = "(null)" exec: packet_type = "(null)" rlm_exec: Wait=yes but no output defined. Did you mean output=none? Module: Instantiated exec (exec) Module: Loaded expr Module: Instantiated expr (expr) Module: Loaded Kerberos krb5: keytab = "radius-krb5.keytab" krb5: service_principal = "radius" rlm_krb5: krb5_init ok Module: Instantiated krb5 (krb5) Module: Loaded PAP pap: encryption_scheme = "crypt" pap: auto_header = yes Module: Instantiated pap (pap) Module: Loaded CHAP Module: Instantiated chap (chap) Module: Loaded MS-CHAP mschap: use_mppe = yes mschap: require_encryption = no mschap: require_strong = no mschap: with_ntdomain_hack = no mschap: passwd = "(null)" mschap: ntlm_auth = "(null)" Module: Instantiated mschap (mschap) Module: Loaded System unix: cache = no unix: passwd = "(null)" unix: shadow = "(null)" unix: group = "(null)" unix: radwtmp = "/var/log/radius/radwtmp" unix: usegroup = no unix: cache_reload = 600 Module: Instantiated unix (unix) Module: Loaded preprocess preprocess: huntgroups = "/opt/radius/etc/raddb/huntgroups" preprocess: hints = "/opt/radius/etc/raddb/hints" preprocess: with_ascend_hack = no preprocess:
random & dh -- best practices for EAP-TLS ?
Hi, i've had EAP-TLS working well for a few weeks now, but am wondering about the most secure way to set up the dh and random files. Initially i just created static files using commands found in the list archives and/or the eap howto: openssl dhparam -text -5 -out /opt/radius/etc/dh 512 dd if=/dev/urandom of=/opt/radius/etc/random count=2 And it works fine. But my concern is that this random data will become stale. How often should these files be refreshed -- with each server restart? Or at regular intervals via cron? Or would it be better to specify a dynamic source of entropy directly in radius.conf? (E.g. /dev/urandom , although i know people some people frown upon this.) Or does the staleness of the random data in those two files not matter? Any tips would be be greatly appreciated. TIA, -Matt - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Help using rlm_passwd and rlm_krb5 with a huntgroup?
Hi, i've been successfully using 0.9 thru 0.9.3 in a simple config in which all authentication is done by rlm_krb5. Now, i also need to authenticate a certain subgroup of users with rlm_passwd. This new subgroup of users will be identified by an IP-based huntgroup. The huntgroup selection, and authentication with krb5 or passwd all seem to work fine, when tested individually. My problem is for cases when a user is to be authenticated by rlm_krb5 as determined by huntgroup, but also happens to exist in the passwd file. In this case, the user's password is checked against the passwd file entry before rlm_krb gets called. This behavior is not what i was hoping for. Does it have to do with rlm_passwd being an authorize module, while rlm_krb5 is an authenticate module? Is there a way around this? Freeradius version is 0.9.3, built on Redhat 9. The relevant config info (i think) is below. Output from radiusd -X -x is in an attached text file. # radius.conf: # modules { ... passwd 1aix-passwd { filename = ${raddbdir}/aix-passwd format = "*User-Name:Crypt-Password" hashsize = 100 } ... } authenticate { krb5 ... } authorize { ... 1aix-passwd ... } # huntgroups: # aixusersNAS-IP-Address == 1.1.1.1 # users: # DEFAULTHuntgroup-Name == aixusers, Auth-Type := 1aix-passwd DEFAULTAuth-Type := Kerberos # BTW, another weird thing is that radiusd was not able to instantiate the rlm_passwd module unless i began the instance name with a digit. In other words, if i used "aix-passwd", radiusd complained: /opt/radius/etc/raddb/users[1]: Parse error (check) for entry DEFAULT: Unknown value aix-passwd for attribute Auth-Type Errors reading /opt/radius/etc/raddb/users radiusd.conf[931]: files: Module instantiation failed. But when i stuck a 1 at the beginning, it worked. Is this expected? Thanks in advance, -Matt ### ### radiusd -X -x startup output: ### [...] Wed Jan 21 17:32:40 2004 : Debug: Module: Loaded passwd Wed Jan 21 17:32:40 2004 : Debug: passwd: filename = "/opt/radius/etc/raddb/aix-passwd" Wed Jan 21 17:32:40 2004 : Debug: passwd: format = "*User-Name:Crypt-Password" Wed Jan 21 17:32:40 2004 : Debug: passwd: authtype = "(null)" Wed Jan 21 17:32:40 2004 : Debug: passwd: delimiter = ":" Wed Jan 21 17:32:40 2004 : Debug: passwd: ignorenislike = yes Wed Jan 21 17:32:40 2004 : Debug: passwd: allowmultiplekeys = no Wed Jan 21 17:32:40 2004 : Debug: passwd: hashsize = 100 Wed Jan 21 17:32:40 2004 : Info: rlm_passwd: nfields: 2 keyfield 0(User-Name) listable: no Wed Jan 21 17:32:40 2004 : Debug: Module: Instantiated passwd (1aix-passwd) [...] Wed Jan 21 17:32:40 2004 : Info: Listening on IP address *, ports 1812/udp and 1813/udp. Wed Jan 21 17:32:40 2004 : Info: Ready to process requests. ### ### success case, when rlm_passwd is expected: ### rad_recv: Access-Request packet from host 127.0.0.1:32782, id=2, length=65 User-Name = "test" User-Password = "pswdpass" NAS-IP-Address = 1.1.1.1 NAS-Port = 1 Framed-Protocol = PPP Wed Jan 21 17:33:28 2004 : Debug: modcall: entering group authorize for request 0 Wed Jan 21 17:33:28 2004 : Debug: modsingle[authorize]: calling preprocess (rlm_preprocess) for request 0 Wed Jan 21 17:33:28 2004 : Debug: modsingle[authorize]: returned from preprocess (rlm_preprocess) for request 0 Wed Jan 21 17:33:28 2004 : Debug: modcall[authorize]: module "preprocess" returns ok for request 0 Wed Jan 21 17:33:28 2004 : Debug: modsingle[authorize]: calling chap (rlm_chap) for request 0 Wed Jan 21 17:33:28 2004 : Debug: modsingle[authorize]: returned from chap (rlm_chap) for request 0 Wed Jan 21 17:33:28 2004 : Debug: modcall[authorize]: module "chap" returns noop for request 0 Wed Jan 21 17:33:28 2004 : Debug: modsingle[authorize]: calling eap (rlm_eap) for request 0 Wed Jan 21 17:33:28 2004 : Debug: modsingle[authorize]: returned from eap (rlm_eap) for request 0 Wed Jan 21 17:33:28 2004 : Debug: modcall[authorize]: module "eap" returns noop for request 0 Wed Jan 21 17:33:28 2004 : Debug: modsingle[authorize]: calling suffix (rlm_realm) for request 0 Wed Jan 21 17:33:28 2004 : Debug: rlm_realm: No '@' in User-Name = "test", looking up realm NULL Wed Jan 21 17:33:28 2004 : Debug: rlm_realm: No such realm "NULL" Wed Jan 21 17:33:28 2004 : Debug: modsingle[authorize]: returned from suffix (rlm_realm) for request 0 Wed Jan 21 17:33:28 2004 : Debug: modcall[authorize]: module "suffix" returns noop for request 0 Wed Jan 21 17:33:28 2004 : Debug: modsingle[authorize]: calling 1aix-passwd (rlm_passwd) for request 0 Wed Jan 21 17:33:28 2004 : Debug: rlm_passwd: Added Crypt-Password: 'z' to config_items Wed Jan 21 17:33:28 2004 : Debug: modsingle[authorize]: returned from 1aix-passwd (rlm_passwd) for request 0 Wed Jan 21 17:33:28 2004 : Debug: modcall[authorize]: module "1aix-passwd" return