Re: Deleting VLAN information while proxying
[EMAIL PROTECTED] wrote: > > I cant see WHY the VLAN info needs to reach other sites at all...perhaps > the National Proxy should be stripping out such things? anyway, if memory > Alan, your logic sounds fine but it has two flaws: 1. you should not depend on someone whom you cannot control to do the work for you. 2. some countries already made decisions that the national proxy MUST NOT interfere with the stuff sent in the radius packets. It was argued by some colleagues that for instance two institutions could have an explicit agreement and honor each other's VLAN settings. Actually we did manage do fix that thing using rlm_perl in postauth section. rlm_perl was hacked a bit so that it would be able to delete attributes. I really think that this is a perfectly natural need to be able to control attributes sent when the request comes from am outside proxy. The approach based on NAS IP Address is not correct, since NAS addresses are often from private address space and can repeat in various institutions. Tomasz - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_attr_rewrite
Is it possible to delete entire attributes with rlm_attr_rewrite? Tomasz -- Tomasz Wolniewicz [EMAIL PROTECTED]http://www.uni.torun.pl/~twoln Uczelniane Centrum Informatyczne Information&Communication Technology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University, pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: +48-693-032-576 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Deleting VLAN information while proxying
Alan DeKok wrote: > Can you not key off of the NAS information, and *not* add VLAN data, > then? > > I am not sure what you mean by that. Using NAS information is the only thing that came to our minds, that is we create a large hunt group containing all local NASes and add VLAN data only when this is hit. But we did not manage to make any comparison of NAS-IP-Address other then equality. If one could use regex then it would be easy, but somehow this did not seem to work. Obviously one could use another dirty hack - add another proxy server and do all cleaning there, but it seems that there should be a clean and simple way of doing what we need. Actually one might argue that it is the network provider that should be careful to filter out all foreign VLAN attributes on input as this can be a security hazard not to do so, and this task is easily done with attr_filter. Unfortunately if a user gets to a site that does not filter VLAN attributes on input, in most cases the VLAN will not match anything useful and the user will not get connected, so it makes a lot of sense to block the VLANs also on the output as a good service to our users (not to mention the fact that telling people our VLAN numbers is probably not very wise either). Tomasz - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Deleting VLAN information while proxying
Alan DeKok napisał(a): > Tomasz Wolniewicz <[EMAIL PROTECTED]> wrote: > >> Our university radius server sets VLAN information based on user >> attributes form the LDAP directory. >> This works fine when the system is used internally. However when our >> user authenticates while visiting another institution, this VLAN >> information should not be sent out. >> > > rlm_attr_filter should work, I think. > > Alan DeKok. > > Alan, thanks, but it seems that when freeradius does the internal proxy to service the eap-ttls then the pre-proxy and post-proxy are not being entered, and this is where we would expect to put attr_filter. We tried the post_auth but it refuses to take attr_filter. Tomasz - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Deleting VLAN information while proxying
We have the following problem arising form the eduroam project. Our university radius server sets VLAN information based on user attributes form the LDAP directory. This works fine when the system is used internally. However when our user authenticates while visiting another institution, this VLAN information should not be sent out. In such a situation, the authentication request arrives via the national proxy. We have managed to configure VLAN blocking for EAP-TLS since then we can use Client-IP-Address information. If this address corresponds to the address of the national proxy then we do not set VLAN information at all. This approach breaks down with EAP-TTLS. The internal proxy mechanism rewrites the Client-IP-Address to localhost and all requests look the same. We could in principle base our decision on huntgroups, creating a huntgroup for all out NASes, but his looks so clumsy and a mess to administer. Is there a better trick to solve this? Tomasz -- Tomasz Wolniewicz [EMAIL PROTECTED] http://www.uni.torun.pl/~twoln Uczelniane Centrum Informatyczne Information&Communication Technology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University, pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: +48-693-032-576 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
VSAs in 3COM accounting
Hi, I have some 3COM access points AP 7250. In the accounting packets I get things like: Tue Apr 12 13:11:59 2005 Acct-Status-Type = Alive Acct-Session-Id = "000e356a0cfa-000e6ad5defe-0344" NAS-IP-Address = 192.168.36.3 Acct-Input-Octets = 32733 Acct-Output-Octets = 26338 Acct-Input-Packets = 221 Acct-Output-Packets = 186 Vendor-Specific = 0x45415020557365726e616d652069733a203337303740636572747966696b6174792e756d6b2e706c Vendor-Specific = 0x564c414e2049442069733a2031 Vendor-Specific = 0x4553534944203d20656475726f616d Vendor-Specific = 0x45415020547970652069733a204541502d544c53 Acct-Session-Time = 11229 Client-IP-Address = 192.168.36.3 Acct-Unique-Session-Id = "70ab7f6a7a0a3309" Timestamp = 1113304319 I have looked through the mail archives and from what I have found there I would guess that the first 4 bytes of the Vendor-Specific value should be the Vendor-Id. But this seems strange that these Ids should be so high and that they should be different. Am I missinterpreting something? Tomasz -- Tomasz Wolniewicz [EMAIL PROTECTED]http://www.uni.torun.pl/~twoln Uczelniane Centrum Informatyczne Information&Communication Technology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University, pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: +48-693-032-576 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Attr_Filter
We have made a trivial patch to the attr_filter that changes the dafault behaviour from reject to accept, that is we accept and pass over all attributes which are not listed in the attrs file and apply the usual rules to the ones that are listed. In particular an entry: Tunnel-Private-Group-Id := 34, Tunnel-Type := VLAN, Tunnel-Medium-Type := 6, Tunnel-Private-Group-Id !* ANY, Tunnel-Type !* ANY, Tunnel-Medium-Type !* ANY will send all attributes unchanged, except for the VLAN attributes. For those it will delete any incoming ones and add those setting up VLAN to 34. regards Tomasz On Fri, Jan 28, 2005 at 03:05:26AM -0800, Cool Man wrote: > Hi all, > > I want to know if there is any method to add > attributes in a proxy reply based on realm. > > I have tried adding an attribute > > Tunnel-Type:= VLAN > > in attrs file, but when the proxy reply comes the > attr_filter only adds this attribute in newly built > proxy reply and doesn't keep all other attributes came > with original proxy reply. > > is there a way to add new through attr_filter > attributes by keeping all attributes came in the proxy > reply. > > I will appreciate your suggestions. > Best Regards, > Raza. > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Tomasz Wolniewicz [EMAIL PROTECTED]http://www.uni.torun.pl/~twoln Uczelniane Centrum Informatyczne Information&Communication Technology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University, pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: +48-693-032-576 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP/TLS, EAP-TTLS with LDAP
Alan, could you be a LITTLE bit more specific about that? Its Christmas :). How can I tell define conditions which will notice that it is the EAP-TTLS case and not EAP/TLS? Perhaps there is no way, as at the beginning it is simply an EAP message, so the server has no way of telling which way to go? Tomasz On Wed, Dec 22, 2004 at 11:14:31AM -0500, Alan DeKok wrote: > Tomasz Wolniewicz <[EMAIL PROTECTED]> wrote: > > Does someone have an idea how to switch off LDAP for processing of the > > outer part of the EAP-TTLS message? > > Put ldap into an Atz-Type block, and configure the server to call > the block only in the conditions you want it to be called. > > Alan DeKok. > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Tomasz Wolniewicz [EMAIL PROTECTED]http://www.uni.torun.pl/~twoln Uczelniane Centrum Informatyczne Information&Communication Technology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University, pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: +48-693-032-576 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP/TLS, EAP-TTLS with LDAP
I expect my users to athenticate with either EAP/TLS or EAP-TTLS/PAP. In the first case User-Name is processed twice, first the outer identity, and later the inner one. Actually I have no interest in processing the outer identity as this only serves setting up the correct realm, but the uid has no meaning. It turns out that I search the whole user database and throw away the result, which seems like a big waste of resources. And to make things worse, this goes on with every packet of the conversation. I have figured out a way of dealing with this, by returning from the authorize list whenever eap returns updated, unfortunately this does not work with TTLS in which case the outer identity is THE one that we are interested in. Does someone have an idea how to switch off LDAP for processing of the outer part of the EAP-TTLS message? Tomasz -- Tomasz Wolniewicz [EMAIL PROTECTED]http://www.uni.torun.pl/~twoln Uczelniane Centrum Informatyczne Information&Communication Technology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University, pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: +48-693-032-576 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Removing unwanted attributes
I have seen this question before (Removing VSAs from proxied requests), but no answers. I have just done some detective work to find which attributes to put into the attrs file to make EAP/TTLS work through a proxy. My only reason to switch the attr_filter on, is to control the VLAN assgnement. All other attributes should go through unmodified. It would seem natural to have directives saying what to do with attributes not mentioned on the list - delete or send through. Perhaps such mechanism is actually present? Yours Tomasz -- Tomasz Wolniewicz [EMAIL PROTECTED]http://www.uni.torun.pl/~twoln Uczelniane Centrum Informatyczne Information&Communication Technology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University, pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: +48-693-032-576 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: groupmembership_filter
Hi Kostas, I was thinking about it and I see that changing the order will not do much good. I have serveral groups defined and typically a user has a groupmembership_attribute set to one value. When radius checks groups it tries all groups form the config, one by one. If the user does not belong to a given group then changing the order will still run two searches. I think the only choice is to disable the groupmembership_filter search by some setting in the config file. Since it now has a default value it could break peoples' servers to change this default behaviour, but setting it to NULL or something could be acceptable. Yours Tomasz On Tue, Nov 30, 2004 at 01:40:26PM +0200, Kostas Kalevras wrote: > On Tue, 30 Nov 2004, Tomasz Wolniewicz wrote: > > >I am using the groupmembership_attribute to add users to certain groups, > >unfortunately rlm_ldap will always also run a subtree search using the > >groupmembership_filter, which for my case is completely useless. From what > >I > >see in the code, there seems to be no way to switch this search off. Would > >it > >not be a good idea to allow the user to set this filter (or perhaps the > >groupname_attribute) to something like NONE that would tell rlm_ldap not > >to bother? Saving one unnecessary search over possibly a large tree could > >be worth the bother. To make things easier I have set up the > >groupmembership_filter to (objecClass = nosuchclass), this way with > >indexing over the object class the negative reply to this search should be > >quick enough, but still I would prefer to simply save this extra call. > > > >Perhaps there is some way that I have overlooked? > > You 're right on that. The code should first do a search based on the > groupmembership_attribute (if it is set) and if that fails then use > groupmembership_filter. Can you also open a bug report on > bugs.freeradius.org for that please? > > I 'll try and make the changes (they 're rather trivail) as soon as > possible. > > > > >Yours > >Tomasz > > > >-- > >Tomasz Wolniewicz > > [EMAIL PROTECTED]http://www.uni.torun.pl/~twoln > > > >Uczelniane Centrum Informatyczne Information&Communication Technology > >Centre > >Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University, > >pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland > >tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: > >+48-693-032-576 > > > >- > >List info/subscribe/unsubscribe? See > >http://www.freeradius.org/list/users.html > > > > -- > Kostas Kalevras Network Operations Center > [EMAIL PROTECTED] National Technical University of Athens, Greece > Work Phone: +30 210 7721861 > 'Go back to the shadow' Gandalf > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html -- Tomasz Wolniewicz [EMAIL PROTECTED]http://www.uni.torun.pl/~twoln Uczelniane Centrum Informatyczne Information&Communication Technology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University, pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: +48-693-032-576 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
groupmembership_filter
I am using the groupmembership_attribute to add users to certain groups, unfortunately rlm_ldap will always also run a subtree search using the groupmembership_filter, which for my case is completely useless. From what I see in the code, there seems to be no way to switch this search off. Would it not be a good idea to allow the user to set this filter (or perhaps the groupname_attribute) to something like NONE that would tell rlm_ldap not to bother? Saving one unnecessary search over possibly a large tree could be worth the bother. To make things easier I have set up the groupmembership_filter to (objecClass = nosuchclass), this way with indexing over the object class the negative reply to this search should be quick enough, but still I would prefer to simply save this extra call. Perhaps there is some way that I have overlooked? Yours Tomasz -- Tomasz Wolniewicz [EMAIL PROTECTED]http://www.uni.torun.pl/~twoln Uczelniane Centrum Informatyczne Information&Communication Technology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University, pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: +48-693-032-576 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-TTLS proxying
I hoped noone will bring that up, since this was my silly mistake. Of course everything is just as it should be and the reason for this odd behavour was that out of laziness we have set up two servers on one machine (on different ports). Obviously radius realises that keys and everything are the same so it does not bother doing a TTLS proxy. So unfortunaley this was a silly question, and no problem on the side of freeradius. Tomasz On Fri, Jul 16, 2004 at 12:24:31PM +0100, Luis Guido wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of Tomasz Wolniewicz > > Sent: Tuesday, July 13, 2004 21:30 > > To: [EMAIL PROTECTED] > > Subject: EAP-TTLS proxying > > > > > > I hope this is not a totally stupid question. > > Suppose a user [EMAIL PROTECTED] wants to access the network at org-2 by > > authenticating at org-1 via the proxy mechanism. > > Suppose we want to use PAP-TTLS. > > It would seem natural that the proxying is done on the basis > > of the outer > > identity and the tunneled data is never revealed to the proxy server > > at org-2. > > Yes that's exacly how it should be. > > > Unfortunately our tests seem to show that the > > server at org-2 needs > > to get the user data, including the password. > > Very weird I have that same scenario and password AND inner username > is never revealed. Because that information is tunneled on a secure TLS > tunnel and encapsulated on a EAP packet. The 1st server (that acts as a > proxy) just see some anonymous username an EAP-Message , and some more > stuff (Message-Authenticator; etc...) but never the real username and > password. The org-2 server CAN'T open a TLS connection to get access to > the "critit information": user+pass!!! If that happen that's no longer a > "secure connection" :) > > > Is it possible to configure things in the secure way? Of course, the > > servers need to trust each other, but some trust is one thing > > and seeing > > passwords in plain text is another. I realise that other forms of > > authentication, which do not transmit passwords will not have > > that problem. > > That's the way things are suposed to be Only the authentication > server has access to user+pass > Can you send the config? We have a cookbook for freeradius (is all in > portuguese but the configuration part is in "native english") at: > http://www.fccn.pt/index.php?module=pagemaster&PAGE_user_op=view_page&PA > GE_id=199&MMN_position=140:4:90 > > You are welcome to download, try and comment it off course. > Contributions are most welcome! > > Luis Guido > > > Yours > > Tomasz > > > > -- > > Tomasz M. Wolniewicz > >[EMAIL PROTECTED] > > http://www.uni.torun.pl/~twoln > > > > Uczelniane Centrum > > Informatyczne Information&Communication Technology Centre > > Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University, > > pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland > > tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: > > +48-693-032-576 > > > > - > > List info/subscribe/unsubscribe? See > > http://www.freeradius.org/list/users.html > > > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Tomasz Wolniewicz [EMAIL PROTECTED]http://www.uni.torun.pl/~twoln Uczelniane Centrum Informatyczne Information&Communication Technology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University, pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: +48-693-032-576 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-TTLS proxying
I hope this is not a totally stupid question. Suppose a user [EMAIL PROTECTED] wants to access the network at org-2 by authenticating at org-1 via the proxy mechanism. Suppose we want to use PAP-TTLS. It would seem natural that the proxying is done on the basis of the outer identity and the tunneled data is never revealed to the proxy server at org-2. Unfortunately our tests seem to show that the server at org-2 needs to get the user data, including the password. Is it possible to configure things in the secure way? Of course, the servers need to trust each other, but some trust is one thing and seeing passwords in plain text is another. I realise that other forms of authentication, which do not transmit passwords will not have that problem. Yours Tomasz -- Tomasz M. Wolniewicz [EMAIL PROTECTED]http://www.uni.torun.pl/~twoln Uczelniane Centrum Informatyczne Information&Communication Technology Centre Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University, pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: +48-693-032-576 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
