Forum Discussion
clesan201305_11
Nimbostratus
NimbostratusGoogle Authenticator iRule Verification
Hi,
I've been following this article: https://devcentral.f5.com/articles/two-factor-authentication-with-google-authenticator-and-apm
To implement two-factor authentication with APM. After creating an access policy, data group and all the likes, I find that the APM is expecting a different code than the authenticator shows. I found out by printing the variables that I enter as a code, and the variables that the APM expects as a code, into the logs. The whole process itself works. The iRule is triggered, the username is found in the datagroup, and the calculations are made. It's just expecting a different code. For example, my code will say "781023", and the BIGIP will be expecting code "826015". I tested this with multiple different accounts and the same results all around. I'm wondering if Google just changed its algorithm a few years ago and the article became outdated, or if something in recent F5 versions has changed that changes the calculation algorithm. Has anyone done a recent implementation with this iRule without any issues? I quadruple-checked everything and added log entries to every part of the iRule. I know it's being triggered correctly, but it's just coming up with a different expected code than Google is.
In that article, there are 2 comments by people with the same issue on 11.5, so at least I'm not alone :-)
Binh_Luong_1782We have the same issue since we upgraded to 11.6 from 11.3. Each time we load the config we see: "/Common/Google_SoftToken_Generator_V3:33: warning: [use curly braces to avoid double substitution]" Maybe that's the reason the code calculation is different. We couldn't figure it out how to fix the code. So we just move Google Authenticator to another F5 box which is still on 11.3. I hope someone can look into the GA code and make it work for 11.6 otherwise we have to stop using it.
My two cents.
ArieAltostratus
The error could be caused by the slight difference between the way 11.3 and 11.6 parse Tcl.
In my experience it's usually due to the use of the
command. Here's how I fixed one of the offending lines:exprBefore:
HTTP::respond 301 Location "http://www.domain.org/blog/$DstPath/[expr ([string length [HTTP::query]]>0)?"?[HTTP::query]":""]"After (note the added curly braces):
HTTP::respond 301 Location "http://www.domain.org/blog/$DstPath/[expr {([string length [HTTP::query]]>0)?"?[HTTP::query]":""}]"- Arie
Here's another example:
Before:
set cookie_expire_date [clock format [expr [clock seconds] + $cookie_expire] -format "%a, %d-%b-%Y %H:%M:%S GMT" -gmt true]After:
set cookie_expire_date [clock format [expr {[clock seconds] + $cookie_expire}] -format "%a, %d-%b-%Y %H:%M:%S GMT" -gmt true] - Binh_Luong_1782
Thanks Arie,
I will give it a go and see if that will fix the issue.
Cheers.
- ArieAny luck?
- Binh_Luong_1782
Hi Arie,
No luck. I fixed all the expr with curly braces. But the F5 is expecting a different code than my Google code on the iPhone.
Binh
- ArieAre you still seeing the errors when you verify the config?
- Binh_Luong_1782
Nope, no more errors using the curly braces. But the Google code is still wrong. As I don't know the logic of the calculations, so not sure if the curly braces are correct are not.
- Sam_Hall
I know this thread is old, but I just went through the same process trying to get the otp iRule working as normal without warnings.
The problematic expr statements contain string concatenation used to generate hex values for bitwise operations. It wont work as expected if you simply wrap that in curly brackets, so I just break it up a little. For example this becomes this...
set o [expr 0x$k ^ 0x5C ] set i [expr 0x$k ^ 0x36 ]set kh 0x$k set o [expr {$kh ^ 0x5C} ] set i [expr {$kh ^ 0x36} ]