APM Cookbook Series: You Down with OTP? (pt1)
All corny early 90's hip hop jokes aside, if you're not down with OTP or One-Time Password by now, then this is definitely the place to be. By the time you finish this two part series you will understand and be able to deploy a complex OTP policy complete with error handling. We will start with the basics in part one and then drive it home in part two. Like many, my first experience with OTP and APM on the BIG-IP was guided by fellow F5'er, Per Boe's excellent write up from a post that none other than the illustrious, Jason Rahm shared with us way back in early 2011. As with all things tech, 3 years later things have changed quite a bit and although fundamentally OTP has not changed that much, our implementation has been streamlined. For instance, the once necessary iRule has been integrated and we can do some really cool new things with embedded dropdown options on the logon page. Cody's great Cookbook article here demonstrates the very popular dropdown use-case for domain selection. In part one we will review all of the necessary objects and configuration of those objects. Then we will start with a functional OTP Access Policy that leverages the objects we created to get familiar with the basic concepts. This will be very similar to the write up from 2011 but with an open-source SMS Gateway that anyone can use free of cost. Finally, we will wrap things up in part two with a deeper dive into OTP as a technology and create a more complex OTP policy. This policy will include a logon page dropdown (new in 11.5.x) that can dynamically select the use of SMTP and SMS delivery mechanisms, with full error handling, based on available AD attributes or logon page selection. By the end of these articles you will be more than down with OTP, I promise!! In fact you should be floored with all of the possibilities that VPE can provide by implementing policy branches to customize the UX....which is what it's all about right?? Well maybe...after SUX - the (Secure User Experience) of course :) BTW: This lab demonstration was a blast to build out and if you are anything like me, then the first time you hear that SMS alert come in on your phone, you will definitely smile. Try it out, have fun and post feedback! Prerequisites: You will need the following before proceeding with Part 1: A client to test from (Windows, MAC or Linux with any browser) Active Directory with the following attributes available and set with values; (mobile, mail) A BIG-IP with APM provisioned. (v11.x) - recommended 11.5.x. Your BIG-IP must be able to get to the Internet. A device capable of receiving SMS Part 1: Creating the Virtuals We will begin by configuring the Virtual Servers that will host the APM Access Policy. All you technically need is a standard virtual server listening on port 443 with an http and client side ssl profile applied. Given you are working in the Common partition, create your virtuals with the following commands. tmsh create ltm virtual /Common/ {destination /Common/:443 ip-protocol tcp mask 255.255.255.255 profiles add { /Common/clientssl {context clientside} /Common/http { } /Common/tcp { } } source 0.0.0.0/0 translate-address enabled translate-port enabled } Optional: Create a port 80 redirect so you don't have to remember to type "https" tmsh create ltm virtual /Common/ { destination /Common/:80 ip-protocol tcp mask 255.255.255.255 profiles add { /Common/http { } /Common/tcp { } } rules { /Common/_sys_https_redirect }} Verifying Resources AD - Do not move on until you can authenticate with an account (preferably a service account but any will do for this lab as long as it can authenticate and read). Instructions for validating authentication can be found below in Figure 1. Configure your Active Directory Object under: Access Policy >> AAA Servers Figure 1. Configuring AAA AD Servers To verify the above configuration before moving forward you can use the "adtest" command. *The special characters in the password are escaped with "\". adtest -t auth -h "s1.myfselab.com" -r "myfselab.com" -u serviceacct -w p\@\$\$w0rd1 [root@bigip1:Active:Standalone] config # adtest -t auth -h "s1.myfselab.com" -r "myfselab.com" -u user1 -w p\@\$\$w0rd1 Test done: total tests: 1, success=1, failure=0 Tip: use the debug option if you have failures. -d 1 adtest -t auth -h "s1.myfselab.com" -r "myfselab.com" -u serviceacct -w p\@\$\$w0rd1 -d 1 Once authentication is verified we can create our OTP HTTP Form, also found under Access Policy >> AAA Servers Figure 2. Configuring AAA HTTP Form A quick word on textbelt, a free open source SMS gateway and brain child of Ian Webster, a Software Engineer at Google. We all owe him a debt of gratitude and possibly a donation for maintaining a free, awesome and downright user friendly SMS service. There are a few limitations that you can get familiar with here: http://textbelt.com but in general this sublime open source SMS service can't be beat for ease of use and lab testing. Thanks Ian! Take a close look at the Form Method, Form Action, Hidden Form Parameters/Values and Successful Logon Detection Match Type and Value fields in Figure 2. Most of the parameters/values were dictated by the textbelt API and are included on the textbelt homepage but the Hidden Form Parameters/Values field has some unique customizations so that APM can insert custom variables per the session. Breakdown Let's break down the variables in the string for the Hidden Form Parameters/Values field: Values will be learned during certain stages of policy execution. For example, when the AD Query action takes place the "mobile" attribute will be learned and stored in memory as a session variable. When the OTP Generate action takes place then the value will be determined for that session variable. number=%{session.ad.last.attr.mobile}&message=OTP %{session.otp.assigned.val} Expires after use or in %{session.otp.assigned.ttl} seconds. The variable "{session.ad.last.attr.mobile}" will pull the value from the Active Directory Attribute for "mobile". The variable "{session.otp.assigned.val}" will pull the value from a secure memory space and insert it into the message body. The variable "{session.otp.assigned.ttl}" will display the timeout value in seconds for the OTP as configured in your policy. Ultimately the message will look like this when it is sent to the SMS Gateway: number=555123456&message=OTP 786341 Expires after use or in 300 seconds If you have problems, Ian also listed some troubleshooting commands that you can utilize. Make sure to check those out, assign all fields per the image above and move on once you have the syntax correct which should be fine as long as you followed the steps above. That's it for the pre-requisites. Now time for the fun part...tying it all together in VPE with an Access Policy. Access Policy Configuration Head on over to Access Policy>>Access Profiles>>Access Profiles List and click the "+". Create an APM/LTM type profile and take all of the defaults. Choose your language and hit "Finished". Now edit your policy. You should be here: Figure 3. Creating the Access Policy Add a logon page and take the defaults. Add an AD Auth object and set your AD Server. Figure 4. Adding AD Auth Add a message box or MB, off of the successful branch and keep the successful ending at deny. APM Pro Tip: This MB will serve as your successful ending alert and prevent you from having to manually clear sessions constantly during the policy testing phase. Figure 5. Adding a Message Box (MB) Your policy should now look like this: Figure 6. Visual Policy Now apply your new Access Policy to the Port 443 Virtual Server and test. If all goes well you should see this positive affirmation after successful authentication: Figure 7. Message Box - Positive Affirmation Adding the OTP Macro Figure 8. Adding the OTP Macro Add an Ad Query object, name it appropriately and choose your AD server. Set the Required Attributes to "mobile" and "mail". (We will only use mobile in Part 1 of this series) Figure 9. Adding AD Query & Required Attribs Edit the Branch Rules and delete the default expression "Primary User Group 100". Figure 10. Editing AD Query Branch Rules Add an OTP Generate object and take the defaults. Your policy should now look like this: Figure 11. Verify the Visual Policy - OTP Macro After the OTP Generate object add a variable assign object: Custom Variable: session.user.otp.pwd = session.user.otp.pwd Custom Expression: expr {[mcget {session.user.otp.pw}]} Figure 12. Variable Assign - Secure OTP (Select Secure from the list to define the session variable as secure. A secure session variable is variable that is encrypted in the session database. The secure session variable value is not displayed in the session report, or logged by the logging agent.) Next we are going to call on that HTTP AAA Form that we created earlier. Add an HTTP Auth Agent: Figure 13. Adding HTTP Auth Agent Add another logon page so the client has a place to enter their OTP password: Figure 14. Adding the OTP Logon Page Add an OTP Verify Object. Your policy should look like this: Figure 15. Verify Visual Policy - OTP Macro Edit your terminals to indicate success or failure: Figure 16. Editing Terminals You may need to add a new one. Make sure that the default stays on top: Figure 17. Adding New Terminals Now add the Macro to your main policy between the AD Auth and the MB: Figure 18. Adding the Macrocall Here is the final policy. We will keep the allowed ending set to "deny" for now until we are ready to go prime time with the site. Figure 19. Verify Visual Policy - Complete As long as you have your mobile number set under the AD Attribute and given your BIG-IP has outbound connectivity, then you should now be able to successfully test your new service and receive a SMS that, when received, looks like this: Figure 20. IOS - SMS Message Received If you successfully authenticate you should reach your affirmation again. Figure 21. Congratulations! Not only have you achieved success, you have completed part 1! Great job. Please be sure to check out part 2 where we will dive even deeper into APM and this OTP policy. Here's a sneak peak at the macro: You didn't think I was going to show you the whole thing yet did you?!!? ‘til next time…Send an One Time Password (OTP) via the MessageBird SMS gateway
Problem this snippet solves: This snippet makes it possible to send an One Time Password (OTP) via the MessageBird SMS gateway. This snippet uses iRuleLX and the node.js messagebird package to interact with the MessageBird API. How to use this snippet: Prepare the BIG-IP Provision the BIG-IP with iRuleLX. Create LX Workspace: messagebird Add iRule: messagebird_irule Add Extension: messagebird_extension Add LX Plugin: messagebird_plugin -> From Workspace: messagebird Install the node.js messagebird module # cd /var/ilx/workspaces/Common/messagebird/extensions/messagebird_extension # npm install messagebird --save messagebird@2.1.4 node_modules/messagebird # irule To make it works, you need to install the irule on the Virtual Server that publish your application with APM authentication. access profile If you already have an existing access profile, you will need to modify it and include some additionnal configuration in your VPE. If you have no access profile, you can starts building your own based on the description we provide below. Configuring the Visual Policy Editor The printscreen below is a minimal Visual Policy Editor used to make MessageBird OTP Authentication works properly : For a larger version of this image please download here. Irule Event – MessageBird This is an irule event with the ID set to ‘MessageBird’. This will trigger the messagebird_irule to come into action. MessageBird Status This is an empty action with two branches. The branch named "successful" contains the following expression : expr { [mcget {session.custom.messagebird.status}] contains "successful" } Message Box This is a message box that will inform the user that there was a failure sending the One Time Password. messagebird_irule ### ### Name : messagebird_irule ### Author : Niels van Sluis, <niels@van-sluis.nl> ### Version: 20180721.001 ### Date : 2018-07-21 ### when ACCESS_POLICY_AGENT_EVENT { if { [ACCESS::policy agent_id ] eq "MessageBird" } { # Set MessageBird access key set accessKey "<ACCESS_KEY>" # Set user-friendly message which will be send prior to the OTP itself set message "Your OTP is: " # Set username used for logging purposes only set username "[ACCESS::session data get session.logon.last.username]" # Set OTP generated by BIG-IP APM which will be added to the SMS message. set generatedOTP "[ACCESS::session data get session.otp.assigned.val]" # Set phonenumber to send the SMS to set telephoneNumber "[ACCESS::session data get session.ad.last.attr.telephoneNumber]" # Set the sender of the message. This can be a telephone number (including country code) or an alphanumeric string. # In case of an alphanumeric string, the maximum length is 11 characters. set sender "MessageBird" if {[info exists username] && ($username eq "")} { log local0. "Error: username variable is empty; no OTP sent." return } if {[info exists generatedOTP] && ($generatedOTP eq "")} { log local0. "Error: generatedOTP variable is empty; no OTP sent for user $username." return } if {([info exists telephoneNumber] && $telephoneNumber eq "")} { log local0. "Error: telephoneNumber variable is empty; no OTP sent for user $username." return } set rpc_handle [ ILX::init messagebird_plugin messagebird_extension ] if {[ catch { ILX::call $rpc_handle sendOTP $generatedOTP $telephoneNumber $sender $message $accessKey } result ] } { log local0. "sendOTP failed for telephoneNumber: $telephoneNumber, ILX failure: $result" return } log local0. "MessageBird status for user $username ($telephoneNumber): $result" ACCESS::session data set session.custom.messagebird.status $result } } Code : /** *** Name : messagebird_extension *** Author : Niels van Sluis, *** Version: 20180721.001 *** Date : 2018-07-21 **/ // Import the f5-nodejs module. var f5 = require('f5-nodejs'); // Create a new rpc server for listening to TCL iRule calls. var ilx = new f5.ILXServer(); ilx.addMethod('sendOTP', function(req, res) { var generatedOTP = req.params()[0]; var telephoneNumber = req.params()[1]; var sender = req.params()[2]; var message = req.params()[3]; var accessKey = req.params()[4]; var params = { 'originator': sender, 'recipients': [ telephoneNumber ], 'body': message + generatedOTP }; var messagebird = require('messagebird')(accessKey); messagebird.messages.create(params, function (err, response) { if (err) { //console.log(err); return res.reply('failed'); } //console.log(response); return res.reply('successful'); }); }); // Start listening for ILX::call and ILX::notify events. ilx.listen(); Tested this on version: 13.0Complete MFA solution with GA stored in Active Directory
Problem this snippet solves: All modern business applications require Multi-Factor Authentication (MFA) to be used for remote access by employees. There are many vendors on market selling enterprise MFA solutions that may be utilised with F5 BIG-IP Access Policy Manager (APM). Those solutions are complex and allow customers to create flexible policies which allow them to decide when and whom will be authorised to access protected applications. But what about those customers which have no needs for using complex enterprise solutions or does not have adequate budget for such spendings? How to use this snippet: For those customers I would like to present my One-Time Password (OTP) application which requires BIG-IP LTM/APM/iRulesLX. Shared secret value is stored in Active Directory and QR code is generated in user's browser. All you need after implementing this application on your BIG-IP is. to ask your users to get any OTP-compatible mobile application, like Google Authenticator or Microsoft Authenticator Please see https://github.com/akhmarov/f5_otp/ for instructions UPDATE 1: New version now support APM 15.1+ Modern Customization UPDATE 2: Added trusted device support UPDATE 3: Added multi-tenancy support Tested this on version: 15.1Local Hostname field in BigIP SMTP settings
Hi, I am a little confused about what should be the local hostname in SMTP settings, all the help and documentation say is "Type the host name used in SMTP headers in the format of a fully qualified domain name. This setting does not refer to the BIG-IP system’s Hostname." I would assume that host name should be BigIp's as I want BigIp to send an email out!! or am I not understanding it? Please suggest, Thanks
Issues with External logon page for 2FA (OTP) in BigIP/APM
My company has implemented external logon page using the consistent look & feel with the rest web GUI in our company. It works pretty well with BigIP/APM for username/password authn flow. Now my company has a new requirement to enable One Time Password (OTP) with the username/password authn mechanism. Naturally we have tried to reuse the same external logon page for OTP verification. It works also normally as expected when the OTP is right. However, if a wrong OTP code was typed in the external logon page, the APM will premature the ongoing APM evaluation and set the policy result as "redirect" although the OTP Verify, Max Logon Attempts Allowed is by default set as 3. If the built-in Logon page with BigIP's default GUI look & feel is used for OTP verification, BigIP/APM works as expected in the situations with wrong OTP code. Only when three wrong OTP codes were attempted, will BigIP/APM redirect browser to the authn-failed page specified in VPE. Can someone shed the light on or share any experiences of using an external logon page as OTP Verify GUI and the Max Logon Attempts Allowed still works fine? Thanks in advance!
APM OTP not being received
We're investigating an issue where OTP isn't being recieved by users. The logging just seems to to suggest a black hole. User confirms not in junk etc. This doesn't happen all the time, it is quite sporadic. Apr 6 10:46:19 BIGIP1 notice apmd[14867]: 01490010:5: /Common/Citrix_XenDesktop:Common:82caf589: Username '*removed*' Apr 6 10:46:39 BIGIP1 notice apmd[14867]: 01490115:5: /Common/Citrix_XenDesktop:Common:82caf589: Following rule 'Pass' from item 'Firewall' to terminalout 'Pass' Apr 6 10:52:54 BIGIP1 notice tmm2[22524]: 01490502:5: /Common/Citrix_XenDesktop:Common:82caf589: Session deleted due to user inactivity. A successful one reads as: Apr7 05:03:48 BIGIP1 notice apmd[14867]: 01490010:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Username '*removed*' Apr7 05:04:21 BIGIP1 notice apmd[14867]: 01490115:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Following rule 'Pass' from item 'Firewall' to terminalout 'Pass' Apr7 05:04:59 BIGIP1 notice apmd[14867]: 01490115:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Following rule 'Successful' from item 'OTP Verify' to terminalout 'Success' Apr7 05:04:59 BIGIP1 notice apmd[14867]: 01490220:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Pool '/Common/Pool_A' assigned Apr7 05:04:59 BIGIP1 notice apmd[14867]: 01490005:5: /Common/Citrix_XenDesktop:Common:35ba7aa7: Following rule 'fallback' from item 'Pool Assign ALGCTXA' to ending 'Allow' Is there any additional logging that can be put on to see what is going on with sending the OTP email? Thanks in advanceBreaking up with your identity: it’s not me, it’s you!
Let me tell you why I’m glad my gran is not on the Internet. When it comes to technology securitymost of myexperienceis with customers: with other peoples systems, not mine. However, today I write about a personal experience that scares me a little. I signed up for a Gmail account back when it was an invitation-only beta service. My first impression of it was nothing short of wow! This exclamation inspired by its simplicity, and the fact that it offered an enormous amount of free space. I recall being impressed by that fact that in a time of rapid innovation the Gmail team weren’t trying to do too much with it. I think it was the first time I was able to describe a web-based service as being humble and don’t think I’ve seen anything like it since, until maybe Medium. Over the years my relationship with Google grew to include Google Docs, Google Sites, Analytics and even ‘Google Apps for Your Domain’. Our relationship blossomed – not quite this far, but we were on a good thing. Being an early adopter often means getting first pick of your account name and avoiding the dreaded nathanpearce1234. One cannot win all the time and I don’t always get my way but occasionally there is room for compromise. For example, when I signed up for Twitter, @NathanPearce was already taken. Consequently, and like many others, I reversed my name and have been happily tweeting from @PearceNathan for a few years now. It did weird me out a little when @NathanPearce followed me earlier this year (are you reading this post, @NathanPearce?). For the sci-fi fans: fortunately, I didn’t implode, burst into flames or leap to a parallel universe at this occurrence. I’ve managed to come to terms with the fact that there are a number of people in the world named Nathan Pearce. Mum, you were wrong! There’s a Nathan Pearce working at Sony Entertainment, another is a web savvy 9 year old, and then we have the most interesting Nathan Pearce of all – the web-challenged, heavy-metal loving, corn farmer. And it’s not just his music and farming preferences I’m familiar with. I also know where he travels, his preferred dating sites (a niche farmer-friendly service) and a number of other interesting factoids. How do I know all this? Because Nathan-corn-metal, as he will be known hereafter, keeps providing my email address to people thinking that it is his own. Before you start speculating as to how this mishap can occur, a lesser-known fact about Gmail is how it handles a period before the @ symbol. With Gmail, the following email addresses are all the same: firstlast@gmail.com first.last@gmail.com f.irstlast@gmail.com And, so on. I’ve heard of some clever people using this to their advantage: providing one format for family, another for shopping on-line, etc., and then using Gmail filters to file (delete) messages as appropriate. So, I can confirm that this isn’t a simple formatting mistake. Nathan-corn-metal believes that my email address are belong to him. This mistake (delusion) might seem trivial to some but has also lead to a few interesting circumstances. Email confirmation Nathan-corn-metal does get on the net from time to time. My first interaction was when he signed up for Decibel Magazine – a heavy metal e-zine. I’ve started to enjoy the monthly issues and have been following the developments of many a ‘Lars’ and the up and coming band, Monster Magnet. I’m still not listening to the genre but I’ve developed an appreciation that was never there before. I do hope he renews again this year, for the third time! What Nathan-corn-metal has not learned to appreciate is that when one sign’s up for a service on-line, there often lacks a process to confirm one’s contact details. The moment he hits Submit, the subscription was handed over to me and, unfortunately, I have no way of letting him know of the error, as email is the only detail of contact provided. Telephone bookings I’ll admit that the Decibel Magazine subscription didn’t actually tip me off as to the problem at hand. It was the creation of an on-line travel account. I assume Nathan-corn-metal’s account was setup over the telephone for the following reason’s: the login id was the email address there was a flight booking already in the account So, how did I know there was a flight booked, you may ask? Was there not a password on the account? Yes, there was a password on the account. However, I didn’t need it as there was a link in the automated email addressed to me that went straight to the booking, providing me with access to everything including account preferences and the booking page. Good Samaritan for the good intention At this point I started thinking about how I would feel if I’d made such a mistake and I decided to try and fix things. Surely, the travel company had a contact phone number. I called the travel agency asking to speak to a representative about an existing booking. To their credit, they were very quick to answer the phone. Unfortunately, every moment after this was truly shocking. I didn’t play any games for, despite his apparent learning difficulties, Nathan-corn-metal, for all I know, could be a decent chap. But my attempt at doing the right thing was met with resistance. Maybe it was a lack of understanding of the urgency of the problem? I didn’t know but I had to attempt a new tactic. Being told over and over again that it wasn’t the travel agencies problem was not good enough. Next, I explained it in terms of liability by advising that I would be altering the flight details and then maybe booking myself a trip to Venice using their customer credentials. Then by explaining that as they were the ones to leak said credentials it should make interesting reading in the news. Suddenly, my suggestion that they lock down the account and contact Nathan-corn-metal by telephone immediately was set in motion. Should this have been so difficult? Lesson learned? When so many on-line services fail to provide sufficient checks to ensure we are who we say we are, it is suddenly very simple for a lot to go wrong. I’m delighted to say that I still communicate with my grandparents via hand-written letter for I don’t believe that the Internet is a safe place for them. While the law might have clear definitions for liability, in reality, what is practiced is far from acceptable. Some organizations are building in security checks but only from the perspective of hacking attempts. What about a simple mistake at the time of account creation as done so by the aforementioned head banging tractor driver? In this example, holding off on the creation of an account until verification via OTP (One Time Password) for example would eliminate many false positive during account creation. Never underestimate the human element!
