Auth fails through WSA when client uses NEGOEXTS

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Introduction

This document describes how to overocme the issue when Auth fails through Cisco Web Security Appliance (WSA) when client uses NEGOEXTS.

Background Information

• KRB5- Kerberos auth method that is used if Kerberos is supported and configured correctly on the client and if a valid Kerberos ticket is present for the service being accessed
• NTLMSSP- Microsoft NTLM Security Support Provider method that is used if no valid Kerberos tickets are available but Negotiate auth method is supported

Problem: Auth Fails through WSA when client uses NEGOEXTS

In more recent versions of Microsoft Windows, a new auth method is supported called NegoExts, which is an extension to the Negotiate authentication protocol. This mechType is considered more secure than NTLMSSP, and is preferred by the client when the only supported methods are NEGOEXTS and NTLMSSP. More information can be found in this link:

This scenario typically occurs when the Negotiate auth method is selected and there is no KRB5 mechType (most likely due to missing a valid Kerberos Ticket for the WSA service). If the client selects NEGOEXTS (may be seen as NEGOEX in wireshark), then the WSA is unabled to process the auth transaction and auth fails for the client. When this occurs, these logs are seen in the auth logs:

14 Nov 2016 16:06:20 (GMT -0500) Warning: PROX_AUTH : 123858 : [DOMAIN]Failed to parse NTLMSSP packet, could not extract NTLMSSP command14 Nov 2016 16:06:20 (GMT -0500) Info: PROX_AUTH : 123858 : [DOMAIN][000] 4E 45 47 4F 45 58 54 53 00 00 00 00 00 00 00 00 NEGOEXTS .

When auth fails, this occurs:

If guest privileges are enabled - client is classified as Unauthenticated and redirected to the website

If guest privileges are disabled - client is presented with another 401 or 407 (depending on proxy method) with the remaining auth methods presented in the response header (Negotiate is not presented again). An auth prompt is likely to be occured if NTLMSSP and/or Basic auth is configured. If there are no other auth methods (Identity is configured only for Kerberos), then auth simply fails.

Solution

The solution to this issue is to either remove Kerberos auth from the Identity -or- fix the client so that it gets a valid Kerberos ticket for the WSA service.