Inleiding
Dit document beschrijft hoe u het probleem kunt verhelpen wanneer de autorisatie mislukt via Cisco Web Security Applicatie (WSA) wanneer de client NEGOXTS gebruikt.
Achtergrondinformatie
De Cisco Web Security Applicatie (WSA) kan gebruikers authenticeren om beleid toe te passen dat is gebaseerd op gebruiker of groep. Een van de beschikbare methoden is Kerberos. Wanneer het gebruiken van Kerberos als authentificatiemethode in een Identiteit, antwoordt WSA op het HTTP-verzoek van een cliënt met een (transparante) reactie 401 of 407 (expliciete) HTTP die de kop WWW-Authenticate bevat: Onderhandelen. Op dit punt stuurt de client een nieuw HTTP-verzoek met de autorisatie: Onderhandel header, die de Generic Security Service Application Program Interface (GSS-API) en Simple Protected Negotation (SPNEGO) protocollen bevat. Onder SPNEGO, presenteert de gebruiker de mechTypes die het ondersteunt. Dit zijn de mechTypes die WSA ondersteunt:
- KRB5- Kerberos auth methode die wordt gebruikt als Kerberos correct wordt ondersteund en geconfigureerd op de client en als er een geldig Kerberos-ticket aanwezig is voor de service die wordt benaderd
- NTLMSSP - Microsoft NTLM Security Support Provider-methode die wordt gebruikt als er geen geldige Kerberos-tickets beschikbaar zijn, maar de onderhandelingsautorisatiemethode wordt ondersteund
Probleem: autorisatie mislukt door WSA wanneer client NEGOEXTS gebruikt
In recentere versies van Microsoft Windows, wordt een nieuwe auth methode ondersteund genaamd NegoExts, wat een uitbreiding is van het Negotiate verificatieprotocol. Dit mechType wordt als veiliger beschouwd dan NTLMSSP, en heeft de voorkeur van de client wanneer de enige ondersteunde methoden NEGOEXTS en NTLMSSP zijn. Meer informatie is te vinden op deze link:
Uitbreidingen van het onderhandelingspakket voor verificatie
Dit scenario komt typisch voor wanneer de Negotiate auth methode wordt geselecteerd en er is geen KRB5 mechType (zeer waarschijnlijk wegens het missen van een geldig Kerberos Ticket voor de dienst WSA). Als de klant NEGOEXTS selecteert (kan worden gezien als NEGOEX in wireshark), dan is WSA niet in staat om de auth transactie te verwerken en auth faalt voor de client. Wanneer dit voorkomt, worden deze logboeken gezien in de auth logboeken:
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 ........
Als de auth mislukt, gebeurt dit:
Als gastrechten zijn ingeschakeld - client wordt geclassificeerd als niet-geverifieerd en doorgestuurd naar de website
Als de gast privileges zijn uitgeschakeld - client wordt gepresenteerd met een andere 401 of 407 (afhankelijk van proxy methode) met de resterende auth methodes gepresenteerd in de response header (Onderhandelen wordt niet opnieuw getoond). Er wordt waarschijnlijk een auth-prompt weergegeven als NTLMSSP en/of Basic auth is geconfigureerd. Als er geen andere auth-methoden zijn (Identity is alleen geconfigureerd voor Kerberos), dan mislukt auth simpelweg.
Oplossing
De oplossing voor dit probleem is om Kerberos auth uit de Identity te verwijderen of de client te repareren zodat het een geldig Kerberos-ticket krijgt voor de WSA-service.
Feedback