Forum Discussion

Gilles_from_Lux's avatar
Gilles_from_Lux
Icon for Nimbostratus rankNimbostratus
Dec 15, 2016

APM - AD domain session variable reset after failed logon?

Hi everybody,

I'm starting using APM now in our company. We have a setup where we need to authenticate external and internal users in 2 separate AD domains on the logon page. So the user needs to select his domain in a drop down box and enters his username and domain password.

Before sending the credentials to the domain controller, we do a simple check on the predefined domain value set up in the select box from the logon page to be able to send the credentials to the correct domain controller.

We use the following expression to check the domain:

expr { [mcget {session.logon.last.domain} ] eq "DomainA"}

Now I have the following problem: When for example I'm trying to logon and I select the wrong domain, authentication fails. This is absolutely OK. I'm redirected to the logon page. Now that I know I selected the wrong domain, I select the other domain on the logon page and I cannot logon, even the password and the correct domain has been selected. In the APM log file, I can see that APM did not updated the session.logon.last.domain variable. It tries to authenticate always using the first domain selected.

So my question:

  • Are some variables beeing reset if logon fails?

  • If not, how do I can reset this particularly variable?

Thanks a lot,

Kind regards,

Gilles

13 Replies

  • Gilles,

     

    I do believe I have seen this as a bug. To mitigate this, you can set the number of authentication attempts under AD Auth to 1, and it will terminate the session after each unsuccessful attempt, so user would have to click on a new link to start a new session. As a plus, you can customize the message upon auth failure to give user feedback on what to look out for. For example, you can check the value of AD error message value using this syntax: expr { [mcget {session.ad.last.errmsg}] contains "Invalid user credentials"} and customize feedback to user accordingly on the Deny page based upon the value et in that variable.

     

    • Gilles_from_Lux's avatar
      Gilles_from_Lux
      Icon for Nimbostratus rankNimbostratus

      Hi Michael,

       

      thank you for your reply. We have upgraded our F5 platform a few days ago and are now on the latest release 12.1.1 HF2.

       

      Before we were on 11.6.0 HF6 and I'm not 100% sure, but I think we did not have this kind of problem before.

       

      Is there no other possibility, for example resetting the variable to none after the logon fails?

       

      Do you know where the loop is done to the logon page again if logon fails? I suppose that the policy is not executed from the beginning, but that the loop is integrated in the AD authentication object in VPE? Is this correct?

       

      Kind regards,

       

      Gilles

       

    • Michael_Koyfma1's avatar
      Michael_Koyfma1
      Icon for Cirrus rankCirrus

      You can see if you can get better behavior by using Macros.

       

      Put the Logon action in the macro, change "Max Logon Attempts Allowed" to 1 and configure the macro to loop with a value of 3 failed authentication attempts, and see if the issue is still there.

       

  • Gilles,

     

    I do believe I have seen this as a bug. To mitigate this, you can set the number of authentication attempts under AD Auth to 1, and it will terminate the session after each unsuccessful attempt, so user would have to click on a new link to start a new session. As a plus, you can customize the message upon auth failure to give user feedback on what to look out for. For example, you can check the value of AD error message value using this syntax: expr { [mcget {session.ad.last.errmsg}] contains "Invalid user credentials"} and customize feedback to user accordingly on the Deny page based upon the value et in that variable.

     

    • Gilles_from_Lux's avatar
      Gilles_from_Lux
      Icon for Nimbostratus rankNimbostratus

      Hi Michael,

       

      thank you for your reply. We have upgraded our F5 platform a few days ago and are now on the latest release 12.1.1 HF2.

       

      Before we were on 11.6.0 HF6 and I'm not 100% sure, but I think we did not have this kind of problem before.

       

      Is there no other possibility, for example resetting the variable to none after the logon fails?

       

      Do you know where the loop is done to the logon page again if logon fails? I suppose that the policy is not executed from the beginning, but that the loop is integrated in the AD authentication object in VPE? Is this correct?

       

      Kind regards,

       

      Gilles

       

    • Michael_Koyfman's avatar
      Michael_Koyfman
      Icon for Cirrocumulus rankCirrocumulus

      You can see if you can get better behavior by using Macros.

       

      Put the Logon action in the macro, change "Max Logon Attempts Allowed" to 1 and configure the macro to loop with a value of 3 failed authentication attempts, and see if the issue is still there.

       

  • Hi,

     

    I am not sure this is a bug bug the APM behavior since the start of APM product.

     

    VPE box are executed only once from start to endings.

     

    there is no back to logon page from Authentication box but authentication box prompt last logon page until max attempts.

     

    if you insert conditions and boxes between logon page and Authentication boxes, there are executed only once.

     

    the only solution is to insert as answered Michael the logon page and authentication boxes in macro with loop.

     

  • jk303's avatar
    jk303
    Icon for Nimbostratus rankNimbostratus

    I'm having the same issue even with the workaround using Macro (per: https://support.f5.com/csp/article/K48343296). I even took OUT the loop and just added manual 3 authentication macro boxes. Same behavior - if user enters incorrect password 1st time, and then correct password 2nd time - the system doesn't let the user login until session is over.

     

    HOW is this "by design" ? In any case - anyone successfully used Macro's in their environment to bypass this limitation? (11.6).

     

  • Hi,

     

    The main solution is to set the ad auth max authentication attempts to 1 to force loop!!!

     

    This solution work successfully for any version I worked with since 11.1 to 13.0

     

  • jk303's avatar
    jk303
    Icon for Nimbostratus rankNimbostratus

    Right, its set to 1 and loop 3. I think problem is, I'm setting variables using iRule after auth login page (not using external page) as I need to do GET prior POST on 2nd authentication. SO what I'm seeing, the variables are still NOT reset when it goes back to the login page. I'm still having the same issue of not resetting variables.

     

  • I never use irule event cause of this behavior.

     

    Irule event must not be used to change existing variable but only create new one.

     

    when irule event set a variable, it's for the whole session.

     

    During policy evaluation, when a box request a session value, this variable is cached for next uses. if the Policy evaluation process contains a variable value, it won't refresh the cache for new value.

     

    Can you provide the irule code, we will try to help you to convert it to variable assign.

     

    Your issue is not the same as this thread (which is marked as solved). ask a new question to get more help.

     

  • jk303's avatar
    jk303
    Icon for Nimbostratus rankNimbostratus

    I need to use iRule to assign variables as my 2nd authentication device is not your typical POST external page. When I begin my LOOP again - I would hope/assume that my NEW userID or PasswordID would be assigned AGAIN as user may have missed it 1st time. I don't understand why this would be be design as 'not possible'.

    I simply want to assign new values to my variable such as username and password on the 2nd time around user goes through the loop.

    Basically - when I go back to Logon Page on Loop2 (followed by variable assignment by iRule) the NEW info added by user isn't updated. (same information from loop1 is used to sign in user).

    IS there a way to force a change EACH time around in this scenario? I can change/update these variables through out the single loop, BUT not when it goes back to Login Page again.

    when HTTP_REQUEST { if { [HTTP::uri] starts_with "/gg" || [HTTP::uri] starts_with "/cgi/login" } { ACCESS::disable pool "pl_pool1_https"

        if { [HTTP::uri] eq "/cgi/login" && [HTTP::method] eq "POST" } {
            HTTP::collect [HTTP::header Content-Length]
        } elseif { [HTTP::uri] eq "/gg/Start" && [HTTP::method] eq "POST" } {
            HTTP::header replace "Referer" "https://deskit.domain.com/v/index.html"
        }
    }
    

    }

    when HTTP_REQUEST_DATA { set g_login "" set g_passwd "" set g_passwd1 "" set g_realm "" foreach field [split [HTTP::payload] "&"] { foreach {n v} [split $field "="] { switch $n { "login" { set g_login [URI::decode $v] } "passwd" { set g_passwd [URI::decode $v] } "passwd1" { set g_passwd1 [URI::decode $v] } "realm" { set g_realm [URI::decode $v] } } } } HTTP::release HTTP::redirect "/my.policy" }

    when ACCESS_POLICY_AGENT_EVENT { ACCESS::session data set session.logon.last.username $g_login ACCESS::session data set -secure session.logon.last.password $g_passwd ACCESS::session data set -secure session.logon.last.nonce $g_passwd1

    }

    when ACCESS_ACL_ALLOWED { set type [ACCESS::session data get session.client.type] if { !($type starts_with "C") } { if { [HTTP::uri] == "/" } { ACCESS::respond 302 Location "https://[HTTP::host]/C/deskIT/site/default.aspx/" } } }