Solutions

Intermittent Internet access problems when running Windows 7 or Windows Vista through the ProxySG

Solutions ID:    KB3459
Version:    14.0
Status:    Published
Published date:    09/29/2009
Updated:    10/30/2013
 

Problem Description

Windows 7 and Windows Vista users report Intermittent Internet access problems accessing the Internet through the ProxySG. In this instance, the symptoms are as follows:

  • Sometimes the content_filter page comes up denying access to the Internet.
  • The ProxySG is using IWA or Windows SSO authentication
  • affected users are running Windows 7 or Windows Vista.
  • Either the user's computer name or NT AUTHORITY/ANONYMOUS LOGON is passed via BCAAA to the Proxy's authentication table instead of the correct user name.

 

 

Resolution

This is a known issue unique to ProxySG deployments where IP-based authentication surrogate modes are used with IWA or Windows SSO authentication. In these cases, the appliance is saving credentials that appear as follows: machinename$ or this : NT AUTHORITY\ANONYMOUS LOGON.  Since this isn't the user's actual user ID, policy rules for AD users and groups fail to match, and the user is unable to access web resources to which they should have access.

Here's the timeline of events that lead to this behavior in a typical IWA authentication deployment :

  1. User starts their Windows Vista or Windows 7 PC.
  2. Before login, the PC sends a request to several different URLs, (most commonly http://www.msftncsi.com) to verify that the PC has Internet connectivity.
  3. The proxy sends an authentication challenge to this request, to validate the user.
  4. The PC, not yet having access to a users' AD credentials, sends the user's NETBIOS host name in response to the Proxy's authentication challenge.
  5. The proxy sends this information to BCAAA, which queries the AD - "is this a valid user credential"?
  6. Windows server 2003 would have said 'no', however, Windows Server 2008, using a feature known as 'fallback authentication' responds with, "Yes, these credentials are valid".
  7. The proxy saves the workstation host name in the authentication credential cache for 15 minutes (by default, or more if the IWA realm is set for more).
  8. After the user logs in, requests they make for web resources are tied to their machine name, and the authentication surrogate saved on the proxy.
  9. This issue resolves itself after the authentication surrogate timeout expires, and user-generated web requests can be validated appropriately.

For Windows SSO deployments, the process is a little different:

  • User starts their Windows Vista or Windows 7 PC.
  • Before login, the PC sends a request to several different URLs, (most commonly http://www.msftncsi.com) to verify that the PC has Internet connectivity.
  • The proxy sends a query to an AD domain controller via BCAAA to determine the user account making the web request.
  • Since the user has not yet logged in to the workstation, Windows AD doesn't yet know who they are. Instead, the domain controller sends NT AUTHORITY/ANONYMOUS LOGON back to the proxy as a valid credential.
  • BCAAA saves the ANONYMOUS LOGON ID in the SSO user table, which is shared with the Proxy.
  • After the user logs in to their workstation, requests they make for web resources are logged as coming from ANONYMOUS USER and as such, policy based on AD user or group names fails to match their requests.

The end result in both cases is the same -- users aren't tracked in policy or access logging correctly.  

Common Solution: 

In both authentication realm types, the following simple CPL policy will correct this behavior: 

<Proxy>
url.domain=msftncsi.com authenticate(no) allow 
deny.unauthorized condition=SILENT_USERS realm=<REALM_NAME>

; Definitions
define condition SILENT_USERS
    user="NT AUTHORITY\ANONYMOUS LOGON" 
    user="Anonymous logon" 
    user="NT AUTHORITY\Anonymous logon" 
end
 

Windows SSO scenarios have the flexibility of an additional solution. Edit the SSO.INI file, (found on the server running BCAAA) as follows:

  1. Locate the [SSOServiceUsers] section.
  2. Add the following entries to this section:
    ANONYMOUS LOGON
    NT AUTHORITY/ANONYMOUS LOGON
  3. Save sso.ini.
  4. Restart the BCAAA service.

Now, when BCAAA queries the domain to identify users in this scenario, BCAAA will know that ANONYMOUS LOGON is a service account and not to be used to authenticate proxied user requests.

 

 ADDITIONAL RELATED INFORMATION:

  • Access logs report requests to msftncsi.com - https://kb.bluecoat.com/index?page=content&id=KB3008
  • Information on Windows 2008's 'fallback authentication' - https://kb.bluecoat.com/index?page=content&id=KB3436
  • While Microsoft's network awareness service (NCSI) is the most common cause of this behavior, other applications and associated domains have been reported. If, after implementing the solution policy in this article, users still experience issues, see the attached policy for more URLs that can trigger this behavior.
  • Refer to FAQ873 for more information on NT AUTHORITY\ANONYMOUS LOGON occurences since the example above is not the only cause for this.

 Note: The described issues may occur in older versions of SGOS. This has been fixed in the following versions:

5.4.11.2 (and higher)
5.5.9.1 (and higher)
6.2.7.1 (and higher)
6.3.2.2 (and higher)
6.4 (all versions and later)

 

 

Attachment

auth_bypass_best_practice_v2.txt
3K • < 1 minute @ 56k, < 1 minute @ broadband



Rate this Page

Please take a moment to complete this form to help us better serve you.

Did this document help answer your question?
 
 
If you are finished providing feedback, please click the RATE CONTENT button. Otherwise, please add more detail in the following text box and then click RATE CONTENT.
 
 

Your response will be used to improve our document content.

Ask a Question