How to work around authentication problems with user-agents like iTunes and Winamp

book

Article ID: 166528

calendar_today

Updated On:

Products

ProxySG Software - SGOS

Issue/Introduction

To perform authentication, the ProxySG appliance can use one of two methods:

  • Challenge the browser and ask it to provide credentials (such as IWA, LDAP, or RADIUS).
  • Try to figure out the name of the user via the source IP address (Windows SSO uses this method).

Browsers like Internet Explorer or Mozilla Firefox know how to handle an authentication challenge. In most cases the browser can return the user information via NTLM without the user even knowing it, or it can also open an authentication challenge and prompt the users to enter their username and password. This works because those browsers were programmed to understand what to do when challenged with an HTTP-401 or HTTP-407 authentication challenge but this is not the case with all user-agents.

A user-agent that doesn't support an authentication challenge and receives an HTTP error 401 or HTTP error 407 usually hangs or displays an error message saying that the server can't be reached.

From the perspective of the ProxySG appliance, it is not possible to 'teach' the application how to return credentials; to work around the issue, you must add a rule in content policy language (CPL) to bypass authentication for the specific user-agent that doesn't support it.

Note: Perform a policy trace or a packet capture to determine the user-agent, or something unique about the name of the user-agent.

The following is an example of a rule that would bypass authentication if the user-agent has "ipad" in it

 <Proxy>
    request.header.User-Agent="ipad"  authenticate(no)