Forum Discussion

ted_haining_909's avatar
ted_haining_909
Icon for Nimbostratus rankNimbostratus
Apr 24, 2013

session table calls causing irule failure and tcp reset in LDAP authentication

I have tried filing a support incident to help resolve the issue I will describe here because appears to be an OS sofware version issue, not an iRule issue. So far, the support engineer there has told me that it is outside his scope and that I should bring it up here.

 

I have an LTM that is to be deployed as part of the back end of a big data/business intelligence mobile app in order to enable scalability.

 

 

I created an iRule which enhances the standard _sys_auth_ldap rule to perform three additional types of tasks:

 

1. perform some elementary HTTP URL parsing to accept only URLs which the mobile app can legally produce,

 

2. use data returned with successful LDAP authentication to make decisions about where the HTTP connection should be serviced,

 

3. use the session and table commands to count the number of bad app login commands and lockout an app when too many bad logins have occurred.

 

This iRule was tested extensively on an F5 LTM/VE running 11.2.1 Build 797.0 during the last few months. For business reasons, we are forced to deploy this same iRule on a LTM 1600 running 10.2.4 Build 595.0 Hotfix HF3 for production. In the production configuration, the session and table commands are failing about 50% of the time, and in a way that leaves no error messages that I can find in any logs, and results in the iRule stopping and a TCP reset being sent to a script used for testing mobile app registration and initial login.

 

 

The exact place I am commonly seeing the problem is early in the AUTH_RESULT portion of the iRule where checks to see if any failed login attempts have previously been made and cleared if the current attempt is successful:

 

 

when AUTH_RESULT {

 

set auth_status [AUTH::status]

 

HSL::send $hsl "$hsl_lvl Auth result! $auth_status for $conn_id"

 

 

if {not [info exists tmm_auth_http_sids(ldap)] or

 

(not [info exists tmm_auth_http_collect_count])} {

 

return

 

}

 

if { $auth_status == 0} {

 

incr tmm_auth_http_successes

 

array set auth_response_data [AUTH::response_data]

 

set auth_deploy [lindex [array get auth_response_data ldap:attr:description] 1]

 

HSL::send $hsl "$hsl_lvl Redirecting $device_id to $auth_deploy for $conn_id"

 

clear any failed login attempts

 

if { $restful_auth_name != "legacy_deploy" and

 

$restful_auth_name != "new_deploy" and

 

[table lookup -subtable "failed_login" $restful_auth_name] != "" } {

 

table delete -subtable "failed_login" $restful_auth_name

 

}

 

set auth_pass 1

 

node $auth_deploy 8080

 

}

 

 

The 'table lookup -subtable "failed_login" $restful_auth_name' command succeeds or fails with about equal frequency.

 

Can anyone help?

 

 

Thanks,

 

Ted

 

application delivery
dev
DevOps
irules

3 Replies

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Apr 24, 2013
    I believe you may be running into this error on your 10.x platform:

     

     

     

    CR140154: This release does not support using a command that suspends iRule processing (session, persist add/lookup/delete, table, after) in the AUTH_RESULT event in an iRule. There is no workaround for this issue.

     

     

     

    It appears to have been resolved in 11.1.0. That said, I have been able to work around this issue on 10.x platforms by doing the table processing in other events. If you need more help, please post your entire iRule.

     

  • ted_haining_909's avatar
    ted_haining_909
    Icon for Nimbostratus rankNimbostratus
    Apr 25, 2013

    Thanks for the help, Kevin. That's not the best answer I could get, but at least it points out the way forward.

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Apr 25, 2013
    Like I said, there are ways around this. With ACA OCSP (client certificate) I can set a local variable in AUTH_RESULT and pick it up in CLIENTSSL_HANDSHAKE to do the table commands. You should be able to do something similar.