Forum Discussion

gscholz's avatar
gscholz
Icon for Nimbostratus rankNimbostratus
Nov 11, 2019

VIP targeting VIP, access policy on subordinate VIP causes problem

Hello!

I am trying to implement the following scenario:

Users connect to server1.example.com using various URIs. Depending on the URI different authentication methods are supposed to be used, for example:

  1. https://server1.example.com/uri1/* gets forwarded straight to a pool.
  2. https://server1.example.com/uri2/* requires Basic authentication.
  3. https://server1.example.com/uri3/* requires AD authentication.
  4. https://server1.example.com/uri4/* requires AD authentication with Kerberos Constrained Delegation.

My approach is now to create new virtual servers on a separate VLAN that have different access policies attached. The "main" virtual server has a local traffic policy attached that distributes the traffic according to the URI used. This works fine for scenario #1, but not for #3 or #4 which I have tested.

My understanding is that the traffic flow should look like this:

https://server1.example.com/uri3/

-> Main_VS -> Local Traffic Policy ("if path starts with /uri3 then forward traffic to Sub_VS_AD-Auth")

-> Sub_VS_AD-Auth -> Access Policy -> AD-Auth passed -> All good.

However, if I have a condition for matching the URI in the Local Traffic Policy forwarding the traffic seems to happen, but the access policy doesn't get processed, and the client browser gets a reset in the end.

This is what the APM log looks like for a session that does not work:

Nov 11 13:34:36 hostname notice tmm3[16030]: 01490506:5: /Common/APOL_Sub_Server1_Auth-AD:Common:ea55e315: Received User-Agent header: xxxx.

Nov 11 13:34:36 hostname notice tmm3[16030]: 01490500:5: /Common/APOL_Sub_Server1_Auth-AD:Common:ea55e315: New session from client IP x.x.x.x (ST=xx/CC=DE/C=EU) at VIP 172.16.0.5 Listener /Common/Sub_VS_AD-Auth (Reputation=Unknown)

Nov 11 13:34:47 hostname debug apm_websso.7[18421]: 014d0052:7: (null):Common:00000000:Expire thread: TGTMap:0 UCCmap:0

Nov 11 13:34:49 hostname notice tmm[16030]: 01490521:5: /Common/APOL_Sub_Server1_Auth-AD:Common:282b5413: Session statistics - bytes in: 0, bytes out: 0

I would like to note that if I change the local traffic policy rule to forward _all_ traffic to Sub_VS_AD-Auth the issue does not occur.

If I use an iRule like the one below instead the issue does occur.

when HTTP_REQUEST {
    if { [class match [HTTP::uri] starts_with uri3]} {
        log local0. "[IP::client_addr] IP client accepted."
        virtual /Common/Sub_VS_AD-Auth
        log local0. "Client forwarded."
    }
}

Would anybody have recommendations what I should change to make it work?

Edit: Main_VS listens on port 443 and has clientssl configured, but no serverssl as Sub_VS listens on a high port and does not use SSL at all. In the access policy under SSO/Auth Domains I have disabled Secure.

1 Reply

  • Hi  ,

     

    I'm setting this up with a customer this week. To provide different SSO methods to different virtual servers, we are using a single APM policy with Multiple Domain SSO. The way this works is that each virtual server is assigned to the main policy. The host names for those virtual servers are added to the main policy SSO/Auth Tab with the SSO appropriate to them. The different SSO policies get their credentials from the main policy's cached AUTH credentials.

     

    If a user signs in through app1, their cached credentials will be used for app2, app3, etc. Likewise, if a user signs in through app2, their cached credentials will work for app1, app3, etc.

     

    Here's a link for BIG-IP v.11.6.x, but the same principle works for newer versions as well. We're using v.13.x for our config. https://techdocs.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-authentication-single-sign-on-11-6-0/25.html.

     

    We are using Kerberos for our AUTH, and using the SSO ASSIGN VARIABLE to store username and password for the different SSO methods. Apps use a variety of SSO (NTLM, Kerberos, Forms, etc..), but only one profile per host name or domain.

     

    Regards,

     

    Keith