- Freeradius-Users - lists.freeradius.org

TTLS/MSChapv2 Failure
by Andrew 06 Apr '07

06 Apr '07

[sorry for sending the previous email without a subject] When I am goind TTLS/MSChapv2 with wrong username/password comination, I found the FreeRadius server is sending out EAP-Failure message to the Security Supplicant. My question is according to MSChapv2 RFC, a MSChapv2 Failure packet is also supposed to be sent out. Why the MSChapv2 Failure is not sent? Thanks, Andrew -- http://www.fastmail.fm - IMAP accessible web-mail

2 1

None
by Andrew 05 Apr '07

05 Apr '07

When I am goind TTLS/MSChapv2 with wrong username/password comination, I found the FreeRadius server is sending out EAP-Failure message to the Security Supplicant. My question is according to MSChapv2 RFC, a MSChapv2 Failure packet is also supposed to be sent out. Why the MSChapv2 Failure is not sent? Thanks, Andrew -- http://www.fastmail.fm - Does exactly what it says on the tin

1 0

Res: Res: Res: NAS-IP-Address
by Erico Augusto 05 Apr '07

05 Apr '07

Let I explain better ... I'm configuring WPA, so the Access Point sends Access-Request RADIUS packets to freeradius, with the Client-IP-Address 10.10.10.1(that is the Access Point IP Address, configured manually), to authenticate user. freeradius receives Client-IP-Address from Access Point. No doubt about that. All what I'm trying to do is send Client-IP-Address, after DHCP server assigns one to the client(10.10.10.30, for example), via Post-Auth, to my application, so that it can be possible to configure the firewall, allowing the traffic from the host with Client-IP-Address. Thanks, Erico. ----- Mensagem original ---- De: Alan DeKok <aland(a)deployingradius.com> Para: FreeRadius users mailing list <freeradius-users(a)lists.freeradius.org> Enviadas: Quarta-feira, 4 de Abril de 2007 18:27:42 Assunto: Re: Res: Res: NAS-IP-Address Erico Augusto wrote: > during authorize phase, client doesn't have an IP (configure to DHCP), > so the Access-Point fills the Client-IP-Addess with its own > IP(NAS-IP-Address - 10.10.10.1). No. Client-IP-Address is the address of the RADIUS client that sent the UDP packet. It is added by FreeRADIUS, and is internal to the server. It has no meaning outside of FreeRADIUS. The rest of your questions can be answered by saying that the attribute is internal to FreeRADIUS, and isn't what you think it is. Therefore, it doesn't have the problems you think it has. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html __________________________________________________ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/

2 1

problem with freeradius & fedors core 5,6
by Jackson Jerry-NPC637 05 Apr '07

05 Apr '07

Hi I hope I haven't missed something obvious, but am having trouble getting radius to start after /configure/make/make install running Fedora core 5 or 6. This is the error - [root@LinuxServer freeradius-1.1.5]# radiusd -X Starting - reading configuration files ... reread_config: reading radiusd.conf Config: including file: /usr/local/etc/raddb/proxy.conf Config: including file: /usr/local/etc/raddb/clients.conf Config: including file: /usr/local/etc/raddb/snmp.conf Config: including file: /usr/local/etc/raddb/eap.conf Config: including file: /usr/local/etc/raddb/sql.conf Using deprecated naslist file. Support for this will go away soon. read_config_files: reading clients read_config_files: reading realms radiusd: entering modules setup Module: Library search path is /usr/local/lib *** glibc detected *** radiusd: double free or corruption (fasttop): 0x08b30140 *** ======= Backtrace: ========= /lib/libc.so.6[0x8d6f18] /lib/libc.so.6(__libc_free+0x79)[0x8da41d] /usr/local/lib/libltdl.so.3[0x5736bb] /usr/local/lib/libltdl.so.3(lt_dlopenext+0xbe)[0x57404e] radiusd(find_module_instance+0x317)[0xf571a7] radiusd(setup_modules+0x1d8)[0xf57758] radiusd(main+0x45c)[0xf5ad8c] /lib/libc.so.6(__libc_start_main+0xdc)[0x8887e4] radiusd[0xf4ecd1] Thanks for your help. Jerry J.

3 2

FreeBSD FreeRADIUS port updated to 1.1.5, with various enhancements
by David Wood 05 Apr '07

05 Apr '07

Hi all, Whilst this post is mainly aimed at FreeBSD users, I'd be grateful if the developers could cast a glance at the section between the lines of ***. That section contains patches that may be relevant to all FreeRADIUS users and be worth committing to the main FreeRADIUS CVS, also it contains a couple of comments relating to configure. A new version of the FreeBSD FreeRADIUS port has just been committed to the FreeBSD ports tree. Not only is the port now based on FreeRADIUS 1.1.5, there's been various other changes. This has taken rather longer than I'd hoped (pneumonia got in the way - I still don't feel too great), but I hope I've caught up on the backlog of changes people have requested as well as updating the port to 1.1.5. My notes didn't appear in the commit message, and are only in the PR submitting the update. I thought the other changes were worth mentioning here for any discussion and comment. I've gone on a further round of patch removal with this update. Since Alan and the other developers moved to the 'new' build system in 1.1.3, things are much cleaner than was historically the case. Rather than maintaining historic patches, I've chosen to remove them where possible. This seems much better from a maintenance point of view - I would rather have the fewest possible patches, even if I risk breaking things when initially removing a patch. I'd removed the only historic patch that changed the functionality of the server in one of the 1.1.4 releases - from then on, the server you get with the port behaves exactly the same as the server you get if you build FreeRADIUS yourself from source. That patch was pointed out to me as redundant and I had to agree. FreeRADIUS has had with_ntdomain_hack for some time, which allowed for the same end result. This change didn't lead to a single complaint, though it missed the deadline for FreeBSD 6.2-RELEASE (which actually shipped with 1.1.3), so it may be that quite a few users haven't yet caught up with the change. The patches I've removed this time were all build related. I hope I haven't broken the server on non-i386 platforms - if I have, I'm waiting for the PRs, emails of complaint or tinderbox complaining at me! Unfortunately I don't have access to a FreeBSD amd64 box, which is the main non-i386 platform. All I can say is that the server works fine on my FreeBSD 6.2-RELEASE-p2 i386 box, and has done so for a couple of weeks. I was intending to post a candidate port here for more testing (and/or open up my local Subversion repository for public access), but I felt obliged to submit my own update when someone submitted a (slightly flawed) update to 1.1.5 that I refused to approve. If the submitter is reading, you added dictionary.asn to pkg-plist correctly, but failed to add it to the DICTS= line in the Makefile. I may look at changing the Makefile to be more automatic with regard to dictionaries in the future. One group of patches that remain are patches that I believe from the CVS comments are only needed for FreeBSD 4.x. At the moment, I believe files/patch-src-modules-rlm_attr_rewrite-rlm_attr_rewrite.c is only needed for 4.x. The same is true of some of the lines in the port's Makefile. I'm torn as to what to do with these. I don't like gratuitous breakage, but the ports framework no longer supports FreeBSD 4.x, the FreeBSD project regards 4.x as End of Life (whilst it still has its fans, FreeBSD 4.x is quite outdated in various ways), I can't test the server on FreeBSD 4.x and I've had no feedback since 1.1.3 concerning FreeBSD 4.x support. Even if 1.1.4 worked on FreeBSD 4.x, I might have broken FreeBSD 4.x support with the changes I've made in 1.1.5. If that's the case, I'm pretty sure I know which change has broken things, but I'll probably forget pretty soon unless someone complains. I'm now developing the port with the aid of my local Subversion server. This makes tracking my changes rather easier, but even with good log messages, there's limitations on what I can remember after a while. Unless someone contacts me to request otherwise, I'm likely to rip out FreeBSD 4.x support sooner rather than later. It will definitely be removed in any FreeRADIUS 2.x port. My feeling is that I'll probably rip out the 4.x stuff either in a few weeks' time or with the release of a port based on a future FreeRADIUS 1.1.6 release. ************************************************************************ The second group of patches that remain I'm going to post below - because I think they might be candidates for committing to FreeRADIUS itself. It was clearly felt by previous contributors to the port that the Makefiles don't always contain $(CFLAGS) when they would be expected to. It might be that these patches are also unnecessary with the build system used from 1.1.3 onwards - if so, will someone explain why and I'll remove these patches too. I believe they are still needed judging by the output of make, but I'm willing to be corrected (in Alan's gentle style if needs be!). The port uses the FreeBSD ports libtool, not libtool that ships with FreeRADIUS (not that this will necessarily make a difference, but it seemed worth mentioning). --- src/modules/rules.mak.orig Mon Mar 27 15:43:04 2006 +++ src/modules/rules.mak Mon Mar 27 15:44:11 2006 @@ -112,7 +112,7 @@ $(TARGET).la: $(LT_OBJS) $(LIBTOOL) --mode=link $(CC) -release $(RADIUSD_VERSION) \ - -module $(LINK_MODE) $(LDFLAGS) $(RLM_LDFLAGS) -o $@ \ + -module $(LINK_MODE) $(CFLAGS) $(RLM_CFLAGS) $(LDFLAGS) $(RLM_LDFLAGS) -o $@ \ -rpath $(libdir) $^ $(top_builddir)/src/lib/libradius.la \ $(RLM_LIBS) $(LIBS) --- src/modules/rlm_sql/drivers/rules.mak.orig Mon Mar 27 15:39:02 2006 +++ src/modules/rlm_sql/drivers/rules.mak Mon Mar 27 15:39:29 2006 @@ -100,8 +100,8 @@ $(TARGET).la: $(LT_OBJS) $(LIBTOOL) --mode=link $(CC) -release $(RADIUSD_VERSION) \ - -module $(LINK_MODE) $(LDFLAGS) $(RLM_SQL_LDFLAGS) -o $@ \ - -rpath $(libdir) $^ $(RLM_SQL_LIBS) + -module $(LINK_MODE) $(CFLAGS) $(RLM_SQL_LDFLAGS) -o $@ \ + -rpath $(libdir) $^ $(RLM_SQL_LIBS) $(LDFLAGS) ####################################################################### # --- src/main/Makefile.in.orig Wed Feb 14 15:44:23 2007 +++ src/main/Makefile.in Mon Mar 12 13:20:32 2007 @@ -61,9 +61,9 @@ radiusd: $(SERVER_OBJS) $(MODULE_OBJS) ../lib/libradius.la $(LIBTOOL) --mode=link $(CC) -export-dynamic -dlopen self \ - $(LDFLAGS) -pie $(LINK_MODE) -o $@ $(SERVER_OBJS) \ + $(CFLAGS) $(LDFLAGS) -pie $(LINK_MODE) -o $@ $(SERVER_OBJS) \ $(MODULE_LIBS) $(LIBS) $(SNMP_LIBS) $(PTHREADLIB) \ $(LIBLTDL) $(OPENSSL_LIBS) radiusd.lo: radiusd.c ../include/request_list.h ../include/modules.h ../include/modcall.h ../include/modpriv.h $(LIBTOOL) --mode=compile $(CC) $(CFLAGS) -c radiusd.c The patches might well have lost their tabs when posted above - they can be found in the FreeBSD ports tree as /usr/ports/net/freeradius/files/, then patch-src::modules::rules.mak patch-src::modules::rlm_sql::rules.mak and patch-src-main-Makefile.in CVSweb is at http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/freeradius/files There's one patch I wrote, which I think is a bug in a Makefile for 1.1.4 and 1.1.5 (hence the file name of patch-raddb-Makefile-1.1.4_bug): --- raddb/Makefile.orig Mon Apr 10 19:53:20 2006 +++ raddb/Makefile Sun Jan 14 23:10:15 2007 @@ -7,7 +7,7 @@ experimental.conf hints huntgroups ldap.attrmap \ mssql.conf naslist naspasswd oraclesql.conf postgresql.conf \ preproxy_users proxy.conf radiusd.conf realms snmp.conf \ - sql.conf sqlippool.conf users otp.conf otppasswd.sample + sql.conf sqlippool.conf users otp.conf all: otppasswd.sample seems to have disappeared from 1.1.4 onwards - is this a bug in that Makefile as I believe? If so, can that be fixed in CVS? There's two other things I'm currently modifying the source to achieve, on which I'd appreciate comments. patch-doc::Makefile surrounds the contents of the install target in doc/Makefile with #ifndef NOPORTDOCS ... #endif. FreeBSD ports have to respect this flag. Is a neater way to pass --with-docdir=/dev/null to configure if NOPORTDOCS is defined (which I haven't tried) and abandon the patch. Has anyone any other suggestions? I've refined handling of the sample configuration further in 1.1.5. Up to and including the initial release of 1.1.4 it was very unfriendly - the sample configuration was installed with the files suffixed with .sample. I changed this to be a bit more user friendly in a later 1.1.4 release, but there were still .sample files mixed with the 'live' configuration. In the 1.1.5 port, the sample configuration is now installed in ${EXAMPLESDIR}/raddb (default /usr/local/share/examples/freeradius/raddb). These files are not suffixed with .sample as they used to be. The 'live' FreeRADIUS configuration stays in the same location - ${PREFIX}/etc/raddb (default /usr/local/etc/raddb). I had suggested mention of this change was made in /usr/ports/UPDATING, but it didn't happen. I feel this is much neater than the old setup (especially for those of us that have their configuration in some sort of revision control system). You no longer have 'sample' files mixed with live ones in the same directory and diffing your configuration against the sample one is much more straightforward (no need for find, sed and for loops - or equivalent). The port uses some intelligence - when you install it, if a particular file doesn't exist in the 'live' configuration folder, it copies it across from the sample configuration. When you uninstall the port, if a file is identical in the 'live' configuration to the equivalent sample file, the live file is deleted - otherwise it's left alone. This is standard behaviour for FreeBSD ports. Note that this copying / deleting behaviour now extends to raddb/certs and all its contents - which it didn't previously. You can, if you wish, put your own certificates in raddb/certs and the port will now leave them alone - though my preferred solution is to use a separate folder (raddb/mycerts on my installation). I probably should have added some further code to chmod the files in the 'live' configuration appropriately on installation - I'll consider that for a future release of the port. To install the sample raddb files in the correct location, I'm running sed across all Makefile and Makefile.in files, replacing $(R)$(raddbdir) with the appropriate location. I'd rather do this via configure, but if I use --with-raddbdir, that changes the install location of the files *and* the default location the server looks for those files. The latter change isn't wanted. I'd somehow missed the -d flag to radiusd - even though I'd gone looking for it and it's staring at me in man 8 radiusd. I could change the port to use --with-raddbdir pointing at to the sample location, then have radiusd.sh.in using -d defaulting to the 'live' location (but being changeable via an option in /etc/rc.conf). At that point, I can ditch the sed stuff. The fewer changes to the source, the happier I am. However, it would still be nice to have the default location correct in radiusd, otherwise people using radiusd -X won't realise that that starts FreeRADIUS with the sample configuration, not the live one (this seems a really bad idea!). I could look at supporting a debug option to the rc.d script - but would people know to use it? Is it possible to have a configuration option that sets the default configuration directory for radiusd separately to the value of --with-raddbdir (but if not issued, it defaults to raddbdir). That would be the best solution, rather than patching the source. I'll have a go at this patch if nobody else is interested - so long as the developers are happy to merge that patch into HEAD when it's done (I'd work against 1.1.5). ************************************************************************ The other changes relate purely to FreeBSD. Firstly, as requested here by Mike Jakubik, I'm now automagically configuring the REQUIRES line of the rc.d script for FreeRADIUS to add dependencies on OpenLDAP, MySQL and PostgreSQL if the appropriate options are enabled when the port is built. Mike - I hope it works - I had to remove the old BEFORE: DAEMON stipulation to avoid circular dependencies in rcorder as we discussed here on freeradius-users. I'm really not sure why BEFORE: DAEMON was the default. Other similar ports don't have it, so I took the decision to remove it. Removing it might break some people's setups (depending on how they're using FreeRADIUS), but I'll wait for the complaints and, if necessary, support the 'old' situation via an option. I hope that I've helped more people than I've hindered. The 'recovery' code that's been added to CVS for offline SQL servers will help when it appears in 1.1.6, but I still would rather have the correct dependencies for rcorder. On that note, Alexander Klepikov - I did consider your patch, but decided that as Alan finished up committing a rather more extensive change to the behaviour of rlm_sql to FreeRADIUS CVS, which I didn't really want to backport to 1.1.5. I'm afraid it's going to be a case of waiting until 1.1.6 is released. One possible future project is to add optional support to the port to build from a CVS checkout of branch_1_1 or a CVS snapshot. Is anyone interested? If I'm going to consider this, I need to minimise the number of patches first for such a feature to have the best chance of success. Following a request from a developer working on one of the firewall / router products that's FreeBSD based, I've added a freeradius-mysql slave port. This is exactly the same as the main freeradius port, except that MySQL support is always configured on (and isn't, therefore, available as an OPTION). I suggest people keep using net/freeradius, turning on the MySQL option if they need it. The slave port is simply to ensure that there will be a freeradius-mysql package on the FreeBSD FTP servers which contains MySQL support for rlm_sql as well as the rest of FreeRADIUS. (Unlike on some Linux distributions, the packages that result from this sort of slave port are complete - they don't just contain the 'extra' files to add to the same version of the server). I've added support for the Firebird module - but judging by the comments in the FreeRADIUS CVS, I'm not sure whether this will work until 1.1.6 is released. It appears to compile and install - but I can't test it. I've tidied up the SQL sections of the port's Makefile - this was really just to add robustness, but it seemed worth doing whilst I was adding Firebird support. Finally, there's two minor changes I didn't document anywhere else. I found and fixed one SQL related glitch in pkg-plist - I wonder if anyone noticed (I'm not sure how many versions that problem was there for, but it predated 1.1.5). I've also moved to using the .tar.bz2 tarball - downloading smaller files from the FTP servers seemed to make sense. If this is less 'official' than the .tar.gz, I'll change back. Apart from automatic chmodding of files in raddb on installing the port (by this I mean running a chmod g-w,o-rwx on the files in raddb), which I will consider adding, as well as trying the two changes I comment on above that avoid patching the source, is there anything else I've missed or that people want to suggest for the FreeBSD port? Is there any interest in access to my local Subversion repository and/or ViewVC for the port? If someone makes a case, I'd propose that such access would be read only. However, if someone wants to make a case for write access, especially if that person is a FreeRADIUS developer, I am prepared to listen. Write access would require a client certificate from CAcert. There's no need to have your name assured with CAcert, as the Subversion setup uses the email address that is in all CAcert client certificates as the user name - but if you have your real name in the certificate, it makes my logging tidier. I may also add support for Thawte Freemail client certificates (especially as I regard Thawte's system as that bit more robust than CAcert). Best wishes, David -- David Wood david(a)wood2.org.uk

3 8

Re : Re : EAP/TTLS PEAP MSCHAP
by Eshun Benjamin 05 Apr '07

05 Apr '07

Thanks I can connect windows with PEAP/ MSCHAPv2 . Need to fix the certificates. ================================================== Benjamin K. Eshun ----- Message d'origine ---- De : Arran Cudbard-Bell <A.Cudbard-Bell(a)sussex.ac.uk> À : FreeRadius users mailing list <freeradius-users(a)lists.freeradius.org> Envoyé le : Mercredi, 4 Avril 2007, 23h16mn 24s Objet : Re: Re : EAP/TTLS PEAP MSCHAP Ian Truelsen wrote: > On Wed, 2007-04-04 at 20:58 +0100, Arran Cudbard-Bell wrote: > >> According to the microsoft support article >> (http://support.microsoft.com/kb/814394/en-us) >> >> "The IAS or the VPN server computer certificate is configured with the >> Server Authentication purpose. The object identifier for Server >> Authentication is 1.3.6.1.5.5.7.3.1." >> >> But I have no idea how to add it to the certificate, if you find out >> please let me know :) >> >> > Check out this article: > > http://www.linuxjournal.com/article/8095 > > It explains how to get the MS attributes into the certificates. > > Hope this helps. > Excellent, thanks, just what I was looking for :) Is it really just as simple as creating the certificate, signing it with the right extensions, installing the proper rootCA on the windows machines , and configuring the windows supplicant correctly ? Which would be In authentication tab Enable IEEE 802.1x authentication for this network Setting EAP Type to PEAP In properties Validate server certificate Authentication method EAP-MSCHAP v2 Checking the Root CA the certificate was signed with . In Configure Automatically use my windows logo name and password unchecked. Or are there more weird windows things ? Gah... never appreciated Mac OSX so much. "oo looks like your connecting to an 802.11x network , please enter your username and password, hmm you havent chosen to explicitly trust this certificate would you like to ? .... Connected!"..... "and now i'm going to save your username and password in the keychain so you'll never have to go through this amazingly simple process ever again". --- Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com

1 0

Res: Res: NAS-IP-Address
by Erico Augusto 04 Apr '07

04 Apr '07

during authorize phase, client doesn't have an IP (configure to DHCP), so the Access-Point fills the Client-IP-Addess with its own IP(NAS-IP-Address - 10.10.10.1). Note that during authorize FreeRADIUS sends 10.10.10.1(NAS-IP) as Client-IP, and during Post-Auth, 127.0.0.1 ... I'm sure that there is anything configured to do that. Isn't that a possible reason to FreeRADIUS send a loopback IP at Client-IP-Address Attribute in Post-Auth phase? Thanks a lot... Erico. ----- Mensagem original ---- De: Internet-Wifi Operador <internet-wifi(a)hotmail.com> Para: freeradius-users(a)lists.freeradius.org Enviadas: Quarta-feira, 28 de Março de 2007 3:30:52 Assunto: RE: Res: NAS-IP-Address something more freeradius don't put this any IP in NAS-IP-Value this value come from the clliente (NAS) Fabián >From: Erico Augusto <ericosign(a)yahoo.com.br> >Reply-To: FreeRadius users mailing list ><freeradius-users(a)lists.freeradius.org> >To: FreeRadius users mailing list <freeradius-users(a)lists.freeradius.org> >Subject: Res: NAS-IP-Address >Date: Tue, 27 Mar 2007 21:24:38 -0700 (PDT) > >well, I don't know what chillispot means until now ... googling it I can >say that my application acts like that. >why? >thanks, Erico. > >----- Mensagem original ---- >De: Internet-Wifi Operador <internet-wifi(a)hotmail.com> >Para: freeradius-users(a)lists.freeradius.org >Enviadas: Terça-feira, 27 de Março de 2007 15:37:03 >Assunto: RE: NAS-IP-Address > >Hi, >Are you using Chillispot or something like that? > > > >Fabián > > > > > > >From: Erico Augusto <ericosign(a)yahoo.com.br> > >Reply-To: FreeRadius users mailing list > ><freeradius-users(a)lists.freeradius.org> > >To: freeradius-users(a)lists.freeradius.org > >Subject: NAS-IP-Address > >Date: Tue, 27 Mar 2007 11:14:19 -0700 (PDT) > > > >Hi, > > > >i) during Authentication phase, NAS-IP-Address attribute is filled with > >correct IP. > >During Post-Auth, NAS-IP-Address is filled with loopback 127.0.0.1 >Address > >... > >Is it possible to send the correct NAS-IP-Address during Post-Auth? How >is > >it possible? > > > >Thanks, Erico. > > > > > > > > > > > > > >__________________________________________________ > >Fale com seus amigos de graça com o novo Yahoo! Messenger > >http://br.messenger.yahoo.com/ > > > >- > >List info/subscribe/unsubscribe? See > >http://www.freeradius.org/list/users.html > >_________________________________________________________________ >Exercise your brain! Try Flexicon. >http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglinema… > > >- >List info/subscribe/unsubscribe? See >http://www.freeradius.org/list/users.html > > > > > >__________________________________________________ >Fale com seus amigos de graça com o novo Yahoo! Messenger >http://br.messenger.yahoo.com/ >- >List info/subscribe/unsubscribe? See >http://www.freeradius.org/list/users.html _________________________________________________________________ 5.5%* 30 year fixed mortgage rate. Good credit refinance. Up to 5 free quotes - *Terms https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&searc… - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html __________________________________________________ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/

2 1

EAP/TTLS PEAP MSCHAP
by Eshun Benjamin 04 Apr '07

04 Apr '07

Mac connects but ms windows does not. I am doing server side cert. Error from ms windows. User-Name = "testgeneral" NAS-IP-Address = 10.1.5.26 Called-Station-Id = "0016014d9158" Calling-Station-Id = "0019e3034ceb" NAS-Identifier = "0016014d9158" NAS-Port = 36 Framed-MTU = 1400 State = 0x3d946123f5f422f576bed1eb52863e55 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0202005019800000004616030100410100003d030146139aedbfdec7d57168bf7fdbe984cfd19f5d1e7c13ee839e4b0a55d34aa86600001600040005000a000900640062000300060013001200630100 Message-Authenticator = 0x3efce19c566f372e8744589f65d58401 Wed Apr 4 14:32:48 2007 : Debug: Processing the authorize section of radiusd.conf Wed Apr 4 14:32:48 2007 : Debug: modcall: entering group authorize for request 74 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: calling preprocess (rlm_preprocess) for request 74 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: returned from preprocess (rlm_preprocess) for request 74 Wed Apr 4 14:32:48 2007 : Debug: modcall[authorize]: module "preprocess" returns ok for request 74 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: calling mschap (rlm_mschap) for request 74 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: returned from mschap (rlm_mschap) for request 74 Wed Apr 4 14:32:48 2007 : Debug: modcall[authorize]: module "mschap" returns noop for request 74 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: calling suffix (rlm_realm) for request 74 Wed Apr 4 14:32:48 2007 : Debug: rlm_realm: No '@' in User-Name = "testgeneral", looking up realm NULL Wed Apr 4 14:32:48 2007 : Debug: rlm_realm: No such realm "NULL" Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: returned from suffix (rlm_realm) for request 74 Wed Apr 4 14:32:48 2007 : Debug: modcall[authorize]: module "suffix" returns noop for request 74 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: calling eap (rlm_eap) for request 74 Wed Apr 4 14:32:48 2007 : Debug: rlm_eap: EAP packet type response id 2 length 80 Wed Apr 4 14:32:48 2007 : Debug: rlm_eap: No EAP Start, assuming it's an on-going EAP conversation Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: returned from eap (rlm_eap) for request 74 Wed Apr 4 14:32:48 2007 : Debug: modcall[authorize]: module "eap" returns updated for request 74 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: calling files (rlm_files) for request 74 Wed Apr 4 14:32:48 2007 : Debug: users: Matched entry testgeneral at line 216 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: returned from files (rlm_files) for request 74 Wed Apr 4 14:32:48 2007 : Debug: modcall[authorize]: module "files" returns ok for request 74 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: calling etc_smbpasswd (rlm_passwd) for request 74 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: returned from etc_smbpasswd (rlm_passwd) for request 74 Wed Apr 4 14:32:48 2007 : Debug: modcall[authorize]: module "etc_smbpasswd" returns notfound for request 74 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: calling pap (rlm_pap) for request 74 Wed Apr 4 14:32:48 2007 : Debug: rlm_pap: Found existing Auth-Type, not changing it. Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: returned from pap (rlm_pap) for request 74 Wed Apr 4 14:32:48 2007 : Debug: modcall[authorize]: module "pap" returns noop for request 74 Wed Apr 4 14:32:48 2007 : Debug: modcall: leaving group authorize (returns updated) for request 74 Wed Apr 4 14:32:48 2007 : Debug: rad_check_password: Found Auth-Type EAP Wed Apr 4 14:32:48 2007 : Debug: auth: type "EAP" Wed Apr 4 14:32:48 2007 : Debug: Processing the authenticate section of radiusd.conf Wed Apr 4 14:32:48 2007 : Debug: modcall: entering group authenticate for request 74 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authenticate]: calling eap (rlm_eap) for request 74 Wed Apr 4 14:32:48 2007 : Debug: rlm_eap: Request found, released from the list Wed Apr 4 14:32:48 2007 : Debug: rlm_eap: EAP/peap Wed Apr 4 14:32:48 2007 : Debug: rlm_eap: processing type peap Wed Apr 4 14:32:48 2007 : Debug: rlm_eap_peap: Authenticate Wed Apr 4 14:32:48 2007 : Debug: rlm_eap_tls: processing TLS Wed Apr 4 14:32:48 2007 : Debug: rlm_eap_tls: Length Included Wed Apr 4 14:32:48 2007 : Debug: eaptls_verify returned 11 Wed Apr 4 14:32:48 2007 : Debug: (other): before/accept initialization Wed Apr 4 14:32:48 2007 : Debug: TLS_accept: before/accept initialization Wed Apr 4 14:32:48 2007 : Debug: rlm_eap_tls: <<< TLS 1.0 Handshake [length 0041], ClientHello Wed Apr 4 14:32:48 2007 : Debug: TLS_accept: SSLv3 read client hello A Wed Apr 4 14:32:48 2007 : Debug: rlm_eap_tls: >>> TLS 1.0 Handshake [length 004a], ServerHello Wed Apr 4 14:32:48 2007 : Debug: TLS_accept: SSLv3 write server hello A Wed Apr 4 14:32:48 2007 : Debug: rlm_eap_tls: >>> TLS 1.0 Handshake [length 038f], Certificate Wed Apr 4 14:32:48 2007 : Debug: TLS_accept: SSLv3 write certificate A Wed Apr 4 14:32:48 2007 : Debug: rlm_eap_tls: >>> TLS 1.0 Handshake [length 0004], ServerHelloDone Wed Apr 4 14:32:48 2007 : Debug: TLS_accept: SSLv3 write server done A Wed Apr 4 14:32:48 2007 : Debug: TLS_accept: SSLv3 flush data Wed Apr 4 14:32:48 2007 : Error: TLS_accept:error in SSLv3 read client certificate A Wed Apr 4 14:32:48 2007 : Error: rlm_eap: SSL error error:00000000:lib(0):func(0):reason(0) Wed Apr 4 14:32:48 2007 : Debug: In SSL Handshake Phase Wed Apr 4 14:32:48 2007 : Debug: In SSL Accept mode Wed Apr 4 14:32:48 2007 : Debug: eaptls_process returned 13 Wed Apr 4 14:32:48 2007 : Debug: rlm_eap_peap: EAPTLS_HANDLED Wed Apr 4 14:32:48 2007 : Debug: modsingle[authenticate]: returned from eap (rlm_eap) for request 74 Wed Apr 4 14:32:48 2007 : Debug: modcall[authenticate]: module "eap" returns handled for request 74 Wed Apr 4 14:32:48 2007 : Debug: modcall: leaving group authenticate (returns handled) for request 74 Sending Access-Challenge of id 0 to 10.1.5.26 port 2048 EAP-Message = 0x010303f21900160301004a02000046030146139af0c3e704b47f4b6b436a8b07d916c60b21a951af6c2918a39cadca6aa22013971c62e79c9f9f6e232f6d035b7705438843f46c8e38f788750500db6621bf000400160301038f0b00038b00038800038530820381308202eaa003020102020900e8e427c494215d09300d06092a864886f70d0101050500308188310b30090603550406130244453110300e060355040813075361636873656e3110300e060355040713074472657364656e3110300e060355040a13074d50492d4342473111300f060355040b1308436f6d7075746572310f300d06035504031306736572766572311f301d06092a86 EAP-Message = 0x4886f70d010901161061646d696e406d70692d6362672e6465301e170d3037303332343131313731395a170d3130303332333131313731395a308188310b30090603550406130244453110300e060355040813075361636873656e3110300e060355040713074472657364656e3110300e060355040a13074d50492d4342473111300f060355040b1308436f6d7075746572310f300d06035504031306736572766572311f301d06092a864886f70d010901161061646d696e406d70692d6362672e646530819f300d06092a864886f70d010101050003818d0030818902818100ac1158639bcdf711751f54bdf25c666d6f3a532967a7cba624a5167b EAP-Message = 0xfb5c89d5a3f9d86fe9a7a2b0899925a4373725bed9eb20d41f05019541ee096201bb57b8f01646ac62884f36d54ea32620a11c760e769ace49d8d7dc42b3ba35c6d410b2fddbc2d689536f66646e94f594b516cb5b312f96f562529bcd7015540fd2be7d0203010001a381f03081ed301d0603551d0e041604141acd4d6d72dc026df7d0a5e77ea636e2c9bcfd4f3081bd0603551d230481b53081b280141acd4d6d72dc026df7d0a5e77ea636e2c9bcfd4fa1818ea4818b308188310b30090603550406130244453110300e060355040813075361636873656e3110300e060355040713074472657364656e3110300e060355040a13074d50492d4342 EAP-Message = 0x473111300f060355040b1308436f6d7075746572310f300d06035504031306736572766572311f301d06092a864886f70d010901161061646d696e406d70692d6362672e6465820900e8e427c494215d09300c0603551d13040530030101ff300d06092a864886f70d0101050500038181009e5e89fa8a5e26ce9710bfde499a2b36d412f5acff40b544eec4839a67b768e6a778a5b8d54c8ad8b3ec8f438e96e0740103cbdb3e64c751e722e2c3538dccac3a993b94824ba4e48ba40ebc5c7b37c5c6048616f3b10d7f3d4b23cd84cd1e3e4b318e75d4fcd637ee1b5f263cd4adb006a80f62639825f6fb1a284e254a89be16030100040e000000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x4e138cc588a831123b8c899c1e03c4fc Wed Apr 4 14:32:48 2007 : Debug: Finished request 74 Wed Apr 4 14:32:48 2007 : Debug: Going to the next request Wed Apr 4 14:32:48 2007 : Debug: rl_next: returning NULL Wed Apr 4 14:32:48 2007 : Debug: Waking up in 6 seconds... rad_recv: Access-Request packet from host 10.1.5.26:2048, id=0, length=143 User-Name = "testgeneral" NAS-IP-Address = 10.1.5.26 Called-Station-Id = "0016014d9158" Calling-Station-Id = "0019e3034ceb" NAS-Identifier = "0016014d9158" NAS-Port = 36 Framed-MTU = 1400 State = 0x4e138cc588a831123b8c899c1e03c4fc NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020300061900 Message-Authenticator = 0xf89ebcfef5ea8e2a15b9fc63884890df Wed Apr 4 14:32:48 2007 : Debug: Processing the authorize section of radiusd.conf Wed Apr 4 14:32:48 2007 : Debug: modcall: entering group authorize for request 75 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: calling preprocess (rlm_preprocess) for request 75 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: returned from preprocess (rlm_preprocess) for request 75 Wed Apr 4 14:32:48 2007 : Debug: modcall[authorize]: module "preprocess" returns ok for request 75 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: calling mschap (rlm_mschap) for request 75 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: returned from mschap (rlm_mschap) for request 75 Wed Apr 4 14:32:48 2007 : Debug: modcall[authorize]: module "mschap" returns noop for request 75 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: calling suffix (rlm_realm) for request 75 Wed Apr 4 14:32:48 2007 : Debug: rlm_realm: No '@' in User-Name = "testgeneral", looking up realm NULL Wed Apr 4 14:32:48 2007 : Debug: rlm_realm: No such realm "NULL" Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: returned from suffix (rlm_realm) for request 75 Wed Apr 4 14:32:48 2007 : Debug: modcall[authorize]: module "suffix" returns noop for request 75 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: calling eap (rlm_eap) for request 75 Wed Apr 4 14:32:48 2007 : Debug: rlm_eap: EAP packet type response id 3 length 6 Wed Apr 4 14:32:48 2007 : Debug: rlm_eap: No EAP Start, assuming it's an on-going EAP conversation Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: returned from eap (rlm_eap) for request 75 Wed Apr 4 14:32:48 2007 : Debug: modcall[authorize]: module "eap" returns updated for request 75 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: calling files (rlm_files) for request 75 Wed Apr 4 14:32:48 2007 : Debug: users: Matched entry testgeneral at line 216 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: returned from files (rlm_files) for request 75 Wed Apr 4 14:32:48 2007 : Debug: modcall[authorize]: module "files" returns ok for request 75 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: calling etc_smbpasswd (rlm_passwd) for request 75 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: returned from etc_smbpasswd (rlm_passwd) for request 75 Wed Apr 4 14:32:48 2007 : Debug: modcall[authorize]: module "etc_smbpasswd" returns notfound for request 75 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: calling pap (rlm_pap) for request 75 Wed Apr 4 14:32:48 2007 : Debug: rlm_pap: Found existing Auth-Type, not changing it. Wed Apr 4 14:32:48 2007 : Debug: modsingle[authorize]: returned from pap (rlm_pap) for request 75 Wed Apr 4 14:32:48 2007 : Debug: modcall[authorize]: module "pap" returns noop for request 75 Wed Apr 4 14:32:48 2007 : Debug: modcall: leaving group authorize (returns updated) for request 75 Wed Apr 4 14:32:48 2007 : Debug: rad_check_password: Found Auth-Type EAP Wed Apr 4 14:32:48 2007 : Debug: auth: type "EAP" Wed Apr 4 14:32:48 2007 : Debug: Processing the authenticate section of radiusd.conf Wed Apr 4 14:32:48 2007 : Debug: modcall: entering group authenticate for request 75 Wed Apr 4 14:32:48 2007 : Debug: modsingle[authenticate]: calling eap (rlm_eap) for request 75 Wed Apr 4 14:32:48 2007 : Debug: rlm_eap: Request found, released from the list Wed Apr 4 14:32:48 2007 : Debug: rlm_eap: EAP/peap Wed Apr 4 14:32:48 2007 : Debug: rlm_eap: processing type peap Wed Apr 4 14:32:48 2007 : Debug: rlm_eap_peap: Authenticate Wed Apr 4 14:32:48 2007 : Debug: rlm_eap_tls: processing TLS Wed Apr 4 14:32:48 2007 : Debug: rlm_eap_tls: Received EAP-TLS ACK message Wed Apr 4 14:32:48 2007 : Debug: rlm_eap_tls: ack handshake fragment handler Wed Apr 4 14:32:48 2007 : Debug: eaptls_verify returned 1 Wed Apr 4 14:32:48 2007 : Debug: eaptls_process returned 13 Wed Apr 4 14:32:48 2007 : Debug: rlm_eap_peap: EAPTLS_HANDLED Wed Apr 4 14:32:48 2007 : Debug: modsingle[authenticate]: returned from eap (rlm_eap) for request 75 Wed Apr 4 14:32:48 2007 : Debug: modcall[authenticate]: module "eap" returns handled for request 75 Wed Apr 4 14:32:48 2007 : Debug: modcall: leaving group authenticate (returns handled) for request 75 ================================================== Benjamin K. Eshun ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com

2 1

question about freeradius, 802.1x with peap, auth via LDAP
by wenny wang 04 Apr '07

04 Apr '07

Hi, I need help/advise with te following scenario: 1. I have a freeradius server, this server is not part of Active Directory Domain, server is able to perform ldapsearch for user account. 2. the workstation is a windows 2000 pc, need to be authenticated thru Cisco catalyst switch to the freeradius server with user's LAN username and password transparently (peap) my question is: what is the requirement for radius server, does the server needs to be part of the Active Directory Domain?, can you direct me to a how to link?, I have made several configurations but none were successful, please help, thanks.

3 2

Duplicate accounting log entries
by Patric 04 Apr '07

04 Apr '07

Hi guys, Hope someone can help, as this has me banging my head on the wall :] I am getting duplicate updates from my NAS, and Im trying to figure out how to prevent them from being written to my accounting logs table. I unfortunately have absolutely no control over the NAS, so thats not even an option. What I want to do is make the acct_session_id or acct_unique_id fields unique, or even make a composite key of them both, but I have found entries in my table where the following happens: This scenario is with DSL accounts: I have 3 records for 3 different users all with the same acct_session_id. 2 of these records have the same acct_unique_id, and the 3rd has a different acct_unique_id. Everything else in the records is identical. If I make a composite key combining the session and unique id's I will get rid 1 of the 2 records that have the same unique id, but I will still be sitting with 2 duplicate entries, each with a different unique id. I then thought to make the acct_session_id unique, which would solve the above scenario, but then I came across another problem. This scenario deals with dialup accounts: I have 2 records with the same acct_session_id but they are for 2 different users. Each record has a different acct_unique_id though. So if I make a composite key combining the session and unique id's both these records will exist, which is correct as they are for 2 different users. If I make only the acct_session_id unique to solve the DSL problem above, then one of these records wont be inserted, and an update will occur instead, as per the alternate accounting query. Am I missing something? Is there any other way to do this? I do not know why I am getting duplicate acct_session_id's from my NAS, but as I said there is no way for me to go that route... Any help or guidance would REALLY be appreciated! Thanks Patrick

3 9