<p>Thanks a lot Alexander. Your thoughts help me a lot. I will utilize python to get otp integrated and use its native lib. :)</p>
<p>I'm afraid our vpn client doesn't support otp. But when it passes user/passwd to radius. I think vpn client or NAS really doesn't care about your backend. I think for otp first, I must pass the user name with otp password together to otp server. For second ldap auth, I may strip off the user name prompt. It's a reverse version compared to usual AD/RSA way.</p>
<p>Another question for users file, for default users, should I put auth-type as my python or ldap? I'm a little bit confused there. If I only put python there, ldap module may not be executed.</p>
<p>Really appreciated your help. I feel more confident now for this project.</p>
<p>Thanks.</p>
<p>Lou</p>
<div class="gmail_quote">On Jun 18, 2011 6:11 AM, "Alexander Clouter [via FreeRadius]" <<a href="/user/SendEmail.jtp?type=node&node=4501373&i=0" target="_top" rel="nofollow" link="external">[hidden email]</a>> wrote:<br type="attribution">
> <br>> <br>> madmatrix <<a href="/user/SendEmail.jtp?type=node&node=4501373&i=1" target="_top" rel="nofollow" link="external">[hidden email]</a>> wrote:<br>>> <br>>> Thanks a lot Alexander. I'm familiar with python. So rlm_python might <br>>> a good choice for me. The main thing I want to do is to give remote <br>
>> vpn client a two-factor authentication.<br>>><br>> Depending on how your VPN works and what the clients can support, you <br>> could use the OTP to create the tunnel, and then EAP on the inside to <br>
> authenticate (and VLAN assign) the user. It would complement any <br>> wireless/wired 802.1X solution you have on site perfectly too.<br>> <br>> Although a good plan, as the OTP being the first hop means your user <br>
> credentials cannot be brute forced, your might find it complicated to <br>> pull off; at a first glance I am not sure how something like IPsec could <br>> be OTPised...maybe you will get more luck with OpenVPN.<br>
> <br>>> Since freeradius, pam and all opensource otp solution are available, I <br>>> think free two-factor authentication is doable instead the expensive <br>>> RSA solution. <br>>><br>> Always bear in mind, as long as the man hours you put in are less or <br>
> roughly equal to the RSA solution (over a three year period), then <br>> that's a worthwhile approach. Also gives you something to present as a <br>> talk to other organisations. :)<br>> <br>>> So the first authentication is against our AD. If successful, the <br>
>> system should generate one time password and send it to user through <br>>> SMS or the other ways. The user then put otp into the 2nd challenge <br>>> prompt. Freeradius authenticate this otp against otp server.<br>
>> <br>>> I already tried using pam to authenticate against AD or OTP. I was <br>>> trying to use PAM stack to make this happen. But it's hard to put some <br>>> scripts to send password to user between the two PAM modules. So I <br>
>> turned to FreeRadius to see if it can have some ways to do this.<br>>> <br>> For your initial version, I recommend when the user is prompted for a <br>> password, you get them to type "<otp> <password>" (RSA style). Check <br>
> the OTP *first* and then validate the password. You RADIUS <br>> configuration will look like:<br>> ----<br>> authorize {<br>> ....<br>> <br>> your_python_otp_script<br>> <br>> ldap<br>> <br>
> ....<br>> }<br>> ----<br>> <br>> 'your_python_otp_script' will *rewrite* User-Password so that when it <br>> gets to the ldap module it's as if the user just sent their password <br>> without the OTP. Of course if the OTP is incorrect, <br>
> your_python_otp_script can return instantly reject giving you your two <br>> factor authentication.<br>> <br>>> So if I use rlm_python, I can utilize some existing executable files <br>>> (like ldapsearch, ldapcompare, otp_auth) to directly authenticate <br>
>> against LDAP and OTP. To send OTP to user is much easier to do in <br>>> python too. Am I correct?<br>>> <br>> rlm_python will let you change how your OTP system functions quickly <br>> which is helpful as:<br>
> * newer flexibility technologies come along you want to use<br>> * users fix the initial approach too complicated. As the brains is <br>> really all in a python script, you should find it trivial to <br>> change to meet their needs<br>
> <br>> One word of warning, do *not* use system()/exec() or whatever python <br>> uses. Use a native LDAP module. Same with the OTP/SMS approach if <br>> possible. Calling OS commands like that, especially when there are <br>
> native libraries, is generally a Bad Idea(tm) and the coding gods *will* <br>> smite you for your crimes.<br>> <br>> Cheers<br>> <br>> -- <br>> Alexander Clouter<br>> .sigmonster says: Time as he grows old teaches all things.<br>
> -- Aeschylus<br>> <br>> -<br>> List info/subscribe/unsubscribe? See <a href="http://www.freeradius.org/list/users.html" target="_top" rel="nofollow" link="external">http://www.freeradius.org/list/users.html</a><br>> <br>> <br>
> _______________________________________________<br>> If you reply to this email, your message will be added to the discussion below:<br>> <a href="http://freeradius.1045715.n5.nabble.com/chain-two-authentication-modules-together-tp4499333p4501148.html" target="_top" rel="nofollow" link="external">http://freeradius.1045715.n5.nabble.com/chain-two-authentication-modules-together-tp4499333p4501148.html</a><br>
> <br>> To unsubscribe from chain two authentication modules together, visit <a href="" target="_top" rel="nofollow" link="external">
</div>
<br/><hr align="left" width="300" />
View this message in context: <a href="http://freeradius.1045715.n5.nabble.com/chain-two-authentication-modules-together-tp4499333p4501373.html">Re: chain two authentication modules together</a><br/>
Sent from the <a href="http://freeradius.1045715.n5.nabble.com/FreeRadius-User-f2740693.html">FreeRadius - User mailing list archive</a> at Nabble.com.<br/>