Intermittent Internet access problems when using Windows hosts through the ProxySG

Products

• Advanced Secure Gateway Software - ASG
• ProxySG Software - SGOS
• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Windows 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, Windows Vista and WIndows 10.
• 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.

Environment

This issue happens for BCAAA as well as IWA-Direct setup

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 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.