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
