Two-Factor Authentication With Google Authenticator And APM
Introduction
Two-factor authentication (TFA) has been around for many years and the concept far pre-dates computers. The application of a keyed padlock and a combination lock to secure a sing...
Published Feb 21, 2012
Version 1.0George_Watkins_
Historic F5 Account
Joined September 17, 2008
George_Watkins_
Historic F5 Account
Joined September 17, 2008
Cthulhucalling_
Nov 12, 2014Cirrus
The sample doesn't seem to work anymore, but here's the steps for creating an APM policy for AD + Google auth
1. Login page. For field 3, change it to a text type, and change the session and post variable names to ga_code_attempt. Change "Logon Field Input 3" to "Google Auth"
2. AD Auth. Set up to auth against your domain controller
3. AD Query for object attribute. Add a required attribute for wherever you are storing the shared key. For testing, I put mine in the 'mobile' attribute for my user account. Yes, I know this is not secure. Delete the default branch rule, create a new one. Call it "Has shared key". Condition is "Active Directory Query has passed".
4. Create an iRule Event object attached to the "Has shared key" branch. Call this "Google Auth verify". For the id, enter "ga_code_verify". Delete the default branch rule. For simplicity's sake just create 1 branch. Call the first one "Success". Go to Advanced enter the expression "expr { [mcget {session.custom.ga_result}] == 0}". Fallback shouuld go to a Deny
5. Attach your resource assigns and ALLOW statement to the Success branch.
Assign this APM policy to a virtual server, add the google_auth_verify_apm iRule to the server. Modify the iRule as instructed above to change ga_key_storage to 'ad' and ga_key_ad_attr to whatever attribute you're using ('mobile' in my case).
Generate your shared secret and paste it into your user attribute and test. Works like a charm. Make sure that the clock on your F5 is using NTP as the the time needs to be accurate.