For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

navgup_66025's avatar
navgup_66025
Icon for Nimbostratus rankNimbostratus
Aug 08, 2013

Auth_Status and Persist

1) I have PoolK and PoolF and default pool has to be PoolK

 

2) first client request always go to PoolK

 

3) Check if client has been authenticated to PoolK using Auth_status command, if YES persist always on PoolK

 

4) Check if client has been authenticated using Auth_status, If NO, send it to PoolF and persist there.

 

 

 

What kind of auth profile is recommended for http traffic?

 

Is it better to have this check in HTTP_REQUEST or HTTP_RESPONSE?

 

Could please help me write the irule? thanks

 

 

 

20 Replies

  • Is there a better way to post or send files to you. I don't want it to be publicly available. But any way, i am sending first 6 http traffic from the fiddler. As you can see Authorization header is pretty big and always starts with YII..

     

    GET https://portal1.net/_images/portal12_login_header.gif HTTP/1.1 Accept: / Referer: https://portal1.net/nad Accept-Language: en-US User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C) Accept-Encoding: gzip, deflate If-Modified-Since: Wed, 31 Jul 2013 22:59:05 GMT Host: portal1.net Connection: Keep-Alive Cookie: PD-S-SESSION-ID-PROD2=2_1_1--3Ekvrq-aNe2dMkB2vNRgZxck0lWiWgxi2WMogRbtTsYNm; BIGipServeriportal1_test_Ashit=3142023068.47873.0000 Authorization: Negotiate YIIGWwYGKwYBBQUCoIIGTzCCBkugMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBhUEggYRYIIGDQYJKoZIhvcSAQICAQBuggX8MIIF+KADAgEFoQMCAQ6iBwMFACAAAACjggSBYYIEfTCCBHmgAwIBBaEJGwdBRFUuRENOoh8wHaADAgECoRYwFBsESFRUUBsMamVuaWUuYW8uZGNuo4IERDCCBECgAwIBF6EDAgEDooIEMgSCBC49pfwnnobj9pJZ8FUfd40vqcR2s0DCyJJriGDDcNaFQ4HbJjypsRynavruyFjckkatP7zfyIJ3rQmAt8ulNZkF2+i4nxakh8RsrIFPAWvR03u95/r4N44HYJbKjNuQC8VaqHVD1lAVzE3kJe9zeanLa/0JUvPUGpstM5wXsIOLbVABW+/kcX4dWOL4joOvW1k6hyGqi/q0BL+hcPoFxJJisc3gTNalbFzpdVV3QqxiQrhFHXrFO8BcvJHTMyjUbkL3Y8AFWxXQ4bbfTuGBvV9jFhh05C/dDDKecoMLLMjjS++T3jQffpUrrr1I0+ypdTvdPQ1+n4FQA86IBOUq25PaAoABov0DPFZRaagggX6/146JhMUOlZMXESksTJ+yHBIBZdkwV6zPylcFQ1r2sJ1cal6+uf6q3+aIBZo8rRSzu3oZBf3PwLZjnSQWO0NFAbQujULCgfeqmVHzapJLiYbaF0sOY/xwcnN5t2/EymmkrxLUqIH0xxDwYYyrjzgYNpqEG4805Ckpp1ascrfD9TZIVFTFvb9VuvlWEMS1V63fE/HxXkTyLMfNBb1xZuZUE9S8wgrix8uvx3hjr3pPItduCay7GX9N0W49zxVbi6M81Zntvf2LgJO6/4dIdATY+iuJh0RAYpBMXiZUSD5pZOvVdpL52c917AbBZ5n5cL0gOr5EFN3lyO3kh43wV9i3gQLqQnXQvSFmGXyaef+zNAqTtlsVU40zoUl2k4K3OvlmJ8qLYdazcLnT9cMgDqtFnH1mPq5ChhiOsdseDwo+0GKZKCjNmyNk8p9O6ny0wkgsEuKrYO8LsMF2gD66d/PbsCR3jGeuazJAWGUe0fanwq+cqR2db0goPv9wMKAY046Upnd6yam8cRhAkRo5dSXIhmjAOYpxe8Xwajc/AsWkiAGqkNaWPS3XvVOMrQpBALO50m+zrrMGMsJt1JUsuNAvWLtYyTRQidOcFTlr7U6gZ8CgJj9GCMf6tXl5Mlti5G3X9UNVU/BRsZ4B4TJyAaaQuQueENzdLVQ1g3Y3xK1486lXmizBMPa3gBEsbx6HnElnaLvRtHfxp7fGMsmdnw4JJMp/ZP45vRs508B/isKETCMtc+STL0j3IxXMNS9fAyxqMT1qDSKVfS0pgA49r02/bkE1GiSpyxGRbDzH7IitM3H60gn784YmSwCTpaDGVl/9PVBjS0myFqBBPYtsKsuCB28pgv03SKqopyN1FqYaV/C6rwMY9chUSLFZ546UP4gcFgivhEq1efQer6Z9pF1w1jFTnbUhjOKX1Y9+rYgQx17Z6ic7eGQSP/qJqbVgQbYtUE6Cn/BRURlIDTWRrS4K/vj09ImuOMwc1bkg51/4q4fpgf3EHMcCrfHVpJA/yxeWeBEUk+tMYbPRvWLK13cpJO2ortMJ2hR+ODkQtoN5EaSCAVwwggFYoAMCAReiggFPBIIBSxC0Qz9YI8/XwxRexSw6NMjO0ujMtKQNq9ZKbiArefczvkWcQqI24vL9KLNLm4qoRc74CFnJrUkHaepSQTsDcQ4oEokwlrUFZYfZj1+ThqR0+5L/N5OiWyFhXB1Vyx29Ye2NGPsneqc5kySKt9Z9/Q3w1EtdhfJsU0AuzzCzQ/Z9L5pN8+JCJweNc1FFB0PWGSJ4tIfElUNqxYTYCeM93xcsaNM5yxhOhohfqRDPsE+p/k37k1aexpdgjgC6yaRuZ23uEsBrhV4flclDBe38X10W29WnbvIM8HRg4M2v5wDOwuY4Z70C5fF4EcW+xM4o1nQwki8/la9gHMShBsuCp73+fbeCa3ACNBVeiOcFzJnivaVci1FradHZwj9APj2Dp0yKOq/zw5Dl5s3GDHLSanS9EQ+F+9M8QNOwKLAleOFwCFk0eKwAkFXZhUQ=

     

  • Okay, then something like this?

    when HTTP_REQUEST { 
        if { ( [string tolower [HTTP::uri]] starts_with "/nad" ) or ( [HTTP::header Authorization] starts_with "Negotiate YII" ) } { 
            pool poolK
        } 
    }
    

    "Is there a better way to post or send files to you."

    I think you can send it in a direct message.

    So then, without seeing the Fiddler trace first, can I assume the traffic looks (or should look) something like this:

    1. User navigates to site and goes to poolF
    2. User navigates to the "/nad" URI and gets sent to poolK
    3. The poolK server responds with an initial 401 to authenticate
    4. The user goes off and gets a Kerberos ticket and then makes a new request with the Authorization header
    5. The new request, and all future requests, are sent to poolK by virtue of the Authorization header

    Is that more or less what you're looking for?

  • How do i send it directly? email address or ftp server? Your understanding of the traffic is correct. However, after the initial login there may still be some requests that may not meet either condition (/nad or YII), in those case, i would like the connection to persist to poolK without saying it is poolK. So can i do something like this:

    when HTTP_REQUEST {
     if { ( [string tolower [HTTP::uri]] starts_with "/nad" ) or ( [HTTP::header Authorization] starts_with "Negotiate YII" ) } { 
     pool poolK
     else {
     persist ...pool currently being used.....
     }
    
  • Just sent you a private message with my email address.

     

    "after the initial login there may still be some requests that may not meet either condition"

     

    I'm curious why this would be. If the client is authenticating via Kerberos, NTLM, or even Basic, the Authorization header should ALWAYS be in the request.

     

  • I sent you email with two types of fiddler data. One successscenario and another when it is jumping from poolK to poolF.

     

  • Haven't had a chance to look at Fiddler traces yet, but here's an idea. Add a new cookie when the 401 response comes through. Something like this:

    when HTTP_REQUEST {
       if { ( [string tolower [HTTP::uri]] starts_with "/nad" ) or ( [HTTP::cookie exists AUTHTOKEN] ) } {
           pool poolK
       }
    }
    when HTTP_RESPONSE {
        if { [HTTP::status] equals "401" } {
            HTTP::cookie insert name AUTHTOKEN value 1
        }
    }
    

    Hopefully the traces will show why the client isn't sending the Authorization header though.

  • Instead of redirect 302, i am going to test rewrite.

    when HTTP_REQUEST {
      set host [HTTP::host]
      set uri [HTTP::uri]
      set header_auth [HTTP::header "Authorization"]
      if { $uri contains "/nad" } {
        HTTP::uri "/"
        log local0.debug "1st time: Sending Req to Kerb Pool >> '$header_auth' "
        pool poolK
        }
      if { $header_auth starts_with "Negotiate YII" or [HTTP::cookie exists BIGipServerpoolK] } {
        log local0. "Subsequent Req: Sending req again to Kerb pool"
        pool poolK
        }
    }
    
  • Is "/nad" just an arbitrary client side trigger URI? Non-existent on the server side? If so, then yes, by all means rewrite it. It does seem odd that the Authorization header just goes away after the first request after the 401, but I guess that's just how it's designed. In any case, you still need to focus on some sort of persistence value. The "PD-S-SESSION-ID-PROD2" cookie does get set in the 401, so unless that can get set any time BEFORE a user accesses the auth path, it's still probably a good thing to check on each request. Worst case, as I mentioned before, just set a new cookie on the 401 response and track that in the request.

     

  • Yes, /nad is an arbitrary client side trigger and not exist on the server. The challenge with "PD-S-SESSION-ID-PROD2" cookie is, it is common between both pools (i.e poolK and poolF) because it is sent by the backend servers (all nodes). I also noticed in the fiddler data i sent you, there multiple 401 response we get. Like you said, it is good to check on each request but when i check for cookie BIGipServerpoolK, it works more consistently.

     

    But, here is something about persistence that i want to clarify. I have cookie peristence as primary and source_addr persistence as fallback in the VIP configuration. If i reverse it, meaning make source_addr primary and cookie as fallback, Will i still get the desired results? When does fallback takes effect?

     

    [admin@u12:Active] tmp b virtual vpool list virtual vpool { snat automap pool poolF fallback persist webs_persist destination 10.3.8.195:https ip protocol tcp persist cookie-sso1 irule sso1 profiles { clientssl { clientside } jhttp {} serverssl-insecure-compatible { serverside } tcp-cell-optimized {} } }

     

  • If i reverse it, meaning make source_addr primary and cookie as fallback, Will i still get the desired results? When does fallback takes effect?

     

    Cookie persistence cannot be a fallback method. I would also recommend that cookie persistence be your preferred persistence method. Fallback generally happens when the primary method is unavailable (ie. the cookie is missing).