Re: [RADIATOR] FW: RADIATOR: EAP-FAST-MSCHAPv2
I tried EAP-FAST with GTC as an inner authentication its working fine, but for MSCHAPv2 I saw message in log file that rejected. Regards Sudhir H -Original Message- From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On Behalf Of Sudhir Harwalkar Sent: Friday, April 06, 2012 11:20 AM To: radiator@open.com.au Subject: [RADIATOR] FW: RADIATOR: EAP-FAST-MSCHAPv2 Hi Heikki, When I run the EAP-FAST I seen rejected message in the log file is it due do log file config. Please find the attached log file. Thanks Sudhir H -Original Message- From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On Behalf Of Heikki Vatiainen Sent: Thursday, April 05, 2012 4:50 PM To: radiator@open.com.au Subject: Re: [RADIATOR] RADIATOR: EAP-FAST-MSCHAPv2 On 04/05/2012 10:15 AM, Sudhir Harwalkar wrote: Hello Sudhir, As I am verifying EAP-FAST which uses inner authentication as MSCHAPv2, for this our device requires any certificates like client certificates? I red that it requires PAC means pac key should match from both sides like radius sever and our device? If the client does not send its PAC, Radiator will try to allocate one to it. Then client is then disconnected. Next time when the client tries to authenticate, it will have a PAC and the authentication should then proceed. By default Radiator keeps the PACs in memory with the other option being SQL. So do not restart Radiator unless you want to clear the PAC. Thanks! Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator Larsen Toubro Limited www.larsentoubro.com This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. Larsen Toubro Limited www.larsentoubro.com This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] RADSEC, failure algorithm, eduroaming and long reply times
Hello Heikki, Am 05.04.2012 21:19, schrieb Heikki Vatiainen: ... Thanks for clarifying this. I see what you mean. The interest is not in dead realm marking or determining the reachability of a realm somewhere down the proxy chain, but just the health of next hop. In other words, is radius1.dfn.de responding to Server-Status or not. If not, the radius2.dfn.de should be used. This is how I understand it. yep thats what I'm looking for. This is similar done in radsecproxy with the 'statusServer' option, please see in their implementation: http://software.uninett.no/radsecproxy/ and serverStatus ... What I am thinking if an option to return Access-Reject would be needed when your server sees a timeout while trying to forward the request. In other words, there are two things I am thinking of: 1) Status-Server to poll next hop I suggest a new implementation for this case similar to radsecproxy 2) what to do when a request times out. yep this are two cases, I'm looking for case 1.) since I'm the first one in the proxy chain. Maybe you should allow the users of radiator to choose what algo to use. The current algo is OK in a peer2peer situation and the new statusServer algo is needed in a proxy chain. Stay with algo 2 as is and allow to choose statusServer as an option. If the user enables statusServer the failure algo no longer uses NoreplyTimeout as a switchover, thats all. Instead use a StatusServerTimeout, and let all other hooks as is. Then we users can determine what to do when the next-server is down (StatusServerTimeout) and what to do if the Access-Request times out (NoreplyTimeout), but don't use NoreplyTimeout inherently for next-hop failure algo if StatusServer is choosen by the user. About 2): Currently nothing is done. If an Access-Reject is returned then at least the server that forwarded us the request (previous server) would see as being alive. If it can use Status-Server, then Access-Reject would not be needed to signal your server is still alive and was not the reason for the timeout. I don't think you should change this behaviour, stay with it. ... Ok. How about using Status-Server to see if the next hop is alive and DRM to try if the destination realm is reachable by some other route? I am trying to get an idea if DRM has been deemed unnecessary in eduroam use. As I know, our NREN next-hop radius (DFN, german research network) is using radsecproxy. Interestingly, radsecproxies uses serverStatus and RADIATOR - as the next hop - answers properly as a server but don't uses Status-Requests as client. BTW, all what I wrote about AuthBy RADSEC belongs also to AuthBy RADIUS or all other AuthBy proxies! ... I think I understand what you need. I was just trying to clarify if Status-Server would be enough or if anything else is needed too. Thanks Heikki for your patience and the rest of your team for RADIATOR too. Best Regards Charly ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] FW: RADIATOR: EAP-FAST-MSCHAPv2
On 04/06/2012 10:07 AM, Sudhir Harwalkar wrote: I tried EAP-FAST with GTC as an inner authentication its working fine, but for MSCHAPv2 I saw message in log file that rejected. The log file you sent previously shows that the user (sudhir) was found from the users file. MSCHAPv2 then failed which indicates the password was incorrect or your client calculated EAP-MSCHAPv2 credentials incorrectly. I would check the password first to see it was correctly entered. Heikki Regards Sudhir H -Original Message- From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On Behalf Of Sudhir Harwalkar Sent: Friday, April 06, 2012 11:20 AM To: radiator@open.com.au Subject: [RADIATOR] FW: RADIATOR: EAP-FAST-MSCHAPv2 Hi Heikki, When I run the EAP-FAST I seen rejected message in the log file is it due do log file config. Please find the attached log file. Thanks Sudhir H -Original Message- From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On Behalf Of Heikki Vatiainen Sent: Thursday, April 05, 2012 4:50 PM To: radiator@open.com.au Subject: Re: [RADIATOR] RADIATOR: EAP-FAST-MSCHAPv2 On 04/05/2012 10:15 AM, Sudhir Harwalkar wrote: Hello Sudhir, As I am verifying EAP-FAST which uses inner authentication as MSCHAPv2, for this our device requires any certificates like client certificates? I red that it requires PAC means pac key should match from both sides like radius sever and our device? If the client does not send its PAC, Radiator will try to allocate one to it. Then client is then disconnected. Next time when the client tries to authenticate, it will have a PAC and the authentication should then proceed. By default Radiator keeps the PACs in memory with the other option being SQL. So do not restart Radiator unless you want to clear the PAC. Thanks! Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator Larsen Toubro Limited www.larsentoubro.com This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. Larsen Toubro Limited www.larsentoubro.com This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] RADSEC, failure algorithm, eduroaming and long reply times
On 04/06/2012 12:55 PM, Karl Gaissmaier wrote: BTW, all what I wrote about AuthBy RADSEC belongs also to AuthBy RADIUS or all other AuthBy proxies! Yes, that's true. There are some more specialised proxying algorithms, but at least RadSec and plain RADIUS proxying can be considered for this. I think I understand what you need. I was just trying to clarify if Status-Server would be enough or if anything else is needed too. Thanks Heikki for your patience and the rest of your team for RADIATOR too. Thanks for your comments and the time you used explaining the situation. I'll let you know how this goes once I hear more from development. Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
