Question
- Why are computer machine names or NULL usernames logged in accesslogs?
- How do you identify the requests using workstation or NULL credentials for later authentication exemption?
Environment
- Cisco Web Security Appliance (WSA) - all versions
- Authentication Scheme NTLMSSP with IP Surrogates
- Windows Vista and newer desktop and mobile Microsoft Operation Systems
Symptoms
The WSA blocks requests from some users or behaves unexpectedly.
The accesslogs shows computer machine names or NULL username and domain instead of userIDs.
The issue resolves itself after:
- Surrogates time out (default value for Surrogate Timeout is 60 minutes)
- Restarting proxy process (CLI command > diagnostic > proxy > kick)
- Flushing authentication cache (CLI command > authcache > flushall)
Background Information
In recent versions of Microsoft Operating System, it is not required that an actual user is logged in anymore for applications to send requests to the Internet anymore. When those requests are received by the WSA and are requested to authenticate, no user credentials are available to use for authentication by the client workstation which instead may take the computer's machine name for a substitute.
The WSA will take the provided machine name and forward it to the Active Directory (AD) which validates it.
With a valid authentication, the WSA creates an IP Surrogate binding the machine's workstation name to the workstation's IP address. Further requests coming from the same IP will use the surrogate and thus workstation name.
With the workstation name not being member of any AD group, requests may not trigger the expected Access Policy and thus be blocked. The problem persists until the surrogate has timed out and the authentication has to be renewed. This time, with an actual user logged in and valid user credentials available, a new IP Surrogate will be created with this information and further requests will match the expected Access Policy.
Another scenario seen is when applications send invalid credentials (NULL username and NULL domain) and NOT valid machine credentials. This is considered an authentication failure and will be blocked or if guest policies are enabled, the failed auth is considered as a "guest".
The workstation name ends with a $ followed by @DOMAIN which makes workstation names easy to trace by using the CLI command grep on the accesslogs for $@. See the example below for clarification.
> grep $@ accesslogs
1332164800.0000 9 10.20.30.40 TCP_DENIED/403 5608 GET http://www.someURL.com
"gb0000d01$@DOMAIN" NONE/- - BLOCK_WEBCAT_11-DefaultGroup-Internet-NONE-NONE-
NONE-NONE <-,-,"-","-",-,-,-,"-","-",-,-,"-",-,"-","-",-,"-","-","-","-","-","-",
0.00,0,-,"-","-"> -
The line above shows an example of an IP Surrogate already having been created for the IP address 10.20.30.40 and the machine name gb0000d01$.
In order to find the request that sent the machine name, the first occurrence of the workstation name for the specific IP address have to be identified. The following CLI command accomplishes this:
> grep 10.20.30.40 -p accesslogs
Search the result for the first occurrence of the workstation name. The three first requests are commonly recognized as a NTLM Single-Sin-On (NTLMSSP/NTLMSSP) handshake as described here and shown in the example below:
1335248044.836 0 10.20.30.40 TCP_DENIED/407 1733 GET http://SomeOtherURL.com -
NONE/- - OTHER-NONE-DefaultGroup-NONE-NONE-NONE-NONE
<-,-,"-","-",-,-,-,"-","-",-,-,"-",-,"-","-",-,"-","-","-","-","-","-",
0.00,0,-,"-","-"> -
1335248044.839 0 10.20.30.40 TCP_DENIED/407 483 GET http://SomeOtherURL.com -
NONE/- - OTHER-NONE-DefaultGroup-NONE-NONE-NONE-NONE
<-,-,"-","-",-,-,-,"-","-",-,-,"-",-,"-","-",-,"-","-","-","-","-","-",
0.00,0,-,"-","-"> -
1335248044.845 10 10.20.30.40 TCP_DENIED/403 2357 GET http://SomeOtherURL.com
"gb0000d01$@DOMAIN" NONE/- - BLOCK_ADMIN_PROTOCOL_11-DefaultGroup-DefaultGroup-
DefaultGroup-NONE-NONE-NONE
<-,-,"-","-",-,-,-,"-","-",-,-,"-",-,"-","-",-,"-","-","-","-","-","-",
0.00,0,-,"-","-"> -
When troubleshooting, ensure that these thee requests are for the same URL and are logged in a very short time interval indicatiting that it is an automated NTLMSSP handshake.
In the example above, the preceding requests are logged with the HTTP response code 407 (Proxy Authentication required) for explicit requests, while transparent requests would be logged with HTTP response code 401 (Unauthenticated).
There is a new feature available on AsyncOS 7.5.0 and higher where you can define a different surrogate timeout for machine credentials. It can be configured using the following command:
> advancedproxyconfigChoose a parameter group:- AUTHENTICATION - Authentication
related parameters- CACHING - Proxy Caching related parameters- DNS - DNS related
parameters- EUN - EUN related parameters- NATIVEFTP - Native FTP related parameters-
FTPOVERHTTP - FTP Over HTTP related parameters- HTTPS - HTTPS related parameters-
SCANNING - Scanning related parameters- WCCP - WCCPv2 related parameters-
MISCELLANEOUS - Miscellaneous proxy relatedparameters[]> AUTHENTICATION...Enter the
surrogate timeout.[3600]>Enter the surrogate timeout for machine credentials.[10]>.
You can use the same steps to detect which requests get the NULL credentials sent and discover which URL or User Agent are sending the invalid credentials and exempt them from authentication.
Exempting the URL From Authentication
In order to prevent this request causing the false surrogate to be created, the URL has to be exempted from authentication.Or, instead of exempting the URL from authentication, you might decide to exempt the application sending the request itself from authentication, making sure to get any requests for the application to be exempted from authentication. This is possible by adding the User Agent to be logged in the accesslogs by adding the additional parameter %u in the optional Custom Fields in the WSA's accesslog subscription. After identifying the User Agent, it has to be exempted from authentication.
Feedback