Forum Discussion
wbrowne
Altostratus
AltostratusiRule for HTTP::cookie creation works once on the first login. Any login after that no cookie is created
when HTTP_RESPONSE {
# if table shoud be set then take record of the ClientIP and set encrytped cookie
if { [ACCESS::session data get session.custom.suppressmfa.setauthtable] == 1 } {
HTTP::cookie insert name $static::suppress_mfa(cookie) value $static::suppress_mfa(value) path "/"
HTTP::cookie expires $static::suppress_mfa(cookie) $static::suppress_mfa(seconds) relative
HTTP::cookie secure $static::suppress_mfa(cookie) enable
HTTP::cookie httponly $static::suppress_mfa(cookie) enable
HTTP::cookie encrypt $static::suppress_mfa(cookie) $static::suppress_mfa(passphrase)
HTTP::header "Cache-Control" "max-age=$static::suppress_mfa(seconds)"
}
}
}Hello,
I have an iRule that creates a cookie on HTTP_Response, sets an expiratoin, and sets a Cache-Control. This worked perfectly for months, then we upgraded to 14.1.4 it stopped working. The access policy has 2 logins, the first is an MFA login (microsoft authenticator) and the second is a domain login (username/pw). When the cookie is created and while it is still valid any further logins will suppress the MFA portion of the access policy. In the iRule "when Rule_Init" an array is created. In the array there are 4 variables. This is used to set the cookie "when HTTP_RESPONSE". Upon the next login "when ACCESS_SESSION_STARTED" checks the cookie and sets a "hash" variable. Then "when ACCESS_POLICY_AGENT_EVENT" does a compare of the "hash" to the "value" if they match then it sets the bypass. If they do not then it continues with the "when HTTP_RESPONSE" portion and tries to create the cookie. Like I said it creates it one time for one person but never again until I flip over to the standby or reboot. I am thinking there has to be some sort of cache going on. I have been working on this since we upgraded and can not figure out why it is no longer working any help would be greatly appreciated. I modeled this after this https://devcentral.f5.com/s/articles/Suppress-MFA-for-a-period-of-time I just adapted it for my needs. Below is the portion that is not working
wbrowneI was able to get this fixed with the help of a colleague. No matter what we tried in the response it always worked for the first person but no one after. We took the when HTTP_RESPONSE out completely and added a when ACCESS_POLICY_COMPLETES.
when ACCESS_POLICY_COMPLETED { if { [ACCESS::session data get session.custom.suppressmfa.setauthtable] == 1 }{ set sessionauth [ACCESS::session data get session.custom.suppressmfa.setauthtable] if {$static::AMIADEV_Cookie_debug } {log local0. "AMIA set auth table is $sessionauth"} table set tab_amia:[IP::client_addr] Authed $static::suppress_mfa(seconds) set taba [table lookup tab_amia:[IP::client_addr]] if {$static::AMIADEV_Cookie_debug } {log local0. "$taba"} HTTP::cookie insert name $static::suppress_mfa(cookie) value $static::suppress_mfa(value) path "/" if {$static::AMIADEV_Cookie_debug } {log local0. "cookie $static::suppress_mfa(cookie) set for $static::suppress_mfa(seconds)"} HTTP::cookie expires $static::suppress_mfa(cookie) $static::suppress_mfa(seconds) relative if {$static::AMIADEV_Cookie_debug } {log local0. "cookie expires in $static::suppress_mfa(seconds)"} HTTP::cookie secure $static::suppress_mfa(cookie) enable HTTP::cookie httponly $static::suppress_mfa(cookie) enable HTTP::cookie encrypt $static::suppress_mfa(cookie) $static::suppress_mfa(passphrase) ACCESS::respond 302 noserver "Location" [ACCESS::session data get session.policy.result.start_uri] "Cache-Control" "no-cache, must-revalidate" Set-Cookie "$static::suppress_mfa(cookie)=[HTTP::cookie $static::suppress_mfa(cookie)];path=/;secure;httponly;Max-age=$static::suppress_mfa(seconds)" if {$static::AMIADEV_Cookie_debug } {log local0. "policy completed"} foreach aHeader [HTTP::header names] { if {$static::AMIADEV_Cookie_debug } {log local0. "$aHeader: [HTTP::header value $aHeader]"}} unset sessionauth unset taba } }- Nikoolayy1
MVP
So the HTTP_RESPONSE event didn't match for the users after the first user?
If so this is strange and this as you mentioned did work for older versions. Maybe a bug or change in how the F5 processes packets in the newer versions.
What found is that HTTP_RESPONSE is not triggered for locally generated F5 response and as this is APM, maybe this can be case:
- Nikoolayy1
This seems complex. Have you checked with F5 ihealth if qkview shows a bug as it worked before and maybe the upgrade has a new bug? Also check for any TCL errors and you can contact the TAC as it worked before.
Is this from where you got the idea https://devcentral.f5.com/s/articles/Suppress-MFA-for-a-period-of-time ? You can check the post again as I see some changes and you can ask a question if in 14.4 there is something different.
- wbrowne
Nikoolayy1,
you are correct that is exactly what I modeled this after. I had edited my post to include that but the edit was no longer there. It is complex. However, the most complex parts are working jus the Response is what is not. Specifically the HTTP::cookie portions
- Nikoolayy1
I see that you posted in the other ducussion. While you wait you can add log local0 after HTTP RESPONSE to see if the HTTP response is at all triggered for the next clients after the first one. Also a log local0 after ACCESS::session data get session.custom.suppressmfa.setauthtable but before table set and log local after the table set .My idea is if possible to see where it breaks in the LTM log.
Also as I mentoned check in the F5 ihealth for under diagnostics if any bugs are detected for the commands that this irule worked and also check the ltm log for TCL error. It is possible after the upgrade a bug to be hit or irule command to have been removed. What was you previous version before this?
- wbrowne
Thank you I have put a log in. I also created a support ticket and working with a support engineer. I will upload to iHealth and check on bugs. Thanks for the suggestions
