[RADIATOR] documentation typo at 13.1.33 DefineFormattedGlobalVarsystem
Hi radiator team, there is a missing whitespace in the documentation: > 13.1.33 > Variable names prefixed with GlobalVar: > The attribute to be compared is taken from a GlobalVar. GlobalVar variables > can be set > from the command line, or with the DefineFormattedGlobalVar parameter. This > can be > useful for activating different sets of users in multiple instances of > Radiator. > # In the config file: > DefineFormattedGlobalVarsystem mysystem > # in a users file: > username Password=fred,GlobalVar:system=mysystem Must be: > DefineFormattedGlobalVar system mysystem Best Regards Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hi, anyway it's a bit proprietary that Radiator ignores the correct identifier in an Access-Reject packet. The Identifier is also part of RFC2865: Identifier The Identifier field is one octet, and aids in matching requests and replies. The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time. Freeradius has never complained about these Access-Reject packets generated by radsecproxy. Because these packages can be matched by the identifier. Also there is no doubt that radsexcproxy might violate RFC 2865 and Radiator violates RFC5997, it is always not very useful ignoring part of a standard header and insist on a Ext-Id to match an Access-Reject. Best wishes Ralf On Jul 15, 2013, at 9:35 AM, Karl Gaissmaier wrote: > Hello, > > Am 15.07.2013 09:27, schrieb Stefan Winter: >> Hi, >> >>> this may be true for Status-Server but not for the Access-Rejects >>> generated by the radsecproxy. This has to be corrected by radsecproxy. >>> >>> And yes, Radiator AuthRADSEC has to fix the problem with Status-Server. >>> Both together are incompatible but often used together in eduroam. >> >> Yes, the lack of returning Proxy-State when radsecproxy crafts its own >> Rejects is definitely a problem of radsecproxy; it violates RFC2865, >> section 5.33: >> >> " This Attribute is available to be sent by a proxy server to >> another server when forwarding an Access-Request and MUST be >> returned unmodified in the Access-Accept, Access-Reject or >> Access-Challenge." >> >> I've sent a notice to the radsecproxy mailing list, notifying them of >> the problem. I'm hoping to see a next release with a proper fix. > > Thanks, you got the point and saved my day! > > Best Regards > Charly > -- > Karl Gaissmaier > Universität Ulm / Germany > > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Verein zur Förderung eines Deutschen Forschungsnetzes e.V. Alexanderplatz 1, D - 10178 Berlin Tel.: 030 88 42 99 23 Fax: 030 88 42 99 70 http://www.dfn.de smime.p7s Description: S/MIME cryptographic signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward
Hi, > 1.)Radiator has to fix AuthRADSEC. The user has to choose to use >extended-Ids in the Proxy-State Attribut if the upstream proxy >will handle this. By default it should use 8 Bit Identifiers. > > 2.)radsecproxy has to fix the self generated Access-Rejects. >If a Proxy-State Attribut was present in the Access-Request, the >generated Access-Reject must copy this attribut and send it back. I agree with both points. both servers are doing something wrong..and the interop causes issues. alan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hello, Am 15.07.2013 09:27, schrieb Stefan Winter: > Hi, > >> this may be true for Status-Server but not for the Access-Rejects >> generated by the radsecproxy. This has to be corrected by radsecproxy. >> >> And yes, Radiator AuthRADSEC has to fix the problem with Status-Server. >> Both together are incompatible but often used together in eduroam. > > Yes, the lack of returning Proxy-State when radsecproxy crafts its own > Rejects is definitely a problem of radsecproxy; it violates RFC2865, > section 5.33: > > " This Attribute is available to be sent by a proxy server to >another server when forwarding an Access-Request and MUST be >returned unmodified in the Access-Accept, Access-Reject or >Access-Challenge." > > I've sent a notice to the radsecproxy mailing list, notifying them of > the problem. I'm hoping to see a next release with a proper fix. Thanks, you got the point and saved my day! Best Regards Charly -- Karl Gaissmaier Universität Ulm / Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward
Hi, Am 15.07.2013 09:15, schrieb a.l.m.bu...@lboro.ac.uk: > Hi, > >> 1272017248108...@wlan.mnc001.mcc262.3gppnetwork.org > > 3gppnetwork realms are invalid. ..just like hotmail, gmail, yahoo etc - > until a notice comes from eduroam stating that these realms now have agreed > relationship, they are public realms and not within the private scheme of > eduroam. thats's not the point, I had (again) a wrong example choosen. Some users have just typos in their realms, an endpoint eduroam SP can not handle all typos, we proxy it upstream. If the upstream Rejects it, it should not strip the Proxy-State Attribut. >> RFC 5997, saying that Status-Server MUST NOT be proxied and therefore >> the Proxy-State attribut isn't allowed. > > status-server musnt be proxiedits only for the first-hop check of > a remote proxy and not the end target - but that surely isnt the issue? > a Status-Server message is easy to deal with - you just send something back > to show you are alive - RADIATOR has been sending a basic statts page back > for status-server queries to it for years. Radiator doesn't proxy the Status-Server requests, he generates it and has a wrong scheme to deal with the limited 8-Bits of Request Identifiers. Again: 1.)Radiator has to fix AuthRADSEC. The user has to choose to use extended-Ids in the Proxy-State Attribut if the upstream proxy will handle this. By default it should use 8 Bit Identifiers. 2.)radsecproxy has to fix the self generated Access-Rejects. If a Proxy-State Attribut was present in the Access-Request, the generated Access-Reject must copy this attribut and send it back. Best Regards Charly -- Karl Gaissmaier Universität Ulm / Germany ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hi, > this may be true for Status-Server but not for the Access-Rejects > generated by the radsecproxy. This has to be corrected by radsecproxy. > > And yes, Radiator AuthRADSEC has to fix the problem with Status-Server. > Both together are incompatible but often used together in eduroam. Yes, the lack of returning Proxy-State when radsecproxy crafts its own Rejects is definitely a problem of radsecproxy; it violates RFC2865, section 5.33: " This Attribute is available to be sent by a proxy server to another server when forwarding an Access-Request and MUST be returned unmodified in the Access-Accept, Access-Reject or Access-Challenge." I've sent a notice to the radsecproxy mailing list, notifying them of the problem. I'm hoping to see a next release with a proper fix. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward
Hi, > status-server musnt be proxiedits only for the first-hop check of > a remote proxy and not the end target - but that surely isnt the issue? > a Status-Server message is easy to deal with - you just send something back > to show you are alive - RADIATOR has been sending a basic statts page back > for status-server queries to it for years. This is about Status-Server requests *originating* from Radiator to check another server's alive state. Radiator sends a Proxy-State in the request (which is not supposed to be done), and then complains that it doesn't get it back (which is only supposed to happen with Access-Requests, not Status-Server). Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward
Hi, > 1272017248108...@wlan.mnc001.mcc262.3gppnetwork.org 3gppnetwork realms are invalid. ..just like hotmail, gmail, yahoo etc - until a notice comes from eduroam stating that these realms now have agreed relationship, they are public realms and not within the private scheme of eduroam. > RFC 5997, saying that Status-Server MUST NOT be proxied and therefore > the Proxy-State attribut isn't allowed. status-server musnt be proxiedits only for the first-hop check of a remote proxy and not the end target - but that surely isnt the issue? a Status-Server message is easy to deal with - you just send something back to show you are alive - RADIATOR has been sending a basic statts page back for status-server queries to it for years. alan ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
