Fehlerbehebung bei Kerberos-Authentifizierung auf SWA

Einleitung

In diesem Dokument werden die Grundlagen der Kerberos-Authentifizierung und die Schritte zur Fehlerbehebung bei der Kerberos-Authentifizierung in einer sicheren Webappliance (SWA) beschrieben.

Terminologie

• SWA: Sichere Web-Appliance
• CLI: Kommandozeilenschnittstelle
• AD: Active Directory
• Rechenzentrum: Domänencontroller
• SPN: Name des Dienstprinzipals
• KDC: Kerberos-Schlüsselverteilungscenter
• TGT: Ticket gewähren Ticket (Authentifizierungs-Ticket)
• TGS: Dienst für die Ticketgewährung
• HA: Hohe Verfügbarkeit
• VRRP: Virtual Router Redundancy Protocol
• CARP: Common Address Redundancy Protocol
• SPN: Name des Dienstprinzipals
• LSAP: Lightweight Directory Access Protocol

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Authentifizierung und Realms auf SWA
• Active Directory- und Kerberos-Authentifizierung

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Kerberos - Netzwerkablauf

Bild: Beispiel für den Kerberos-Netzwerkfluss

Dies sind die grundlegenden Schritte für die Authentifizierung in einer Kerberized-Umgebung:

1. Der Client fordert ein TGT vom KDC an.

2. Der KDC überprüft die Anmeldeinformationen des Clientcomputerbenutzers und sendet einen verschlüsselten TGT und Sitzungsschlüssel zurück.

3. Das TGT wird mit dem geheimen TGS-Schlüssel verschlüsselt.

4. Der Client speichert das TGT und fordert automatisch ein neues an, wenn es abläuft.

Zugriff auf einen Dienst oder eine Ressource:

1. Der Client sendet das TGT zusammen mit dem SPN der gewünschten Ressource an das TGS.
2. Der KDC überprüft das TGT und die Zugriffsrechte des Client-Systems des Benutzers.

3. Das TGS sendet einen dienstspezifischen Sitzungsschlüssel an den Client.
4. Der Client stellt den Sitzungsschlüssel für den Dienst bereit, um den Zugriff zu prüfen, und der Dienst gewährt den Zugriff.

Kerberos-Authentifizierungsablauf in SWA

1. Der Client fordert über SWA Zugriff auf www.google.com an.

2. SWA antwortet mit einem HTTP-407-Status und bittet um Authentifizierung.

3. Der Client fordert ein Dienstticket vom AD-Server für den Dienst HTTP/SWA.domain.com mit dem TGT an, das er während des Domänenbeitritts erhält.

4. Der AD-Server validiert den Client und stellt ein Service-Ticket aus. Wenn das Ticket erfolgreich ist und der SPN der SWA gefunden wird, wird mit dem nächsten Schritt fortgefahren.

5. Der Kunde sendet dieses Ticket an SWA.

6. Der SWA entschlüsselt das Ticket und überprüft die Authentifizierung.

7. Wenn die Authentifizierung erfolgreich ist, überprüft SWA die Richtlinien.

8. SWA sendet eine HTTP 200 OK-Antwort an den Client, wenn die Transaktion zulässig ist.

Wozu dient SPN?

Ein SPN identifiziert eine Dienstinstanz in der Kerberos-Authentifizierung eindeutig. Sie verbindet eine Dienstinstanz mit einem Dienstkonto, sodass Clients ohne den Kontonamen eine Authentifizierung für den Dienst anfordern können. Jedes Konto in einer KDC-Implementierung, z. B. AD oder OpenLDAP, verfügt über einen SPN. Während der SPN einen Service streng identifiziert, wird er manchmal fälschlicherweise verwendet, um in Szenarien, in denen der Service auch als Client agiert, auf den Client-Namen (UPN) zu verweisen.

In Kerberos identifiziert ein SPN eine Serviceinstanz innerhalb eines Netzwerks eindeutig. Es ermöglicht Clients, die Authentifizierung für einen bestimmten Dienst anzufordern. Der SPN verknüpft die Dienstinstanz mit ihrem Konto, sodass Kerberos Zugriffsanforderungen für diesen Dienst ordnungsgemäß authentifizieren und autorisieren kann.

Konfiguration des Active Directory-Servers

1. Erstellen Sie ein neues Benutzerkonto, oder wählen Sie ein vorhandenes Benutzerkonto aus.

2. Registrieren Sie den SPN für das ausgewählte Benutzerkonto.

3. Stellen Sie sicher, dass keine doppelten SPNs registriert sind.

Tipp: Was ist bei Kerberos mit SWA hinter dem Load Balancer oder bei einem Traffic Manager/Traffic Shaper anders?

• Anstatt den SPN für den virtuellen HA-Hostnamen mit einem Benutzerkonto zu verknüpfen, ordnen Sie den SPN für das HTTP-Datenverkehrsumleitungsgerät (z. B. Load Balancer oder Traffic Manager) einem Benutzerkonto im AD zu.

Best Practices für die Implementierung von Kerberos finden Sie unter:

• Best Practices für sichere Web-Appliances 
• Firewall-Ports für SWA-Verbindungen konfigurieren 

Fehlerbehebung

Fehlerbehebung bei Kerberos mit SPN-Befehlen

Dies ist eine Liste nützlicher setspn-Befehle zur Verwaltung von SPNs in einer Kerberos-Umgebung. Diese Befehle werden in der Regel über eine Befehlszeilenschnittstelle mit Administratorberechtigungen in einer Windows-Umgebung ausgeführt.

setspn -L <User/ComputerAccountName>

setspn -A <SPN> <User/ComputerAccountName>

setspn -D <SPN> <User/ComputerAccountName>

setspn -Q <SPN>

setspn -L <User/Computer account>

setspn -S <SPN> <User/Coumputer_AccountName>

setspn -R <User/Coumputer_AccountName>

Beispiele für SPN-Befehle und -Ausgaben

Die angegebenen Beispiele zeigen die Verwendung:

• Benutzer-/Computerkonto: vrrpserviceuser
• SPN: http/WsaHostname.com oder http/proxyha.localdomain

Überprüfen Sie, ob SPN bereits einem Benutzerkonto zugeordnet ist:

setspn -q <SPN>

setspn -q http/proxyha.localdomain

Szenario 1: SPN nicht gefunden.

Szenario 2: SPN gefunden.

• Ordnen Sie einen SPN einem gültigen Benutzer-/Computerkonto zu:

setspn -s <SPN> <User/computer account>

Beispiele: 

setspn -s http/proxyha.localdomain vrrpserviceuser 

• Löschen/Entfernen eines SPN, der bereits mit einem Benutzer- oder Computerkonto verknüpft ist:

setspn -d <SPN> <User/computer account>

Beispiele: 

setspn -d http/proxyha.localdomain pod1234-wsa0

Stellen Sie sicher, dass keine doppelten SPNs für den virtuellen HA-Hostnamen vorhanden sind, da Fehler später auftreten können.

• Auszuführender Befehl:

setspn –x

Daher wird das Kerberos Service-Ticket dem Client nicht bereitgestellt, und die Kerberos-Authentifizierung schlägt fehl.

Vorsicht: Wenn Duplikate gefunden werden, entfernen Sie Duplikate mit dem Befehl setspn -d.

• Listen Sie alle SPNs auf, die einem Konto zugeordnet sind:

 setspn –l <User/Computer account>

Beispiele:

setspn –l vrrpserviceuser

Fehlerbehebung bei Kerberos auf SWA

Informationen, die der Cisco Support zur Behebung von Kerberos-Authentifizierungsproblemen benötigt:

• Aktuelle Konfigurationsdetails
• Authentifizierungsprotokolle (vorzugsweise im Debug- oder Trace-Modus)
• Übernommene Paketerfassungen (mit geeigneten Filtern):
  • Client-Gerät
  • SWA
•  Zugriffsprotokolle mit %m aktivierter benutzerdefinierter Formatangabe. Dabei muss der Authentifizierungsmechanismus angezeigt werden, der für eine bestimmte Transaktion verwendet wurde.
• Um detaillierte Authentifizierungsdetails zu erhalten, fügen Sie diese benutzerdefinierten Felder den Zugriffsprotokollen funktionierender/nicht funktionierender Proxys hinzu, um zusätzliche Informationen abzurufen. Weitere Informationen finden Sie unter Hinzufügen von Parametern in Zugriffsprotokollen.
• Navigieren Sie in der SWA-GUI zu Systemverwaltung > Protokoll-Subscription > Zugriffsprotokolle > Benutzerdefinierte Felder > Diese Zeichenfolge für Authentifizierungsprobleme hinzufügen:

server IP address = %k, Client IP address= %a, Auth-Mech = %m, Auth_Type= %m, Auth_group= %g, Authenticated_Username= %A, Date= %L, Transaction_ID= %I Auth response = %:<a, Auth total = %:>a;

• SWA-Zugriffsprotokoll für Details zur Benutzerauthentifizierung.
• Cisco SWA zeichnet authentifizierte Benutzernamen im Format Domäne\username@authentication_realm auf:

• Führen Sie die Einstellungen für den Authentifizierungsbereich über die Benutzeroberfläche aus. Navigieren Sie zu Netzwerk > Authentifizierung, und klicken Sie dann im Abschnitt Aktuelle Einstellungen testen auf den Namen Ihres Bereichs.
• Klicken Sie auf Test starten.

Server nicht in Kerberos-Datenbank gefunden

Ein häufiger Fehlerfall sind Web-Anfragen, die mit "Server nicht in Kerberos-Datenbank gefunden" fehlschlagen:

curl -vx proxyha.local:3128 --proxy-negotiate -u: http://www.cisco.com/
* About to connect() to proxy proxyha.localdomain port 3128 (#0)
* Connected to proxyha.local (10.8.96.30) port 3128 (#0)
< HTTP/1.1 407 Proxy Authentication Required
< Via: 1.1 pod1234-wsa02.local:80 (Cisco-SWA/10.1.2-003)
< Content-Type: text/html
gss_init_sec_context() failed: : Server not found in Kerberos database
< Proxy-Authenticate: Negotiate
< Connection: close
* HTTP/1.1 proxy connection set close!

In diesem Fall zeigt der Fehler an, dass der Dienstprinzipalname, der dem Proxyadressenwert proxyha.local entspricht, nicht auf dem Active Directory-Server registriert ist. Um dieses Problem zu beheben, müssen Sie überprüfen, ob der SPN http/proxyha.local im AD DC registriert und einem entsprechenden Dienstkonto hinzugefügt wurde.

Verwandte Inhalte

• Konfigurieren der sicheren Webappliance zum Zulassen des Gastzugriffs 
• Konfigurieren der Active Directory-Authentifizierung in SWA 
• Konfigurieren der Kerberos Single-Sign-On-Authentifizierung in SWA 
• Umgehung des Datenverkehrs in einer sicheren Web-Appliance