Einleitung
In diesem Dokument wird beschrieben, wie das Problem behoben wird, wenn die Authentifizierung über die Cisco Web Security Appliance (WSA) fehlschlägt, wenn der Client NEGOEXTS verwendet.
Hintergrundinformationen
Die Cisco Web Security Appliance (WSA) kann Benutzer authentifizieren, um Richtlinien basierend auf Benutzer oder Gruppe anzuwenden. Eine der verfügbaren Methoden ist Kerberos. Wenn Kerberos als Authentifizierungsmethode in einer Identity verwendet wird, antwortet die WSA auf die HTTP-Anforderung eines Clients mit einer 401 (transparent) oder 407 (explizit) HTTP-Antwort, die den Header WWW-Authenticate: Negotiate enthält. An diesem Punkt sendet der Client eine neue HTTP-Anforderung mit dem Header Authorization: Negotiate, der die Protokolle Generic Security Service Application Program Interface (GSS-API) und Simple Protected Negotiation (SPNEGO) enthält. Unter SPNEGO präsentiert der Benutzer die MechTypes, die er unterstützt. Dies sind die von der WSA unterstützten MechTypes:
- KRB5 - Kerberos-Authentifizierungsmethode, die verwendet wird, wenn Kerberos vom Client richtig unterstützt und konfiguriert wird und wenn ein gültiges Kerberos-Ticket für den Dienst vorhanden ist, auf den zugegriffen wird
- NTLMSSP - Microsoft NTLM Security Support Provider-Methode, die verwendet wird, wenn keine gültigen Kerberos-Tickets verfügbar sind, aber die Negotiate-Authentifizierungsmethode unterstützt wird
Problem: Auth schlägt bei Verwendung von NEGOEXTS durch WSA fehl
In neueren Versionen von Microsoft Windows wird eine neue Authentifizierungsmethode namens NegoExts unterstützt, die eine Erweiterung des Negotiate-Authentifizierungsprotokolls darstellt. Dieser MechType gilt als sicherer als NTLMSSP und wird vom Client bevorzugt, wenn die einzigen unterstützten Methoden NEGOEXTS und NTLMSSP sind. Weitere Informationen finden Sie unter:
Einführung von Erweiterungen für das Negotiate-Authentifizierungspaket
Dieses Szenario tritt in der Regel auf, wenn die Negotiate-Authentifizierungsmethode ausgewählt ist und es keinen KRB5-MechType gibt (höchstwahrscheinlich, weil ein gültiges Kerberos-Ticket für den WSA-Dienst fehlt). Wenn der Client NEGOEXTS auswählt (was in Wireshark als NEGOEX angesehen werden kann), ist die WSA deaktiviert, um die Authentifizierungstransaktion zu verarbeiten, und die Authentifizierung für den Client schlägt fehl. In diesem Fall werden diese Protokolle in den Authentifizierungsprotokollen angezeigt:
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 ........
Wenn die Authentifizierung fehlschlägt, geschieht Folgendes:
Bei aktivierten Gastberechtigungen wird der Client als nicht authentifiziert klassifiziert und an die Website weitergeleitet.
Wenn Gastberechtigungen deaktiviert sind - dem Client werden weitere 401 oder 407 (je nach Proxymethode) angezeigt, wobei die übrigen Authentifizierungsmethoden im Antwortheader aufgeführt werden (Negotiate wird nicht erneut angezeigt). Wenn NTLMSSP und/oder die grundlegende Authentifizierung konfiguriert ist, tritt wahrscheinlich eine Authentifizierungsaufforderung auf. Wenn es keine anderen Authentifizierungsmethoden gibt (die Identität wird nur für Kerberos konfiguriert), schlägt die Authentifizierung einfach fehl.
Lösung
Die Lösung für dieses Problem besteht darin, entweder die Kerberos-Authentifizierung aus der Identität zu entfernen - oder - den Client zu reparieren, sodass er ein gültiges Kerberos-Ticket für den WSA-Dienst erhält.
Feedback