Edge SWG (formerly ProxySG) Kerberos Authentication Flow with IWA-Direct
search cancel

Edge SWG (formerly ProxySG) Kerberos Authentication Flow with IWA-Direct

book

Article ID: 249766

calendar_today

Updated On:

Products

ProxySG Software - SGOS ISG Proxy

Issue/Introduction

The purpose of this article is to provide representation of the traffic flow of IWA-Direct Kerberos authentication via Edge SWG (formerly ProxySG) appliances.

Resolution

Kerberos Authentication Flow with IWA-Direct

  1. Prior to accessing the Edge SWG (formerly ProxySG) appliance, the user logs into the local domain and obtains a TGT.
  2. The user attempts to access a URL that requires authentication; the Edge SWG (formerly ProxySG) appliance sends a challenge asking for Kerberos credentials.
  3. The client workstation obtains a Service Ticket from the KDC:
    • The Service Ticket is generated based on the authentication challenge URL.
    • The challenge URL identifies the service.
    • The challenge URL depends on the authentication mode.
  4. The Service Ticket is presented to the Edge SWG (formerly ProxySG) appliance.
  5. The Edge SWG (formerly ProxySG) validates the Service Ticket without consulting a DC.
    • Validation is performed with GSSAPI, which is part of the MIT Kerberos library that has been ported to SGOS.
    • Service key related:
      • If the “explicit proxy/load balancer” feature has NOT been configured in the IWA-­Direct realm (the typical scenario), the service key is the Edge SWG (formerly ProxySG) appliance’s machine account password. Otherwise, the service key is the password hash of the load balancer user. This allows multiple Edge SWG (formerly ProxySG) appliances to share the same service key, as it allows the key to be tied to a user’s password, rather than a machine account password.
  6. Policy evaluation continues as configured on the proxy appliance.

Additional Information

It's key to note that the service ticket (initially requested by the client) already contains the end user's group memberships. Additionally, by default, the service ticket is cached for 10 hours, which can be changed in AD group policy if desired.

The client will not renew a cached service ticket until it expires, or until the user logs in to Windows again. Since the ticket contains group memberships, the user’s groups won’t get updated until the client gets a new ticket. This means the Edge SWG (formerly ProxySG) appliance won’t learn about group membership changes until the client gets a new ticket. Similarly, if an administrator makes a change to AD group membership and then logs the user out of the Edge SWG (formerly ProxySG) appliance, the Edge SWG (formerly ProxySG) appliance won’t pick up the group membership change until the client gets a new ticket (for example, logs out of Windows and then logs back in).