Re: Q: Define realms per virtual server.
On Jun 10, 2013, at 3:58 PM, Alan DeKok wrote: > >> I can't find any way to restrict the actual realm definitions to a virtual >> server. They are all global configuration loaded via proxy.conf. > > They are global. That's what I suspected. Thanks for confirming. In my case I have two virtual servers, one which handles a local staff SSID and one which handles our eduroam SSID. Defining a NULL domain for the local SSID virtual server has the unfortunate effect of allowing a NULL domain for eduroam virtual server as well. I was able to achieve most of what I wanted by adding more checks in the virtual server authorize section of the eduroam server to double check for a NULL domain and force a reject. > >> Is there some method I'm missing for making the realm definitions >> per-server? Thanks in advance, > > Source code modifications. Always an option, but not necessarily the easiest. Thanks for the help, -David Mitchell > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Q: Define realms per virtual server.
Greetings,
I'm hitting a situation where I would like to be able to define different
realms in my virtual servers. Simply including realm definitions inside of the
virtual servers doesn't work. It doesn't generate an error either, but the
defined realm doesn't work.
server internal {
realm DEFAULT {
authhost = remote1.com
accthost = remote1.com
nostrip
}
listen {
ipaddr = *
port = 1814
type = auth
}
listen {
ipaddr = *
port = 1815
type = acct
}
. . .
}
The 'realm' keyword is overloaded, being used both for the definitions of the
delimiters and of the realms themselves. And while the former is loaded via a
module syntax and can be loaded per-virtual-server (via suffix, ipass, etc.) I
can't find any way to restrict the actual realm definitions to a virtual
server. They are all global configuration loaded via proxy.conf. Is there some
method I'm missing for making the realm definitions per-server? Thanks in
advance,
-David Mitchell
-----
| David Mitchell (mitch...@ucar.edu) Network Engineer IV |
| Tel: (303) 497-1845 National Center for |
| FAX: (303) 497-1818 Atmospheric Research |
-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: TLS Check Cn Question
On May 26, 2011, at 1:25 AM, Alan DeKok wrote: > David Mitchell wrote: >> currently I'm using the check_cert_cn option in my EAP-TLS setup. I think >> I may have the need to support two possible CN formats. Is there any >> way to do a conditional check? > > Your message contains the answer to that question. > >> I don't think the eap.conf file is >> unlang interpreted so I don't think I can include full regexp or if-then >> conditionals can I? Is there some other way to accomplish this? The >> docs mention possibly doing this by checking TLS-Client-Cert-CN but >> I'm not sure where exactly I would do that. Thanks in advance, > > The CN is just a string. Check it like you would check any string. Well yes, that's true. I'm just not sure where the best place to put the check is since I don't believe eap.conf is unlang interpreted. Should it go into the sites-enabled/default post-auth section? That's really the piece that's not clear to me is where I can put the more sophisticated checks. I think I can write them once I have an idea of where to put them. Thanks in advance, -David Mitchell > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
TLS Check Cn Question
Greetings, currently I'm using the check_cert_cn option in my EAP-TLS setup. I think I may have the need to support two possible CN formats. Is there any way to do a conditional check? I don't think the eap.conf file is unlang interpreted so I don't think I can include full regexp or if-then conditionals can I? Is there some other way to accomplish this? The docs mention possibly doing this by checking TLS-Client-Cert-CN but I'm not sure where exactly I would do that. Thanks in advance, -David Mitchell ----- | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Nexus Configurations
On May 6, 2011, at 2:50 AM, Darren Shaw wrote: > Good morning David, > > To answer your questions > > We do have a local username; all our switches have, 500 of them. Is the user you are testing with configured on the switch? If so, as what type of user? Have you tried a username which is not configured on the switch? > > I have traced the request and response between the FreeRadius server and the > N5K, the server returns a service-type (6) AVP of Shell user (6) which > according to the Free Radius documentation at > http://freeradius.org/rfc/attributes.html is an Administrative user. Is the Cisco-AVPair also in that response packet? Also, I put the syntax for adding those attributes into the 'users' file. It's probably possible to get them crammed in via the 'default' configuration but it's not necessarily the right place. It may also be the case that you need to make sure you are *not* sending the Cisco-AVPair 'shell:priv-lvl=15'. I know that I needed to put my IOS and NX-OS devices into different huntgroups so that I could assign different AVPair's. I tried just sending both values to both types of devices and did not get the desired effect. -David Mitchell > > The syntax that I have placed into the following file > > Cisco-AVPair += "shell:roles=network-admin", >> Service-Type := Administrative-User, > > I have also tried > > Hint == "XX", Auth-Type := Accept >Reply-Message = "ACCEPT: Authorizing enable access", >Cisco-AVPair = "shell:roles*\"network-admin\"", >Cisco-AVPair += "shell:priv-lvl=15", >Service-Type = Administrative-User, >Fall-Through = No > > Cisco-AVPair = "shell:roles=\"network-operator vdc-admin\"" >>> Cisco-AVPair = "shell:roles*\"network-operator vdc-admin\"" >>> Cisco-AVPair = "shell:roles=\"network-admin vdc-admin\"" >>> Cisco-AVPair = "shell:roles*\"network-admin\"" > > The configuration I have on the 5K > > radius-server host key 7 "XX" authentication accounting > aaa group server radius FreeRadius >server x >use-vrf management > aaa authentication login default group FreeRadius > source address x > > It looks as though the 5K is not interpreting the attribute correctly, or I > am not editing the correct file. Whatever syntax I use I get the same > results, I get authenticated but the nexus places me as an operator. > > The file I am editing is /usr/local/etc/raddb/sites-available/default > > Rgds > Darren Shaw > The Network Team > Computing Services > University of Huddersfield > Queensgate > Huddersfield > HD1 3DH > > TEL: 01484 471317 > MOBILE: 07792 773807 > > > -Original Message- > From: freeradius-users-bounces+d.shaw=hud.ac...@lists.freeradius.org > [mailto:freeradius-users-bounces+d.shaw=hud.ac...@lists.freeradius.org] On > Behalf Of David Mitchell > Sent: 05 May 2011 15:35 > To: FreeRadius users mailing list > Subject: Re: Nexus Configurations > > > On May 5, 2011, at 4:47 AM, Darren Shaw wrote: > >> Hello David, >> >> Thanks for the syntax. Sadly this still does not work. The free radius >> server will authenticate me as a user but the 5K wants me as an operator and >> not admin. >> >> If you have the 5K working, could I be cheeky and ask if you could mail me >> the radius config on your 5K > > There isn't anything in the radius config that enables this as far as I can > tell. Do you have a > local account on the 5K? That might override the info from the RADIUS server. > Run the command > 'show user-account' after logging in. For me, it indicates that the account > was created via remote > authentication. I assume you have run the radius server in debug mode to > verify that the attributes > are actually in the access accept packets sent back to the switch? > > > -David Mitchell > >> >> thanks >> >> Rgds >> Darren Shaw >> The Network Team >> Computing Services >> University of Huddersfield >> Queensgate >> Huddersfield >> HD1 3DH >> >> TEL: 01484 471317 >> MOBILE: 07792 773807 >> >> -Original Message- >> From: freeradius-users-bounces+d.shaw=hud.ac...@lists.freeradius.org >> [mailto:freeradius-users-bounces+d.shaw=hud.ac...@lists.freeradius.org] On >> Behalf Of David Mitchell >> Sent: 04 May 2011 15:14 >> To: FreeRadius users mailing list >> Subject: Re: Nexus Configu
Re: Nexus Configurations
On May 5, 2011, at 4:47 AM, Darren Shaw wrote: > Hello David, > > Thanks for the syntax. Sadly this still does not work. The free radius server > will authenticate me as a user but the 5K wants me as an operator and not > admin. > > If you have the 5K working, could I be cheeky and ask if you could mail me > the radius config on your 5K There isn't anything in the radius config that enables this as far as I can tell. Do you have a local account on the 5K? That might override the info from the RADIUS server. Run the command 'show user-account' after logging in. For me, it indicates that the account was created via remote authentication. I assume you have run the radius server in debug mode to verify that the attributes are actually in the access accept packets sent back to the switch? -David Mitchell > > thanks > > Rgds > Darren Shaw > The Network Team > Computing Services > University of Huddersfield > Queensgate > Huddersfield > HD1 3DH > > TEL: 01484 471317 > MOBILE: 07792 773807 > > -Original Message- > From: freeradius-users-bounces+d.shaw=hud.ac...@lists.freeradius.org > [mailto:freeradius-users-bounces+d.shaw=hud.ac...@lists.freeradius.org] On > Behalf Of David Mitchell > Sent: 04 May 2011 15:14 > To: FreeRadius users mailing list > Subject: Re: Nexus Configurations > > > On May 4, 2011, at 4:48 AM, Darren Shaw wrote: > >> Good Morning >> >> I am new to this forum and to the workings of FreeRadius and I have a query >> around the Cisco Nexus family. >> >> Currently we have all our switches and routers authentication to FreeRadius >> and all seems to be working. The problem comes when I want to authenticate >> my Nexus 7K and 5K's. The 7Ks and 5Ks will authenticated me but the Nexus >> puts me in an operator role and not in an administrator's role. >> >> According to Cisco I have to place the following into >> >> /usr/local/etc/raddb/sites-available/default >> >> Cisco-AVPair = "shell:roles=\"network-operator vdc-admin\"" >> Cisco-AVPair = "shell:roles*\"network-operator vdc-admin\"" >> Cisco-AVPair = "shell:roles=\"network-admin vdc-admin\"" >> Cisco-AVPair = "shell:roles*\"network-admin\"" > > This is what I'm adding to the replies for Nexus 5K's. I don't have any 7K's > but I'd be surprised if > they were any different. I have not tried to send two roles so I can't > confirm the syntax for that. > >Cisco-AVPair += "shell:roles=network-admin", >Service-Type := Administrative-User, > > -David Mitchell > >> >> >> The current service type is = Administrative -User >> >> I have tried each AVPair and nothing works. Has anyone else had this issue? >> >> If anyone has any advice I would be really grateful. >> >> Thanks >> >> >> >> Rgds >> Darren Shaw >> The Network Team >> Computing Services >> University of Huddersfield >> Queensgate >> Huddersfield >> HD1 3DH >> >> TEL: 01484 471317 >> MOBILE: 07792 773807 >> >> >> >> ____ >> >> --- >> This transmission is confidential and may be legally privileged. If you >> receive it in error, please notify us immediately by e-mail and remove it >> from your system. If the content of this e-mail does not relate to the >> business of the University of Huddersfield, then we do not endorse it and >> will accept no liability. >> - >> List info/subscribe/unsubscribe? See >> http://www.freeradius.org/list/users.html > > - > | David Mitchell (mitch...@ucar.edu) Network Engineer IV | > | Tel: (303) 497-1845 National Center for | > | FAX: (303) 497-1818 Atmospheric Research | > ----- > > > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > > --- > This transmission is confidential and may be legally privileged. If you > receive it in error, please notify us immediately by e-mail and remove it > from your system. If the content of this e-mail does not relate to the > business of the University of Huddersfield, then we do not endorse it and > will accept no liability. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Nexus Configurations
On May 4, 2011, at 4:48 AM, Darren Shaw wrote: > Good Morning > > I am new to this forum and to the workings of FreeRadius and I have a query > around the Cisco Nexus family. > > Currently we have all our switches and routers authentication to FreeRadius > and all seems to be working. The problem comes when I want to authenticate my > Nexus 7K and 5K’s. The 7Ks and 5Ks will authenticated me but the Nexus puts > me in an operator role and not in an administrator’s role. > > According to Cisco I have to place the following into > > /usr/local/etc/raddb/sites-available/default > > Cisco-AVPair = "shell:roles=\"network-operator vdc-admin\"" > Cisco-AVPair = "shell:roles*\"network-operator vdc-admin\"" > Cisco-AVPair = "shell:roles=\"network-admin vdc-admin\"" > Cisco-AVPair = "shell:roles*\"network-admin\"" This is what I'm adding to the replies for Nexus 5K's. I don't have any 7K's but I'd be surprised if they were any different. I have not tried to send two roles so I can't confirm the syntax for that. Cisco-AVPair += "shell:roles=network-admin", Service-Type := Administrative-User, -David Mitchell > > > The current service type is = Administrative –User > > I have tried each AVPair and nothing works. Has anyone else had this issue? > > If anyone has any advice I would be really grateful. > > Thanks > > > > Rgds > Darren Shaw > The Network Team > Computing Services > University of Huddersfield > Queensgate > Huddersfield > HD1 3DH > > TEL: 01484 471317 > MOBILE: 07792 773807 > > > > > > --- > This transmission is confidential and may be legally privileged. If you > receive it in error, please notify us immediately by e-mail and remove it > from your system. If the content of this e-mail does not relate to the > business of the University of Huddersfield, then we do not endorse it and > will accept no liability. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Ignoring EAP-Type/tls because we do not have OpenSSL,> support.
David Mitchell wrote: > Douglas Caro wrote: > >> # freeradius -v >> freeradius: FreeRADIUS Version 2.1.9, for host i486-pc-linux-gnu, built >> on Sep 13 2010 at 09:40:57 >> Copyright (C) 1999-2009 The FreeRADIUS server project and contributors. > > It seems suspicious to me that your freeradius is reporting a build date > of today. Unless the .deb installation causes this date to up updated, > it implies that you built this binary locally. I have to be honest, even > though I run Debian a lot I usually compile FreeRadius myself so I'm not > that familiar with the packaged version. You tried Alexander's tips, not mine. You built your own binary, and if you didn't get TLS support you will have to debug the configure/make process yourself. The 2.1.8 version in the Lenny backports has TLS support built in. I'm 100% certain of this because I just installed it and checked. -David Mitchell > > -David Mitchell > >> The messages keep appearing >> Ignoring EAP-Type/tls because we do not have OpenSSL support. >> Ignoring EAP-Type/ttls because we do not have OpenSSL support. >> Ignoring EAP-Type/peap because we do not have OpenSSL support. >> >> Thanks >> Douglas >> - >> List info/subscribe/unsubscribe? See >> http://www.freeradius.org/list/users.html > > -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Ignoring EAP-Type/tls because we do not have OpenSSL,> support.
Douglas Caro wrote: > > # freeradius -v > freeradius: FreeRADIUS Version 2.1.9, for host i486-pc-linux-gnu, built > on Sep 13 2010 at 09:40:57 > Copyright (C) 1999-2009 The FreeRADIUS server project and contributors. It seems suspicious to me that your freeradius is reporting a build date of today. Unless the .deb installation causes this date to up updated, it implies that you built this binary locally. I have to be honest, even though I run Debian a lot I usually compile FreeRadius myself so I'm not that familiar with the packaged version. -David Mitchell > > The messages keep appearing > Ignoring EAP-Type/tls because we do not have OpenSSL support. > Ignoring EAP-Type/ttls because we do not have OpenSSL support. > Ignoring EAP-Type/peap because we do not have OpenSSL support. > > Thanks > Douglas > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html -- ----- | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius-Users Digest, Vol 65, Issue 43
Douglas Caro wrote: > Thanks for all, but it didn't work... Odd. Can you double check that OpenSSL got installed? It should be package libssl0.9.8 -David Mitchell > > #dpkg -l |grep freer > ii freeradius > 2.1.8+dfsg-1~bpo50+1 a high-performance and highly > configurable R > ii freeradius-common > 2.1.8+dfsg-1~bpo50+1 FreeRADIUS common files > ii freeradius-dialupadmin > 2.1.8+dfsg-1~bpo50+1 set of PHP scripts for > administering a FreeR > ii freeradius-ldap > 2.1.8+dfsg-1~bpo50+1 LDAP module for FreeRADIUS server > ii freeradius-mysql > 2.1.8+dfsg-1~bpo50+1 MySQL module for FreeRADIUS server > ii freeradius-postgresql > 2.1.8+dfsg-1~bpo50+1 PostgreSQL module for FreeRADIUS > server > ii freeradius-utils > 2.1.8+dfsg-1~bpo50+1 FreeRADIUS client utilities > ii libfreeradius-dev > 2.1.8+dfsg-1~bpo50+1 FreeRADIUS shared library > development files > ii libfreeradius2 > 2.1.8+dfsg-1~bpo50+1 FreeRADIUS shared library > > # freeradius -v > freeradius: FreeRADIUS Version 2.1.8, for host i486-pc-linux-gnu, built > on Jan 3 2010 at 15:51:52 > Copyright (C) 1999-2009 The FreeRADIUS server project and contributors. > > The messages keep appearing > Ignoring EAP-Type/tls because we do not have OpenSSL support. > Ignoring EAP-Type/ttls because we do not have OpenSSL support. > Ignoring EAP-Type/peap because we do not have OpenSSL support. > > Thanks > Douglas > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Ignoring EAP-Type/tls because we do not have OpenSSL support.
Sallee, Stephen (Jake) wrote: > I switched to CentOS for my FR server because my Ubuntu install was > being too picky. I was able to get it to work but I had to compile > OpenSSL from source, then the libs are in different places, etc. it was > a headache. CentOS was much easier for me, if you're not forced to use > Debian you may consider it. The current Ubuntu 10.04 LTS AKA Lucid Lynx includes 2.1.8 with OpenSSL enabled. Prior to that release, you would have had to compile from source or otherwise obtain a build with OpenSSL enabled. -David Mitchell > > Just my $.02. > > Jake Sallee > Godfather Of Bandwidth > Network Engineer > > Fone: 254-295-4658 > Phax: 254-295-4221 > > > > -Original Message- > From: freeradius-users-bounces+jake.sallee=umhb@lists.freeradius.org > [mailto:freeradius-users-bounces+jake.sallee=umhb@lists.freeradius.o > rg] On Behalf Of John Dennis > Sent: Friday, September 10, 2010 1:57 PM > To: FreeRadius users mailing list > Cc: Douglas Caro > Subject: Re: Ignoring EAP-Type/tls because we do not have OpenSSL > support. > > On 09/10/2010 02:49 PM, Douglas Caro wrote: >> Hi, >> >> In #freeradius -X, I have those messages: >> >> Ignoring EAP-Type/tls because we do not have OpenSSL support. >> Ignoring EAP-Type/ttls because we do not have OpenSSL support. >> Ignoring EAP-Type/peap because we do not have OpenSSL support. >> >> I've researched on the subject, but I didn't find anything. >> >> Linux Debian Lenny >> Freeradius 2.0.4 > > It means it wasn't built with OpenSSL support. That used to be the case > due to licensing issues but the new deb packages include it. Try to use > a new package. I'm not a deb guy so I can't tell you where to find the > newer deb packages, but it's been discusssed on this list previously, > search the archives. > -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Ignoring EAP-Type/tls because we do not have OpenSSL support.
John Dennis wrote: > On 09/10/2010 02:49 PM, Douglas Caro wrote: >> Hi, >> >> In #freeradius -X, I have those messages: >> >> Ignoring EAP-Type/tls because we do not have OpenSSL support. >> Ignoring EAP-Type/ttls because we do not have OpenSSL support. >> Ignoring EAP-Type/peap because we do not have OpenSSL support. >> >> I've researched on the subject, but I didn't find anything. >> >> Linux Debian Lenny >> Freeradius 2.0.4 > > It means it wasn't built with OpenSSL support. That used to be the case > due to licensing issues but the new deb packages include it. Try to use > a new package. I'm not a deb guy so I can't tell you where to find the > newer deb packages, but it's been discusssed on this list previously, > search the archives. Debian Stable AKA Lenny still provides 2.0.4 with no OpenSSL. Using the backports (which is now an official Debian service) you can install the newer 2.1.8 with OpenSSL support enabled. See http://backports.debian.org/Instructions/ for instructions on configuring the backports. -David Mitchell > -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: CA_file vs. CA_path
David Mitchell wrote: > Alan DeKok wrote: >> David Mitchell wrote: >>> I now have 2.1.10 compiled and running. It seems to work fine. I did >>> have to make one change to my configuration. I had been using CA_path to >>> refer to the certificates which can authenticate clients for EAP-TLS >>> authentication in 2.1.8. In 2.1.10, that doesn't seem to work. If I >>> specify a single file via CA_file that works fine. I can manage either >>> way I think since the file referenced in CA_file can contain multiple >>> certificates. I did verify that I had run 'c_rehash' in my CA_path >>> directory. I'm not sure why CA_path doesn't work since the OpenSSL docs >>> indicate that they are largely interchangable. Is it an intentional >>> change? >> Nope. It's not an intentional change. I don't know why it would be >> different. > > I did change OpenSSL versions as well so I can't say for sure that it > has anything to do with FreeRadius. I'll try and poke around some and > see if I can figure out what's going on. Thanks for confirming it wasn't > meant to change. I've done some recompiling and I believe that the new behavior is due to the new version of OpenSSL. If I compile FreeRadius using the default Debian OpenSSL (0.9.8g) I can use CA_path as expected. Compiling FreeRadius and specifying the locally installed OpenSSL 1.0.0a results in CA_path not working. In both cases I was compiling FR 2.1.9. I have not dug into the OpenSSL code. I've looked in there before and it scares me ;-) -David > > -David > >> Alan DeKok. >> - >> List info/subscribe/unsubscribe? See >> http://www.freeradius.org/list/users.html > > -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with 2.1.10 hanging
Alan DeKok wrote: > David Mitchell wrote: >> My 2.1.10 server I got compiled has a problem where it hangs after a few >> hours. I'm not sure if it's related to the number of requests it's >> processed or not. It's happened three times so far. Restarting the >> server always gets it working again. Using tcpdump I can confirm that >> it's receiving requests from the NAS but not processing them. Using >> strace I can see that it's stuck on a futex: >> >> write(1, "Wed Aug 25 16:13:45 2010 : Info: "..., 70) = 70 >> futex(0x827fe88, FUTEX_WAIT_PRIVATE, 2, NULL > > It's blocked in a write? Weird... > > See doc/bugs. You should be able to run it under gdb. Then when it's > blocked, hit -C, and do "bt". That should show *which* mutex is > locked. I have it running in gdb now. I'll follow up on the devel list once I get some useful info. Thanks, -David > >> Alan, let me know if you'd rather have this type of thread on the >> Developer list instead of the User list. Thanks, > > That's probably the better place. > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Problem with 2.1.10 hanging
My 2.1.10 server I got compiled has a problem where it hangs after a few hours. I'm not sure if it's related to the number of requests it's processed or not. It's happened three times so far. Restarting the server always gets it working again. Using tcpdump I can confirm that it's receiving requests from the NAS but not processing them. Using strace I can see that it's stuck on a futex: write(1, "Wed Aug 25 16:13:45 2010 : Info: "..., 70) = 70 futex(0x827fe88, FUTEX_WAIT_PRIVATE, 2, NULL The server is doing nothing more than EAP-TLS authentication for some wireless AP's. Debug from the config loading and the last few packets are below. Alan, let me know if you'd rather have this type of thread on the Developer list instead of the User list. Thanks, -David Mitchell Wed Aug 25 14:29:47 2010 : Info: FreeRADIUS Version 2.1.10, for host i686-pc-linux-gnu, built on Aug 25 2010 at 07:46:58 Wed Aug 25 14:29:47 2010 : Info: Copyright (C) 1999-2009 The FreeRADIUS server project and contributors. Wed Aug 25 14:29:47 2010 : Info: There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A Wed Aug 25 14:29:47 2010 : Info: PARTICULAR PURPOSE. Wed Aug 25 14:29:47 2010 : Info: You may redistribute copies of FreeRADIUS under the terms of the Wed Aug 25 14:29:47 2010 : Info: GNU General Public License v2. Wed Aug 25 14:29:47 2010 : Info: Starting - reading configuration files ... Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/radiusd.conf Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/proxy.conf Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/clients.conf Wed Aug 25 14:29:47 2010 : Debug: including files in directory /usr/local/etc/raddb/modules/ Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/cui Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/detail Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/exec Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/mac2ip Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/pam Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/unix Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/logintime Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/etc_group Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/inner-eap Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/ippool Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/sqlcounter_expire_on_login Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/expr Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/wimax Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/echo Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/linelog Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/always Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/preprocess Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/expiration Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/pap Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/attr_filter Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/checkval Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/chap Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/smsotp Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/detail.example.com Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/otp Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/passwd Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/attr_rewrite Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/ntlm_auth Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/perl Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/smbpasswd Wed Aug 25 14:29:47 2010 : Debug: including configuration file /usr/local/etc/raddb/modules/acct_unique Wed Aug 25 14:29:47 2010 : Debug: including config
Re: CA_file vs. CA_path
Alan DeKok wrote: > David Mitchell wrote: >> I now have 2.1.10 compiled and running. It seems to work fine. I did >> have to make one change to my configuration. I had been using CA_path to >> refer to the certificates which can authenticate clients for EAP-TLS >> authentication in 2.1.8. In 2.1.10, that doesn't seem to work. If I >> specify a single file via CA_file that works fine. I can manage either >> way I think since the file referenced in CA_file can contain multiple >> certificates. I did verify that I had run 'c_rehash' in my CA_path >> directory. I'm not sure why CA_path doesn't work since the OpenSSL docs >> indicate that they are largely interchangable. Is it an intentional >> change? > > Nope. It's not an intentional change. I don't know why it would be > different. I did change OpenSSL versions as well so I can't say for sure that it has anything to do with FreeRadius. I'll try and poke around some and see if I can figure out what's going on. Thanks for confirming it wasn't meant to change. -David > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Compiling with newest OpenSSL
Alan DeKok wrote: > David Mitchell wrote: >> I misread that page thinking that v2.1.x would just give me 2.1.9 and >> that master would be 2.1.10. Either way, I was able to get v2.1.x (aka >> 2.1.10) to configure openssl using the LIBS="-ldl" addition. I'm not >> sure what's changed in the "master" that configure seems to figure that >> out on it's own, but it might be nice to add to 2.1.10 if it's not too >> much work. > > You're probably using "--with-system-libtool". Change that to (or > add) --without-system-libtool I'll play around with those two options more the next time I compile. > >> Now I'm hitting the undefined reference to >> `lt__PROGRAM__LTX_preloaded_symbols' problem. I think I've moved past >> that by just adding >> #define lt__PROGRAM__LTX_preloaded_symbols lt_libltdl_LTX_preloaded_symbols >> to modules.c. > > That's also a libtool / libltdl issue. > >> It occurs to me. Is that libtool expecting a macro to be >> defined for _PROGRAM_ and thats why it's defining a symbol which doesn't >> actually exist? I'm just sort of thinking out loud based on your notes here: >> https://bugs.launchpad.net/ubuntu/+source/freeradius/+bug/421005 > > It's a libtool / libltdl versioning issue. Did I mention that they > cause nearly as many problems as they solve? Yeah, I think so. -David > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
CA_file vs. CA_path
I now have 2.1.10 compiled and running. It seems to work fine. I did have to make one change to my configuration. I had been using CA_path to refer to the certificates which can authenticate clients for EAP-TLS authentication in 2.1.8. In 2.1.10, that doesn't seem to work. If I specify a single file via CA_file that works fine. I can manage either way I think since the file referenced in CA_file can contain multiple certificates. I did verify that I had run 'c_rehash' in my CA_path directory. I'm not sure why CA_path doesn't work since the OpenSSL docs indicate that they are largely interchangable. Is it an intentional change? I didn't see anything in the ChangeLog about it. -David -- ----- | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Compiling with newest OpenSSL
Alan DeKok wrote: > David Mitchell wrote: >> I'm hitting some snags trying to compile from source with the newest >> OpenSSL. I have compiled Openssl 1.0.0a and installed in /usr/local/ssl >> (the default location). With FreeRadius 2.1.9 configure fails to detect >> with errors which look like something which is possibly a problem with >> my OpenSSL install. Ultimately, configure finds OpenSSL OK with the git >> version but the resulting compile fails for reasons unrelated to >> OpenSSL. > > Which "git" version are you using? Which branch? > >> I'm not sure the best way to proceed. FR 2.1.9 doesn't seem to >> like OpenSSL 1.0.0a, but the current git version seems to have a bug >> which is stopping the build. Any ideas? Thanks in advance! > > $ LIBS="-ldl" ./configure ... > > That should address the "cannot find dlopen" issues. > > It's a little annoying that the crypto libraries require dlopen(). > >> I'm OK with running the git version as this is only for use on a test >> server right now. But my compile ultimately fails with: >> > ... >> /home/mitchell/src/newest/freeradius-server/src/freeradius-devel/radiusd.h:107, >> from rlm_acctlog.c:28: >> /home/mitchell/src/newest/freeradius-server/src/freeradius-devel/smodule.h:144: >> error: expected specifier-qualifier-list before ‘RADCLIENT’ > > Ah... you're using the git "master" branch. Don't do that. > > Read http://git.freeradius.org and follow the instructions for the > "v2.1.x" branch. That page also explains why you SHOULDN'T use the > "master" branch. I misread that page thinking that v2.1.x would just give me 2.1.9 and that master would be 2.1.10. Either way, I was able to get v2.1.x (aka 2.1.10) to configure openssl using the LIBS="-ldl" addition. I'm not sure what's changed in the "master" that configure seems to figure that out on it's own, but it might be nice to add to 2.1.10 if it's not too much work. Now I'm hitting the undefined reference to `lt__PROGRAM__LTX_preloaded_symbols' problem. I think I've moved past that by just adding #define lt__PROGRAM__LTX_preloaded_symbols lt_libltdl_LTX_preloaded_symbols to modules.c. It occurs to me. Is that libtool expecting a macro to be defined for _PROGRAM_ and thats why it's defining a symbol which doesn't actually exist? I'm just sort of thinking out loud based on your notes here: https://bugs.launchpad.net/ubuntu/+source/freeradius/+bug/421005 Anyway, I've got it built. I need some coffee before I install and try to run it though. Thanks for the help, -David > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Compiling with newest OpenSSL
I'm hitting some snags trying to compile from source with the newest OpenSSL. I have compiled Openssl 1.0.0a and installed in /usr/local/ssl (the default location). With FreeRadius 2.1.9 configure fails to detect with errors which look like something which is possibly a problem with my OpenSSL install. Ultimately, configure finds OpenSSL OK with the git version but the resulting compile fails for reasons unrelated to OpenSSL. I'm not sure the best way to proceed. FR 2.1.9 doesn't seem to like OpenSSL 1.0.0a, but the current git version seems to have a bug which is stopping the build. Any ideas? Thanks in advance! To wit, this configure line with FR2.1.9: ./configure --with-openssl-includes=/usr/local/ssl/include/ --with-openssl-libraries=/usr/local/ssl/lib/ Fails with these results in the config.log: configure:21394: checking for DH_new in -lcrypto configure:21429: gcc -o conftest -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS conftest.c -lcrypto -L/usr/local/ssl/lib/ -lnsl -lresolv -lpthread >&5 /usr/local/ssl/lib//libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup': dso_dlfcn.c:(.text+0x1c): undefined reference to `dlopen' dso_dlfcn.c:(.text+0x32): undefined reference to `dlsym' dso_dlfcn.c:(.text+0x3c): undefined reference to `dlclose' /usr/local/ssl/lib//libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr': dso_dlfcn.c:(.text+0x70): undefined reference to `dladdr' dso_dlfcn.c:(.text+0xc1): undefined reference to `dlerror' /usr/local/ssl/lib//libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func': dso_dlfcn.c:(.text+0x3bd): undefined reference to `dlsym' dso_dlfcn.c:(.text+0x42e): undefined reference to `dlerror' /usr/local/ssl/lib//libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var': dso_dlfcn.c:(.text+0x49d): undefined reference to `dlsym' dso_dlfcn.c:(.text+0x50e): undefined reference to `dlerror' /usr/local/ssl/lib//libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload': dso_dlfcn.c:(.text+0x56c): undefined reference to `dlclose' /usr/local/ssl/lib//libcrypto.a(dso_dlfcn.o): In function `dlfcn_load': dso_dlfcn.c:(.text+0x615): undefined reference to `dlopen' dso_dlfcn.c:(.text+0x66d): undefined reference to `dlclose' dso_dlfcn.c:(.text+0x69c): undefined reference to `dlerror' collect2: ld returned 1 exit status But when I check the newest version of FreeRadius out from git this test passes with the exact same configure statement. So I assume something got changed in FreeRadius. configure:18454: checking for DH_new in -lcrypto configure:18489: gcc -o conftest -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS conftest.c -lcrypto -L/usr/local/ssl/lib/ -lnsl -lresolv -ldl -lpthread >&5 configure:18495: $? = 0 configure:18513: result: yes I'm OK with running the git version as this is only for use on a test server right now. But my compile ultimately fails with: libtool: compile: gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -g -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef -I/home/mitchell/src/newest/freeradius-server/src -I/home/mitchell/src/newest/freeradius-server/libltdl -c rlm_acctlog.c -fPIC -DPIC -o .libs/rlm_acctlog.o In file included from /home/mitchell/src/newest/freeradius-server/src/freeradius-devel/radiusd.h:107, from rlm_acctlog.c:28: /home/mitchell/src/newest/freeradius-server/src/freeradius-devel/smodule.h:144: error: expected specifier-qualifier-list before ‘RADCLIENT’ -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: windows users having trouble authenticating
Alan DeKok wrote: > John Dennis wrote: >> On 08/03/2010 01:30 PM, Alan DeKok wrote: >>> Using a known root CA for RADIUS authentication isn't really >>> recommended. >> Why? >> >> P.S. just to clarify, it's not "using a known root CA for >> RADIUS authentication", rather it's using a server cert signed by a >> known root CA. > > Sure. > > It's because *anyone* can set up an AP, and a RADIUS server that your > PC will accept. If the AP has the same SSID as (say) your work, it will > happily send your work username && login via EAP to the rogue AP. The level of risk here varies depending on the EAP method. If you are using EAP-TLS, the server only gets a copy of the certificate so there is no risk of him stealing your credentials. With EAP-PEAP/MSCHAPv2 I believe the attacker can get enough information to perform a dictionary attack against your password which depending on it's strength may or may not be a problem (I'm not certain about this one if somebody else wants to chime in). And then there is EAP-TTLS where the rogue server will end up with a cleartext copy of the username and password if the user can be tricked into accepting the servers certificate. > The various EAP methods *should* have tied usernames (i.e. domains) to > a field in the certificate. e.g. a cert with CN "rad...@example.com" > should be sent logins for "u...@example.com", but NEVER sent logins for > "u...@example.net" > > You should ONLY send your login credentials when you *know* who it is > on the other end of the EAP conversation. > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: windows users having trouble authenticating
Alan DeKok wrote: > Sallee, Stephen (Jake) wrote: >>> The various EAP methods *should* have tied usernames (i.e. domains) >> to a field in the certificate. e.g. a cert with CN "rad...@example.com" >>> should be sent logins for "u...@example.com", but NEVER sent logins >> for "u...@example.net" >> >> How does this workout with child domains? For example: I have two >> domains 1) umhb.edu and 2) Cru.umhb.edu. "Cru" is a child of >> "umhb.edu", if I get a single cert for FreeRADIUS.umhb.edu will it be ok >> for authenticating users on both umhb.edu AND Cru.umhb.edu? > > I said it SHOULD have been that way. It doesn't work that way now. > > There is NO tying of certificate CNs to user names. We should probably expand on that. With respect to the server's certificate, there is nothing tying it to anything on any client I've tested. The server's certificate is presented and you are allowed to accept it. If it isn't signed by a trusted authority you may have to click some additional warnings. FreeRadius can of course compare the client certs CN to the username for what it's worth. On most platforms, the user can put whatever they want for the username though. Or on XP, it gets auto-filled with the value of the CN from the clients certificate. So that particular check is of dubious value. With respect to Jake's question, I'm not sure if he's talking about the server certificate or the client certificate. Strictly speaking, server certificates are not really tied to a domain or DNS entry with EAP. I don't think the client ever actually sees the true IP address of the radius server or it's domain name. The NAS does (or might), but from the client to the Radius server it's all encapsulated and strictly speaking isn't IP traffic at all. You can use the server cert wherever you want, no matter what DNS name is on it. As long as you can get the users to click OK when they are presented with it, it will be fine. -David Mitchell -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Alan DeKok wrote: > Andreas Hartmann wrote: >> In eap.conf, the option eap -> tls -> cache -> enable is switched off >> and fast_reauth in wpa_supplicant is enabled. > > Uh... that makes no sense. > > You've disabled caching (i.e fast re-auth) on the server, and enabled > it on the client. Why are you surprised that fast re-auth isn't working? I've seen similar problems between FreeRadius and wpa_supplicant both with and without the cache enabled. Getting wpa_supplicant to restart seems to clear it temporarily. My reading of Andreas's message was that he has tried it both ways. I haven't yet dug into it enough to try and pin down where the problem is. It does seem that problems with the cache should just result in a slow authentication taking place, not a total failure of authentication. -David Mitchell > >> If the reconnect takes place, the missing cache-data seems to be the >> problem -> the user cannot be authenticated: > > That's what you told the server to do. > >> If fast_reauth in wpa_supplicant is disabled, the reauthentication works >> fine, but the connection between the AP and the supplicant ist >> interrupted for about 20 seconds - much to long :-). >> >> >> Do you have any idea how to solve this problem? > > Find out why the supplicant is taking 20s for authentication. > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TLS CN Check Question
Alan DeKok wrote:
> David Mitchell wrote:
>> I've encountered a similar issue I'm not sure how to deal with. Is there
>> a place I can log any attributes of the certificate?
>
> Not at this moment. Patches are welcome.
>
>> I log my accounting
>> records via linelog, and as long as the configuration I end up with
>> forces something reasonable into the User-Name value I do log a
>> username. But it occurs to me it might be nice to have some kind of
>> record of the certificate which was used. Either the CN, or serial
>> number, or something. Is there a way to do this?
>
> Source code changes.
I believe I've found a better workaround for my original problem. By
using the realm module, I can strip off the unwanted portion of the
User-Name attribute.
In sites-enabled/default enable the 'suffix' module as needed.
In proxy.conf:
# We don't actually care about the realm, we just need a match
realm "~.+$" {
authhost = LOCAL # not strictly necessary
accthost = LOCAL # not strictly necessary
}
In eap.conf:
# Check for either Stripped-User-Name or User-Name, as we don't know
# which format the client will use.
check_cert_cn = %{%{Stripped-User-Name}:-%{user-nam...@%{calling-station-id}
Then issue certificates with a CN of the form usern...@1122.3344.5566.
Most clients prompt the user for the value of User-Name, so they can
just enter 'username'. XP sends the actual value of CN, but the realm
strips the extra info back off so that we can do the comparison we want.
-David
>
> Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
-
| David Mitchell (mitch...@ucar.edu) Network Engineer IV |
| Tel: (303) 497-1845 National Center for |
| FAX: (303) 497-1818 Atmospheric Research |
-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TLS CN Check Question
David Mitchell wrote: > Is there some other way to accomplish this? I was thinking if perhaps > the certificate attributes ended up in a place where I could perform > more thorough unlang comparisons I could get the same effect. The > authentication eventually passes through the users file, and the > User-Name and Calling-Station-Id should be available there but I don't > know if I can access the CN or other certificate attributes there. Does > anybody know if this is possible? I've encountered a similar issue I'm not sure how to deal with. Is there a place I can log any attributes of the certificate? I log my accounting records via linelog, and as long as the configuration I end up with forces something reasonable into the User-Name value I do log a username. But it occurs to me it might be nice to have some kind of record of the certificate which was used. Either the CN, or serial number, or something. Is there a way to do this? -David Mitchell -- ----- | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-TLS CN Check Question
Greetings,
I'm working with the EAP-TLS configuration and one thing I'd like to do
is to be able to restrict a certificate to use on a specific device. In
most cases, I can get this to work:
check_cert_cn = %{User-Name}-%{Calling-Station-Id}
However, by default WindowsXP is using the value of CN from the
certificate as the username so I get a value which matches
check_cert_cn = %{User-Name}
making it hard to integrate the Calling-Station-Id into the comparison.
Full regexp comparisons don't seem to be available, at least that used
to be the case based on my reading of the mailing list archives.
Is there some other way to accomplish this? I was thinking if perhaps
the certificate attributes ended up in a place where I could perform
more thorough unlang comparisons I could get the same effect. The
authentication eventually passes through the users file, and the
User-Name and Calling-Station-Id should be available there but I don't
know if I can access the CN or other certificate attributes there. Does
anybody know if this is possible?
As a fallback, I can have the XP users jump through more configuration
hoops, or put only the Calling-Station-Id into the CN but I do like
having the username in there as well. Thanks in advance,
-David Mitchell
--
-----
| David Mitchell (mitch...@ucar.edu) Network Engineer IV |
| Tel: (303) 497-1845 National Center for |
| FAX: (303) 497-1818 Atmospheric Research |
-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: separating Users?
freerad...@corwyn.net wrote: > > > > There's a piece of RADIUS that I'm not understanding. > > If I have an entry in my ./users file > DEFAULT Auth-Type:=Accept,Ldap-Group == "Group1" > > Service-Type=NAS-Prompt-User,cisco-avpair="shell:priv-lvl=15" > > And another entry > DEFAULT Auth-Type:=Accept,Ldap-Group == "Group2" > > Service-Type=NAS-Prompt-User,cisco-avpair="shell:priv-lvl=15" > > where I'm trying to authorize users in Group1 for one set of switches, > and users in Group2 for another set of switches, how does freeradius > know which is which? You want something like this in huntgroups. It will assign the huntgroup based on the value of NAS-IP-Address. cisco NAS-IP-Address == 10.0.0.1 cisco NAS-IP-Address == 10.0.0.2 And then in your users file: DEFAULT Ldap-Group == cisco-admin, Huntgroup-Name == cisco Service-Type := Administrative-User, Reply-Message := "Authorized Users Only" DEFAULT Ldap-Group == cisco-user, Huntgroup-Name == cisco Service-Type := NAS-Prompt-User, Reply-Message := "Authorized Users Only" This gives the different classes of users different levels of access to the same devices. It should be clear though how to make it do what you want. I see several potential problems in your config. 1) Don't specify the Auth-Type. You still want to check the password I assume. I think your config will let in any user who is in group "Group1" irrespective of the supplied password. 2) You don't specify the requirement to match a huntgroup name. All of the match clauses should be provided comma separated after DEFAULT. 3) You probably don't want the '=' operator, as it will not replace an existing entry in the reply. The ':=' will replace an existing entry. This probably isn't a problem in you case, but I would do it anyway. 4) I never had much luck with that priv-lvl=15 AV pair. I have both CatOS and IOS devices respecting the Service-Type AV though. -David Mitchell > > Rick > > > > > Rick Steeves > http://www.sinister.net > > In reality nothing is more damaging to the adventurous spirit within a > man than a secure future - Alexander Supertramp > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Session resumption problem
Alexander Clouter wrote: > Make sure you 'git cherry-pick' the patches related to: > > https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=15 > https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=21 > > ...if you are using a vanilla 2.1.7. Thanks for the heads up. I'm currently in a testing phase, so I'll probably just grab the current git version and run that. Given the rate things move for me, 2.1.8 will be out by the time I'm ready for production. -David > > Cheers > -- ----- | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Session resumption problem
Alan DeKok wrote: > David Mitchell wrote: >> I was searching back in the archives, and in September there was a user >> who reported a problem with session resumption. I'm seeing the exact >> same symptoms I believe, also on Debian 5.0 with OpenSSL 0.9.8g. I never >> saw any follow up? Is there a fix known for this? I am using a locally >> compiled version of FreeRadius 2.1.7. It's linked against the system >> OpenSSL libraries though. Building a local 0.9.8k or even 1.0.0 is >> certainly an option if there is a chance it will help. > > There isn't a lot we can do. It's not clear *why* OpenSSL resumes > sessions when session resumption is disabled. I did manage to find an easy workaround for this. Simply enabling the cache in eap.conf allows these connections to succeed. I think there may still be a bug somewhere, or maybe more than one. At a minimum it seems a bit foolish for wpa_supplicant to keep trying to do a fast reconnect after getting an Access-Reject. Whatever the root problem is, there is an easy workaround. I wanted to follow up primarily in case others find this thread in the future it will have a workaround. I'm guessing the only real downside to enabling the EAP cache is memory usage, which I'm not too worried about. -David Mitchell > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: wpa/wpa2 on logs
Alan Buxey wrote: > Hi, >> Our Cisco's can optionally include it in the Accounting packets. It >> looks like this: >> >> Cisco-AVPair = "auth-algo-type=eap-peap" > > thats just the method - just like MSCHAPv2 is the inner type - this doesnt > state the link-layer encryption - ie TKIP or AES Oops, my mistake. Yeah, I don't see the encryption type in any of my accounting packets. I can view it from the CLI of course, but that doesn't address the original question. -David > > > alan > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- ----- | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: wpa/wpa2 on logs
Our Cisco's can optionally include it in the Accounting packets. It looks like this: Cisco-AVPair = "auth-algo-type=eap-peap" I had to include the following configuration on the AP so it would send it: radius-server vsa send accounting And configure accounting of course. -David Mitchell Alan Buxey wrote: > Hi, > >> Hmm, just thought, some vendors may include the information in the RADIUS >> packet as VSAs (Vendor Specific Attributes). >> >> Might be worth running the server in debugging mode (radiusd -X) and see >> what your wireless controllers >> are actually sending in Access-Request packets. >> >> So although you won't get the info in the EAP Tunnel, you may find it's >> available in the RADIUS Access-request >> packets. > > I thought the same thing - so had a quick look at our incoming RADIUS > Access-Requests etc... > and nothing useful buried there - but there again, I havent looked at the > other end > yet to see if there are other options or VSAs that can be used - we can > currently get > such info from the wireless control system - so that information is being > passed from > the LWAPP/CAPWAP systems to the controller - and a suitable SNMP to the WCS > from the > RADIUS server would allow you to tie the two together (best done out of > band!) .. > this is probably a useful step for any site wondering whether to drop WPA/TKIP > support for example (for security - move to WPA2/AES) - you'd need to see how > many non-AES clients you had before the change.. > > > alan > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Session resumption problem
Alan DeKok wrote: > David Mitchell wrote: >> I was searching back in the archives, and in September there was a user >> who reported a problem with session resumption. I'm seeing the exact >> same symptoms I believe, also on Debian 5.0 with OpenSSL 0.9.8g. I never >> saw any follow up? Is there a fix known for this? I am using a locally >> compiled version of FreeRadius 2.1.7. It's linked against the system >> OpenSSL libraries though. Building a local 0.9.8k or even 1.0.0 is >> certainly an option if there is a chance it will help. > > There isn't a lot we can do. It's not clear *why* OpenSSL resumes > sessions when session resumption is disabled. OK. I can't easily replicate it. At least, I don't know exactly what circumstances cause it. The clients doesn't always cause this error to pop up. Only sometimes. I was hoping their was a known fix. It sounds like I'll have to dig into it deeper if it turns out to be a big issue. Thanks, -David Mitchell > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Session resumption problem
I was searching back in the archives, and in September there was a user who reported a problem with session resumption. I'm seeing the exact same symptoms I believe, also on Debian 5.0 with OpenSSL 0.9.8g. I never saw any follow up? Is there a fix known for this? I am using a locally compiled version of FreeRadius 2.1.7. It's linked against the system OpenSSL libraries though. Building a local 0.9.8k or even 1.0.0 is certainly an option if there is a chance it will help. Here's a snippet from the original thread. I think it was about Sept. 1st 2009. I get similar errors. Sometimes the client (an Ubuntu 9.04 Jaunty laptop) connects, but sometimes I get this resumption error. My other clients (XP, iPhone, etc.) don't seem to ever exhibit the problem. > [peap] Success > [peap] FAIL: Forcibly stopping session resumption as it is not allowed. > [eap] Freeing handler Arg. FreeRADIUS tells OpenSSL to *not* allow session resumption, and it still negotiates session resumption. Which OS are you using? Which version of OpenSSL? -- ----- | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How can I output Cisco-AVPair Attributes in linelog?
Bob Franklin wrote:
> On Tue, 6 Oct 2009, Alan DeKok wrote:
>
>>> Start = "Connect: User: %{User-Name} ( client: %{Calling-Station-Id}
>>> location: %{WISPr-Location-Name}) %{Cisco-AVPair[*]}"
>>>
>>> or the first one by using %{Cisco-AVPair[1]}. But I have no guarantee
>>> that the ssid will be the first AV pair.
>>
>> Yes... there's no simple way to do that right now.
>
> We do this:
>
> elsif ("%{Cisco-AVPair}" =~ /^ssid=(.+)$/) {
> # a Cisco AP
>
> update request {
> UCam-Location-Id := "%{NAS-IP-Address}"
> UCam-Essid-Name := "%{1}"
> }
>
> [We use UCam-Essid-Name and UCam-Location-Id as local dictionary items
> to handle different types of APs by setting a common field.]
>
>
> I've never seen another Cisco-AVPair attribute (only 'ssid=xxx') -- what
> happens if there is and I'm doing the above? Will it match the first
> (or an abitrary one) or will it find one which matches and return false
> if there if isn't?
That's a good question. I get about six AVPair's so I could test. What
portion of the config do you put that code into?
-David Mitchell
>
> - Bob
>
>
--
-
| David Mitchell (mitch...@ucar.edu) Network Engineer IV |
| Tel: (303) 497-1845 National Center for |
| FAX: (303) 497-1818 Atmospheric Research |
-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: How can I output Cisco-AVPair Attributes in linelog?
Alan DeKok wrote:
> David Mitchell wrote:
>> The SSID is in a Cisco-AVPair. I can include them all via
>>
>> Start = "Connect: User: %{User-Name} ( client: %{Calling-Station-Id}
>> location: %{WISPr-Location-Name}) %{Cisco-AVPair[*]}"
>>
>> or the first one by using %{Cisco-AVPair[1]}. But I have no guarantee
>> that the ssid will be the first AV pair.
>
> Yes... there's no simple way to do that right now.
Is usage of Cisco-AVPair, or other similar variables, common enough to
include code for it? For example, perhaps they could be accessed via a
Perl hash-like structure as %{Cisco-AVPair[ssid]} to get "TEST" from
Cisco-AVPair = "ssid=TEST". I don't think the coe would be hard to
write, but I have no idea where it would fit in.
>
>> I've tried using unlang constructs to pull the data out, but can't
>> figure out the right syntax. I'm trying something like the config below,
>> just to see if the 'if/else' clauses even fire and they don't. No matter
>> what I put in for the regexp, SSID never gets redefined to TRUE or
>> FALSE. It always outputs as 'Junk'. I'm sure this is doable, I just
>> don't know the exact syntax. Any ideas? Thanks in advance.
>>
>> >From linelog configuration:
>>
>> Accounting-Request {
>> SSID="Junk"
>> Pairs = "%{Cisco-AVPair[0]}"
>
> You can't do that. The configuration files are NOT a programming
> language. If you want to set temporary variables (really attributes),
> see the "update" section.
Oddly, I can do that. It works fine and I can reference the variables
later as ${SSID} and ${Pairs}. I was hoping that I could use unlang
constructs in the linelog config file but it sounds like that isn't the
case. I can live with just dumping %{Cisco-AVPair[*]} into my logs, I
just end up with some extra junk I don't care about. I've never been
100% clear on where I can and can't use unlang syntax. Thanks for the help,
-David Mitchell
>
> Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
-
| David Mitchell (mitch...@ucar.edu) Network Engineer IV |
| Tel: (303) 497-1845 National Center for |
| FAX: (303) 497-1818 Atmospheric Research |
-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
How can I output Cisco-AVPair Attributes in linelog?
Greetings,
I'm playing with using the linelog module to syslog accounting records.
The basics are pretty straightforward to configure, and I have them
working. What I can't figure out is how to include the ssid in the
linelog output. 'radiusd -X' kindly dumps the contents of the received
accounting requests:
rad_recv: Accounting-Request packet from host 10.2.2.2 port 1646, id=62,
length=234
Acct-Session-Id = "004D"
Called-Station-Id = "001b.d517.4080"
Calling-Station-Id = "0026.4aea.ba42"
Cisco-AVPair = "ssid=TEST"
Cisco-AVPair = "vlan-id=228"
Cisco-AVPair = "nas-location=Office"
WISPr-Location-Name = "Office"
User-Name = "testuser"
Cisco-AVPair = "connect-progress=Call Up"
Acct-Authentic = RADIUS
Acct-Status-Type = Start
NAS-Port-Type = Wireless-802.11
Cisco-NAS-Port = "301"
NAS-Port = 301
Service-Type = Framed-User
NAS-IP-Address = 10.2.2.2
Acct-Delay-Time = 0
The SSID is in a Cisco-AVPair. I can include them all via
Start = "Connect: User: %{User-Name} ( client: %{Calling-Station-Id}
location: %{WISPr-Location-Name}) %{Cisco-AVPair[*]}"
or the first one by using %{Cisco-AVPair[1]}. But I have no guarantee
that the ssid will be the first AV pair.
I've tried using unlang constructs to pull the data out, but can't
figure out the right syntax. I'm trying something like the config below,
just to see if the 'if/else' clauses even fire and they don't. No matter
what I put in for the regexp, SSID never gets redefined to TRUE or
FALSE. It always outputs as 'Junk'. I'm sure this is doable, I just
don't know the exact syntax. Any ideas? Thanks in advance.
>From linelog configuration:
Accounting-Request {
SSID="Junk"
Pairs = "%{Cisco-AVPair[0]}"
if ( Pairs =~ /.*/ ) {
SSID="TRUE"
}
else {
SSID = "FALSE"
}
Start = "Connect: User: %{User-Name} ( client:
%{Calling-Station-Id} location: %{WISPr-Location-Name}) SSID:${SSID}
${Pairs}"
--
-
| David Mitchell (mitch...@ucar.edu) Network Engineer IV |
| Tel: (303) 497-1845 National Center for |
| FAX: (303) 497-1818 Atmospheric Research |
-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [OT] radius, pam and ts
Vittore Zen wrote: > Hi, > > to everyone. I know this is an OT post but i don't know where post. > > I have a freeradius server that's work fine. > I have a tslp that's work fine (with passwd user) (it's and ubuntu > 8.04 with ltsp correctly installed) > > Now I want use freeradius to autenticate user in tslp desktop. > > So, I think to install http://freeradius.org/pam_radius_auth but no > request is sent to freeradius server. pam_radius_auth is packaged in Ubuntu as package 'libpam-radius-auth' and will put it's config file in /etc/pam_radius_auth.conf. You will need to activate the module in your pam configuration in /etc/pam.d. That step is not automatic as there are lots of ways to use the module. > > The questions: > 1. where install pam_radius_auth? In /etc or in /opt/ltsp/i386/etc? > 2. how to configure for ltsp? > > Thanks in advance > v. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- - | David Mitchell ([EMAIL PROTECTED]) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius and Cisco (cisco-avpair = "shell:priv-lvl=15"doesn't work)
Ivan Kalik wrote: > You need to have a look at switch radius documentation to see which > Service -Type are you suposed to return. Administrative-User? This is IOS, correct? You need to add 'aaa authorization exec default group radius none' to your config or else the switch will ignore your higher access level attributes. In my experience, you can set either the Service-Type or the cisco av-pair. There is no need to set both. -David Mitchell > > Ivan Kalik > Kalik Informatika ISP > > > Dana 11/7/2008, "Simo" <[EMAIL PROTECTED]> piše: > >> On Fr, 2008-07-11 at 10:38 +0100, Ivan Kalik wrote: >>> Cisco-NAS-Port = "tty2" >> Thnx for your reply. I have setting the NAS-Port to tty2 but i'm still >> having the same Problem. >> And here is the reply of switch (priv=1 was requested): >> >> ďťż04:25:06: AAA: parse name=tty2 idb type=-1 tty=-1 >> 04:25:06: AAA: name=tty2 flags=0x11 type=5 shelf=0 slot=0 adapter=0 >> port=2 channel=0 >> 04:25:06: AAA/MEMORY: create_user (0x80D37CDC) user='' ruser='' >> port='tty2' rem_addr='192.168.178.3' authen_type=ASCII service=LOGIN >> priv=1 >> 04:25:06: AAA/AUTHEN/START (4223102353): port='tty2' list='' >> action=LOGIN service=LOGIN >> 04:25:06: AAA/AUTHEN/START (4223102353): using "default" list >> 04:25:06: AAA/AUTHEN/START (4223102353): Method=radius (radius) >> 04:25:06: AAA/AUTHEN (4223102353): status = GETUSER >> 04:25:11: AAA/AUTHEN/CONT (4223102353): continue_login (user='(undef)') >> 04:25:11: AAA/AUTHEN (4223102353): status = GETUSER >> 04:25:11: AAA/AUTHEN (4223102353): Method=radius (radius) >> 04:25:11: AAA/AUTHEN (4223102353): status = GETPASS >> 04:25:12: AAA/AUTHEN/CONT (4223102353): continue_login (user='admin') >> 04:25:12: AAA/AUTHEN (4223102353): status = GETPASS >> 04:25:12: AAA/AUTHEN (4223102353): Method=radius (radius) >> 04:25:12: AAA/AUTHEN (4223102353): status = PASS >> >> thnx for help >> Simo >> >> >> - >> List info/subscribe/unsubscribe? See >> http://www.freeradius.org/list/users.html > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- - | David Mitchell ([EMAIL PROTECTED]) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Proxy help
Ivan Kalik wrote:
>> OK, I think I have this figured out. Does this seem like a reasonable
>> solution? From sites-enabled/default:
>>
>> pre-proxy {
>># Save our relevant attributes in the 'control' list before
>># we send our request to the proxy. We will retrieve them later.
>>update control {
>>Service-Type := "%{reply:Service-Type}"
>>Reply-Message := "%{reply:Reply-Message}"
>>}
>> }
>>
>> post-auth {
>>update reply {
>>Service-Type := "%{control:Service-Type}"
>>Reply-Message := "%{control:Reply-Message}"
>>}
>> }
>>
>
> I don't think that you need pre-proxy entries. Service -Type should be
> in the request list, so you can update reply from there. And
> Reply-Message can probably be derived from the Service-Type?
I set those two attributes in the users file based on the group the
username is in and the huntgroup the NAS is in. I tried to find
somewhere I could grab the attributes from, but I couldn't find them
anywhere. My guess is that the users file set them in the reply packet,
but they got overwritten by the response from the proxy? From what I can
tell, when I get the response from the proxy nothing is left in the
reply packet except proxy-state. Is that normal, or possibly a bug?
-David
>
> Ivan Kalik
> Kalik Informatika ISP
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
-
| David Mitchell ([EMAIL PROTECTED]) Network Engineer IV |
| Tel: (303) 497-1845 National Center for |
| FAX: (303) 497-1818 Atmospheric Research |
-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Proxy Timeout Behavior
David Mitchell wrote:
> David Mitchell wrote:
>> I'm trying to figure out how to have FreeRadius not send an
>> authentication failed response if it can't reach a proxy. What I would
>> prefer is that it simply not respond at all. That would allow my NAS to
>> fall back to using a local password if my proxy is down or unreachable.
>> A quick look at the source to event.c makes it appear that sending the
>> reject is hard coded. Is there some way around this that I'm missing?
>> Thanks in advance,
>
> I solved this with the following in radiusd.conf, in case any body else
> has the same problem.
This should say it's in sites-enabled/default, not radiusd.conf. Oops.
-David Mitchell
>
> post-proxy {
> # If the server tries to proxy a request and the request
> # times out, then the
> # request is processed through the modules in this section.
> #
> # 'fail' causes the server to ignore the request, so the NAS
> # will fall back to the line/enable/whatever password.
> Post-Proxy-Type Fail {
> fail
> }
>
> }
>
>> -David Mitchell
>>
>
>
--
-
| David Mitchell ([EMAIL PROTECTED]) Network Engineer IV |
| Tel: (303) 497-1845 National Center for |
| FAX: (303) 497-1818 Atmospheric Research |
-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Proxy help
OK, I think I have this figured out. Does this seem like a reasonable
solution? From sites-enabled/default:
pre-proxy {
# Save our relevant attributes in the 'control' list before
# we send our request to the proxy. We will retrieve them later.
update control {
Service-Type := "%{reply:Service-Type}"
Reply-Message := "%{reply:Reply-Message}"
}
}
post-auth {
update reply {
Service-Type := "%{control:Service-Type}"
Reply-Message := "%{control:Reply-Message}"
}
}
Ivan Kalik wrote:
>> Sure, but where?
>
> Read the first sentence of man unlang. Same place you are calling attrs
> from.
>
> Ivan Kalik
> Kalik Informatika ISP
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
-
| David Mitchell ([EMAIL PROTECTED]) Network Engineer IV |
| Tel: (303) 497-1845 National Center for |
| FAX: (303) 497-1818 Atmospheric Research |
-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Proxy Timeout Behavior
David Mitchell wrote:
> I'm trying to figure out how to have FreeRadius not send an
> authentication failed response if it can't reach a proxy. What I would
> prefer is that it simply not respond at all. That would allow my NAS to
> fall back to using a local password if my proxy is down or unreachable.
> A quick look at the source to event.c makes it appear that sending the
> reject is hard coded. Is there some way around this that I'm missing?
> Thanks in advance,
I solved this with the following in radiusd.conf, in case any body else
has the same problem.
post-proxy {
# If the server tries to proxy a request and the request
# times out, then the
# request is processed through the modules in this section.
#
# 'fail' causes the server to ignore the request, so the NAS
# will fall back to the line/enable/whatever password.
Post-Proxy-Type Fail {
fail
}
}
>
> -David Mitchell
>
--
-----
| David Mitchell ([EMAIL PROTECTED]) Network Engineer IV |
| Tel: (303) 497-1845 National Center for |
| FAX: (303) 497-1818 Atmospheric Research |
-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Proxy Timeout Behavior
I'm trying to figure out how to have FreeRadius not send an authentication failed response if it can't reach a proxy. What I would prefer is that it simply not respond at all. That would allow my NAS to fall back to using a local password if my proxy is down or unreachable. A quick look at the source to event.c makes it appear that sending the reject is hard coded. Is there some way around this that I'm missing? Thanks in advance, -David Mitchell -- ----- | David Mitchell ([EMAIL PROTECTED]) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Proxy help
David Mitchell wrote:
> Ivan Kalik wrote:
>> Update reply with unlang:
>>
>> http://freeradius.org/radiusd/man/unlang.html
>
> Sure, but where? In the 'attrs' file? I tried adding something there and
> it complains:
>
> DEFAULT
> Service-Type := %{proxy-request:Service-Type},
> # Service-Type == Framed-User,
> # Service-Type == Login-User,
> Login-Service == Telnet,
>
> results in
> /home/mitchell/fr/etc/raddb/attrs[104]: Parse error (reply) for entry
> DEFAULT: Expected end of line or comma
> Errors reading /home/mitchell/fr/etc/raddb/attrs
>
> Is attrs not using unlang? If not, what should I be using instead? It
> does look like unlang gives me what I want, but it's not clear where I
> can use it.
So I'm closer. I can update things in post-auth using for example:
update reply {
Service-Type := "%{control:Service-Type}"
Reply-Message := "Go Away %{request:User-Name}"
}
But I can't get %{Service-Type} to expand. I have no idea what happened
to the value I set earlier in the users file. It almost seems like I
should not be using the users file at all and trying to implement my
authz in post-auth using unlang? That doesn't really seem right though.
-David
>
> -David
>
>> Ivan Kalik
>> Kalik Informatika ISP
>>
>>
>> Dana 26/6/2008, "David Mitchell" <[EMAIL PROTECTED]> piše:
>>
>>> I should probably add that I can get the Service-Type added using the
>>> 'attrs' file in the post-proxy section. But I want to set the
>>> Service-Type based on the user and huntgroup so that users have either
>>> Administrative-User or Login-User access depending on the user and
>>> device. This doesn't seem to be possible in the attrs file.
>>>
>>> -David
>>>
>>> David Mitchell wrote:
>>>> I've having a problem getting the proper attributes set on my response
>>>> packets when using a proxy.
>>>>
>>>> If I authenticate locally with something like this in users:
>>>> username Cleartext-Password password
>>>> Service-Type = Administrative-User,
>>>> Reply-Message = "Authorized Users Only",
>>>>
>>>> it works fine. The Service-Type and Reply-Message get sent off to the
>>>> NAS and life is good. However, if I activate a NULL realm and proxy the
>>>> authentications out, it no longer works. My users file looks more like
>>>> this:
>>>> DEFAULT
>>>> Service-Type = Administrative-User,
>>>> Reply-Message = "Authorized Users Only",
>>>>
>>>> Judging from the post-proxy-detail and reply-detail logs it looks like
>>>> the proxy server is dropping all the attributes and my server doesn't
>>>> put them back? Is that correct? And is that the way it's supposed to
>>>> work? Thanks in advance,
>>>>
>>>> -David Mitchell
>>>>
>>>>
>>> --
>>> -----
>>> | David Mitchell ([EMAIL PROTECTED]) Network Engineer IV |
>>> | Tel: (303) 497-1845 National Center for |
>>> | FAX: (303) 497-1818 Atmospheric Research |
>>> -
>>> -
>>> List info/subscribe/unsubscribe? See
>>> http://www.freeradius.org/list/users.html
>>>
>>>
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>
>
--
-
| David Mitchell ([EMAIL PROTECTED]) Network Engineer IV |
| Tel: (303) 497-1845 National Center for |
| FAX: (303) 497-1818 Atmospheric Research |
-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Proxy help
Ivan Kalik wrote:
> Update reply with unlang:
>
> http://freeradius.org/radiusd/man/unlang.html
Sure, but where? In the 'attrs' file? I tried adding something there and
it complains:
DEFAULT
Service-Type := %{proxy-request:Service-Type},
# Service-Type == Framed-User,
# Service-Type == Login-User,
Login-Service == Telnet,
results in
/home/mitchell/fr/etc/raddb/attrs[104]: Parse error (reply) for entry
DEFAULT: Expected end of line or comma
Errors reading /home/mitchell/fr/etc/raddb/attrs
Is attrs not using unlang? If not, what should I be using instead? It
does look like unlang gives me what I want, but it's not clear where I
can use it.
-David
>
> Ivan Kalik
> Kalik Informatika ISP
>
>
> Dana 26/6/2008, "David Mitchell" <[EMAIL PROTECTED]> piše:
>
>> I should probably add that I can get the Service-Type added using the
>> 'attrs' file in the post-proxy section. But I want to set the
>> Service-Type based on the user and huntgroup so that users have either
>> Administrative-User or Login-User access depending on the user and
>> device. This doesn't seem to be possible in the attrs file.
>>
>> -David
>>
>> David Mitchell wrote:
>>> I've having a problem getting the proper attributes set on my response
>>> packets when using a proxy.
>>>
>>> If I authenticate locally with something like this in users:
>>> username Cleartext-Password password
>>> Service-Type = Administrative-User,
>>> Reply-Message = "Authorized Users Only",
>>>
>>> it works fine. The Service-Type and Reply-Message get sent off to the
>>> NAS and life is good. However, if I activate a NULL realm and proxy the
>>> authentications out, it no longer works. My users file looks more like this:
>>> DEFAULT
>>> Service-Type = Administrative-User,
>>> Reply-Message = "Authorized Users Only",
>>>
>>> Judging from the post-proxy-detail and reply-detail logs it looks like
>>> the proxy server is dropping all the attributes and my server doesn't
>>> put them back? Is that correct? And is that the way it's supposed to
>>> work? Thanks in advance,
>>>
>>> -David Mitchell
>>>
>>>
>>
>> --
>> -
>> | David Mitchell ([EMAIL PROTECTED]) Network Engineer IV |
>> | Tel: (303) 497-1845 National Center for |
>> | FAX: (303) 497-1818 Atmospheric Research |
>> -
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
>>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
-
| David Mitchell ([EMAIL PROTECTED]) Network Engineer IV |
| Tel: (303) 497-1845 National Center for |
| FAX: (303) 497-1818 Atmospheric Research |
-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Proxy help
I should probably add that I can get the Service-Type added using the 'attrs' file in the post-proxy section. But I want to set the Service-Type based on the user and huntgroup so that users have either Administrative-User or Login-User access depending on the user and device. This doesn't seem to be possible in the attrs file. -David David Mitchell wrote: > I've having a problem getting the proper attributes set on my response > packets when using a proxy. > > If I authenticate locally with something like this in users: > username Cleartext-Password password > Service-Type = Administrative-User, > Reply-Message = "Authorized Users Only", > > it works fine. The Service-Type and Reply-Message get sent off to the > NAS and life is good. However, if I activate a NULL realm and proxy the > authentications out, it no longer works. My users file looks more like this: > DEFAULT > Service-Type = Administrative-User, > Reply-Message = "Authorized Users Only", > > Judging from the post-proxy-detail and reply-detail logs it looks like > the proxy server is dropping all the attributes and my server doesn't > put them back? Is that correct? And is that the way it's supposed to > work? Thanks in advance, > > -David Mitchell > > -- - | David Mitchell ([EMAIL PROTECTED]) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Proxy help
I've having a problem getting the proper attributes set on my response packets when using a proxy. If I authenticate locally with something like this in users: username Cleartext-Password password Service-Type = Administrative-User, Reply-Message = "Authorized Users Only", it works fine. The Service-Type and Reply-Message get sent off to the NAS and life is good. However, if I activate a NULL realm and proxy the authentications out, it no longer works. My users file looks more like this: DEFAULT Service-Type = Administrative-User, Reply-Message = "Authorized Users Only", Judging from the post-proxy-detail and reply-detail logs it looks like the proxy server is dropping all the attributes and my server doesn't put them back? Is that correct? And is that the way it's supposed to work? Thanks in advance, -David Mitchell -- ----- | David Mitchell ([EMAIL PROTECTED]) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Movaz Dictionary
Greetings, does anybody know of a dictionary for Movaz equipment? Specifically, their docs refer the to attributes Movaz-Initial-CLI-Access-Level and Movaz-Max-CLI-Access-Level but don't provide the information needed to encode them as far as I can tell. I'll try working with their support staff more, but so far we haven't had any luck getting the needed information. If anybody here knows how I'd appreciate the help. Thanks. -- ----- | David Mitchell ([EMAIL PROTECTED]) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: x99 Token Module Problems
On Jan 11, 2006, at 4:28 PM, Alan DeKok wrote: David Mitchell <[EMAIL PROTECTED]> wrote: I have now is if I should try to write patches against 1.0.5 or 1.1.0-pre0. There are pretty substantial differences between the two WRT the rlm_x99/rlm_otp code. Do you have a feel for when 1.1.0 will be released? Days. I'd like to do it this week, if at all possible. Cool. I'll plan on working against 1.1.0 and hopefully any patches I come up with will be ready in time for consideration to be included in 1.1.1. -David Mitchell Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: x99 Token Module Problems
Alan, those answers are pretty much what I expected. Once I started digging in, I had some other questions and dropped a note to Frank Cusack directly since he seems to be the author of most of that module. One big question I have now is if I should try to write patches against 1.0.5 or 1.1.0-pre0. There are pretty substantial differences between the two WRT the rlm_x99/rlm_otp code. Do you have a feel for when 1.1.0 will be released? Nothing specific of course, I'm just wondering about a ballpark. Days, months, years. Thanks for your help, -David Mitchell Alan DeKok wrote: David Mitchell <[EMAIL PROTECTED]> wrote: 1) Our tokens display the response in so-called 'phone number' formatting. FreeRadius knows about 4 different CryptoCard formattings according to x99passwd.sample: d7, d8, h7 and h8. Where a response would be formatted as '12345678' in d8 and '1235678' in d7, our tokens display '123-5678'. I was thinking I would either add a new CC encoding setting or modify the module to ignore dashes. But if there is another way I'd love to hear it. I'd add a new encoding. 2) The X99 module, if it is performing a resync, generates a State attribute which the authenticating device is expected to return unadultered in the response packet. However, the value includes NULL values in the middle of it. Our Cisco devices (both IOS and CatalystOS) appear to be using strcpy() Yuck. That's a direct violation of the RFC's. or something similar to copy the State attribute and only return the value up to the embedded NULL as a result. Code already exists in the module to generate an ASCII state value, and I was planning on changing the module so that the ASCII value was always used. My reading of the relevant RFC tells me that this is in fact a Cisco bug, but I have not had good luck in the past convincing Cisco that my interpretation of RFC's is more correct than theirs. File a bug on bugs.freeradius.org that their implementation is broken. Maybe that will get their attention. If you know of a way to work around these without hacking on the code, I'd appreciate knowing about it. Or if you have an opinion about how to best fix the above issues in the code, I'd be interested in that as well. Thanks in advance, For the state problem, just print an ascii state. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
x99 Token Module Problems
Greetings, I'm working on using FreeRadius to authenticate to our Cisco devices using CryptoCards. I've run into a couple of snags which I don't think can be fixed easily via configuration but will require code changes. Before I start doing anything code-wise, I wanted to see if anybody knew of a workaround. 1) Our tokens display the response in so-called 'phone number' formatting. FreeRadius knows about 4 different CryptoCard formattings according to x99passwd.sample: d7, d8, h7 and h8. Where a response would be formatted as '12345678' in d8 and '1235678' in d7, our tokens display '123-5678'. I was thinking I would either add a new CC encoding setting or modify the module to ignore dashes. But if there is another way I'd love to hear it. 2) The X99 module, if it is performing a resync, generates a State attribute which the authenticating device is expected to return unadultered in the response packet. However, the value includes NULL values in the middle of it. Our Cisco devices (both IOS and CatalystOS) appear to be using strcpy() or something similar to copy the State attribute and only return the value up to the embedded NULL as a result. Code already exists in the module to generate an ASCII state value, and I was planning on changing the module so that the ASCII value was always used. My reading of the relevant RFC tells me that this is in fact a Cisco bug, but I have not had good luck in the past convincing Cisco that my interpretation of RFC's is more correct than theirs. If you know of a way to work around these without hacking on the code, I'd appreciate knowing about it. Or if you have an opinion about how to best fix the above issues in the code, I'd be interested in that as well. Thanks in advance, -David Mitchell -- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
