On Sun, Nov 12, 2017 at 11:16 AM, Kevin Cernekee <cernekee at gmail.com> wrote: > I worked on the original stoken integration, but have only ever used > it with Cisco VPNs. It looks like the Juniper logic was updated in > this commit: > > commit 1ff34cb9689fbaf57decac537df1e32e799bb9c7 > Author: Janne Juntunen <janne.juntunen at hermanit.fi> > Date: Tue Nov 29 22:37:22 2016 +0000 > > Add support for Google Authenticator 2fa on Juniper VPN > > We resently changed our Juniper VPN from SMS 2fa to use Google > Authenticator instead. Before it worked perfectly with "openconnect > --juniper" switch, but after the change all we got was: > > Unknown form ID 'frmTotpToken' > and a dump of the form. > > I spent some time debugging the issue, and managed to write a very > simple fix for it. > > Signed-off-by: Janne Juntunen <janne.juntunen at hermanit.fi> > Signed-off-by: David Woodhouse <dwmw2 at infradead.org> > > Maybe the Google Authenticator form (OC_TOKEN_MODE_TOTP) needs to be > handled differently from the RSA SecurID form (OC_TOKEN_MODE_STOKEN). I had done some more digging and adding: + strcmp(form->auth_id, "ftmTotpToken") && + strcmp(form->auth_id, "frmLogin")) gets me part of the way there. The problem is both the 2FA and actual password forms use the same frmLogin form type and type="password" form field. I initially thought that was the only problem so I hacked http.c to set a vpninfo->token_successful (and then skipped generating a token if that was already successful). That still didn't solve my problem and I used --dump-http-traffic and see that the stoken code being sent is completely different than what the stoken command actually generates. I had no idea why that would have been the case. That's where I was last at when I put this aside to get real work done :) Andy
