Microsoft PEAP
I have already testet freeRADIUS with EAP-TLS and it worked fine. Now I also want to offer PEAP authentication. How far is it implemented in freeradius now? Is it possible to use it with about 200 clients or should I wait till the code is more stable? Thanks Berndt - TGM - Die Schule der Technik IT-Service A-1200 Wien, Wexstr. 19-23 Tel. +43(1)33126/316 Fax: +43(1)33126/154 E-Mail: [EMAIL PROTECTED] - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with attr_filter
On Sat, 13 Dec 2003 15:09:03 -0500
Alan DeKok [EMAIL PROTECTED] wrote:
Stephan von Krawczynski [EMAIL PROTECTED] wrote:
1) It does not recognize at all vendor specific attributes. The reason is
this code part taken from src/modules/rlm_attr_filter/rlm_attr_filter.c :
...
if(reply_item-attribute == check_item-attribute) {
Unfortunately check_item-attribute contains the vendor id and therefore
can never match the reply_item-attribute which does not contain vendor
info.
Huh? I don't see why that would be true. If the standard API's are
used to create VP's, then the 'attribute' entry ALWAYS contains the
vendor information.
Hm, this was my first thought, too. But I checked the incoming data via tcpdump
as a hexdump and had to find out that there was no vendor info.
This can be dealt with through adding a 0xFF. My test shows that
this works out.
Except for USR VSA's. They need 0x. See the other code in
rlm_attr_filter.c.
2) Unfortunately this brings up another issue, the item_type seems to be
incorrect. Testing the stuff above shows server reply containing:
X-Ascend-IPX-Alias = 3134307025
which obviously :-) reads bad1bad1 in hex.
See src/lib/radiusd.c. The attribute in the *packet* is supposed to
have 4 octets of data, but doesn't.
That looks to me like the dictionaries on the server and the client
disagree about what type that attribute is.
In fact this citation of mine was a bit irritating, the output was generated by
radtest, but radtest falsely interpreted the vendor which was no Ascend but
Bintec. On Bintec this attribute is STRING. So besides the major vendor id
problem, there was a problem with interpreting the attribute without vendor
knowledge. This led me to the patch described below, which is just ugly.
You also haven't said *where* this attribute is coming from.
Knowing that would help.
This is the funny part: I have two setups that produce packets without vendor
ids, first is freeradius-0.8.1 (I really checked the dictionary on this one,
the ID is in the dictionary, but packets do not contain any). The second is
some SGI-based radius server I have no hands on. This one neither sends
vendor info and was configured for completely different clients than the
freeradius installation. So basically we have incoming proxy-packets for two
different vendors from two very different installations, both containing no
vendor info at all.
I made a patch to replace the attribute from reply_item with the one from
check_item before copying it to reply_tmp, but that is a real hack. I wonder if
there is a clean solution at all, though...
--
Regards,
Stephan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
freebsd vs. wireless 802.1x
Hi, all I just got freeradius work with 802.1x working recently. But I have some questions left. 1. My client is a notebook running windows xp. I can establish connection to AP using predefined key or just check 'the key is provided for me automatically'. My question is the key radius send to AP and client. How do those key generated? Will the key changed after a period just like IPSEC rekey function? 2. I enabled radius accounting. Only start record in detail file but no stop record. It looks like this: Sun Dec 14 15:37:49 2003 User-Name = xyz Class = 0x Acct-Session-Id = 61 Acct-Status-Type = Start NAS-IP-Address = a.b.c.d Client-IP-Address = a.b.c.d Acct-Unique-Session-Id = 47da917536dd15e1 Timestamp = 1071387469 Sun Dec 14 15:40:55 2003 User-Name = xyz Class = 0x Acct-Session-Id = 61 Acct-Status-Type = 0 Acct-Terminate-Cause = Idle-Timeout NAS-IP-Address = a.b.c.d Client-IP-Address = a.b.c.d Acct-Unique-Session-Id = 47da917536dd15e1 Timestamp = 1071387655 What is this 'Acct-Status-Type = 0' record? Can I get bytes transfered during this session like dialup record? Thanks, - Yahoo! http://tw.promo.yahoo.com/mail_premium/stationery.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with attr_filter
Stephan von Krawczynski [EMAIL PROTECTED] wrote: Huh? I don't see why that would be true. If the standard API's are used to create VP's, then the 'attribute' entry ALWAYS contains the vendor information. Hm, this was my first thought, too. But I checked the incoming data via tcpdump as a hexdump and had to find out that there was no vendor info. sigh Could you please stick to one topic? You originally said that in the SERVER, the DATA STRUCTURES didn't have the vendor information. I was confused, because that's pretty much impossible. Now, you change your mind, and say something else, about tcpdump. Stop it. It's annoying, and it makes me inclined to ignore you, until you have a consistent story. In fact this citation of mine was a bit irritating, the output was generated by radtest, but radtest falsely interpreted the vendor which was no Ascend but Bintec. Then you're *very* confused. Go read the dictionary.ascend file. Both vendors are idiots, and have put their attributes into the base 256 attributes, rather than using VSA's. THAT'S why you didn't see a vendor Id: They weren't using VSA's. If you had said that in the first place, it would have helped significantly. On Bintec this attribute is STRING. So besides the major vendor id problem, there was a problem with interpreting the attribute without vendor knowledge. This led me to the patch described below, which is just ugly. Don't bother with any patch. Fix the client so it works. Fix the client so it sends VSA's. This is the funny part: I have two setups that produce packets without vendor ids, first is freeradius-0.8.1 (I really checked the dictionary on this one, the ID is in the dictionary, but packets do not contain any). I doubt that very much. The second is some SGI-based radius server I have no hands on. This one neither sends vendor info and was configured for completely different clients than the freeradius installation. So basically we have incoming proxy-packets for two different vendors from two very different installations, both containing no vendor info at all. See? Both vendors are stupid and broken. I made a patch to replace the attribute from reply_item with the one from check_item before copying it to reply_tmp, but that is a real hack. I wonder if there is a clean solution at all, though... That change has absolutely irrelevant for the problem at hand. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freebsd vs. wireless 802.1x
=?big5?q?Vincent=20Chen?= [EMAIL PROTECTED] wrote: 1. My client is a notebook running windows xp. I can establish connection to AP using predefined key or just check 'the key is provided for me automatically'. My question is the key radius send to AP and client. How do those key generated? Will the key changed after a period just like IPSEC rekey function? If you use PEAP, the keys are generated as part of the PEAP authenticaion process. The keys will be rotated, if you set a Session-Timeout, to make the user re-authenticate. 2. I enabled radius accounting. Only start record in detail file but no stop record. It looks like this: shrug See the FAQ. If the NAS/client doesn't send a stop record, there's nothing the server can do about it. What is this 'Acct-Status-Type = 0' record? See the RFC's. http://www.freeradius.org/rfc/atributes.html It doesn't officially exist, so no one knows what it's supposed to be. Can I get bytes transfered during this session like dialup record? Read the FAQ. The server can't log what isn't sent by the NAS. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with attr_filter
On Sun, 14 Dec 2003 09:15:55 -0500 Alan DeKok [EMAIL PROTECTED] wrote: Stephan von Krawczynski [EMAIL PROTECTED] wrote: Huh? I don't see why that would be true. If the standard API's are used to create VP's, then the 'attribute' entry ALWAYS contains the vendor information. Hm, this was my first thought, too. But I checked the incoming data via tcpdump as a hexdump and had to find out that there was no vendor info. sigh Could you please stick to one topic? You originally said that in the SERVER, the DATA STRUCTURES didn't have the vendor information. I was confused, because that's pretty much impossible. Now, you change your mind, and say something else, about tcpdump. Stop it. It's annoying, and it makes me inclined to ignore you, until you have a consistent story. Sorry Alan, your pretty much in the woods. I try to explain again the setup router | proxy radius server freeradius 0.9.3 /\ client 1 radius server client radius server freeradius 0.8.1SGI-based Now I have several ways to check out what is happening: 1) tcpdump on proxy-server for both client incoming packets (these show _no_ vendor info) 2) tcpdump on proxy-server for router side (these show vendor info if I patch freeradius as explained in former post. no vendor-specific attributes go through the attr_filter if I don't patch) 3) if I don't use attr_filtering (post-proxy) at all, then obviously all attributes go through, and have (of course) no vendor info. Hope this describes the situation a bit clearer. Regards, Stephan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with attr_filter
On Sun, 14 Dec 2003 09:15:55 -0500 Alan DeKok [EMAIL PROTECTED] wrote: Then you're *very* confused. Go read the dictionary.ascend file. Both vendors are idiots, and have put their attributes into the base 256 attributes, rather than using VSA's. THAT'S why you didn't see a vendor Id: They weren't using VSA's. If you had said that in the first place, it would have helped significantly. Unfortunately it would not, because either they are using vendor info or not, but the situation while comparing in rlm_attr_filter is that the reply_item has no vendor info, whereas the check_item (remember: from _same_ vendor!) has one. And _that_ is the primary problem. Thinking about it another possible solution may be to create a patch-dictionary where the attributes contain no vendor info and use these in attr_filter. That sounds like a reasonable no-source-patch solution to this problem. Regards, Stephan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with attr_filter
Stephan von Krawczynski [EMAIL PROTECTED] wrote: THAT'S why you didn't see a vendor Id: They weren't using VSA's. If you had said that in the first place, it would have helped significantly. Unfortunately it would not, If you know more about RADIUS the server than I do, why are you asking questions? Are you going to believe me, or are you going to keep telling me I'm wrong? but the situation while comparing in rlm_attr_filter is that the reply_item has no vendor info, whereas the check_item (remember: from _same_ vendor!) has one. And _that_ is the primary problem. Absolutely not. You haven't understood what I'm saying. To repeat in short, simple, words: Vendor attributes are different from non-vendor attributes. If the names look similar to you, that's an illusion, and has nothing to do with the problem at hand. If the attribute numbers look similar, that, too, is unimportant. The attributes are different. One is a VSA, and the other is not. The code will never be able to compare them as identical, because they're not identical. The RADIUS packet itself says they're different, so the server treats them as different. There will be NO patches going into the server to fix this problem. Thinking about it another possible solution may be to create a patch-dictionary where the attributes contain no vendor info and use these in attr_filter. That sounds like a reasonable no-source-patch solution to this problem. Nonsense. Total nonsense. Go READ the dictionary.ascend, like I TOLD YOU. It ALREADY lists the attributes without vendor info. And as you've seen, this causes problems. As I said in my previous message, BOTH vendors have used the same NON-VENDOR attribute space for their attributes. This is stupid of them, and is the entire source of the problem. Stop trying to fix the server by making it even more broken in ways you've already said you didn't like. Go fix the clients to send the attributes as VSA's. That will solve the problem. I'll bet a simple edit of a dictionary file is all that's needed. There are probably ways to use the server to re-write the attributes to make sense (so attr_filter works), but I don't see any point in explaining them, until it's clear that you've understood what else I've said. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with attr_filter
On Sun, 14 Dec 2003 14:05:19 -0500 Alan DeKok [EMAIL PROTECTED] wrote: Stephan von Krawczynski [EMAIL PROTECTED] wrote: THAT'S why you didn't see a vendor Id: They weren't using VSA's. If you had said that in the first place, it would have helped significantly. Unfortunately it would not, If you know more about RADIUS the server than I do, why are you asking questions? Because there may be others out there that see the same issues but are not quite able to browse the source for further investigation. Stuff like this discussion enters some archives and can be found by people looking for it. And _that_ is why I began this discussion, and _not_ because I am requesting any help. I can very well help myself in this issue. Are you going to believe me, or are you going to keep telling me I'm wrong? You are not wrong, you simply don't listen or don't at least try to understand the problem, again: I have a freeradius 0.8.1 and let it send vendor attributes to a freeradius 0.9.3 proxy that tries to filter _that very same_ vendor attributes and does not recognise them. _That_ is a real issue. It is likely that 0.8.1 is different somehow regarding vendor info behaviour (maybe buggy, I don't know). My expectation was you had some knowledge about this. Do you? but the situation while comparing in rlm_attr_filter is that the reply_item has no vendor info, whereas the check_item (remember: from _same_ vendor!) has one. And _that_ is the primary problem. Absolutely not. You haven't understood what I'm saying. To repeat in short, simple, words: Vendor attributes are different from non-vendor attributes. I know. If the names look similar to you, that's an illusion, and has nothing to do with the problem at hand. If the attribute numbers look similar, that, too, is unimportant. .. as long as they don't belong to the _same_ dictionary, which is exactly the case here. The attributes are different. One is a VSA, and the other is not. The code will never be able to compare them as identical, because they're not identical. The RADIUS packet itself says they're different, so the server treats them as different. Why does a packet come out different from 0.8.1 using the same dictionary as 0.9.3 ? There will be NO patches going into the server to fix this problem. I did not talk about this. I talked about a patch I tried to bring more light into the issue. Thinking about it another possible solution may be to create a patch-dictionary where the attributes contain no vendor info and use these in attr_filter. That sounds like a reasonable no-source-patch solution to this problem. Nonsense. Total nonsense. Go READ the dictionary.ascend, like I TOLD YOU. It ALREADY lists the attributes without vendor info. And as you've seen, this causes problems. As I said in my previous message, BOTH vendors have used the same NON-VENDOR attribute space for their attributes. This is stupid of them, and is the entire source of the problem. Stop trying to fix the server by making it even more broken in ways you've already said you didn't like. Go fix the clients to send the attributes as VSA's. That will solve the problem. I'll bet a simple edit of a dictionary file is all that's needed. Hoho! You are slightly touching the problem: must freeradius 0.8.1 be fixed to produce the same radius packets 0.9.3 can understand/filter? There are probably ways to use the server to re-write the attributes to make sense (so attr_filter works), but I don't see any point in explaining them, until it's clear that you've understood what else I've said. I have heard about attr_rewrite, thanks. But I guess this is overcomplicating the whole story. Something that came to my mind while debugging was: is there a (simple) way to make freeradius write a protocol of all access-packets very like the accounting packets' protocol (detail-file)? I mean besides freeradius debugging mode. That would be very handy (I really don't like tcpdump for long-term protocols). Regards, Stephan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freebsd vs. wireless 802.1x
--- Alan DeKok [EMAIL PROTECTED] =?big5?q?Vincent=20Chen?= [EMAIL PROTECTED] wrote: 1. My client is a notebook running windows xp. I can establish connection to AP using predefined key or just check 'the key is provided for me automatically'. My question is the key radius send to AP and client. How do those key generated? Will the key changed after a period just like IPSEC rekey function? If you use PEAP, the keys are generated as part of the PEAP authenticaion process. Is there a PEAP howto available? After search, I see a lot of EAP/TLS howto but not PEAP. The keys will be rotated, if you set a Session-Timeout, to make the user re-authenticate. This is where I am confused. What keys will be used to rotate? 4 WEP keys defined in AP? Or freeradius will generate new key for each rotation? 2. I enabled radius accounting. Only start record in detail file but no stop record. It looks like this: shrug See the FAQ. If the NAS/client doesn't send a stop record, there's nothing the server can do about it. What is this 'Acct-Status-Type = 0' record? See the RFC's. http://www.freeradius.org/rfc/atributes.html It doesn't officially exist, so no one knows what it's supposed to be. Can I get bytes transfered during this session like dialup record? Read the FAQ. The server can't log what isn't sent by the NAS. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - Yahoo! http://tw.promo.yahoo.com/mail_premium/stationery.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Radius Class and users file
I want to reject user by checking with NAS and User Class, i am using OpenLDAP + FreeRadius 0.9.3 and set 'users' file like below but it not work. DEFAULT NAS-IP-Address==192.168.0.25, Class == TYPE1, Auth-Type := Reject Reply-Message = NAS Access denied!, Fall-Through = No Regards Wichit N. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: MySQL Help!
Title: RE: MySQL Help! Alan, What file(s) should I run ldd against? Chris DeRamus OCIO VPN Administrator SAIC -Original Message- From: Alan DeKok [mailto:[EMAIL PROTECTED]] Sent: Friday, December 12, 2003 4:44 PM To: [EMAIL PROTECTED] Subject: Re: MySQL Help! Deramus, Chris [EMAIL PROTECTED] wrote: I have checked and verified the LD_LIBRARY_PATH variable, I have updated ld.so.conf as well. I've tried multiple configuration options, including disable-shared. Something isn't adding up. Any suggestions would be most appreciated. Thanks and have a good weekend. 'ldd' should tell you which libraries are needed. Maybe MySQL needs additional libraries, which somehow aren't loaded. I don't know how else to help you. The server core doesn't know *anything* about modules/libraries, other than it asks the system to load them. If that doesn't work, there isn't much else the server can do. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: MySQL Help!
Title: RE: MySQL Help! Chris, Thanks for the input, however, when I updated the configure script with your extra code configure would not find lmysqlclient and prompted that I specify the path to the library files by using --with-mysql-lib= When I put in the path to the MySQL library files, it still would not find lmysqlclient. Any other thoughts? If I get it I'll be sure to let you know what it was, thanks so much. Chris DeRamus OCIO VPN Administrator SAIC -Original Message- From: Chris Parker [mailto:[EMAIL PROTECTED]] Sent: Friday, December 12, 2003 5:14 PM To: [EMAIL PROTECTED] Subject: Re: MySQL Help! At 03:42 PM 12/12/2003, Rob Genovesi wrote: oh boy, I remember kicking this around for ever as well ... My solution was to 1) be sure you have development rpms installed and 2) do not use --disable-shared when running configure. I don't know exactly why this changed things, but compiling with shared libraries it was able to find and use all the necessary mysql libs and includes. I installed the following MySQL rpms (Redhat) : MySQL-devel-4.0.16-0 MySQL-shared-compat-4.0.16-0 MySQL-client-4.0.16-0 MySQL-server-4.0.16-0 Aha. Mysql4 changes some stuff. On Solaris we had to change some of the Makefiles manually to get all of the appropriate libs included to build the rlm_mysql driver built. It may be the same on RH as well. Helpfully, MySQL 3 build syntax is not totally workable with MySQL 4 at least as far as FR is concerned. -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless! \ Director, Engineering | @ @ | \ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Digital Cert + Username/Password against LDAP = ???
Hello, I have a requirement for two stage authentication for wireless networks. Before the wireless Windows 2000/XP client is even allowed to reach the domain, it must authenticate to the network with Digital Certs issued from an iPlanet certificate server (EAP-TLS) and also a username/password against LDAP. Would this be EAP-TTLS? If someone can point me to the correct keyword I'm sure I can figure it out from there. Thanks, -Patrick - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Upgrade questions
Can anyone point in the direction of the best way to upgrade to Freeradius version 0.9.3 from version FreeRADIUS Version 0.8-pre with out losing my current configuration? currently FreeRADIUS Version 0.8-pre is being used to authenticate users dialing into a Lucent Max 6000. If there is any other info you would need just respond here. I'm not looking for any easy out, just want to research all possiblities before I mess with the current installation. Thanks in advance. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
