SWG, Kerberos Auth and identify users by credentials

Problem this snippet solves:

When using SWG and NTLM Auth it's possible to identify users by IP address or credentials. However, when using Kerberos Auth it isn't possible to identify users by credentials. This iRule enables the 'identify users by credentials' feature for SWG and Kerberos Auth.

The 'identify by credentials' method adds security to environments that use shared systems (like terminal servers) where multiple users are hidden behind the same IP address.

How to use this snippet:

How to use

  1. Configure an APM Explicit Forwarding Proxy Configuration. Call it for example: /Common/vs_proxy_kerberos. Follow the instructions provided by AskF5, but make sure that this virtual server doesn't listen on any VLAN or tunnel. This will be an internal virtual server.
  2. Create a datagroup of type Address and add IP addresses of shared systems to it. Call it for example: /Common/data_group_ip.
  3. Edit the f5.swg_kerberos_identify_by_credentials iRule variables in the RULE_INIT event to match your configuration.
  4. Configure a second virtual server that holds the f5.swg_kerberos_identify_by_credentials iRule. Call it for example: /Common/vs_proxy_kerberos_front. This virtual server will accept proxy traffic from clients and route it to the internal virtual server.

How it works

The iRule will check if the HTTP request contains a Proxy-Authorization header. If the request contains a Proxy-Authorization header it will take a part of the Base64 Kerberos ticket and maps it to an internal IP address. This internal IP address will be used as a SNAT address. The internal virtual server will use the standard Kerberos Auth 'identification by IP' method to authenticate this session.

The iRule uses tables to map Kerberos tickets to IP addresses. Please note that single users can sometimes use different Kerberos tickets. This results in a single user consuming more than one session. Like NTLM Auth, the 'identify by credentials' method adds extra overhead in the communication between the client and the proxy, because the client is forced to send a Proxy-Authorization header with each request.

Disclaimer

This iRule has been tested in a lab environment only

Code :

https://github.com/nvansluis/f5.swg_kerberos_identify_by_credentials
Published Feb 27, 2019
Version 1.0
APM
authentication
kerberos
Secure Web Gateway
security

Was this article helpful?

2 Comments

Sort By
  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Jan 28, 2020

    Hi Niels,

    I've found your snipped in the hope to find a method to reuse existing APM sessions in the case that Negotiate authentication was used across multiple connections and the client is unable to process http-cookies.

    Can you please further elaborate on how the offsets are choosen to differentiate individual clients?

    set krbTicketPart [string range [findstr [TCP::payload] "Proxy-Authorization: Negotiate YII" 35 " "] 0 30]

    If I b64/ASN.1 decode the krbTicketPart, it includes just the SPNEGO-OID which should be the same for every single client?

    Application 0 (2 elem)
  OBJECT IDENTIFIER 1.3.6.1.5.5.2
  [0] (1 elem)
    SEQUENCE (2 elem)
      [0] (1 elem)
        SEQUENCE (4 elem)
          OBJECT IDENTIFIER

    Cheers, Kai

  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Jan 29, 2020

    Digged a little bit further into reusing existing APM sessions in the case that Negotiate-Kerberos is used.

     

    Without fully decoding the Negotiate-Kerberos message in front of APM (including decrypting session ticket information, extracting session specific keys and finally verifying the Message-Authenticator), its not possible to securely identify the user.

     

    I'm working right now on an APM policy that lookups existing APM session for the same user directly after Kerberos-Auth action is complete and then starts to copy session information from the existing APM session to speed up VPE processing. After VPE is finished, an iRule will destroy the just created APM session after HTTP_RESPONSE and then steer subsequent request over the same TCP connection to the old APM session. Not ideal, but seems to be the best what can be done... :-(

     

    Cheers, Kai