otp
5 TopicsAPM 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 advance426Views0likes0CommentsIssues 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!486Views0likes0CommentsiRule to decrypt and rewrite RADIUS User-Password AVP
In the RADIUS protocol, the user's cleartext password is transmitted inside Attribute-Value Pair (AVP) 2, padded with null characters as necessary, and then encrypted by the shared secret by XOR'ing it across the authenticator somehow or other. The technical details of how this works is a bit above my level of understanding as I'm not a cryptography expert. We have an infrastructure where our PAN VPN Gateway prompts a user for their username and password. In our environment, after the password, the user appends a fixed-length HOTP token from a Yubikey. The backend FreeRADIUS server has been configured to decrypt the password received, extract the fixed-length token, and perform backend checks to our LDAP and token servers. FYI, the password is encoded as PAP prior to RADIUS encryption in our setup, which is why this works; CHAP would prevent this from working. We've been having trouble with the stability of our FreeRADIUS server and we would like to leverage our much more stable Aruba ClearPass infrastructure which is load balanced globally with our GTMs and LTMs and highly stable. This also moves control of the RADIUS piece away from the systems team and onto the network team (me, specifically). Unfortunately, ClearPass doesn't have a direct mechanism to break the password from the token, and PAN doesn't have a way to transmit the token separately. This is where we would like to leverage an iRule. Basically, the way I envision this working is as such: Decrypt the password+OTP that is received from PAN using the authenticator value and shared secret Rewrite AVP 2 as just the password, encrypted by the shared secret (make sure to adjust the length of the AVP) Insert AVP 17 (which is not defined by the IEFT) with the token (ClearPass can be configured to look for this by modifying its RADIUS dictionary). Rewrite the length value at layer 7 if necessary - not sure if this would happen automatically by the F5; probably not. Ship the modified RADIUS packet to ClearPass I know how to accomplish all of this on the ClearPass side, but my dev skills are weak, I'm not very familiary with Tcl, and I don't have a solid understanding of how to encrypt/decrypt the password correctly. I've search high and low but the only solutions for decrypting the password seem to be written in languages that are even more difficult to understand like C. I obviously understand it is too much to expect someone to write the entire solution for me, but any advice on where to start would be very helpful. I think the trickiest part for me would be the encrypt/decrypt step.Solved2.9KViews0likes21CommentsLocal 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, Thanks555Views0likes2Comments