Good day Heikki. I have completed testing based your input for configuration changes and I now have a working config that meets the requirements. Users have to enter their username and password and then the OTP received on their mobile device. I will post a sanitized working config for reference in the near future. More testing needs to be completed before it can be cleaned up and I am ready to call it good.
Thanks again for your input! Joe. > On Dec 22, 2015, at 8:38 AM, Joe Honnold <joe_honn...@starkey.com> wrote: > > Thanks for the reply. I will give it a shot and see what happens. > > Cheers! > Joe. > > > > > On 12/22/15, 8:31 AM, "radiator-boun...@open.com.au on behalf of Heikki > Vatiainen" <radiator-boun...@open.com.au on behalf of h...@open.com.au> wrote: > >> On 12/21/2015 05:23 AM, Joe Honnold wrote: >> >>> I am working on a project for sending users OTP’s to gain access. I >>> would like to have users authenticate to AD and once accepted use Authby >>> OTP to generate a token and send it to the user via SMS. The user >>> would then enter the OTP and gain access. >>> I have done a bit of researching and found a config that I am using as a >>> base. http://www.van-sluis.nl/?p=345 >> >> There is one major difference between the example config you were using >> and what you want to achieve: note that the example AuthBy LDAP2 had this: >> >> # We don't do authentication. Authentication is done by OTP. >> NoCheckPassword >> >>> The Authby LDAP2 in my config is working as expected but the Authby OTP >>> is not. It is a bit confusing at this point as I am unsure how to debug >>> the Authby OTP failure to find the exact issue. >> >> I'd say the problem is that AuthBy OTP sees a password and thinks this >> is the OTP. >> >>> My expectation is that if the Authby OTP was working right a >>> one-password would be generated and the sent to the users mobile number >>> found in AD. >>> >>> Any ideas where to start with this one? >> >> I think the authentication flow needs to be changed with something like >> this: >> >> <AuthBy LDAP2> >> # Add this, otherwise unchanged >> PostAuthHook sub {my $p = ${$_[0]}; $p->{DecodedPassword} = '';} >> </AuthBy> >> >> <AuthBy OTP> >> # Add this, otherwise unchanged >> AddToReply State=otp-check >> </AuthBy> >> >> # New Handler goes here: Verify the OTP >> <Handler State=otp-check> >> AuthBy SSLVPN_OTP >> </Handler> >> >> <Handler Client-Identifier = juni-sslvpn> >> # Unchanged >> </Handler> >> >> >> The idea is this: >> 1) Request first hits the current Handler >> 2) Once AuthBy LDAP2 is done, it clears the password >> 3) AuthBy OTP sees the empty passwords and generates the OTP >> 4) AuthBy OTP adds State in the Access-Challenge >> 5) The Access-Request with OTP will now contain 'State=otp-check' >> request attribute >> 6) The new Handler processes the request and does just the OTP verify >> >> Please note the above is untested, but I'd say it should match how the >> two phase authentication should go. >> >> Please let us know if the above helps, >> 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 > _______________________________________________ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
