Based on FAQ790.
Most likely reasons for this event to be generated include:
Apart from KB4152 - All Internet Explorer (IE) is at least IE6 SP2, we can rule out the IE issue.
After knowing that event 1306 generated in the eventlog because the client was not able to authenticate by proxy, use Reporter to find out the client IP address or the destination URL/hosts that generates most of the requests.
1. If event 1306 occurs a lot during any particular day, obtain the access log for the past day or two.
2. Upload and import it to the Reporter server. For additional information, follow the KB:
KB2983 -Configuring access logging on the ProxySG to an FTP server and to Reporter
3. Generate report where there is No User in the Username field.
4. Example of filter to find out the Client IPs that had the most hits (each request that hits this filter likely generates the 1306 event):
Report Filter: Date is All Dates (xx/xx/xx - xx/xx/xx) where User Is "- EMPTY -" and Client IP Is not -.
5. Example of filter to find out the Site URL/Host IP addresses that had the most hits: (each request who hit this filter likely generates the 1306 event):
Report Filter: Date is All Dates (xx/xx/xx - xx/xx/xx) where User Is "- EMPTY -" and Site Is not "- EMPTY -".
Output on items #4 and item #5 might also list those requests that match Do Not Authenticate in your policy. Because this is intended, find out those that match the authentication rule but are still not able to supply credentials.
The key factor is that the client machine/browser/application is not able to supply login credentials while the proxy sent a challenge; hence, the event 1306 is generated in the BCAAA server log.