Re: [RADIATOR] two factor authentication
Hi Heikki and Mike, I'm already using AuthBy OTP with my own ChallengeHook. I've read RFC2865 yesterday but missed the State attribute, thanks for the great pointer! Thats the working config I came up with: Identifier tsa-otp-client-vpn Filename %L/tsa-otp-client-vpn.authlog LogSuccess 1 LogFailure 1 # log the Handler Identifier to be able to distinguish between AD and OTP auth failures SuccessFormat %l:%U:%{Request:Callback-Number}:%{Handler:Identifier}:OK FailureFormat %l:%U:%{Request:Callback-Number}:%{Handler:Identifier}:FAIL Identifier otp_sms_challenge AuthByPolicyContinueUntilChallenge #StripFromRequest Password # clear the password to force AuthOTP to always generate a OTP PreAuthHook sub { \ my $p = ${$_[0]}; \ my $rp = ${$_[1]}; \ $p->{DecodedPassword} = ''; \ } AuthBy otp_sms #AddToReply State="otp-challenge" Identifier tsa-otp-client-vpn-otp AuthLog tsa-otp-client-vpn # Show any rejection reason to the end user RejectHasReason AuthBy otp_sms Identifier tsa-otp-client-vpn-ad AuthByPolicyContinueUntilChallenge # Show any rejection reason to the end user RejectHasReason AuthLog tsa-otp-client-vpn # Save time by never looking for a default NoDefault Host ip1 ip2 ip3 Port 389 Version 3 # request timeout in seconds Timeout 2 # don't try to reach the ldap for this amount of seconds after failure FailureBackoffTime 0 UsernameAttr samaccountname # don't check the password, just for phone number lookup #PasswordAttr ServerChecksPassword # store the users mobile phone number in the Callback-Number radius attribute AuthAttrDef mobile,Callback-Number,request HandlerId otp_sms_challenge I had to use AuthBy HANDLER for forcing AuthBy OTP to generate the token by using PreAuthHook to delete the DecodedPassword. As you see I've tried StripFromRequest Password which didn't work. I was looking for a way to clear the password between the AuthBy LDAP and AuthBy OTP. Is there a way to do this? Cheers, Alex Am 2012-01-17 21:12, schrieb Mike McCauley: > Hi Heikki, > > I wonder if he should also look at AuthBy OTP? > Cheers. > > On Tuesday, January 17, 2012 09:39:27 PM Heikki Vatiainen wrote: >> On 01/17/2012 08:13 PM, Alexander Hartmaier wrote: >> >> Hello Alexander, >> >>> I'm trying to implement a two factor auth where the user has to enter >>> his Active Directory credentials. >>> Radiator checks those against the AD, if successful creates an OTP and >>> sends that to the mobile phone number fetched from the AD. >> Add State attribute to the challenge at this point. >> >>> A challenge is returned to the NAS. >> See this for how NAS should react to challenge. >> http://tools.ietf.org/html/rfc2865#section-5.24 >> >>> My problem is that I can't distinguish the initial request and the >>> challenge response which should skip the AD auth because this time the >>> password field holds the OTP response. >> State should be echoed back in the challenge response unless the NAS is >> badly broken. >> >>> By looking at the radius packets with tcpdump I couldn't find a >>> difference in the radius attributes sent that let me write two different >>> handlers. >>> >>> Ideas? >> Try something like this. Note that I have used a fixed value for >> challenge, but you could make it generic to protect against replay >> attacks or some other information that might be useful for selecting the >> correct handler for verifying the challenge. >> >> >> # Check challenge here >> >> >> >> # Generate OTP here and send challenge >> >># AD auth happens here >>AddToReply State=whatever >> >> >> >> >> >> Please let us know how it goes. >> Heikki *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Shibboleth authentication for wifi
Thanks for your feedback Heikki. We are eduroam users. We need to implement also this new kind of authentication. I know this new network would be without encryption, but politics wins over technology once again. Best regards. Il 16/01/2012 16.25, Heikki Vatiainen ha scritto: > On 01/13/2012 03:43 PM, Denis Pavani wrote: > >> My company plans to have a wireless network where authentication >> credentials come from a federation using shibboleth. >> We have in production a cisco wireless controller, and really I was >> trying not to bypass it for a different captive portal. >> Is it possibile to use "authby URL" redirecting creentials to a cgi >> which provides shibboleth authentication? >> Does anyone have experience with this? > I think this model is too straightforward to work. You need to allow > passthrough for every organisation that participates in the federation. > The users need to access the authentication web page of their home > organisation. > > After the authentication the user is redirected back to your login web > page and the web server sets the environment variables to reflect the > outcome of user's authentication. That is, you do not get any access of > credentials you could use to do the login. To actually use this > information, you would most likely to bypass the controller to utilise > information from shibboleth. > > One method to make shibboleth based WLAN login is this: > > 1. Create a captive portal that lets the users to select their home > organisation. When the select it, they get redirected to their home > login page. This portal most likely can not be in the controller but > needs a web server with shibboleth authentication modules. The > shibboleth authentication starts here. > > 2. The success URL users get from their home shibboleth login directs > them back to your web server. > > 3. The resource pointed by success URL (e.g., CGI script) creates a > temporary username/password into e.g. SQL database. > > 4. The user is redirected to controller's login page with GET or POST > request type. The request parameters specify the temporary username/password > > 5. Controller does RADIUS authentication against the SQL database > > 6. If the authentication is successful, as it always should be at this > point, the controller opens the captive portal. The user has now logged in. > > Something like the above should make it possible to use shibboleth for > WLAN authentication. Note that it does not enable encrypted radio, so > even if authentication is strong, users are still susceptiple for > eavesdropping. > > Have you considered eduroam for federated authentcation? > > Thanks! > Heikki > -- Ing. Denis Pavani CINECA - Dipartimento Sistemi e Tecnologie NOC - Network Operations Center phone:+39 0516171648 / fax:+39 0512130212 http://www.cineca.it "Siamo pagati per adattarci, improvvisare e raggiungere lo scopo" -- Gunny Highway ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] two factor authentication
Hello Alex - You can use an AuthBy INTERNAL between the other two clauses. See section 5.50 in the Radiator 4.9 reference manual ("doc/ref.pdf"). regards Hugh On 18 Jan 2012, at 21:16, Alexander Hartmaier wrote: > Hi Heikki and Mike, > I'm already using AuthBy OTP with my own ChallengeHook. > I've read RFC2865 yesterday but missed the State attribute, thanks for > the great pointer! > > Thats the working config I came up with: > > > Identifier tsa-otp-client-vpn > > Filename %L/tsa-otp-client-vpn.authlog > LogSuccess 1 > LogFailure 1 ># log the Handler Identifier to be able to distinguish between AD > and OTP auth failures > SuccessFormat %l:%U:%{Request:Callback-Number}:%{Handler:Identifier}:OK > FailureFormat > %l:%U:%{Request:Callback-Number}:%{Handler:Identifier}:FAIL > > > > Identifier otp_sms_challenge > > AuthByPolicyContinueUntilChallenge > > #StripFromRequest Password > > # clear the password to force AuthOTP to always generate a OTP > PreAuthHook sub { \ > my $p = ${$_[0]}; \ > my $rp = ${$_[1]}; \ > $p->{DecodedPassword} = ''; \ > } > AuthBy otp_sms > #AddToReply State="otp-challenge" > > > Request-Type="Access-Request" State="otp-challenge"> > Identifier tsa-otp-client-vpn-otp > > AuthLog tsa-otp-client-vpn > # Show any rejection reason to the end user > RejectHasReason > > AuthBy otp_sms > > > Request-Type="Access-Request"> > Identifier tsa-otp-client-vpn-ad > > AuthByPolicyContinueUntilChallenge > > # Show any rejection reason to the end user > RejectHasReason > > AuthLog tsa-otp-client-vpn > > > # Save time by never looking for a default > NoDefault > > Host ip1 ip2 ip3 > Port 389 > Version 3 > > # request timeout in seconds > Timeout 2 > > # don't try to reach the ldap for this amount of seconds after > failure > FailureBackoffTime 0 > > UsernameAttr samaccountname > # don't check the password, just for phone number lookup > #PasswordAttr > ServerChecksPassword > > # store the users mobile phone number in the Callback-Number > radius attribute > AuthAttrDef mobile,Callback-Number,request > > > > HandlerId otp_sms_challenge > > > > I had to use AuthBy HANDLER for forcing AuthBy OTP to generate the token > by using PreAuthHook to delete the DecodedPassword. > As you see I've tried StripFromRequest Password which didn't work. > I was looking for a way to clear the password between the AuthBy LDAP > and AuthBy OTP. > Is there a way to do this? > > Cheers, Alex > > Am 2012-01-17 21:12, schrieb Mike McCauley: >> Hi Heikki, >> >> I wonder if he should also look at AuthBy OTP? >> Cheers. >> >> On Tuesday, January 17, 2012 09:39:27 PM Heikki Vatiainen wrote: >>> On 01/17/2012 08:13 PM, Alexander Hartmaier wrote: >>> >>> Hello Alexander, >>> I'm trying to implement a two factor auth where the user has to enter his Active Directory credentials. Radiator checks those against the AD, if successful creates an OTP and sends that to the mobile phone number fetched from the AD. >>> Add State attribute to the challenge at this point. >>> A challenge is returned to the NAS. >>> See this for how NAS should react to challenge. >>> http://tools.ietf.org/html/rfc2865#section-5.24 >>> My problem is that I can't distinguish the initial request and the challenge response which should skip the AD auth because this time the password field holds the OTP response. >>> State should be echoed back in the challenge response unless the NAS is >>> badly broken. >>> By looking at the radius packets with tcpdump I couldn't find a difference in the radius attributes sent that let me write two different handlers. Ideas? >>> Try something like this. Note that I have used a fixed value for >>> challenge, but you could make it generic to protect against replay >>> attacks or some other information that might be useful for selecting the >>> correct handler for verifying the challenge. >>> >>> >>># Check challenge here >>> >>> >>> >>># Generate OTP here and send challenge >>> >>> # AD auth happens here >>> AddToReply State=whatever >>> >>> >>> >>> >>> >>> Please let us know how it goes. >>> Heikki > > > *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* > T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien > Handelsgericht Wien, FN 79340b > *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* > Notice: This e-mail contains information that is confidential and may be > privileged. > If you are not the intended recipient, please notify the sender and then > delete this e-mail immediately. > *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* > ___