Authenticated users appear as machine names or Anonymous Logon in Edge SWG (ProxySG)/ASG logs

Products

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

Issue/Introduction

In access logs, policy traces, or authenticated user lists, you see "NT AUTHORITY\ANONYMOUS LOGON" (or language variation) and machine names (names that end with a dollar sign $) instead of usernames.

Environment

Edge SWG (ProxySG).

Cloud SWG with Proxy Forwarding enabled.

Resolution

In cases where the Edge SWG (ProxySG) or Advanced Secure Gateway (ASG) appliance requests authentication before a user logs in to their workstation, Windows machines will send either the workstation name (ending with $) or 'NT AUTHORITY\ANONYMOUS LOGON' as the authentication credentials. The Edge SWG (ProxySG) does not have any control on whether the clients will send user credentials or machine credentials as a response to the authentication challenge from Edge SWG (ProxySG).

We can use the following Content Policy Language (CPL) code to log out the Workstation Machine name and have the User authenticate again (Recommended CPL).

; Logout Windows machine accounts

define condition IWA_SILENT_USERS
user="NT AUTHORITY\anonymous logon"
user="AUTORITE NT\anonymous logon"
user.regex='.+\$$'
end condition

<Proxy>
realm=realmname condition=IWA_SILENT_USERS user.login.log_out(true)

NOTE: Where the IWA realm name, as exactly seen in configuration, is entered in place of the Highlighted section in red. The above CPL will only work for a single realm if you have multiple realm you can use the below CPL instead.

; Logout Windows machine accounts

define condition IWA_SILENT_USERS
user="NT AUTHORITY\anonymous logon"
user="AUTORITE NT\anonymous logon"
user.regex='.+\$$'
end condition

define condition IWA_SILENT_REALMS
realm=realmname
realm=realmname
realm=realmname
end condition IWA_SILENT_REALMS

<Proxy>
condition=IWA_SILENT_REALMS condition=IWA_SILENT_USERS user.login.log_out(true)

If you're using Windows SSO the above CPL will have no affect as we're retrieving the user credentials VIA the BCAAA agent which in turn (depending on configuration) will be querying the Windows Domain Controller directly. To replicate this change for a Windows SSO environment we will need to login to the appropriate BCAAA Windows server. Once logged into the Windows server follow the below steps to make the appropriate changes:

Browse to the BCAAA installation directory (default %programfiles(x86)%\Blue Coat Systems\BCAAA\)
Open the sso.ini file in a text editor
Search for the line containing NetShowServices
Directly below this line add the following text NT AUTHORITY\anonymous logon (See IMG1.1 for reference)
Save the changes and close the file
Restart the BCAAA service (WinKey + R > services.msc > Right-click BCAAA > Restart)

IMG1.1:

Additional Information

Also seen when integrating Edge SWG with Cloud SWG.

- User accesses example.com and IP, user and group information (all forwarded by on premise proxy) shows up correctly

2023-02-17 13:15:57 "proxysg1" 3 10.100.126.247 "COM\user - - "COM\Social Media Access" - OBSERVED "Web Ads/Analytics" https://example.com/ 204 TCP_NC_MISS POST text/plain https example.com/analytics 443 /g/collect ?v=2&tid=G-1GCLN1PYZE&gtm=2oe8f0&_p=1161302571&cid=241464327.1660741954&ul=en-us&sr=3072x1728&_z=ccd.v9B&_s=2&sid=1660741953&sct=1&seg=1&dl=https%3A%2F%2example.com%2F&dt=Name%20C%20Modern&_et=25674 - "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36" 192.168.1.84 573 860 - - - - - - - - 19634 "HeadOffice" gateway_proxy "-" "-" x.x.x.x "United States" CERT_VALID none - - TLSv1.3 TLS_AES_128_GCM_SHA256 128 *.example.com/analytics "Web Ads/Analytics" TLSv1.3 TLS_AES_128_GCM_SHA256 128 - ICAP_NOT_SCANNED - ICAP_NOT_SCANNED - x.x.x.x "United States" - "Invalid" 2 2 - - - - - - - - - - SSL_Intercept_1 - - - - - <ICAP Code> "BE" "Belgium" -

- User then browsed example sites and , we saw the machine name reported rather than the username. HTTP request was blocked due to invalid user – also shows that we are missing group information

2023-02-17 13:17:25 "proxysg1" 2 10.100.126.247 "COM\<computer-name>$" "user-info" - - policy_denied DENIED "Technology/Internet" - 403 TCP_DENIED POST - https opti.example.com 443 /v1:GetModels ?key=<key obfuscated> - "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36" 192.168.1.84 17637 799 - - - - - - - - 19634 "HeadOffice" gateway_proxy "-" "-" x.x.x.x "United States" CERT_VALID none - - TLSv1.3 TLS_AES_128_GCM_SHA256 128 upload.video.example.com "Audio/Video Clips;Mixed Content/Potentially Adult" TLSv1.3 TLS_AES_128_GCM_SHA256 128 - ICAP_NOT_SCANNED - ICAP_NOT_SCANNED - - "United States" - "Invalid" 1 1 - - - - - - - - - - - - - - - - <ICAP Code> - - "Invalid" "Invalid" -

- Policy trace confirms that the inbound request into Cloud SWG is missing group info and the user info is invalid … this originates from the on-premise proxy.

connection: service.name=Explicit HTTP client.address=10.100.126.247 Header address=10.100.126.247 (NAT address=10.255.128.145) (effective address=10.100.126.247) proxy.port=8080 source.port=51585 dest.port=8080
client country= pcid=1023
location-id=19634 access_type=gateway_proxy
time: 2023-02-17 13:26:37 UTC
CONNECT tcp://doccuments.example.com:443/
DNS lookup was unrestricted
Client-IP: 10.100.126.247
BC_Auth_User: user-info
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36
user: name="COM\<computer-name>$" realm=proxy_forward
authentication start 3 elapsed 0 ms
authorization start 3 elapsed 0 ms
authentication status='none' authorization status='none'
user: authenticated=true authorized=true relative username='<computer-name>$'
supplier.allowed_countries: all
supplier.ip:
supplier.country: None
supplier.failures: -
verdict: ALLOWED
bypass_cache(yes)

Making above change on Edge Proxy policy addressed the issue.